Devolving to Waterfall (Part 1)

Patrick Agile, Coaching, Work Related

Context: A multi-part entry about how fast, responsive teams devolve into slower teams as a result of what seems like reasonable and completely rational decisions. I hope to understand when the turning points are and think about what other options existed, so I can either prevent them or turn them around in the teams and organisations I work with. I’m keen for some feedback so please email me (emailpat@[thisdomain]) or leave me a comment!

Imagine that one day, a business had a fantastic new idea to do something revolutionary. They manage to get a team of people together, develop some software for it and get it deployed. It’s a huge success, and the customers and business are happy. They work hard to get features out as soon they are ready (developed, tested and passing Quality Assurance) so that customers can use it as soon as possible. Daily deployments into production are the norm.

Things get bigger over time and the team starts to grow larger. The team can no longer keep up with the pace of requests and deploy the software as well, so they hire a “Release Engineer” who can deploy it instead. The team is ecstatic as they can focus on producing workable software, but then a manager turns around to see the Release Engineer sitting around. He says, ‘Hey, there’s someone who’s doesn’t appear to be working full time. Let’s get him involved on another project.’ To maintain order, the Release Engineer is only available to the team one day a week to do anything. Any new features that the team develops now take a week to appear instead of when the features are ready.

Lesson: Over-optimising locally affects your ability to respond quickly and effectively by adding waiting time to the cycle time.

Solution: Understand the system as a whole and don’t over-optimise. Generate solutions that might have been more effective (i.e. The Release Engineer works half a day on each project and can shift days about when needed).

Notes: I see this all the time at client projects when teams are split into their “functional” areas and need to juggle simultaneous projects about. Context switching constantly over email, IM, telephone and a person sitting there waiting for something to be done prevents them actually getting any work done.

Communication Channels

Patrick Agile, Coaching, Work Related

The way you choose to communicate with your team on a daily basis carries more than just the message you’re trying to say:

  • Finding time to talk to someone one-on-one that suits both of you tells them that you respect them.
  • Talking to someone in front of a crowd tells them that you trust them (note the difference of talking down to them).
  • Talking to them over the phone, or emailing them when you cannot physically talk to them shows that you care.
  • Emailing someone directly when you’re close enough to talk to them tells them that they’re not important to you.
  • CC’ing someone when you’re close enough to talk them tells them that they’re really not important to you.

Being More Effective: Principles and Practices that Just Worked

Patrick Agile, Work Related

At the end of the day, the best thing I really enjoy about agile principles and practices, is that they help us be more effective. I’ve been spending some time reflecting on previous projects and though I didn’t necessarily live and breath agile principles and practices at my previous company, I think I used a few of them to overcome other less effective processes.

At my previous company, at least on the project I was on, we had a framework team developing generic services for other parts of the project to consume. At one point, my manager asked me to complete a review for a new framework service that had been in “Design” for about two months. Being one of the consumers of the service, I quickly pointed out a few scenarios where it would not work and ended up joining the project to make solution a viable one.

Here’s a list of things that I think made it so successful in the end:

  • Just Enough Design – I found white boarding a very effective technique with my manager, who had much more experience to draw upon. We would use real world models talking through the algorithm until we were both happy with it. I would then go, code it and try it out – we didn’t bother documenting anything until we knew our solution was going to work.
  • Iterations – We had several “hang on, that’s not going to work moments”, so each time we would return to the white board, tweak the solution and when happy with the result, I would go back and try it out. We met almost daily (depending on how long it took me to code) to handle each new scenario, slowly tweaking the algorithm into an extremely robust one. We never let ourselves fall into Analysis Paralysis, trying to think of all the possible “hang on” moments when we knew we could progress.
  • Automated Tests – For each scenario we came up with, I would write equivalent JUnit tests to make sure that new enhancements didn’t break our existing models. I found that it was also nice to have feedback that was always honest with me. I worked some long hours and some weekends to get it completed in just over a month, and when you’re tired and not thinking things through properly, I could at least try things out, and know when I had broken things.
  • Using It For Real – I believe the real strength of the tests was that it was based on using a real model of usage. It was the same model we used during the white board sessions, and the mapping from code back into our discussions was really easy for talking over.

The end result of these was a fully working solution developed in less than half the time of what it took to produce a flawed “Design Document”. I find it assuring that you can make the most of these without having to classify them under “XXX practice”, and have to call the entire process “Agile”.

Test Driving Stockholm

Patrick Agile, Travel, Work Related

Test Driving Swing Example in Stockholm SwedenThis weekend went by far too quickly with a quick trip to Stockholm. All of Saturday was pretty much talking shop with a great bunch of agile-enthusiasts that I met at XP2006, who invited me to run a full day session of my Test Driving Swing presentation. I’ve run this session at XP2006 and Javazone this year and because it fits tightly into an hour I found it refreshing to run through it at a much slower pace and in more detail.

The crowd was just the right size to be interactive. I found it effective first taking their objectives and tweaking parts of the presentation to focus on the detail where they wanted. I even had time to run a retrospective that was beneficial to both the audience and myself – I got some useful feedback and the audience participated in their first retrospective, a tool some mentioned that they were going to try on their own projects.

For future demonstrations, I think I’ll avoid typing *all* of the code myself, or at least practice many times since I made a few silly mistakes (and I know that being tired [BA was supremely late arriving in Sweden] is no excuse). I think it would also be good to have a much deeper and more complex system that was completely Test Driven to the extreme as an example, though I know I will have no time to write it on my own any time soon.

I do have to thank the Agical guys for giving me another opportunity to run my session. We had some fun discussions over some wonderful meals and drinks at both MÃ¥rten Trotzig and Gondolen, both very excellent restaurants.

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

Patrick Agile, Coaching, Work Related

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

Patrick Agile, UK Life, Work Related

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