Huddle.net's Collaboration Blog

Developer thoughts on Agile process, cost and value

Posted on 24. Jul, 2009 by Rob in Development

I’ve recently been questioning a lot of things about Agile development and how we do it. But beyond more than just a development perspective as it affects the entire business. Are we doing it as best we can? Why can we never achieve the perfect agile set up? I’m not talking about dropping Agile in any way, just giving thought to some of the processes we have in place. Anyway, here’s a random stream of my thoughts.

Constantly Evolve Your Set Up

Agile is a development process that you tailor to your needs, starting from what we’re told it is (ie from books/consultants etc…), to something that you then evolve over time into what you suits you. It is a ongoing process. No sooner do you think you have it perfectly defined, then something changes. Motivation, output, value, cost etc… there are all sorts of reasons. The important point is that you should always be trying to achieve a better Agile set up. Change alone is a good way of keeping things fresh, and stopping things from becoming stale.

Don’t Be Afraid Of Change

As mentioned above, change keeps things fresh and stops the process from becoming stale. It also allows you to try new things. This is important otherwise you’ll never advance. Some ideas will work, whereas others won’t. For things that do work, it’s win-win. For things that don’t work though it’s not all bad, as it helps gives good perspective and something to compare against.

We for example are always changing not only teams (in terms of members), but also team size. Having large agile development teams was originally a pain for us, and changing to smaller teams was beneficial. However, over time small teams have now become a source of pain and we’re going to try switching back to larger teams. Often it’s not that either was right or wrong, it’s that the circumstances and environment have changed. Either way, a change in process freshens things up and can give renewed motivation. This highlights the point that an Agile setup can never be perfect and always needs to evolve, in some cases back to what it previously was.

How Much Does A “Point” Cost?

One thing I’ve recently been interested in, is how much a point costs to develop (ie from concept to being ready for deployment). It’s something (I don’t know if other developers can relate) I’ve not thought about much before. I work on a 3 point story, but have no concept of the cost of that story. It’s something you should have a concept of, and be working to reduce but it’s mainly to benefit the product owner. If your business has no concept of how much a point costs, then it’s probably developing in terms of priority but with no sense of cost, which is a dangerous way to work (unless your someone like Google with truck loads of cash).

• Over a number of iterations you can work out the cost of a point by working out how much your team costs against the number of points they are getting done.
• The product team will have stories estimated, and using these estimates can gauge roughly how much a story costs to develop based on the number of points.
• And from this cost they can ascertain the value of the story and judge its worth and priority in the backlog.
• Often as a developer it’s easy to forget the process mentioned above. Everything should have a reason and a value. That goes right down to upgrading a piece of technology (like upgrading to the latest version of NHibernate for example).Does it have any value? And are you doing it for yourself, or with a business benefit in mind?
• When points start to become too costly, then it’s a clear sign something is wrong. Maybe there’s too much process, or point estimation is deflating. It’s a sign that you need to sit down and review things with the team.

Achieving Value In Terms Of Output

This is a little bit more tricky. In Agile there is a focus to work on things in priority order, and that a team should be dynamic and can switch in and out of roles. In the real world this doesn’t always apply. From my experience it’s about achieving a balance. Moving people into different positions is a good thing, but it shouldn’t occur all the time. It’d be like taking Wayne Rooney and playing him in goal each week. Maybe for one week it’s beneficial as he’ll learn something new, but you wouldn’t always want him there as he’s not as affective. You wouldn’t be getting as much value from him.

• So it is good to put people into other roles as it builds a more complete team, but you have to do so carefully as you compromise output (at least in the short term), which in turn increases cost as you are completing fewer points.
• Keep in mind that the highest priority stories are the most important. In many cases it comes down to good planning and taking on a range of stories that your team can achieve. Taking on all UI stories when 3/4 of the team is back-end based for example wouldn’t achieve a good output.
• Sometimes you have to sacrifice some high priority work when selecting stories for an iteration, and select stories that may not be as high in priority, but allow greater output and potentially more total value.

Linking Related Work

Another concept of achieving value is to link related work together. If you have two stories that touch the same code, and require similar testing, it’s more beneficial to do them together, than to do them separately. This can be tricky when doing Agile though, as you’re not supposed to know too far ahead in terms of the development plan, nor be developing things you don’t need just yet (or may never need). The further ahead the less specific the plan should be.

• A good example is, I notice a live bug when working on a story that is relatively easy to fix. When testing the story, it’ll cover 2 out of 4 test scenarios for the bug. For the additional 2 test scenarios, it’s worth fixing the bug. It means you’re not working on a priority story/bug briefly to test those additional scenarios, but it’s a quick win and adds value.
• To achieve this you and your team members need to be quite switched on and aware of the product, and what is coming up in the short to mid term. It’s easy as a developer just to focus on the iterations as they come, but you really need to make sure you look ahead.
• Reviewing the backlog, and thinking ahead during estimation means you can “bargain” with the product owner to include additional work for a little more effort, but a lot more value than doing the two pieces of work separately.
• When you notice stories overlapping note it down. Noting it down is another blog post, but for the sake of simplicity, that could be a story comment, or link in one story card to another, using categories as a property of a story etc…
• Be aware of risk when taking on additional work, it boils down to good judgement if the additional work is easy to develop and test without impacting the current story, or commitment of the iteration.
• One thought I’ve considered when stating our commitment for an iteration is to allow a little slack. Maybe give a figure 10% less than we know we can do. That way it allows us room to be flexible, rather than fearing the thought of taking on additional work because our workload is already full to the brim.

Thoughts? Opinions?

Tags: agile