Organistations

Back in October I attended a very thought provoking talk titled “Why Agile Transformations Fail (and what you can do to prevent it…)” by Gez Smith at Agile Tour London.  Gez hosts a podcast at WhyAgileTransformationsFail.com which is a collection of interviews exploring the title of the blog.  He has a great cross selection roles impacted by agile transformations from Developers, Agile Coaches to recruitment consultants. If you have time to listen to the interviews, I would recommend downloading the podcast.  The talk at agile tour London was made up of a number of quotes from the podcast that highlight some themes and challenges to implementing agile in organisations.

Episode 6 of the podcast, an interview with Andrew Horn, is particularly interesting for me.  Andrew talks about the failure of organisations and some of the root causes of failure.  He argues that even profitable companies can be on the verge of failure when we consider market disruptors and the impact of organisational rigidity on innovation.  He introduces the Fractal Model for organisations.  You can read more about this model here.  There a number of parallels with Agile ways of working and in particular the moving of delivery responsibility to those closest the customer/user.  I particularly like the example of Traffic Lights and Roundabouts.

This brings me on to a great book that I would highly recommend.  Reinventing Organisation by Frederic Laloux.  Frederic talks about his research into organisations that are structured in quite radical ways.  With many cases having a completely decentralised organisation structure.  He categories these organisations as Teal, you will have to read the book to discover the other colours and their meanings, but I would be very interested to hear your views on which colour you think your company is?   What this book doesn’t give you is a blueprint for this kind of new organisation.  No two organisations implement a wholly comparable system.  However there are common traits to these organisations.  Again there are strong parallels to agile ways of work, in particular - delegated responsibility.  As such a number of commentators in the agile community are referencing ideas from Laloux’s book.  Definitely worth a read.

Definition of Done?

I wrote this blog post back in 2009 on the blog site of the company (iMeta) I was work for at the time.  Just recently I try to find the post to give some context to colleagues, only to find the company no longer had the post on their site.  So I have reposted the blog post here.

 

Running an Agile project presents a different set of issues to a typical Waterfall project.  One of the most typical questions asked is “what constitutes done?”  How do we know when the software is ready?  Well without documenting what we mean by ready, how can we answer the question?  To overcome this issue it is important to define the project’s Definition of Done (DoD).  This enables anyone on the team to have a clear definition when answering questions, especially with stakeholders, about the progress and state of user stories, tasks, sprints, releases etc.

It is important to realise that a valid DoD for one project may not transfer directly to another project.  There is often cross over, but each project’s DoD should be carefully thought through by the team.

Recently I facilitated a session to define the Definition of Done for a client project that I am running as part of my role.  Below is the approach I took to guide the team through the process.  It worked well and we have a clear DoD for the project.  The DoD will evolve as the team experiences the project.

 

Preparation:

In preparation for the DoD meeting I gathered a number of sticky note pads and pens, enough for each attendee to have their own, some Bluetak and a number of large sheets of paper.

Finally I wrote the key objective onto a whiteboard in a prominent position in the meeting room.  This was to be the driving force for the meeting and if we start to go off topic could be used to bring us back on track.  The objective being:

“What do we need to do, as a team, to delivery software to the customer?”

We are now ready to start the workshop.

Part 1 – Brainstorm:

I asked the team to all take a Pen and Sticky Note pad and write on the sticky notes what they believed was part of achieving the objective written on the whiteboard.  Each time they thought of an idea they would write it down, then please the sticky note in the centre of the table and read out aloud their idea.  

In the brainstorming session it is important to empower everyone to contribute.  No idea is to be criticized!

Quickly we had a large number of sticky notes.  We found that after the first 15 minutes we started to struggle for new ideas, so we moved on.

Part 2 – Categories

Next I asked the team what categories should be used to facilitate our DoD.  We soon came up with a list of three categories that we could use to drive different levels of done for the project.

1.       Release

2.       Sprint

3.       User Story

For each of the categories I place a big sheet of white paper on the wall.

Part 3 – Categorise

Now I asked the team to take the sticky notes from the table and place them into the categories.   By placing the sticky notes onto the sheets of paper on the wall.

Part 4 – Sorting:

Next we started to look at the detail of the ideas.  If we believed that two or more ideas where similar or overlapped.  We overlap the sticky notes.  If any ideas where duplicates we placed them on top of each other.

Where ideas no longer seem valid, had lost their context or simply made no sense we moved these to another area outside of the categories.

Part 5 – Review:

We reviewed each of the sticky notes to analyse the meaning.  Importantly to query if the idea was required to be done?  Was it in the correct category?

This review resulted in a lot of discussion with sticky notes moving around the categories, the definitions being rewritten and consolidated. 

Finally the team settled on good set of definitions.

Part 6 – Document:

The finally part of the session was for me to document the DoD.  We placed the resultant document in a prominent place on the project wiki.  You could place a printed version in the team work space.

Below is our project’s version of a Definition of Done:

MoSCow and the Release Planning Burndown Chart

 

Just recently I have been the ScrumMaster on an interesting project to create a new tool for the agile and scrum development community.    More details of this will be published in the near future.  In the meantime I thought I would share a new take on the release burndown chart.

On this project we conducted a lot of release planning to determine the product owner’s priorities for the functionality.  When doing our release planning we came across a problem with the sheer size of our product backlog and projecting delivery dates.  The total story points was in excess of 700.  Our project sponsors asked numerous difficult and challenging questions about what we could deliver and when.  The simple response of it is the Product Owner’s responsibility to determine the priority and when we can ship just didn’t wash.  We needed a level of confidence about a ballpark timescale and the usability of the product.

To overcome this issue I proceeded to create a variation on the release burndown chart.  We had already invested a lot of time in establishing the MoSCoW priorities for the complete Product Backlog.  In doing so we had created a list of acceptable functionality that needed to be shipped as part of the first release of the tool.  These were our Must haves.  The revised burndown mapped the various MoSCoW totals onto the burndown.  This indicated to us in which sprint the product would be shippable with the level of functionality acceptable to the Product Owner.

We continued to use the burndown to track our progress to against the Must haves deliverable.  Reflecting increases and decreases in the total estimate, as estimates for the stories changed, new stories are added as the Product Owner’s vision changed.

The fundamental underpinning that made the information on the burndown valuable was to always address the Must haves above all other stories.  In our case this was simple as the top of the product backlog was populated with Must haves.

Here is an example of the burndown we used:

Post writing this blog I came across a similar approach detailed in Mike Cohn blog here.

BDD Talk at the next Agile South Coast

 

The next Agile South Coast meeting is coming soon.  The 8th March 2010 to be exact.  Howard van Rooijen will be doing a talk on BDD.  You can find more details on the Agile South Coast website:

www.agilesouthcoast.org.uk

or

Direct Link to the Event

I look forward to seeing you there.

Agile South Coast – New Website

Since my last post the Agile South Coast website has started to take shape.  We have moved away from using Linkedin for organising the group.  The Linkedin group still has it’s place, but the new website gives us a lot more flexibility to deliver content that is relevant and interesting to the group. 

Join this new and exciting group on the below link.  Or just have a browse to see what we are all about.

http://agilesouthcoast.ning.com/

WSUG – Retrospective – 8th Feb 2010 (Agile South Coast)

 

We had an excellent WSUG meeting at the offices of iMeta on 8^th February 2010.  At the end of the meeting we had a little retrospective about the meeting and the group.  Below is a summary of the discussion.

What is holding back attendance of group?

-          “Wessex” name is not helping the group to be recognised.  Most of the group did not associate themselves with the Wessex area.

-          Lack of a website is missing an advertising opportunity. 

-          Reliance of Linkedin could be limiting our audience.

-          The aim of the group is not immediately available.

-          Need more blogs/twitter etc to communicate the activities of the group.

The group agreed to:

-          Change name of group to “Agile South Coast”

-          Create a specific twitter account for the group

-          Attendees will try to bring at least one more person to the next meeting

-          Howard to consider doing a talk at the next meeting in March.

-          Blog about the this meeting and the next meeting

-          Set-up a Ning Network for the Group.

-          Research local companies using Agile/Scrum to enlist more attendees to the group

 

Agile South Coast is a group of likeminded individuals that meeting every second Monday of the month to talk about Agile/Scrum/Lean for the improvement of the attendees and the wider community.  The group normally meets in the Southampton area with easy access from Portsmouth, Winchester, Bournemouth, Poole, Salisbury, Hampshire, Dorset, West Sussex, Wiltshire and beyond.

Charging Problems with iPod Touch and iPhone 3GS in Speaker Docks

 

It appears that Apple have removed one of the ways to charge iPods and iPhone in the latest generation (3GS iPhone and 3rd Gen iPod Touch).  Previous version have allowed charging through either the USB (5V) or Firewire (12V) connections in the standard 30 Pin cable.  Now only USB is supported.

The result is that any device that uses the Firewire to charge will no longer charge.  This includes Speaker Docks, In Car Adapters and Mains Chargers.

I have personal experience of speaker docks (Klipsch) that are advertised as supporting charging on all 30 Pin connectors that do not charge, obviously attempting to charge over Firewire!

There is a solution available from Apple.  It is called a Scosche Passport.  There are various available to fit different applications (Docks, In Car).