Category: Agile

What things in your day add value to the end product?

Something that add values…

Three people with different sets of skills (application developer, server administrator and release engineer) all looking at what could be causing an issue that manifested itself only in the production environment at release time.

In contrast with something that doesn’t…

A manager not involved in the release, sitting over everyone’s shoulders while they’re trying to understand the issue, reminding them to record the time spent against the estimated times in the plan and all the other paperwork.

Lean Presentation Retrospective

The End ResultA couple of Saturday’s ago, the UK office of Thoughtworks ran an internal conference that we call an ‘Away Day’. A work colleague of mine, Tom Scott and I presented a workshop titled Lean at Large: The Value Stream Map. Our goal was a tough one to fit in an hour, with a fundamental aim of giving people experience at value stream mapping and drawing some conclusions from it. Thanks to all the people that came along and participated – we certainly got some great feedback and more importantly we hope you got something useful out it.

We spent some time first talking briefly about lean theory, its relevance to software development before talking more about the wastes in manufacturing and production and their equivalents in software development. We gave an example of how you would leverage a value stream map highlighting system wastes, and then how you might analyse it to gain the most improvements to your system.

Game InteractionsThe next part of our session was more hands, with four volunteers acting out different roles using lego to create a car production line. The other observers broke into groups to observe and map out their value stream maps. Based on feedback notes we handed out and what people said to us after the session, I think most people found it fun and energising for such a late session in the day. Some peopel found it relevant and useful and some others could immediately see parallels in the game to the ways things operated on their current projects or current work environments.

Since we believe in continuous improvement, here are specific actions we will be doing for the next time we run this session:

  • Creating handouts that summarise the wastes and more examples about those you might see in software development.
  • Spend some more time explaining how the game will run and what is expected from each group
  • Run through some more example value stream maps and lean principles before starting the exercise as well as reinforcing them at each iteration.
  • Run the entire session for a minimum of two hours so that people have a chance of implementing one or two changes to see how it affects the entire value stream.
  • Give groups some stopwatches so they can measure how much time is spent on each process
  • At the end of the exercise, draw more parallels with the example production line to a software development project.
  • Potentially expand the complexity of the game with additional roles or constraints for each role

Top Tips With User Stories

Last night I heard Mike Cohn speak about Agile Planning and Estimation. Mike’s a great speaker who I highly recommend to you seeing, but you may know him from his company, Mountain Goat software, or his book, User Stories Applied.

Though I’m lucky enough to practice many of the items he spoke about, my most favourite emphasised points of the night included:

  • Focus on accuracy over precision;
  • Avoid measuring items that are more than a magnitude apart; and
  • Measure size over duration.

Different Approach to Planning IT Projects

I find it interesting to see how most businesses plan for IT projects. The most common approach is for the business to get a set of proposed projects together, but get IT to cost them. They then decide on which one to do based on this input and what benefits are talked about and estimated costs.

When I see the costing process, I see it as heavy weight – lots of predictive plans with lots of magic weighting and theoretical costs. Worse still is that it sets the expectation that the cost is actually predictable when, in reality the detail you get and what it cost you from the original plan are far apart and you just spent a bucket load on this additional lengthy process (the estimate starts to become a promise).

Choosing Paths

An alternative I propose is a lighter weight approach with businesses focusing on what they want to do and not what projects a particular group within the business proposes. It’s more important to focus on the business problem first and the implementation details last so that both are aligned as closely as possible. After identifying what the business want to do they should next define how much they would like to spend. The amount needs to be feasible and measuring existing project costs and benefits and getting IT involvement is definitely required. Magic numbers plucked from thin air are never useful but do need to be balanced in terms of value maximisation and technical feasibility.

The focus for the project implementation should also be different from traditional methods. The focus should no longer be ‘keep to the plan’. It should instead maximise the value the business gets while keeping aligned with the business objective. Agile projects provide a great way of doing this by splitting down the detail into chunks that have identifiable value, getting the business to continually identify what is valuable in relation to their business objective and then getting the value faster and earlier than a big bang approach.

I’d love to hear what you think about this so please drop a comment.

Feedback as Feedback

Regular heart beat retrospectives are a useful tool for measuring how well the team is going. As someone responsible for project delivery, you want to maximise the amount of honest feedback you get (both positive or negative) as they all might pose risk to the project.

The amount of feedback you actually get is a useful indicator rating the team’s comfort level – either with each other, or with other people they report to. I’ve seen a number of feedback sessions stifled by one or two key people that sit inside the room, as people withhold their opinions for fear of negative consequences. Controlling people typically disengage individuals from the team and reduce the effectiveness of feedback you get. Uncomfortable silence or a minimal set of feedback are both signs that people may not be entirely comfortable.

Splitting the group into smaller teams might help to improve individual’s openness, introducing a speaking token so that one person is not always talking or even asking someone to leave is a last option.

Fun with Agile Projects

Dancing SnoopyThe feedback I’ve most recently received on my latest project is how fun it has been. This enjoyment factor is common feedback I get when working on projects with agile values and practices. I do not think this theme is exclusive to agile projects but I definitely think it is more common.

I believe that projects run in this manner are a result of the Agile Manifesto statement of ‘Individuals and interactions over processes and tools’. A result of working closely together and striving for a common goal breaks down the focus on the individual and succeeds in building a fully functional team.

Why you should care as a Project Manager or as a Business Person?

Enjoying your work has a number of effects on the way that you work. I believe studies have disproved that happiness positively impacts productivity, but I believe that in the long term it still has a positive effect. More importantly I believe studies have proved that happiness positively affects staff retention.

If anything, my own opinions are that it works to reduce the overall risk of the project as each person builds on each other’s strengths and contributes positively when someone is at the low in their peaks and troughs. The similar alignment between all team members also leads to people improving the project in different ways because they want the project to succeed and not just because of individual motivations.

Note that working in this manner is not necessarily comfortable for all people but it’s usually because people have built up their own social barriers in order to work effectively in more traditional environments, or they don’t like working in teams.

XP2006 Day 3 Short Summary

Final day. More highlights include:

  • Entertaining keynote with Kent Beck talking about what is more Extreme than XP, and leading on to the discussion about the Responsible Developer. Like XP, his talk focused more on the developer role in an organisation but talked about what comes next.
  • A fun two-part workshop with Rachel Davies and David Hussman talking about Agile Project Parameters where we brainstormed and dicussed the questions we might ask as an agile coach during a Project Chartering session.

XP2006 Day 2 Short Summary

I’ve been having troubles posting things to my blog due to Internet access here, but this entry was written just after Sweden and England drew in the world cup (equivalent of midnight here in Finland), so here’s the recap of today’s goings on:

  • Barry Boehm’s keynote – An interesting discussion in which he discussed different analysis models that could still be used in agile, considering risk management and balancing agility and discipline. He talked about the scaling of agile to scrum of scrums and research indicating where agile is most applicable.
  • Panel of Notable Agile Leaders including (Angela Martin, Rachel Davies, Jutta Eckstein, David Hussman, Emmanuel Gaillot, Mary Poppendieck and Michael Feathers) holding a fantastic discussion on Politics and Religion in Agile Development. A lot of the advice they gave and their own ‘war stories’ struck a chord with me so much in my experiences and different projects I’ve worked on. It was great for them to all be so honest and give their opinions. Kudos to Angela for being an excellent moderator for the session!
  • Value Stream Mapping – An excellent exercise with Mary Poppendieck, involving identifying waste in an entire value chain (i.e. when a customer requests a features and they are using it), and more interestingly the strategies or areas of focus for particular project examples.
  • Coder’s Dojo – Coming half way through this session, I still had lots of fun with this hands of workshop presented by Christophe Thibaut and Emmanuel Gaillot. We did a bit of dynamic language group pairing adhering to a small set of well defined rules that I found fascinating from many different perspectives, most especially the social one.
  • Final keynote by Jack Jarvik discussing methods he applied in the early 1990s that appear aligned or similar to many of the XP/Scrum practices.

What can I say, but what another fantastic day?