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

A Life Reset with Scrum

Reset Your Life with Scrum Lots of people use Scrum and Kanban in their personal lives, but have you thought about using it for a life “reset”?   When would you do a “life reset”? When you’re approaching a big change in your life When you’ve been through...

Read More

Evolving the Story map

I can’t say enough about how useful story maps are and how essential they are on any Agile project. Jeff Pattonis the undisputed (certainly in my mind) master of the story map and it’s well worth looking at the materials on his site. Jeff summarises a story map as, “A prioritized user story backlog helps to understand what to do next, but is a difficult tool for understanding what your whole system is intended to do.

 

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

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 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.

Read More

Even done is never done

A “done” definition in an Agile project is a statement that the team use to measure whether they’ve met all of the requirements for completing a userstory / feature (and in some cases completing an iteration or release). Done is one of the major shifts from doing Agile to being Agile.

So, what is “done”? Is it the quality mantra for the team? Is it the way we communicate completeness to the customer? Is it a process for eliminating waste? Is it about how we would like to work to bring about that “potentially shippable” product? It’s all of this but crucially belongs to the team, is created by the team, and is used as a measure of success. A “done” definition may look similar between teams but is never the same.

A template for the sprint review

Conducting an interesting and engaging end-of-sprint review is an often overlooked art: Not only do we want to show what we have built during the last sprint and collect feedback and good ideas for what to build next; we also want to give our audience a good experience. 

At my workplace we always invite the entire company and often have more than 30 people in the room. As they claim to be happy and to enjoy the fortnightly experience I thought it might be useful to share our template and some guidelines for what is working for us.

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
     

Agile undercover – when customers don’t collaborate

The other night I attended Rashina Hoda’s totally awesome presentation “Agile Undercover: When Customers don’t collaborate” at the Wellington Agile Professionals Network.

Rashina presented the research she had conducted on the basis of interviewing 30 people across 16 organisations in New Zealand and India. Having delivered a steady supply of Agile teams and individuals over the years I was excited to see the results of Rashina’s research.

Her chosen method of research was grounded theory which basically means that instead of testing a pre-conceived theory the researcher gathers data and generates a theory based on the data collected. A bit like Google Flu Trends …

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 …