The Hungry Ant

The quote below was taken from railsstudio.com and gives a nice succint description of how a company that has embraced agile should feel like.

“Our approach involves on-going customer collaboration, complete automated testing, and iterative delivery (weekly demo releases). Our approach to Risk Management is to complete the highest risk tasks as early as possible. We believe in built-in quality. Testing is multi-level and automated. The code base is non-redundant and normalized (no duplication). We welcome (and request) frequent Customer functionality reviews and accept ongoing requirements changes, and improvement. Our design is feature driven, domain focused, and evolutionary. Iterations are each focused on delivering features of greatest current value to the Customer. “

I know most of the world knows this.

But firstly, if you are not using Source control like subversion or git then you should be! Even if it is just one developer.

Secondly, when you commit something to the repository add a comment. It may seem like extra work, but there will come a time when you need to revert your code and you need to know which file to revert to and that little comment will make a massive, massive difference.

Commenting is even more important on distributed teams, as it may be that a team member is not available to clarify something, and that comment might give you the little clue that saves you time and helps you understand the intention of the change.

When trying to work with an agile philosophy it is extremely important that you have the confidence to allow you to improve the code easily (refactoring). This usually means writing tests. Having a strong testing culture from the outset allows you to feel confident to change code in the face of new requirements and learning. Without them, very rapidly your team will start to shy away from changing a certain piece of code and start to build in workarounds.

I liken this process to work-hardening of metal. At some point without tests we have brittle code that is inflexible and easily breaks. Testing allows the code to stay soft and malleable and lets us change code without fear.

I notice often with developers that are new to agile methods that they are scared to touch the code that has already been written and I have to encourage them that with tests we shouldn’t have fear.

I like the practice of refactoring often, sometimes a little bit here and there as I come across something that could be improved. I find this to be an easier way to keep the code “soft” than to just have a refactor session.

Testing also offers us other benefits in terms of better interfaces, more robust code, a form of documentation and a means to know when something is done.

A good product manager needs to understand all parts of the software product development process. Interaction design is one of those disciplines that I find hard to explain to people and an area that I am focussing on to increase my skill set. This book was brilliant and gave me a new way to look at those brilliant apps (like google mail and flickr and lightroom) and the thinking that goes on behind them.

About Face 3 focuses on designing highly interactive apps from the perspective of fulfilling user needs and describes a number of techniques and guidelines for how to achieve this. The book has an increased relevance for web applications as the diffusion of easy Javascript libraries like JQuery and RIA technologies like Flex and Silverlight are blurring the boundaries with desktop applications. Highly recommended.

A sprint in agile speak is a period where the team gets down to working. It is a space where the team knows exactly what it is working on and changes are ideally not permitted. This is because we want to move away from constant interruptions and attempt to build momentum. Typically these interruptions may come from the boss or from salespeople or from a client. They may be just be saying something off the top of their heads and not realise the impact this can have on the team and the work done.

A sprint normally lasts 1 to 2 weeks.  At the start of every sprint we take the product backlog and with the product manager decide what stories are the most important. The stories will be estimated with a complexity in points (more on this later). The team then breaks down the stories into the specific tasks that need to be done to finish the story. These are then estimated and the team works out how much time they have for that sprint and commit to completing that number of tasks in that sprint.

These tasks are placed in a sprint backlog. The team now works on these tasks and knows what they need to do and will not have any interruptions. Any interested parties can see progress on a daily basis.

The sprint provides  a simple change management process. At the end of the sprint we can review what we have and can change priorities and add or delete  tasks. Normally a change is never that important that it cannot wait a week or two. It provides a mechanism to increase productivity while accepting change.

The team have now worked on 2 sprints. The first we tried for a week and we found that it was too short, the second for 2 weeks and this seemed much better. The right balance between organising what we do next and time to actually work. The second sprint we accepted 15 points worth of work as we had 15 days of time. We did 5 points of work and we actually had 12.5 days of time. The next sprint we have taken 6 points of work for 12.5 days and divided the tasks into high and low priority.

We are making progress…

Running a startup is difficult. Running a startup without a clear product vision is even harder. It means that things can change all the time, the team works on tasks but they don’t really understand why. I will be looking to extract these visions over the next few weeks. Just a paragraph or two to describe what we are trying to create.

• Don Norman's jnd.org / Why doing user observations first is wrong
  Determining user needs should be part of the product opportunity assessment and usability testing part of the agile process. Design should be iterative once user needs have been established.
  (tags: agile usability design norman)

A product backlog is a set of the all features that could possibly be implemented for the product. But a product is not just a repository of features. I am a big fan of people and companies like Marty Cagan of svproduct and also 37signals that really get to the point that less is more. The quicker a team can decide on the product’s core purpose and the user need it should fulfill then the easier to prioritise work and to get something out there.

Following some good advice from Marty Cagan that I have also used on other projects, I have asked the team to create some high level objectives for the product based on the old product requirements document. We ended up with a list of 10 high level objectives that we have put in order.

The objectives are of a short form and as an example if we took a project like the BBC iplayer, a core objective for me would be “A viewer can watch a show immediately online”. Interestingly the first forms of the iplayer were not able to fulfill this. The iplayer is now a big success as it fulfills this top level goal through using streaming.

So we now have our top level objectives and this has provided us another tool to organise what goes into our product backlog and how to order it. What I tend to ask is “what is the minimum product?”.

After asking this question, the team have stopped working on a number of features, have reorganised the backlog and are concentrating on getting those features finished and live.

If we were co-located I would look at visualising this roadmap and putting it on the wall, but at the moment it will suffice on a wiki and I will look to review it during the retrospectives.

My goal when introducing agile into a company is to initally provide visibility of the activity that is going on and increase communication.

Very soon after starting to introduce daily meetings and getting my head around the different projects I started looking at the requirements documents for the various projects.

What I found was a document that had been written but was not complete, that was a mix between technical architecture document, a requirements document and a design document. There was no order to what needed to be done and it was difficult to understand what the product was trying to achieve. The document was also written once and hadn’t been updated for a while.

This basically meant that most of the decisions made on who should work on what and what they should do was very unclear. In fact it seemed that the project had started a lot of features but hadn’t completed hardly any of them. Which was obviously causing frustration. A lot of direction was given by voice and would change often.

The product backlog serves to help in this situation and I wanted to introduce it quickly. By taking the requirements document I created a list of user stories that described the functionality required. It was fortunate for this project that I understood the domain quite well so could make a first pass without much difficulty.

My aim was to pull away from the technical aspects of the requirements and try to present the requirements in terms of how the system should fulfill a specific need for a specific type of user. I will not go into the details of user stories here but will leave it for another post.

At the end I had about 50 or so first pass stories that I felt represented the requirements in the document.

In order to not present anything too heavy, I stayed away from web based agile project management tools and just used a google spreasheet, as everyone understands a spreadsheet and it is easy to order.

I then asked the project owner to order this list and to define what would be the minimum set of functionality that we could release with.

The beauty of the product backlog is that it lives, it can be changed, new things can be added and we have a record of all the features that we would like to develop (note the “like” here, there is no commitment, as it depends on the product vision and roadmap).

So the group now has a tool where we can say what we should work on next and for capturing new thoughts while allowing the team to focus on what they should be working on.

Introducing this has been extremely easy. The team were in desperate need for knowing what to work on and the need to get something out of the door, so I have had no resistance to adding this process, which is really great.

The next step is to work on the product roadmap and to get the team to define a sprint backlog.

I am very pleased to say that the team are really embracing the daily meeting and it is now never lasting more than 20 minutes. It feels like the team are appreciating the conciseness of the meeting. This has also come about through the fact that as the meetings are so regular we have less and less to say as we only need to cover the last 24 hours. We still have a few mic problems but they are sorting themselves out and are not a hindrance.