Agile Fairytale - stories to express agile concepts

Agile fairytale is a neat way to express agile concepts in a way that is easily understood, using a context more likely to be meaningful or recognisable to a wide audience.


At the heart of Agile Fairytales are three fundamental concepts:

• Agile Values - Agile Fairytales extends the 5 Agile values of Communication, Simplicity, Courage, Feedback, Respect to include Trust and Transparency and applies them to real life
• People - Agile Fairytales is based on the belief that we can all change for the better
• Continuous Improvement - Agile Fairytales encourages us to improve one step at a time

A Creative Thinking Tool

Agile Fairytales uses simple narratives to structure the way we look at problems. Each fairytale is designed to give us insights into our experiences through a better understanding of ourselves.

When to Use Agile Fairytales

Agile Fairytales are useful in the following situations:

• As an icebreaker
• When creating a new team
• For improving the performance of team members
• As a game with friends and family

Interesting presentations from Agile2010

Here are some presentations I found from the Agile 2010 conference:

Business value modeling - agilecoach.com

QCon brainstorming night

Thanks to the hospitality of the QCon organisesrs, last nights QCon brainstorming session was a great event. As well as all the great discussions going on, there was a seriously generous helping of really nice food and what seemed a never ending supply of drinks.

QCon is a regular event aimed at those interested and engaged in enterprise software development.  The event aims to provide the highest quality presenters and most engaging topics each year.  Previously the QCon schedule has been organised from the input of those wishing to present, but for QCon 2011 the goal is to include ideas and recommendations from the community of people who pay to attend QCon when deciding on the schedule.

There was over 30 people that turned up and it was a great atmosphere. I turned up there early (no surprise) with a friend and we were greeted by our very friendly host, Jørn Larsen (on the far right of the picture).

The evening started with all of us grouped around a big table with lots of flipchart sheets and post-it notes.  As not everyone was lucky enough to make QCon 2010, we briefly discussed QCon and the different types of days and event that typically go.  Usually there are two days of tutorials before the main conference, with the conference itself having a large number of tracks each day (see QCon 2010 tracks).

For the brainstorming proper, we started creating lists of topics we thought would be good for the next qcon event and also identifying any speakers we thought were really good at presenting and generally entertaining the crowd.

I started the ball rolling by writing down some ideas, although half way through writing my first idea I had a feeling that everyone was watching me.  When I looked up everyone was watching me, but got on with adding my crazy ideas and this helped encourage everyone else to do the same.

Very quickly there was a wealth of ideas that came poring out and after I had run out of ideas myself I started writing down lots of ideas that people were discussing as them to make sure they were captured.

We also had a kind of retrospective sheet where we could put post-it notes on for things we wanted to see more of or less of, as well as things to start doing and stop doing.  The funniest comment I saw was to "Stop giving uncle bob martin a small room" - alluding to the fact that he is always a popular speaker and you cant always get in to see him.

All the flipchart sheets got stuck to the wall and we churned out dozens of sheets worth of ideas.  However, it all kind of got put on hold when the first wave of food turned up.  Yes, there was so much food that it did come in waves.  No one went home hungry and even I was too full by the end to want a doggy back to take home what was left.

There were lots of great discussions happening, its a shame we didn't record them for AppleTV!!  There was a continuing trickle of ideas added in between the food, drink and chat until the end of the evening.

Jen and his team now have a very busy few days going through all the weird and wonderful ideas that the group came up with, including all my Kanban, lean system thinking, rightshifting and continual improvements suggestions (I think there was a whole page just on those).  If even just a small part of the ideas we all came up with make it in then QCon 2011 should be a really great event.

If you want to know more about what may be appearing at QCon 2011, you can have a look at the tracks for QCon 2010. The most interesting ones for me were  Agile Evolution, Software Craftsmanship, Dev and Ops: A single team and Irresponsible Architectures & Unusual Architects

My favourite estimation technique

Here is my favourite estimation technique in action

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