Empower the Team

I have stumbled yesterday on this presentation given by Linda Rising at QCon SF 2007: “Perfection Is An Unrealistic Goal”.

It underlines the impedance between how humans are hardwired to work (in ~90 min focused sprints followed
by a 20-30 min break) and the prejudices haunting our workplaces (where productivity is associated with
longer hours without any break and agility means people can interrupt each other at any time).

You can have me but cannot hold me;
Gain me and quickly lose me.
If treated with care I can be great,
And if betrayed I will break.
What am I?

Could it be … Agile ?? No, but was close enough. It turned out to be Trust.

as presented in one of Patrick Lencioni’s books – “The Five Dysfunctions of a Team”:

Poor results in software industry suggest there is something in the way… at what level ?

The definition of SMART on You Learn Something New Every Day blog:

Sufficient Vocabulary
Major Goals
Appropriate Timeframe
Right Examples
Trusting Partners

vs

SMART as used in software develoment projects:

Specific
Measurable
Achievable
Realistic
Time-Bound

Trust, big picture, ubiquituous language, proper examples seem to be second hand concepts for the software develoment world… and that’s because… software developers are WIZZARDS !

I am currently working for a company that is trying to implement an agile process. We have 2-week sprints, daily stand-ups, backlog, burndown charts… but each sprint we are struggling to deliver.

Thinking about the way we are developing, I have suddenly remembered a picture in The Neglected Practice of Iteration (Jeff Patton) that illustrates the difference between incremental and iterative development. Considering the story as our deliverable, we used to split it in increments (tasks). Each developer picked up a task (increment) and worked on it until it was DONE. Integration took place not long before the end, when there is just not enough time left for accommodating feedback from the QA and the business. The amount of work to be done in the last days of the sprint was simply overwhelming.

During a retrospective, we have agreed to take another approach: tackle each story in several iterations. For each story we identify the story backbone (essential functionality), additional features and aspects on which the business has not decided yet. The story backbone is addressed in the first iteration while additional functionality, business rules, UI special features are dealt with in further iterations. We are tasking out for each iteration, therefore tasks are much shorter. Each iteration involves TDD, continuous integration, deployment of perceived functionality and feedback from QA and the business. An iteration is DONE when the QA and the business consider the delivered functionality meets their acceptance criteria. This approach ensures early and continuous integration and feedback.

The advantages are immediate:

1. Enforces development discipline as it requires a proper Continuous Integration environment.

2. First iteration ends early in the sprint, usually within the first 2 days.

3. Provides constant feedback as the QA and the business can test the implemented functionality from the first days of the sprint.

4. Improves communication among team members: the team works in parallel on small bits of functionality and frequently integrates the work.

5. Improves team morale as there is a constant delivery of functionality.

6. Delays implementation of complex/open business rules and special UI features, as these are more likely to change.

7. Reduces waste by keeping QA busy and reducing bottlenecks through frequent integration.

We have applied this approach in our last sprint with promising results. There were some external factors that have influenced our previous sprint and it is hard to accurately estimate the impact of the approach. It does not depend exclusively on the development team… we need the business involved in the feedback process to drive our work. However, I hope this approach will be validated soon in our sprints.

There is a growing interest today in Agile ways to develop software. There are many approaches that gather some principles under a label and then try to prove the new approach is better than the Rational Unified Process (RUP). I think that any approach that includes some of Lean Software Development principles is better than RUP. However, it is hard to say which Agile approach is better than the others.

I know there is no silver bullet and each organisation should find its way in being agile. Only principles that make sense for an organisation should be employed. But which principles ? Lean or Agile ? To answer this question, I have grouped in one table both Lean and Agile principles, as they are described on Poppendieck’s site and in the Agile Manifesto.

Analysing the table above, I have noticed that the set of Lean principles includes the set of Agile principles. What I find interesting is the form these principles are expressed in:

- Lean: very schematic, using just key concepts

- Agile: more detailed, sentence based.

It reminds me of university years when you go to courses and take very detailed notes because everything seems important. At the end of a semester, with an overall picture of what you learned, you could draw a comprehensive and compact schema containing everything worth knowing.

Agile principles look like my student notes, while Lean principles look like that schema you can draw after you get the overall picture. There is a difference in maturity. Lean has been successfully applied in manufacturing since the 80s. Its principles have been refined over the years to retain only what is worth knowing. Agile is still young and looking for an identity.

Agile emerged as a movement to improve software development. Agile approaches proved to be better than waterfall approaches by applying a subset of Lean principles to software development. However, all Lean principles can be applied to software development, as the Poppendiecks are explaining in their books. Therefore, Lean Software Development seems to be a better Agile approach, because it brings into play everything that proved to work in manufacturing.