The Hungry Ant

We are currently developing a new product and are busy analysing all the data we have gathered from interviews and statistical data to create our personas.

My aim as a product owner (in my agile hat) is to arrive at a product backlog that has user stories that are fine grained enough that we can estimate how long things will take. The problem is that often it is difficult to get to the this breakdown as we lack information.

A natural fallout of creating personas is that you often have a set of large stories that describe how a user will use the product. This is agile speak is called an Epic and can then be broken down into smaller chunks for estimating.

Storyboarding is a powerful, tried and tested method of thinking about epics and I like to work with the interaction designers to visualise the Epics. This way we are also thinking about the interface and the interaction which is the next phase for the interaction designers anyway.

The storyboards are quick sketches that I will then breakdown into a set of user stories that can be estimated and hence be actually developed.

So an epic maybe something like:

“George wants to choose where to go on holiday as he has two weeks off at christmas”

which may breakdown to

“George wants to search for a beach holiday because he needs some sun and sand”

“George want to go from the 12th to the 30th of June because that is when his holidays are”

…

I will also add Epics to the product backlog but at a lower priority while they need to be expanded with detail.

When organising a sprint I would advise that there are only one or two goals. Sprints are not very long and by having few goals the team is never in doubt what needs to be done. It is also satisfying to think that something substantial has been completed. It improves motivation and projects seem to move along faster.

If the team is trying to do 5 big goals divided over 5 sprints it is better to do one goal at a time. It means you can also release early, keeping customers, stakeholders and teams happy.

I tend to write the sprint goals when doing the sprint planning meeting and have it visible next to the sprint backlog. This way everyone is clear on what needs to be done.

I place a lot of importance on retrospectives, especially at project close. All projects have good points and bad points and it is important to learn from them so that the next project benefits. Retrospectives also provide the team an official closure and isolate problems to the scope of the project.

Project management processes like Prince 2 find this so important that it is a key phase for all projects.

If you are thinking of having an end of project retrospective, I recommend reading Agile Retrospectives. It provides a list of patterns for running retrospectives, whether at the end of the project or  sprint/epic. My particular favourite is the “Timeline” method for analysing a project. I have had great success with this as it provides an obvious and simple way to gather information about the project and it helps people focus on what actually happened.

Here are some tips for running a retrospective:

• The key skill is to manage the behaviour of the group and to keep the group to analysing the facts and not starting a blaming session.

• Warm people up by starting with introductions or a game. Some people are louder than others, your job is to help everyone be heard, this helps their tongues loosen.

• Have house rules for behaviour during the retrospective, and see that people stick to them.

• Follow a structured approach to extract data, like using the “Timeline” technique. During this phase try to avoid analysing until the next phase. This part is hard as the group wants to talk about the most pressing issues straight away. Although common sense is required.

• As long as you know the group well, keep rolled up pieces of paper to throw at people (gently) if they start deviating from the rules. It seems to help lightens things up when it is needed.

• If there are any action points as part of the retrospective, make sure that they are documented and that someone in the group takes responsibility for each action with a deadline.

• Have a fixed time for the different sections of the retrospective.

• Make sure that you write up the retrospective within a couple of days and circulate while the points are still fresh in people minds.

• Take a digital camera for taking pictures of the timeline and all the materials like post-it notes and pens.

I have been reading “Agile Estimating and Planning” and there is a chapter where Mike Cohn mentions about taking a breather sprint which resonated with how I have been feeling on our current project.

When you are sprinting along in an agile project sometimes it is a good idea after 5 or 6 sprints to take a little 1 week breather to let the team reflect on where they are in the project and maybe do refactorings and look at the product from a distance. Sometimes it is not necessary, but if as a product owner or scrummanager, you notice that there is need for a break, don’t be afraid to take some time to reflect. Sprinting can be quite intense and can feel like you are on a treadmill (especially with 1 or 2 week sprints) so a short refactor/reflection sprint with no planning can be a great idea.

This week is one of those weeks…

The question has come up about whether to refactor in big sessions or whether to refactor a little bit at a time. I definitely prefer to refactor as I go along. Fixing little things as I see them. The reality is that if you wait for the “Refactor Session”, firstly it means that for a sprint you are not producing value to the client and secondly the code has been allowed to get into a mess which then needs this big clean up and is much harder to know what to refactor and how to tackle it.

I guess it is a bit like waiting to clean the dishes until the sink is full or washing plates as soon as they are dirty. The first way means you have a dirty sink and plates that end up with dried up food on it (and a reluctance to go near it), the second way means you always have a clean sink and plates are easy to clean. As I have moved away from my student days I realise that the second way is the better way. And so it is with code

If you find a bug in your code, make sure that you write a test to produce that bug, then write the code that makes the test pass. This way you will always be sure that the bug will never appear again.

Due to our distributed way of working, where we meet in person infrequently, we have been having sprint reviews at the end of our sprints and immediately follow with a sprint planning meeting. This is efficient on time but really does not allow much time to react to the information presented, adjust the product backlog and decide on the tasks for the next sprint. We have also not been allocating enough time for the meetings, leading to poor task definition for the sprints.

On larger projects I have successfully had sprint reviews happen on a different day to the sprint planning meetings, giving adequate time to the product owner to make last minutes changes to the backlog and the team to have a pause before ramping up for another sprint and to give estimates to tasks. But in our case it would be impractical.

The sprint planning meeting is not an easy meeting, it takes mental effort as the team are collectively solving technical problems upfront around what to do and how to do it. It is not a meeting that can be done in a hour. For a sprint review and planning ensure that adequate time is allocated, that the product owner has thought about the product backlog before the meeting and that there is a pause between review and planning.

Comments in code can seem useful but they add noise and they get out of sync with the code. When writing code, I think it is better to use less comments to explain what you are doing and to focus on making your code more readable. Use understandable and descriptive method and variable names, even if they are reeeeeaaalllly long.

If you have a long method where you need a comment to explain a subset of functionality, think about creating a private method with the subset of functionality and give it a name that says what it does. You will quickly find that you don’t need the comment, your method is easier to test and easier to understand.

Of course, if you have some insanely tricky algorithm then maybe a comment is worth adding, but I would first suggest if there was a way to make the tricky algorithm less tricky.

When you are splitting a user story into tasks for the sprint backlog, it is better to keep the tasks small so that they can be completed in a half day or day. It is normally easier to break down a task into smaller tasks and it creates more of a flow in the sprint where there is constant satisfaction in tasks being completed and progress being made. I certainly notice the difference when we have lots of small tasks.

The focus of the team at the moment is to introduce a testing framework to all our projects. Although I don’t think you can be agile without testing, the team were not forced into adopting testing but were gently encouraged when it was obvious that testing would resolve a certain suite of problems. From experience, it is far better when introducing a new process like agile, that the team decided to take on a change through need, rather than it being forced on them.

For example, we are working on Drupal web project that has a complex permissions system. This basically requires a developer to check that the system works for all the configurations every time there is a change to the system. As Drupal is mainly configuration programming, a quick change can take time to verify by hand and is error prone. By introducing testing we can automate these tests and improve project development speed, reduce bugs and move to developing iteratively and then introducing functionality on the basis of what we can actually see working.

Coming from an OO agile background, I find the configuration programming nature of Drupal not my technology of choice, but it is undeniably a very powerful system with many modules already developed, and if you understand it you can develop a complex site, of a certain flavour, very fast.

For Agile it brings it own set of problems and we are slowly trying to resolve them. I hope to write about how we are doing agile development with Drupal for a later post when we have ironed out all the problems. But I guess my main problems are how to test and how to iteratively add modules to the production system while not losing data. Problems I am sure that there are solutions for but that the team needs to resolve.

For testing, We have decided to use Selenium for testing our system as we are not programming as such,  so our tests are actually integration tests and need to work through the browser.  Selenium allows you to write test scripts in many languages that are then played through various browsers. It is not perfect but I haven’t found anything that works better yet.

I don’t like sprints where we are not producing functionality to the client, so we are dividing the sprint into some new functionality as well as improving our our agileness.

For the other project where we are developing in c++ and python, as it is a library, our lives are a lot easier as they are more typical development projects with good test frameworks (we are using BOOST and Pyunit) and the team are very close to having a good test suite that will allow us to start improving and refactoring the code.