Last week I travelled to Wuppertal to participate in the community conference NRWConf 2013. With time cockpit we have been sponsors and speakers for this event for years. In this blog article I publish some photos from NRWConf as well as the slide deck for my talk about effort estimation in agile projects.

Photos

Here are some photos I took at the event. Click to enlarge.

2013-10-11 NRWConf 1 2013-10-11 NRWConf 10 2013-10-11 NRWConf 2 2013-10-11 NRWConf 3 2013-10-11 NRWConf 4 2013-10-11 NRWConf 5 2013-10-11 NRWConf 6 2013-10-11 NRWConf 7 2013-10-11 NRWConf 8 2013-10-11 NRWConf 9

Summary

Do Customer Really Want Agile Development?

Today many developer teams have embraced agile development methods. They love the approach because it emphasizes cross-functional teams, honest communication and equally distributed workload without crunch times at the end of a project. Additionally it allows them to be responsive to wishes of users.

Most customers like agile development, too. It allows them to learn throughout the project. They do not have to have all the good ideas at the beginning of the project. However, there are customer personas who often dislike agile methods. They often have a juridical background. Their job is to setup contracts with suppliers building software for them. They want to define the deliverables in such contracts, they want to define contractual penalties based on a strict time schedule, and they want to have a fixed price to reduce their risk. All these things contrast the principles defined in the agile manifesto. Such people love the waterfall model (or variants of it) because it gives them predictability (or at least it pretends it):

Lawyers Love Waterfalls

If you are writing software and you have to sell development projects to people who are primarily thinking in waterfall models, you often have a hard time. Their arguments are - at least on the first sight - convincing:

• The waterfall model is simple, logical, and easy to understand.
• Before you start to build something, you have to know exactly what to build.
• Agile development teams are just too lazy to plan. Emphasizing an up-front planning phase saves time and money and reduces risk.
• They will cite studies that prove that bugs found in early project stages are less costly to fix. This is why in-depth upfont planning is crucial.
• A detailed project plan is the basis for contracts. It helps to predict features, quality, milestones, costs, etc.
• There are well researched techniques for requirements elicitation and management that helps defining all requirements at the beginning of the project.
• Documentation of the requirements, the process, and the software is very important as it is part of the contract. Additionally, it makes the project independent of specific people/teams.
• If you failed with the waterfall model, you just didn't do it right. You have to work harder and more exact during planning. Show me how you start your project and I can tell you how it will end.

We could go on and on with the list of arguments you will hear from e.g. lawyers when negotiating a contract about an agile software development project.

Your Argument against Waterfalls: Reduce Waste

Ok, if there are so many arguments for waterfall-like project management, how can you argue against it? How can you convince your customers to give you a contract based on agile development principles?

• With waterfall-like methods, all good ideas must come at the beginning. A great idea in a late process cycle is treated like a threat. Does that really make sense? What about the "aha" effect when people first see and try project results? Best ideas often appear during first hands-on experiences.
• Written documentation only makes us only feel safe. Mostly it is just used to prove that we have worked hard. People start to focus on documentation instead of working software. Will the documentation really be read? Is it really complete (or just a lot of paper)? Come on, you waterfall guys. If you are honest you have heard things like “it feels that we are spending more time writing documents than producing software”. Can that be right?
• With waterfall we see the risk of delivering what has been originally asked for (“written in stone”), not what is needed.

• Times are changing. Economy is constantly changing. Planning (or guessing) what the future will bring is hard, if not impossible. Requirements often already change during (extensive) planning phase. There is a cost in being able to repeat in a world that changes fast.

• Waterfall methods are not much fun for a team. A rigid, change-resistant process destroys team work between development team and end users. It often is demotivating.

• Agile methods are not only for nerdish web 2.0 companies. Even the US Department of Defense prefers evolutionary approaches (Source: US Department of Defense, Acquisition Strategy Considerations, Wikipedia): "There are two approaches, evolutionary and single step [waterfall], to full capability. An evolutionary approach is preferred. … [In this] approach, the ultimate capability delivered to the user is divided into two or more blocks, with increasing increments of capability...Software development shall follow an iterative spiral development process in which continually expanding software versions are based on learning from earlier development."

• At the end of the day the whole idea of agile development is to reduce waste. We don‘t want to produce more than we really need. Without agile approaches, solutions often become too complex, too general, too extensible, … (over-engineering). The agile solution: Frequently reprioritize work based on business value.

Where Agile Shines...

If so many customers want waterfall and up-front planning, why don't we follow their wish? Stacey's Agreement and Certainty Matrix suggests an answer. I already wrote about this tool in a previous blog article. You can position your project in this coordinate system based on the level of agreement about requirements (Y axis) and your experience in the selected implementation technology (X axis). If your project is not in the lower left corner, the waterfall model will probably lead to a failure. You can visualize the reason why you want to go for agile. In my experience this is one of the strongest ways to convince a customer who has doubts about agile methods.

Strategic Goal: Move Your Projects to the Lower Left Corner

The matrix above is not only a tool for visualizing the character of a specific project. Entrepreneurs should use it as a strategic tool.

Customers love predictability and we should value this wish! They want to avoid risks and (negative) surprises.

We can help such customers by becoming experts in a certain domain and technology. As experts, we have a lot of experience in our field and it will be much easier for us to plan and estimate projects in our domain and technology. We can tend more to waterfall-like projects instead of having to be agile. The project turnaround time will be shorter and therefore the likelihood of changed requirements during project implementation is reduced.

In my opinion, software companies should aim to use economy of scope (not to be confused with economy of scale which is seldom relevant for software).

I have done quite a lot of talks about software factories and I am a strong believer that this approach is of great value for software vendors and customers.

Agile Does Not Mean Chaos

In my opinion, many customers hesitate from going the agile way, because many development teams pretend to use agile methods but work in a chaotic way instead. Here are my favorite myths about agile methods that you should not believe:

• Myth #1: Agile = Scrum
  There are many agile methods, Scrum is one of them. For time cockpit, we use Kanban for instance.

• Myth #2: In agile projects there is no planning
  „What XP teams find valuable is the collaboration, elicitation, and balancing of priorities in the planning act itself. The plans that result have a short half-life, not because they are bad plans, but because their underlying assumptions have a short half-life.” (Kent Beck, co-creator of XP)

• Myth #3: Agile means no documentation
  Remember the agile manifesto: “while there is value in the items on the right, we value the items on the left more”. Essential documentation is still valuable for customers, partners, and cross-team dependencies

• Myth #4: Agile means no up-front design
  Technical excellence and good design are key. However, value responding to change more than sticking to your original plan. YAGNI (You ain’t gonna need it) is dangerous if change is forseeable (see also Boehm B., Turner R.: Balancing Agility and Discipline)

Planning in Agile Projects: You Have to Establish Trust

Pretending that you have convinced your customer to agree to the agile approach, you will still have the need to plan your project. You will have to answer some of the magic questions like:

• How long will it take?
  You will have to provide a short-, mid-, and long-term project/product roadmap.
• How much will it cost?
  Your customer has to plan budgets and therefore you have to do the impossible: Estimate something without knowing what it exactly will be.

We have to be very careful when answering such questions, because we have to protect the most important asset that we need to sell an agile project: Trust. The truth is that we cannot predict the mid- and long-term future with a very high degree of confidence especially in agile projects. Essentially, we are asking the customer to trust us. An agile project is a journey that the customers taking together with the development team. Tell your customer honestly that you can only plan the near future in detail. Uncertainty rises for plans about the mid- and long-term future.

Remember the basic goal of agile development: Reducing waste. If you make in-depth plans about the mid- and long-term future, it is very likely that these plans will become obsolete. They will become waste - and that is exactly what we try to avoid. The following slide illustrates the idea:

Planning Tools

For planning in agile projects you can use specialized software, but it is not a necessity. I know a lot of teams who love their whiteboards for sprint planning. However, here are some tools that we use (or have used) for our project time tracking software time cockpit:

Slide19 Slide20 Slide21 Slide22

• Whiteboard
  We also love our whiteboards to discuss short-term project plans during product/project planning meetings.
• Microsoft's Team Foundation Services
  In our company we embrace cloud computing. Therefore, we use a combination of locally installed TFS with TFS in the cloud as our source code repository and build system.
• Atlassians Jira
  We prefer Jira over TFS for work item management, because of its awesome Kanban support and customization capabilities in the cloud. However, we have built interfaces between our Jira system and TFS in order to have an integrated system.
• Rallydev
  At very early stages of customer project, I regularly use Rallydev, another tool for agile projects. In my opinion it has outstanding feature for decomposing epic stories as well as effort estimation in early project stages. However, we prefer the tools mentioned above for day to day work.

Effort Estimation in Agile Projects

There is an endless number of books and articles about effort estimation in agile methods like Scrum. I don't want to repeat them in this article. If this is new for you, I would like to point you to a book that might be interesting to read for you: Lacey M, The Scrum Field Guide.

Whatever approach you follow for effort estimation, you always have to remember one thing: Don't lose the trust of your customer! If you communicate estimations, they have to be right most of the times. You can choose not to communicate an estimation, but if you decide to do so, you better try to fulfill your promise.

A very important tool in this regard is a well thought and agreed "Done" checklist. If you agree to finish a certain work item, you better make sure that your own and your customer's understanding of what "Finished" means, is the same. Otherwise you will be gambling away your customer's trust.

Having

• a list of todo items (=product backlog with tasks, stories, and epics),
• rough effort estimations (=story points), and
• data about your team's typical performance (=velocity, number of story points per iteration your team can finish),

you can theoretically do even mid- and long-term release planning. The following image from Lacey M, The Scrum Field Guide illustrates how this could work:

Are We Able to Predict the Future?

However, be very careful about predications of the future. It has been proven that we as humans are not very good in predicting the future. We typically overestimate our knowledge and underestimate coincidence. This brings us go the next topic: Some general thoughts about effort estimation.

I have covered this part of my NRWConf talk already in the blog article How Good Are Your Estimation Skills? It also contains the quiz that I did during my session. If you are interested in this topic, I encourage you to read this blog post. I don't want to repeat the content here.

After reading the blog post about effort estimation and taking the quiz, you might doubt about you estimation skills. However, you should not stop to communicate estimations generally. Instead, you should practice in order to get better (see also my blog article about Six Reasons for Time Tracking in Agile Projects). Additionally, you should try to identify the areas with a high value of information.

In many cases only a few variables influence your effort estimation model massively. Invest your time and money here (e.g. prototypes, feasibility studies, additional technology research, ask external experts).

• Trying to get more information is worthless if...
  • ...you are sure that it is either completely wrong or definitively right.
  • ...a wrong decision has no negative consequences.
  • ...you only have one option anyhow.
• It is only worth limited amount of time and money to get more information if...
  • ...you are rather sure that it is either completely wrong or definitively right.
  • ...a wrong decision has little negative consequences.
  • ...you only have a few options anyhow.
• You should invest time and money to get more information if...
  • ...the decision makers are very unsure (e.g. flip a coin).
  • ...a wrong decision would have severe negative consequences.
  • ...you have many options.

Can Statistics Help?

Well, yes and no. Statistics done right can be of great help. Statistics done wrong can be of great danger. Many people have learned basic statistics focusing on Gaussian distribution (aka Normal distribution) in school. Therefore they use this tool for project planning, too. While Gaussian distribution can savely be assumed for analyzing nature (e.g. size of people, weight of animals, etc.), it might be completely wrong in other areas.

Here is an example: One could follow e.g. Hubbard's Rule of Five: "There is a 93.75% chance that the median of a population is between the smallest and largest values in any random sample of five from that population" (Source: Hubbard, How to Measure Anything). This statement is perfectly true for a Gaussian distribution. One could now ask five people about their effort estimations about a certain project and conclude information about the project's effort based on the previously mentioned rule of five.

Such a conclusion could be very wrong. In software projects there is a natural minimum for the necessary implementation effort. On the other side there is an endless number of things that can go wrong. Additionally, we must not forget that we don't live in statistics, we live in the real world. So if you would really know that there is 95% chance that your project's effort will be below a certain border, this knowledge is not worth anything if the effort in your specific project exceeds all estimated budgets. Nice to know that there are many, many projects that are in a better situation. Your specific project could ruin your company if you signed a very high penalty clause based on statistics.

Project Reporting

The last topic I covered in my NRWConf talk was project reporting in agile projects. I have covered this topic in a dedicated blog post Project Reporting in Agile Projects.

Conclusion - Estimation Tips

• Agile does not work without trust

  • Build trust with honest communication

  • Importance of a „done“ checklist

  • Establishing a good project reporting practice is important and many teams struggle with it

• Agile project management does not eliminate the need for upfront planning

  • Build effort for engineering into your Product Backlog

  • Make sure that all stakeholders (including budget owners) understand the idea of agile development

• Learn to Say "I Don't Know“

  • If you have very limited data, try to resist the (internal or external) pressure to set estimation intervals too narrow

  • If you are forced to estimate, answer with a range where you set the interval wide enough

• Don't Do the Opposite And Always Say "I Don't Know“

• Evaluate Your Estimation Accuracy

  • „Software companies provide estimation training opportunities through their database of completed projects” (Jorgensen, 2002)

• Become a Domain Expert and Benefit From Economy of Scope

  • Try to withstand the tendency to over-estimate your ability to predict the future

• Be Prepared

  • Avoid penalties for late delivery that can ruin you.

  • Try to benefit from being unexpectedly productive, don't lose too much money if you run into unexpected problems.

  • Avoid agreements where you can win a little and lose a lot.

Slides

Here is the slide deck I used for my presentation. Sorry for mixing up German and English. I combined two existing talks for this session and by now I couldn't find the time to translate all the slides to English. 

comments powered by Disqus