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?
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.
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...
In many companies, especially those who provide services to external clients, the main focus from a project management perspective seems to be on resource allocation and utilisation. People are viewed as individual “resources” and an important goal is to maximise people’s utilisation (Before you say this is not true, think about how important this metric is at your company and that people tend to optimise what is being measured).
I know that especially for vendors who often charge by the hour or have to keep cost down in a fixed price and scope scenario, utilisation is hugely important. That’s fair enough. However, making utilisation the main driving factor, will backfire and ultimately lower utilisation.
By foregoing the team approach, aiming to maximise utilisation and piecing together projects through dynamically allocating and re-allocating people we:
“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:
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.
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.
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.
“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:
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.
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.
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 …
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”
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.
One of the teams I have recently coached quickly got a grasp of how to phrase user stories but found it hard to relate to the concept of acceptance criteria.
I wrote this short FAQ as an attempt to make it easier for my team to work with acceptance criteria and hope that other teams might find this useful too:
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:
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:
This is bad news for everyone but has a devastating effect if your project runs any flavour of the waterfall methodology:
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.
Mingle has received a fair bit of attention lately and the latest version, 2.1, has just been released.
I’m quite happy with Rallydev but as Mingle is made by Thoughtworks themselves and the guys at Silverstripe keep raving about it I thought I’d better check it out. Also, as much as I like Rallydev and VersionOne – they’re both a bit weak on the usability side.
Below a list of what I like and dislike about Mingle:
Things I like:
1. Installation & Support