Clive Skipper's Blog

Reading one of my iMeta colleagues blog posts got me thinking about apply some agile principles to the communication methods used on an Agile project. 

I have heard supposedly Agile proponents assert that the only communication method that is effective is face to face communication.  Such that all other communication options are dismissed.  There is no doubt in my mind that face to face is the most effective, but some projects cannot facilitate co-location of the team.  The costs of travel can also be prohibitive and not a motivating factor for some individuals.  Furthermore if you read the Agile Manifesto it states “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”  It does not state that face to face is the only method to be used.

It is confusing to me that this argument is perpetuated.  Especially as it seems to fly in the face of another of the Agile Manifesto principles.   “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.”  I often call this “Inspect and Adapt” principle.  In my mind this applies to all aspects of the team and individual dynamics, including communication methods.  So use this to principle to adapt the communication methods to meet the teams needs.  After all we need to remember another Agile Manifesto principle that we should “Build projects around motivated individuals.   Give them the environment and support they need, and trust them to get the job done.”  Part of the environment that we should provide is the communication channels that work for that project team.  Allow the team to select, modify and change the communication mechanisms.  The communication mechanism selected to support a specific team dynamic, the project may require a specific approach and the project lifecycle may require adaption of the communication to support the project dynamic.

In essence Agile projects need Agile Communication.

Over the last few weeks I have become increasingly interested in how lean principles can be applied to Scrum projects.  In particular I find the principles of Kanban interesting in the application of task management in a Scrum project.  This is extremely interesting here at iMeta, as I have been debating with colleagues the merits of task allocation versus an in flight pull model.

The more I read the more I find that there is an interesting shift it the thoughts of the various commentaries.   The initials documentation on Scrum had a clear direction for the allocation of tasks to be a team responsibility.  The team should select tasks/stories from the sprint backlog as the sprint is in progress – late binding of tasks.  The team is empowered to select tasks.  This could be part of the daily stand up process.  

Just recently there seems to be a move away from this approach.  To have the team select the allocation of tasks at the sprint planning stage.  I understand the principle here, but do worry that this is creating inflexibility for the team, as well as a potential for introducing a critical path.  There is also a risk of creating functional silos.  This approach will work so long at the team fully understands that the task assignment is not a commitment and can be altered and adapted whilst the sprint is in flight.  Remember change is embraced.

An interesting angle is the influence of Lean principles, in particular Kanban, on the thinking in this area.  Clearly Kanban is a pull system.  To apply this to tasks clearly requires the team member to select (Pull) tasks from the sprint backlog.  Furthermore to select tasks on an as needed basis, rather than to be pre-selected at a point in time.

So have we gone full circle?  Yes and no.  Well my belief is that pulling of tasks is the preferable approach to keep team flexibility and ownership of the sprint commitment.  Having said that if the pre-allocation of tasks works for your team and project, that is equally preferable.  Having the flexibility to select the approach that meets your team and project’s needs is more important that being prescriptive.  Remember – Inspect and Adapt.

Another interesting inference from Kanban that can be applied to tasks is that team members shouldn’t have multiple tasks in progress.  This makes sense in terms of allowing the individual to focus on delivering a specific task.  Reducing the noise from other tasks can be important.  As well as, enabling the individual to truly focus on the delivery of the task to the definition of done.  The only exception is where there are blocked tasks.  Clearly we need to be productive and not all blocked tasks can be unblocked quickly.  So we may need to park the task and move on.

1.        “Ready, Fire, Aim: A Rebuttal” - a very interesting article on one of the common criticisms of Agile/Scrum.

2.       “The Official ScrumButt Test” by Jeff Sutherland – an extremely good tool for the team to reflect on the Scrum process.  Should lead to awareness of issues and enable the improvement of Scrum processes.

3.       “Done. Really?” – I know I go on and on about this topic.  But here is another commentary on the importance of the definition of done.

As has been already been explored in Hadi Hariri’s post “scrum is about wearing multiple hats” it is important that the scrum does not take the path of least resistance.  By selecting tasks and stories that are easy or in an area of natural fit due to functional understanding.  Personally I believe that selecting challenging tasks should be viewed as an opportunity not a risk.

One of the opportunities that Scrum presents to the team members is the ability to grow skills by selecting challenging tasks.  Challenging in terms of complexity or simply to allow an individual to use a task to build skills in a business domain or a technical area.  Team members should recognise this opportunity and proactively encourage team members to expand knowledge and skills.  The learning process can be enhanced further by using targeted pairing to share skills and knowledge.

There are so many positives to this approach.  The team’s skills grow, which should be fulfilling and motivating for the individuals.  The breadth of coverage for the product is increased removing the “only Joe does that!” scenario.  The growth of a team that is multi-disciplined is actively encouraged.

Certainly I have noticed that the Scrum team I work with here at iMeta, has made a conscious effort not to select comfortable tasks.  It is conscious effort.  We can all too easily fall back on what we know and feel most comfortable doing.

Take the opportunity to learn!  

This approach is in contrast to a “traditional” software development approach that could have viewed as a risk the assignment of a task to someone who is not going to be the most expedient.  The mitigation to that risk could well have been to assign someone who has the knowledge and skills to do the task.

As an interesting side note.  I have reflected on my writing this post and noticed that I naturally used the word “assign” and “select” for waterfall and scrum respectively without thinking.  Maybe my assimilation into the scrum world is complete. J

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 at iMeta.  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:

TF84034: Team Foundation was unable to initialize the workbook.  This document will no longer be associated with a Team Foundation server.

On further investigation the issue was caused by the addition of a column to the spreadsheet that was not bound to the TFS data set.  Once the workbook is closed and reopened the TFS connection is not re-established.  Microsoft has released a hotfix for this issue:

http://code.msdn.microsoft.com/KB946458/Release/ProjectReleases.aspx?ReleaseId=1024