alacrity in action
| Tags: , , ,

If you ever ventured in the direction of Lean in you software development journey you have probably heard about flow. If you read about Kanban and had a go at using it, you looked very carefully at how your work flows. You would have read perhaps that your work should flow well.

Flow is not a natural term we are necessarily used to though, unless we talk about water. In the early days it’s intuitive to equate flow and speed. It’s the easy conclusion to make when adopting our fluvial experience. So it often comes as a surprise that we are also advised to slow down in order to improve flow.

It certainly felt counter-intuitive when I first come across the idea. Even after having read more on the subject, while cognitively it became clearer, my intuition was still in denial. Until I could experience it first hand in reality.

Few years ago I used to drive from Newark to Nottingham. The journey was pretty straightforward, took about 45 minutes and run something like this: drive a single carriageway A46 for few miles, turn right at the Saxondale roundabout, through Radcliffe with a 40 mph limit and then a dual carriageway to the Nottingham ring road.

After a few years elsewhere, I found myself driving to Nottingham again. I was more worried this time though, as serious roadworks already begun to upgrade A46 to a dual carriageway and with them a 40 mph limit where you could previously drive 60 mph.

I fully expected for my journey to take longer. On the first day, I left home early to add some extra contingency and found myself arriving way too early. I thought I have simply avoided the morning peak. On day two similar thing happened. I started setting off slightly later and still arrived on time. I checked my timing, it turned out I was doing the journey in under 40 minutes.

How could this have been if there certainly weren’t fewer cars and I had to drive more slowly for most of my journey? It turned out a lower speed limit helped improve the flow. Remember the Saxondale roundabout and a limit on the road right after it? It was a bottleneck on that road. As cars now approached the bottleneck more slowly it didn’t clog up so much. The queues on the approach visibly shortened, reduced waiting time and thus my total journey time.

Today the A46 upgrade is almost completed. I no longer drive to Nottingham. The surprise, the experience and the realisation that slowing down really does help go faster is still here and has now become part of my intuition. I have seen it work in IT many times since.

| Tags: , ,

Starting a new piece of software development work can be tricky. It often requires a non-trivial financial input to fund the work of all the required professionals such as analysts, developers, testers, and any other who might be needed. Typically, at the beginning, there is some business plan which, once approved, kicks off analysis effort. Eventually specification for a bunch of features for the new product is presented and development starts.

The business case makes several assumptions, many implicitly. There may be an idea, for example, about how the users will behave with the new system in place or that other products won’t undermine its position. Those are rarely verified later. The document also outlines potential benefits (thats the case element) which seem only to serve in the approval process. Once the money is granted nobody is there to follow up (see also Simon’s post:¬†Business cases are in the eye of the business sponsor). This is perhaps one of the reasons anticipated improvements or savings are not expressed in a clear and measurable way as rarely they are the tracked or even used to keep development work on the right path.

The lean startup philosophy takes a different approach. Following this attitude we have recently started a new project at Energized Work with a day-long chartering exercise attended by the energised team and our customer. It included the entrepreneurs pitch, presentation of personas, the product charter focused on the following 8 weeks of development and clarification of high level user goals.

We used the A3 technique which has its origins at Toyota and is based on the PDCA (Plan-Do-Check-Act) cycle thus a great tool to provide input into development before it begins and feedback from subsequent releases. This approach proved very effective at focusing our thoughts and guiding us through the day.

Picture of an A3 Charter whiteboard We have started with a blank whiteboard divided into the following sections:

  • purpose – key reason for undertaking the work
  • background – existing market and opportunities
  • goals – we hope to achieve by completing the work
  • constraints – limiting our options, budget being the key one
  • assumptions – identifying explicitly what needs to be tested, in priority order
  • users – a list of personas and what is of value to each of them
  • success criteria – how would we know we have done well – including specific measurements and expectation

As the day progressed we went through each of the secions, focusing our exploration with regular pomodoros. By the end the board was full and we all had a much better idea of what we needed to build and why. We now had the essential context for the many decisions we no doubt will be taking with the customer as we discover more while building the product. With our assumptions explicit we were all encouraged to challenge them and ensure they still stand. All brought together created a reference guiding us to build the right thing with every story delivered.

It is important to note the scope of the exercise – not focused on building a nebulous “complete” product but on creating a validated beta within the first investment period that will, hopefully, meet our clearly stated expectations. At that time, equiped with our A3 charter and together with the customer, we will be able to reflect on progress and achivements and decide whether to proceed with the work with another tranche of funding.

The day was also a worthy investment for yet another reason. We have now had specific and measurable sucess criteria with exact values against them (listed in three columns under expectations as: measure, unit, expected value). Im sure Tom Gilb would approve.

Now the development could truly begin.

It was a refreshing and inspiring experience to be part of. It made me realise, how many projects I worked on before, were essentially crawling in the darkness. How often their positive outcome was not as carefully planned for as it might have appeared. How, inadvertently, we had to rely on gut instinct of a few key individuals and serendipity. What real opportunity were missed as teams were floundering. No, I wouldn’t want to go back there.

| Tags: , , ,

First, there was the volcano in April and some speakers couldn’t make it to Atlanta so we had OpenVolcano 2010. This was just an appetiser. Today was another tasty bite, a conference at Bletchley Park organised by Karl and Rachel (to coincide with Agile Coaches Gathering), with a bunch of great presentations initially destined for Atlanta.

The day was nicely concluded by Eric’s talk adapted on the fly and a quick fishbowl session.

Some of the recurrent themes I picked upon, were:

  • visualising the work
  • understanding how the work works
  • understanding the product
  • importance of creating good relationships with all people involved, identifying all stakeholders
  • integrating IT as part of the organisation (not them v/s us)
  • small, small and small – defying the complexity
  • getting quick and frequent feedback, closing the feedback loop
  • code is inventory not until it goes live but until it goes live and delivers value
  • flow – making sure the work flows cleanly and there are clear exit criteria
  • continuous learning by running deliberate experiments and collecting feedback
  • the PDCA Shewhart (Deming) cycle

Kanban is becoming increasingly popular, useful and adaptable as a tool that help visualising the system and thus  facilitating learning and creating a shared understanding.

The main challenge still remains with over-engineered organisations that are bafflingly refusing to embrace the lean goodness defending the status-quo.

Thanks to the organisers, the sponsors, presenters and all the great folk from the community. It was a day well spent.

Presentations and podcasts should be available on Skills Matter website.

  • 08:30-09:00 – Registration and Coffee
  • 09:00-09:45 – Karl Scotland – A Kanban Multiverse
  • 09:45-10:30 – Eric Willeke – Value Stream Languages
  • 10:30-11:00 – Coffee
  • 11:00-11:45 – Simon Baker & Gus Power – Product Development in the Land of the Free
  • 11:45-12:30 – Damon Morgan – Learn to Lean: Becoming a Lean Startup
  • 12:30-13:30 – Buffet Lunch
  • 13:30-14:15 – Benjamin Mitchell – Using Kanban to Get Knowledge and Continuously Improve
  • 14:15-15:00 – Liz Keogh – Behaviour Driven Development: Learning as a constraint
  • 15:00-15:30 – Coffee
  • 15:30-16:15 – Mattias Skarin – Converting A Scrum Team to Kanban
  • 16:15-16:30 – Close