• All
  • Agile
  • Agile Adoption
  • Agile Organisations
  • Coaching
  • JAFAC
  • KanbanFor1
  • Product Development
  • Product Owner
  • Retrospectives
  • Scrum Master
  • Self-Selection
  • User stories
Read More

Interview with a newly-minted Scrum Master

Six months ago SilverStripe, an open-source Content Management System provider and Wellington web agency approached me to help them improve the way in which they deliver client and open source projects, increase employee happiness and, in general, just do the best possible job. To achieve this, we decided to move away from the existing Agile-like (fixed scope/fixed price) approach and introduce Scrum with its focus on client-driven iterations, early feedback and continuous improvement.

Silverstripe have asked me to interview some of their staff about the transition to Agile. The original posts can be found on Silverstripe’s blog (Sam MinnéeAleksandra Brewer), below are selected highlights from the interviews. 

Read More

Exploring servant leadership

A few weeks ago I was sitting next to a log fire, sharing a glass of wine with a few like minded individuals chatting about all things Agile, one of the things we discussed was a time when one of the party was a Scrum Master and that they had a team admin who used to collect all the story data and do the typing up for each sprint. My immediate reaction was that of outrage, “how as a servant leader could you, farm off ‘menial’ tasks to someone else, that’s an integral part of the role”.

It got me thinking, am I the odd one out here?

Most of the Agile literature I have read over the years mentions servant leadership, but never really goes in to too much detail. A quick hike to the lazy man’s oracle, (Wikipedia) and as the saying goes “the more you know, the less you know you know”. To help me learn and understand servant leadership a little more, I decided to dissect the Wikipedia commentary and see what emerged for me.

Robert K. Greenleaf never specifically defined servant leadership but, based on the writings of Greenleaf and others, it can still be defined as a management philosophy which implies a comprehensive view of the quality of people, work and community spirit.”

Read More

Checklists

Checklists have a somewhat bad reputation in the Agile world, probably because they “smell” of too little self-organisation and too much process. I find this reputation is entirely undeserved as they can be extremely useful as a memory aid, or to visualize a workflow. 

Checklists play an important role in areas where missing steps can have disastrous consequences, such as in hospitals or airplanes; or in situations where people are likely to forget individual steps, such as when they’re stressed and tired; or while learning a new process or way of working. 

At work we mainly use checklists when we want to introduce a new workflow and need to make sure we don’t forget about the process or any of its steps. 

Here’s an example of our checklist for the sprint workflow and working with user stories:

Read More

Kanban is not for the Idle or Newbies

For four of my six and a half Agile years I was solidly in the Scrum camp, Lean, in my opinion, was already part of Scrum and its influence made Scrum even better. I don’t think that any Agile practice is for the work shy and there is a lot of personal courage needed to get any practice working well. Many people call Kanban an evolutionary rather than revolutionary process (my disagreement of this bland throw away statement will be in a later post), and I think this allows too many people keep the dinosaurs roaming the earth, if the mass extinction event has just happened then apart from the obvious sense of loss , at least you have an empty playing field to start from. Scrum at least with its slightly more prescriptive approach gives you somewhere to start.

About two years ago Kanban for software finally entered my Agile sphere. I initially relegated it to the ideal-for-support-teams division, and sneered at the new kid on the block. But time spent seeing Kanban in action and listening to the wise words of people like Gareth Evans (understanding the cost of delay was a revelation for me)  and presentations including “Agile isn’t the point, better is the point,” by Michael Bromley, made me think about Kanban in a more positive light.

Read More

The Wall of Pain

Software projects experience a problem called technical debt. In short, technical debt is the result of making a quick and dirty work around (often for valid reasons such as deadlines) which creates rework later.

I recently visited an organisation that had a wall of pain which I thought was an excellent idea as it highlighted the levels of technical debt in the project. This involved a section of the workspace dedicated to items that needed refactoring at a later stage. This made me think about pain and our tolerance to it.

The wall had lots of pain on it and the team did their best to address this pain whenever they could, a commendable exercise for any team.

That said i am not sure how much the pain was actually felt, as i said there were lots of cards and they were not easy to see when the team did their stand up in front of the visible workspace, so they did not feel like they were always on the mind of the team.

Read More

Visible workspaces – a house of cards or something far more solid?

Many people’s first encounter with an implementation of an Agile framework is the visible workspace. I find first reactions to this very telling: for some it feels like a natural way of expressing their work and they can see what is happening in an instant, while for others it’s some cards on a wall that don’t look professional and ”what’s this got to do with real planning anyway”. The professional part of me hides that sinking feeling inside when you know how much energy you are going to have to put in to get them to see that Gantt does not always (even rarely) equal a plan that works.

So for those who don’t know what a visible work space is here is a short list of what it is and what it is not. A visible workspace is:

  • A focal point for the project team, especially during a horizon
  • A representation of the work planned for the iteration
  • An easy way to see who is doing what and when

 

  • A planning tool for the team
  • A repository for non sprint information too, such as highlighting levels of technical debt
  • A living document
  • Easy to understand for anyone in the organisation
Read More

The document dilemma

The Agile manifesto states “Working software over comprehensive documentation” – this seems to be one of the biggest mindset shifts that organisations need to make when adopting any Agile framework. For some people that simple statement brings up visions of chaos, lack of control, and the worst fear of developers doing what they want. At the other end of the spectrum that’s exactly what some people hope it does mean.

If you ask people within most software development teams / companies what they do it is very unlikely that you would get the response “write documents about the products for our clients”. Most responses would be about the latest website or the latest Google hack they are doing. So inherently at an external client facing level we do value working software over comprehensive documentation. Where I believe this value changes is during the production of the working software and the legal requirements from the iron grip of the contract.

Visual Workspaces: Kanban for one

One of the things that immediately caught on when we started our journey towards being Agile at Snapper was the use of visual workspaces. The team loved the sense of achievement of moving a task from “In Progress” to “Done” and found the board helped them stay focused and co-ordinated. Everyone from team member to operations to management appreciated the level of visibility and transparency. Even my partner’s 11-year old daughter thought my work place was the coolest ever as we had covered the walls in colourful sticky notes and Simpsons characters.

Read More

A Scrum Product Owner checklist

After my last post on the role of the Scrum Master I have been asked if I could write a similar role description for the Scrum Product Owner. 

Here’s my view of the role: 

The Product Owner

The product owner is a visionary who can envision the final product and communicate the vision. 

The product owner is also the person who sees the vision through to completion. This includes describing features, collaborating and communicating with the delivery team, accepting or rejecting work results, and steering the project by tracking and forecasting its progress. 

The Product Owner points the team at the right target, the Scrum Master helps the team get to the target as efficiently as possible. In other words: The product owner is the what-person, the Scrum team are the how-people.
 

In general the Product Owner …

 

  • is responsible for that the team builds the right product
  • manages ROI and makes sure to deliver business benefits

Why being a Scrum Master is a full time job

An adequate Scrum Master can handle two or three teams at the time; a great one can only handle one”. (Michael James – An Example Scrum Master’s checklist)

I found that organisations, teams and new Scrum Masters (even freshly certified ones) often aren’t sure what the Scrum Master role entails and what value it provides. 

Here is my attempt to summarize what a good Scrum Master does:
 

The Scrum Master role

Some teams are like symphony orchestras, so they need a leader who keeps everyone on the same sheet of music. Conductors have to be deeply familiar with each instrument and with the music, yet they don’t play in the band or tell the musicians what to do. They let the music provide detailed guidance; their job is to bring out the best in the musicians, both individually and as a group.” (Mike Cohn – Succeeding with Agile)“A Scrum Master is like a conductor coordinating the efforts of musicians, helping them to play together. Some teams are like jazz bands, so they need a leader who encourages improvisation.


 In general the Scrum Master …

 

  • makes sure the team is running (good) Agile development
  • assists team members in adopting and improving Agile Development
  • helps the team maximise throughput and to work in the best possible way
     

Read More

A 5-why root cause analysis retrospective

The idea

For quite a while I have been waiting for an opportunity to try a 5-why root cause analysis in a sprint retrospective. 

The 5-why analysis has its origins within Toyota and lean manufacturing and is used to find the root cause of a problem through identifying a symptom and then repeating the question “Why?” five times. General wisdom and experience state that the nature of a problem and its solution usually become clear after 5 iterations of asking “Why?”.

Here’s an example from wikipedia: 

Problem: My car won’t start.

  • Why? – The battery is dead.
  • Why? – The alternator is not functioning.
  • Why? – The alternator belt has broken.
  • Why? – The alternator belt was well beyond its useful service life and has never been replaced.
  • Why? – I have not been maintaining my car according to the recommended service schedule.

Solution: I will start maintaining my car according to the recommended service schedule.

The plan

I have found 5-why root cause analysis very useful in the past but had never tried it with a group of people or a software development team. 

I “conspired” with our very talented Scrum Master and the plan was to share data from previous sprints, analyse the data as a team and see if we could identify a problem. If so, we would suggest a 5-why analysis to see whether it would point us towards a root cause and a solution.

The execution

1) We started by presenting velocity data:

The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints. 

Read More

Acceptance Criteria and the Definition of Done

Recently some of the teams I’m coaching found it difficult to distinguish between acceptance criteria for user stories and the definition of done. Here’s my attempt to make the distinction clear: 

  • For a user story or feature to be “potentially shippable” it needs to meet the expectations of the Product Owner and be of the agreed quality.
  • The Product Owner’s expectations are phrased as acceptance test criteria. Acceptance test criteria are conditions of satisfaction specific for each individual user story. (For more on acceptance criteria read “On Acceptance Criteria”).
  • The user story’s (internal) quality is defined in the “Done” statement. The “Done” statement is applicable to all user stories in the project.

 

Here’s an example:

User Story:
“As a music lover I want to be able to pay for my album by VISA card”

Read More

Release sprints

To get our code to production what is left to do is to turn the “potentially” releasable product into a releasable product. To do this a number of activities are required: Which ones and how much effort they require varies greatly between types of organisation. 

The fastest way to perform rollout activities is to do them within the development team and to automate as much of the process as possible. While I envy and respect teams that are mature in terms of test and deployment automation and operate in an organisational context that allows them to easily move code from environment to environment I find that this is very often not possible within larger organisations. 

Often, among other activities, someone outside the team has to be instructed as to how to deploy code, other parts of the organisation have to be informed about the changes (eg. end users, operations and maintenance teams, etc), and manual regression testing has to be performed. 

For the kind of large organisations Mike Cohn refers to in his description of a bank with COBOL code and no automated regression testing or large organisations new to Scrum and Agile I, too, find this is best done within a so-called release sprint.

How story points work

One of my clients is a small software development house that does custom development in the form of development projects for clients . I helped them to successfully introduce Agile (Scrum with XP) and both the team and business managers are really happy with it. 

As they liked our methods of planning and estimating (story points and velocity) the account managers and sales team were discussing the options to relate story points to dollar values. 
 
To explain why I think this is very risky and not advisable I wanted to give them some background.
 
“How big” vs. “How long”
Story points are units that are used to size a piece of functionality or work. Sizing in this case means that story points indicate “how big” a piece of work is. 
 
This is often confused with “how long” it takes to implement it but in fact “how big” and “how long” are very different things:  

  • The “how long” is highly dependent on which developer is performing the work 
  • The “how big” bears no relationship to who is performing the work

 

When the red bus hits: Agile when things go wrong

There’s a saying in software development “If someone gets hit by the red bus … “ which roughly translates to that if you lose a project team member or two you still want to be able to get the work done and finish the project. 
 
Normally, red busses are rare: The realistic worst case scenario is one or two team members out with the flu or someone quitting their job. A good team can normally recover from such disruptions. 
 
But red busses can be bigger and more damaging and wipe out large parts of a team: This usually happens if a new CEO, new management or a new government revokes funding, recession hits or an organisation just plain runs out of money. 
 
In this case one of two things normally happen:

  1. The project goes on with fewer team members
  2. The project gets canned or put on hold

 

Waterfall

This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:

How to pick a Scrum team

I was recently asked by a friend how to pick an Agile team. 
 
My friend is a project manager within a New Zealand government department and to deliver an important project he was given complete freedom of choice with regards to project methodology and people.
 
He chose Agile and Scrum as a delivery framework and needed 8 people to form his dream team. The big question was which people to pick and which skills to focus on. 
 
I’ve never been fortunate enough to pick my own scrum team. Normally, I get a certain degree of choice and then a combination of who happens to be available and people who I really, really fight for. And sometimes I fight to avoid getting someone on the team. 
 

When not to run Agile

People keep asking me whether I’d run all projects using an agile framework such as Scrum. 
 
When I answer “of course not” they often not only expect but gently try to steer me towards an answer that excludes certain type of projects: “You certainly wouldn’t use it for a mission critical system, would you? Or a compliance project? Or an infrastructure project? “
 
Actually, yes! I have used Scrum for business critical systems at a major mobile phone manufacturer, have implemented mission critical systems for a publicly owned European Rail Cargo company, a friend of mine has successfully delivered a compliance project and another one has even developed fighter jet control systems for a European Air Force using scrum. 
 
It’s not about the type of project. It’s not even about the size of your project. It’s about whether you’re willing and able to create a setup that allows agile projects to succeed. To me the rather vague terms of organisational and cultural readiness can be narrowed down to a list of primary show stoppers: 
 
I’d NOT run agile if …