Lean or Agile - understand and use both - wisely

The term agile evolved to encapsulated the principles behind software development practices such as extreme programming, scrum, DSDM and other iterative and incremental approaches. Lean has been around a lot longer, (possibly a great deal longer - Chinese Emperors) but has infrequently seemed to gather momentum in software development until recent years.

On the surface that there is a great deal of commonality between the two approaches. For example with Agile, teams focus on doing enough work to get the job done whilst leaving options open, to help managing the inevitable change with less pain and risk (eg. failing early). This agile practice could be viewed as minimising waste, a lean concept, but do most agile teams have the opportunity to understand that they are minimising waste and the implications of doing so?

Agile processes all seem to have a common plan-do-check-act core with there approach. This is interesting to me as that is exactly how I have started several personal Kanban boards. However, those personal Kanban boards just happened to fit that simple value stream and usually evolved in to a more continuous feedback system for work.

Also a scrum board and a Kanban board can visually look very similar, but have a different context and approach, usually have different values and different outcomes. I have seen (bad) scrum boards that look like a micro waterfall process to a prince2 project manager, with all the same problems. A good Kanban board has values derived from the wider organisation that subtly change how that board is used to bring about a very different outcome.

There are many shared or similar principles at play with both Lean and Agile, especially as we learn lessons from applying lean approaches to software development, perhaps the differences are most evident in the goals and the values driving the practices a lean/agile team adopts.

As the goals and values defined will vary depending on the organisation, the overarching principles of both lean and agile can be used as a common framework for guiding teams and organisations to become a leaner and more agile machine (within the limits of their capacity for organisational change).

Effecting organisational change with agile practices alone is a very difficult way to achieve a positive change, borrowing goals and values from Lean broadens the context of your practices so that the organisation moves closer to working as a whole and therefore sees the wider value of organisational change.

In summary, believing that Lean and Agile is the same when applied to software development seems to be a high level view and misses out on the deeper and richer aspects that lean system thinking helps promote.

Then you have the concepts behind a learning organisation that extends lean and agile even further.... but that's another discussion.

Why use scrum (or any other agile process)?

Scrum is a process framework for creating your own agile process, meeting the goals of your particular organisation.  Some aspects as to why you would use scrum (over some other non-agile  or non-iterative process) are as follows:

Managing risk and change effectively

• By using small steps and quick feedback (tests, customers) errors from misunderstandings are quickly addressed.
• Focusing on the most valuable and most risky aspect of the project up front reduce the cost of failure and therefore give a greater understanding of risk in the project. 
• Leaving options open until the last responsible moment (avoiding big up front design) reduces the risk of wasted work and helps facilitate change in line with the business goal.  Architecture evolves instead of being fixed / ridged

A light touch of order to the chaos

• Defines principles to aim for rather than cold dogma
• Defining a flow of work and the roles and responsibilities to manage and maintain that flow
• Organising without stifling the creativity or variation that increases value of the work

Faster time to market

• By releasing functionality early and often, feedback is greatly increased and real understanding of what is needed is quicker to arrive.
• As work is done in small self contained pieces it can be created and delivered quickly

Improved quality

• Defects are discovered and tackled early by including testing aspects and only software needed by the customer is developed

Improved stakeholder satisfaction

• Stakeholders (customers, testers, developers, ba's, etc) have greater involvement and influence in the product development and therefore have more affinity to the project.

Greater employee engagement

• Involved in the whole process & decision making activities giving them a greater understanding of the value of their work

Higher productivity and lower costs

• Only building what's immediately needed reduces the waste of developing things that are not wanted.  
• Smaller code bases should on average have fewer bugs, so writing less code is more productive.

This is by no means an exhaustive list of reasons to start agile adoption (with scrum or similar approaches) but give you a flavour as to the aims and benefits of an agile way of working.

Take a look at my scrum overview for more deals of the aspects of scrum.


Quotes about Kanban

@agilemanager Funniest comment on my talk, "I don't want to be the girl w/ a reputation for always saying 'yes'" ;-) @llillian #lkbe10

Summary of the agile manifesto principles

Regardless of the processes and tools you put in place to become more agile, you should take time to learn and instill the principles of agile to help you understand what you are aiming for.  Reading and understanding the implications of the agile manifesto is therefore a very valuable start, although it is just a start of a very important change.

Here is a quick summary of the agile manifesto to get you started:

• Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
• Welcome changing requirements, empowers business to adapt at its own pace.
• Deliver working solutions frequently, continuous feedback - working software is the primary measure of progress.
• Business and developers work in concert throughout the project (breaking down that divide)
• Build projects around motivated individuals, trust them to get the job done.
• Conveying information with face-to-face conversation.
• Maintain a constant pace indefinitely - sponsors, developers, and users.
• Continuous attention to technical excellence - good design enhances agility.
• Simplicity - the art of maximizing the amount of work not done
• The best architectures, requirements, and designs emerge from self-organizing teams.
• Team focused on continuous improvement.

See the Manifesto for Agile Software for more details

Robert Martin - why tdd is important to a languages survival

This morning I watched a really great key note from Robert Martin (Object Mentor) about how test driven development is very important to a language, not just in terms of writing clean code but as part of an professional approach to project delivery and relations with the wider industry.

In summary, Smalltalk was an amazing language but its community built walls to keep out the rest of the industry and did not accept that they needed tools to keep their work maintainable through testing (TDD).

I hope you enjoy this 1 hour keynote as much as I did: RailsConf 09: Robert Martin, "What Killed Smalltalk Could Kill Ruby, Too"

Six thinking hats - a collaborative thinking system

Edward de Bono devised a simple thinking system called 6 thinking hats which defines how you can approach a problem without descending into argument.

For a long time we have always used argument as a way of discussing ideas and looking for solutions, however argument is very inefficient as its mainly negative and attacking.  The argumentative stance can lead to point scoring and antagonism between the persons discussing the idea, leading to a break down in communication.

With the 6 thinking hats approach, people are thinking in the same direction for a short period of time.  This same direction thinking, often called parrallel thinking, is highly collaborative and productive.  To cover all aspects of the problem, the direction of thinking changes but everyone changes thinking at the same time, maintaining the collaborative nature of the discussion.

This approach helps to open up the topic in discussion and helps avoid any narrow thinking.  When considering a problem from these 6 different perspectives you are more likely to establish a robust solution to that problem.

My typical approach is to start with the blue hat to define the objective of the discussion, followed by the white hat to cover all the facts regarding the subject matter.

I perfer to cover the positive thinking before critical thinking, so would follow with the green  hat and yellow hats to establish a list of ideas and benefits.

I would then finish off with the red and black hats to help focus on what could practically be achieved and what the team feels is the general approach.

There is an interesting Knowledge Gene on 6 thinking hats for an agile retrospective.

Getting started with BDD and Kanban

I am starting writing entry points for getting started with BDD and Kanban, now that Blogspot lets me have pages on this blog.

On the BDD page I have done a quick mind map using Freemind in preparation for the BDD immersion workshop with Liz Keogh on the 26th Feb.

On the Kanban page, there is a quick intro to KanBan and some pointers on how to build a KanBan board and the artefacts that you could add to make the board more expressive.

These pages will evolve as my understanding and experience grows.  Any comments or ideas for these pages are very welcome.

Acceptance-test driving development by John Smart

A summary of the Acceptance-test driving development talk presented by John Smart, principal consultant at Wakaleo Consulting - held at Skills Matter by the Agile Testing user group on 11th February 2010:


Acceptance testing is a a key agile practice, especially in practices such as behaviour drivend development (BDD) and test driven development (TDD).

The main benefit of acceptance tests in agile are not the tests themselves, but the ease in which they allow people to commuicate.  The language of the tests is expressed in the business language (industry domain) usually in a simple to understand structured natural language (often with spreadsheet style tables for typical and edge case data examples).

As the tests are expressed in a business language, they can easily come from the business (customer / product owner).  As the language used to write the tests should be universally understood in the team, it is easier for the whole team to work collaboratively on them.

Using the Given-Then-When structure of BDD, the acceptance tests are also in the perspective of the user.  The tests focus on what the system does and not how the sysem does it (as was mentioned previously at the last agile testing talk by Gojko - this helps keep a seperation between the acceptance tests and the details of the code written).

Acceptance tests are executable!
EasyB, Fitnesse, JBehave and Cucumber are examples of  tools that allow you to execute acceptance tests very easily.

Being able to run the acceptance tests at the drop of a hat is a very powerful way to determine when a feature has been implemented in code.  The tests can generate (html) reports as well as being integrated with continuous integration systems eg. Hudson CI and web testing tools such as Selenium.  All these tools can be integrated as one build process, so when code is checked in or acceptance tests added, every aspect of that change is managed.

How far do you go?
Acceptance tests are very inefficient to debug your code, as are testers and coders.  Finding bugs is wasteful, preventing bugs is much more effective.

When writing acceptance tests think in terms of a story, a happy path of how the system would be used.  Then elaborate your tests as you become more in tune with the users of the system (users also include other systems)

By writing acceptance tests in terms of what the system should do, avoids those tests becoming a lag by having to refactor your acceptance tests for code changes.

Please review the slides and the video from the event for examples of using EasyB and how easy it is to use the BDD style language of Given-Then-When for writing your acceptance tests.  Also, visit the Agile Testing user group and get involved in the agile testing community. 


I would encourage to you to visit the Skills Matter website for lots of upcoming talks on agile testing, BDD and many more excellent topics.  I am attending a BDD workshop on the 26th February by the formidable Liz Keogh, I recommend looking this course up if you are interested in learning BDD effectively.