Navigating Difficult Times

I chose the word "navigating" deliberately. The current economic climate is very difficult for many people and companies throughout the world. And chances are that you are affected in some shape or form as well.

It appears that no 'rule' that worked in the past applies to the current situation. Is that really true? I think it doesn't really matter. The important bit is that if you carefully choose an approach that lets you quickly respond to whatever is waiting for you around the next corner then you will be better off in all likelihood.

Some people and companies still try to come up with a grand plan for how to go forward. And as long as that plan is really more like a description of the direction and the principles to be used I think that is fine. But what good would it do to you if you would spend planning time right now on what you would be working on in 12 months time if all that matters is what you are going to do next month, three months from now, or six months from now!

Respond and adapt. Do both as quickly as needed (but not faster!). Instead of locking down your plans for the next 12 months use rolling plans (a planning tool, actually), e.g. for the next 3 months or for the next 6 months. Then update these plans on a regular basis, either monthly or triggered by new relevant information that warrants a revisit of your plans. If your plans cover 3 months they are much easier and faster to adapt to new insights than plans at the same level of detail that cover 12 months. Trying to update plans that cover a larger time frame tends to result in a lot of waste.

Navigating these difficult and uncertain times is definitely easier if you choose an approach that allows for much faster response and adaptation to the changing environment. At the same time you will be much better off once your markets start to improve again.

No More Iterations?

Here is an interesting thought: What if we could make iterations so short that each "iteration" contains only one story? What if we drop the term iteration altogether once we are there?

How would the development approach look like? Wayne Allen describes in his post what he tried with his team.

What would be the benefits?

Well, you might not need to think again about how to assign engineers to teams. Just create you teams once and then give each of them a board with a backlog that has a small number of slots. Once the team has finished one story you can add another one.

You can save the iteration planning sessions thus saving valuable engineering time.

By measuring how many stories each team can process per time unit (think nano-projects?) you might get to the point that you have a metric that you can use to measure through-put.

I haven't tried it yet, but it looks like something I would want to take a closer look at.

Monitoring and Tracking Projects

Need a template for monitoring and tracking your project? Here you go. We have created a simplified version of the tool we are using in our projects, too. The spreadsheet is prefilled with a sample backlog for a hypothetical project. It assumes sprints of 1 week and a release cycle with 12 sprints.

The template includes graphs for the actual velocity and a burn down graph. If you have questions and/or suggestions for improving the template please use the contact details at the Agile Utilities web site.

Oh, and here is the most important link, the link to Agile Tracker. And of course this template is free.

Impact and Mitigation of Staff Turnover

In my last post I explored the reasons for staff turnover. Reasons can be monetary (e.g. salary) and non-monetary. In all cases the departure of a team member has consequences, some of which may become visible months later.

Example. For one release cycle a project team signed up for a backlog of 70 stories. Two weeks into the release cycle (12 weeks in total) the team got together and identified a few stories that were too large to fit into one iteration (1 week). As a consequence the backlog grew to 80 stories. The team asked the customer to re-prioritize the stories to identify the low priority stories that would have to be moved to a future release. Not surprisingly, the customer wasn't happy about this as it was perceived as "falling behind schedule". On closer investigation it turned out that the initial backlog contained stories that were too big for acceptance. These stories should have been split or re-scoped before the release cycle started. The person who would have spotted this had left the company just a few months ago. Other team members weren't sufficiently aware of the impact large stories could have. The team learned their lesson and it is unlikely that the same mistake will be repeated.

The important lesson to be learned is: The consequences of the departure of a staff member become apparent only as time passes, and sometimes this can be much, much later.

How could the mistake from the example be avoided? I think that it is important to re-emphasize the rules of the game as often as possible. You might sound like a "broken record". But consider the consequences if you don't repeat "the tune"...

The example also demonstrates that when a team member leaves, some knowledge and skills disappear as well. What are the options to mitigate the impact?

Agile methodologies provide quite a few techniques and tools that you can use. In particular all techniques and tools that foster communication, collaborations, and learning are suited to reduce or mitigate the impact to a large degree.

Release planning involving a good cross cut of different roles - developers, testers, customers, performance experts, technical writers, etc. - ensures that all relevant aspects are considered. Techniques like Agile Auction (aka Planning Poker (TM)) help to detect uncertainties or the need for further discussions.

Frequent reviews help to identify over- or under-engineering. Do you really need all these bells and whistles? Are the features implemented in a really compelling way?

Techniques and tools like Pair Programming, wikis and Show-and-Tells help fostering knowledge transfer and the acquisition of skills.

Keep it simple and try tons of different tools and techniques. Don't give up just because one tool or technique didn't work. If it didn't work, try something else. Learn from your observations. And always challenge your team for instance by asking questions like:

• Given this unsatisfying result can you think of a way how we can prevent a similar situation in the future?
• Given the suggested approach, can we think of an even better way of doing this?

Experiment and try new approaches. Doing that you'll have mitigate a large proportion of the possible impact of turnover.

Cards Or Planning Tools?

In one of the newsgroups I monitor there was recently a discussion on Project Planning and Tracking Tools. I'd like to add another experience to this.

In a project for which I started coaching earlier last year, I introduced index cards for stories initially. People looked at it as something very "unprofessional". Paper and pen? How could that possibly work?

Well after a while the team decided that they wanted to introduce XPlanner. After yet a while some customers on the team decided that they were not exactly getting what they were asking for. As a consequence they started to put more details into the tool. Sometimes there were a lot of details even for how to lay out widgets on a screen and what colors to use. Screenshots of mock-ups were eventually added.

Yet another while later the team discovered that this didn't really help. Now the stories were very big and therefore hard to put into a short iteration. And the bigger they were the higher the likelyhood that they were underestimated. An extreme case was a story that was estimated at 47 units but which took 228 units in the end to implement. It actually consisted of a sequence of four stories.

It was clear to them that they had a problem. Now they have reverted back to using index cards. Writing or even drawing on an index card limits the amount of information you put on it. The team decided that the best and most important information on a card was the business value that the completed story tries to provide.

Having less details on the cards themselves has triggered more and better conversations or negotiations between the customer and the engineers. More options are discussed and it is much easier to move storie around. Estimation is better, and the geam gained more flexibility with regards to how to implement a story.

Bottom line: You might have an excellent justification to introduce a software based planning and tracking tool. But sometimes it is better to just go using simpler tools. If your team is co-located you certainly have more options, but even for distributed teams it is worthwhile to look for alternatives. Simple tools may lead to simpler and better solutions.