This is my second post in my Scrum coaching patterns series.
In my last post I asked for some help with a pattern format that I could follow and at least one person must have read my blog as I now have a shiny new format to follow thanks to Gareth Evans for this.
I really like Jonathan Rasmussen’s project inception deck as a simple, quick and cut-to-the-chase way of kicking off projects. Overall, I pretty much stick to Jonathan’s content and flow, but sometimes, I use a press release exercise instead of a product box. The idea of refining a product vision through writing a press release has originally been used by Amazon.com as a mechanism to determine whether a product or service should be built.
My client, a New Zealand government department, is in the process of introducing Agile-Lean. They are currently in a trial phase to see if it is for them and during the early stages they’d like to run Agile and non-Agile projects in parallel.
Fair enough, but how to choose whether a project should be run Agile or Waterfall?
Earlier this year I was invited to join the Scrum plop, to help write some patterns for the Scrum community, unfortunately the stars were not right and I was not able to attend. It did however help me answer a question that a great friend and fellow Agilist Sandy Mamoli put to me, which was “how do you make your blog posts smaller?”
The driving force behind why people start startups is likely to vary wildly across different industries and types of business. For many it’s the promise of lucrative return – from sales of product or selling their eventual company. For some it’s the burning desire to fill a perceived gap in the market – ‘if I want this, surely 3 million other people will want one too’. Perhaps for others it’s curiosity, or a need to be in charge of their own destiny, or all of the above.
One of my current clients, a large government agency, have recognised that their current monothilitic waterfall approach doesn’t work all that well and are trying to decide whether to change their delivery approach to Agile or “just” Iterative (mini-waterfall style).
Following last week’s interview with a newly-minted Scrum Master this week I have had a conversation with developer Mateusz Udowski. We talked about how SilverStripe’s adoption of Agile and Scrum have affected him and why he thinks SilverStripe is now more intelligent as a whole than it was before.
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ée, Aleksandra Brewer), below are selected highlights from the interviews.
The first big task of getting started is updating all the various bits of online information that describe who I am and what I do. So far I’ve kept my Facebook and Twitter presence to be fairly personal, so it’s not relevant there. But Linked In is a very important business marketing tool – not just for any relevant contacts to my new business, but also to maintain local and international networks and connections relevant to my recent or future work. Then there are business cards to be printed, blogs to update and an identity to create.
Choked at the first hurdle.
Last week I presented to Flex and Cold Fusion Developers at cfObjective in Melbourne about Agile technical practices. As several other presentations dealt with practices such as TDD and unit testing I chose to focus on two areas I have become very passionate about during...
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.”
“When you need me but do not want me, then I must stay. When you want me but no longer need me, then I have to go.”
— Nanny McPhee (via Lyssa Adkins)
I am an Agile coach and the goal of my job is to put myself out of a job.
My mission is to teach people Agile and to make sure they understand and correctly apply Agile values, principles, frameworks and techniques. This is quite a big deal as Agile often forces us to change the way we work on a daily basis; how we organise our work, how we collaborate, which tasks we perform and how we communicate with each other and the rest of the organisation.
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:
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.
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.
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:
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.
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.
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 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.
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.
Solution: I will start maintaining my car according to the recommended service schedule.
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.
1) We started by presenting velocity data:
The chart shows our planned (blue) and achieved (red) velocity over the last 10 sprints.
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:
“As a music lover I want to be able to pay for my album by VISA card”