Category Archives: Agile

Chicken, Shut Up!

Posted by Eli Shalom on

In this post I’ll try to explain why it’s better not to accept changes or new tasks during an iteration. The trigger for this post is an experience I had a few weeks ago. I worked on a very interesting project, it’s a project with short iterations and a daily demo. The client is amazing – smart, responsive and very creative. The client acknowledges that not everything is known in advance and many changes are expected along the way. So far, so good. However, there is a downside – the involvement can make the feedback loop too short – as feedback gets translated into tasks within the same iteration.
The goal of agile development process is to deliver products in constant throughput, respond to changes and get to the final release with well working software that provides the exact value the client needed. In order to do all that both parties must stay realistic and take the right risks.

What’s required for efficient development?

Estimations

One of the nice ideas in agile is the iteration plan. During the iteration plan the client gets to tell what’s the most important features, the developers get to ask for details and finally estimate how much effort the feature requires. Since iteration plan includes all the developers planned to work on the features, all get the chance to contribute their point of view about each feature. The points of view are what’s the best way to implement (perhaps base the code on existing solution), they can talk about risks (this feature influences the performance, requires redesign, etc.), when everybody is well involved they point on more missing details in the specifications. All these allow us the reduce the risk – we get better effort estimation and we know better if we should expect side effects.
When a ticket is added during the iteration, it’s planning gets less focus – it is either gets planned by less team members or it gets planned by developers who do it while being distracted by the task they’re already in. The result is usually the we get less accurate estimations.

Focus

We all know that in order to get better software we need better code. With better code we have fewer bugs and easier maintenance. A very well known way to achieve this is having the developers code in “the zone” for as long as possible. Being in the zone requires understanding the problem, finding a solution and being able to incrementally implement it. All agile flavors have a good way in getting the developers in the zone. The idea is same – separating concerns. There’s a defined period of time devoted to non-development tasks, like iteration plan, demos, etc. The rest of the time is focused on development, which is known to us as iteration, sprint and so on. During this time the developers get to work on a predefined tasks, tasks which they had a chance to think about for spec (with the client) and technically (during effort estimations). If the developers are required to step into a mini-phase of planning in the middle of the iteration, the thinking mode must go back to planning mode. This is very likely going to cause a loss of focus which leads to less efficient development.

Priorities

This is the simplest part and the riskiest. It is clear that most software being built is limited by real world constraints – money and time. Since we can’t get all the features from the backlog done on the first iteration we prioritize. This means that out of a set of relevant features, we pick the most important ones. Using this simple rationale we get to maximize the value of the developed software. What happens when a feature sneaks into the iteration? Usually it doesn’t really go through the usual prioritizing mechanism. Mostly commonly the reason for adding a feature is either it looks like it can “seal a feature” or it can solve some local problem. Both reasons provide value, but none promise to maximize the value.

What we lose by silencing the chicken?

The chicken clearly wants the same as the pig – software that meets the user’s needs. The chicken has several ways to help – provide feedback, collect requirements and prioritize. When we force the chicken to stay quiet we limit his ability to provide feedback and re-prioritize. The lack of feedback can lead to work being done for nothing (like change in feature). The lack of ability to prioritize during iteration can lead to a very important feature which was just “discovered” pushed to the next iteration instead being implemented now rather than a less important feature.

Summary

The way of deciding on the right thing to do is by expectation. We know that breaking an iteration has its price, we also know that silencing the chicken has its price. To get the right balance, we should choose only either tiny tasks (e.g. changing label text or the color of a UI element) or essential tasks whose lack is going to make an ongoing tasks redundant. If the importance is arguable, then adding it to the iteration has a high chance of requiring an excessive amount of effort. Usually, the possible damage from putting it off is negligible since we’re not abandoning the task forever, just moving the discussion about it to next iteration plan.
In the long term, using these guidelines also helps the chicken in two levels – firstly by having more realistic expectations. Secondly, they lead to more focused rational planning by always looking at the big picture of the backlog.

Advertisement

Agile means a release is ready today

Posted by Eli Shalom on

The trigger for this post is an interesting experience I had during our weekly demo. I led the demo and made the client worried. This demo had a positive side – only a few crashes, our system had stability problems during the previous phases. Being able to work with almost no exception is great progress. So far, so good. The downside was that we had to set the environment at some points during the demo, like:

  • Run a script to fix the registry
  • Watch the task manager to ensure it’s done processing before sending new request
  • Delete local DB between sessions
  • …

It repeated itself during the last few demos, it annoyed us – the developers and it definitely annoyed the client. The result was a request from the client to change the architecture. This is rarely a legitimate request, the client asks for features, for a “demoable” value. Architecture and design should not be the client’s concerns. This helped us learn important basics about the demo: how did a demo with such progress made a client so worried?

The purpose of demo

A demo has two parallel purposes, they can exist side by side, but it’s crucial to know which one each demo serves:

Feedback for new concepts

This is clear characteristic of demos of new products. The client has a hard time telling what the exact features are that solves the problem the product is aimed for. In this phase, the developers are in charge of demonstrating how the initial ideas “feels” in real life – a POC the client can interact with. The POC phase is important in the product lifetime. In this phase the features must be perceptible, but not perfect. The ideal result of this demo is a client decision on whether the feature is good or not – should it be thrown away or should it go into the product?

Show the value the product provides

Hopefully, this is the characteristic of most demos. These demos give the client a close view of the development progress – the client knows what value the product provides. At this point decisions can be made – use the new value (like selling the new version) and choose the next important value the product should provide.
Choose wisely – which purpose this demo serves? Defining before the demo what it is supposed to achieve is crucial.

When should we choose?

The answer is easy – before the iteration plan. The reasons are clear: For a POC the least possible should be done, the feature may not be part of the product and there is no need to put effort there at this moment. For a progress demo, a feature will be planned differently – coding will take longer (this is not a throw away code – refactoring, unit-testing…), satellite tasks will be required (like installer, licensing, etc.). In this iteration the feature will require more tickets, so it must be planned accordingly.

How to choose?

If there’s confidence that the feature is what the client wants in the product – plan an iteration in such a way that the feature is in the product and it’s “productized”. If there’s a doubt, plan in such a way the feature will be demoable but with as little effort as possible.

What is done

“What is done” is important in a demo that shows the current value of the product. Then what is done? The answer is very simple: The product can be released right after the demo. In these demos there’s a simple but important guideline – perform the demo on a neutral machine from an installed version. Meaning – running the product from the development IDE on a development machine is not good enough.
If the demo’s purpose is to show what the client can use, show the client what can be used. The client can use only what is already “productized”, so if the feature is not part of the installer, it doesn’t help. If the feature is not linked to the license, it doesn’t help. If the feature crashes and constantly requires workarounds, it doesn’t help.

Bottom line

All developers know how to achieve a successful demo. The problem is identifying the next demo purpose. Before planning the next iteration, be clear about the iteration “What is done”. One of the things which could cause a failure is acknowledging the product passed the POC phase and it’s a real product (This is where we failed this week). A good parameter for moving between the phases concluded from the question “when will users use it?”.
After identifying the demo’s purpose, plan the iteration accordingly and make sure the demo fits its purpose.