agile
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
This, in combination with my constant rant against excessive multi-tasking, too much work in progress and finishing one thing before starting the next seemed to have struck a chord with Gina, our designer, who started a "Kanban-for-One" movement at the office.
The “Kanban for One” board
The board, at Snapper known as “a Gina board” is used to organise personal tasks. The standard workflow is “Backlog” (stuff I want to/have to do), “Queue” (the subset of the Backlog that’s up to be worked on next), “In Progress” and “Done”.
The limited space for each of those workflow states imposes a natural limit on the number of items in each state, e.g. no more than 4 stickies fit into the “In Progress” area and getting more than 8 items into your “Queue” column is impossible. The lowest area on the board is either used as an expedite lane or for little inspirational messages and reminders.
The creator
Gina is the proud inventor of the Snapper Agile board. Unfortunately she has the least visually appealing board as she is stuck with an early version that had not received the benefit of several iterations of learning.
Spreading like a rash
Since people can place orders with Gina they’re spreading like a rash through our office.
Andrew with a board full of marketing tasks.
Sean, Head of Product, and obviously obsessed with the alignment of stickies.
The Product Owner’s wall
Reminders and ground rules on Gina’s board. I’m a bit confused about the haircuts though.
The Office
Conclusion
Apart from our team Scrum wall more and more people have or have ordered personal Kanban boards to supplement the team view with individual task management. We really like the boards to keep ourselves organized, protect ourselves from the temptations of multitasking and to communicate to the rest of Snapper what we’re working on.
Some people are combining the personal Kanban boards with the Pomodoro technique which seems to work really well too.
To read more about this topic read Courtney’s excellent post “Adapting Agile’s visible workspaces to the humble to-do list” over at Boost.
|
A Scrum Product Owner Role Checklist
28/05/11 In:Scrum | Agile Teams
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
- is responsible for that budget constraints are met
- is responsible for that what the team is asked to build is aligned with what the sponsor, stakeholders and users want
- provides boundaries to describe the realities within which the vision must be realised (e.g. time frames, external quality)
- makes sure management, stakeholders, sponsors are informed and the vision is aligned with their wishes
As a Product Owner you do ...
Some activities I would expect from an experienced Product Owner:
- Provide a vision for the product
- Communicate the project vision to the team
- Motivate the team to subscribe to the product vision
- Communicate the business benefits of the entire product and each individual feature
- Create and maintain the product backlog
- (the product owner can delegate some of the work of writing user stories to a BA but the Product Owner is still responsible that the work is being done and is being done properly)
- Continuously groom the product backlog
- Prioritise the product backlog
- Define releases
- Define release and sprint goals
- Continuously answer questions to add detail to requirements
- Accept/reject developed user stories at the end of the sprint (or during the sprint)
- Communicate about the project within the organisation (e.g. demo attendance and invites, forecasting, management reporting, sponsor liaison )
Here are some great resources I can highly recommend:
- Jeff Patton’s “The Product Owner and the Product Shaped Hole”
- Jeff Patton’s “How you Slice it - Agile Product Design”
- Bill Gaienne’s “3 Ingredients for a Great Product Owner” (10 min training video)
Why Being a Scrum Master is a Full Time Job
14/05/11 In:Agile Teams | Scrum
“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
"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. 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)
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
- protects the team from disturbance and external threats
- is a “servant leader” with no formal authority - all authority is granted by the team
- has no direct authority over Agile development team members but does have authority over the process
As a Scrum Master you do ...
Some activities I would expect from an experienced Scrum Master:
- Remove impediments
- Facilitate meetings (sprint planning, retrospective, review, daily stand-up)
- Coach the team on the Agile development process and make sure the team improves over time (note the caveat “experienced”)
- Re-enforce good practises
- Challenge bad practises and habits and work towards their removal
- Make sure people do what they have agreed to do
- Make sure that the team follow the team ground rules they have defined
- Make sure that quality is a team effort and commitment to the “done” statement is taken seriously
- Provide transparency via the product and sprint backlogs, daily stand-ups, demos and a visible workspace
- Assist in reaching the sprint goal (help with story creation, testing, making coffee, etc if necessary - loads of ad-hoc stuff)
- Ensure that a collaborative culture exists within the team
- Support the Product Owner
- Improve the team’s engineering practices and tools
- Communicate, communicate, communicate
- Smile lots, make people laugh, and make the team feel that you are one of them not an outsider
… as a Scrum Master you are not expected to do all of this yourself but you are responsible for that it happens.
Also, check out Kane Mar’s excellent mind maps of the Scrum Master role here.
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.
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.
It became obvious that, during the last 4 sprints, we had consistently bitten off way more than we could chew. While it is generally a good thing to strive for what is just out of reach and to improve though practice we thought the gap between attempted goal and real achievement was too big. We certainly didn’t want to lose management’s trust by over-promising and under delivering.
Therefore, we decided to focus on this problem for the remainder of the retrospective.
The problem
The problem was easily summed up as “We over-promise and under-deliver”The first why: Too many stories are almost done
We came up with two reasons for why we kept over-promising and under-delivering:- At the end of the sprint too many stories were “almost” but not entirely done (testing not finished, found a defect, etc)
- Two of our team members had just gone from 50% to 100% and we overestimated the immediate benefit in terms of velocity
The second why: We are running mini-waterfall
To find out why so many stories were almost but not entirely finished by the end of the sprint we had a look at last sprint’s burndown and cumulative flow diagrammes (I love those Rally reports).
The cumulative flow showed us that by day 4 most of our stories were in progress (yellow) but not many were actually completed (blue and green). Only 2 days before the end of the sprint the majority of stories were completed (blue) and then accepted by the product owner on the very last day (green).
This looked suspiciously like a mini-waterfall process where we first went though a development and then a testing phase.
The problem with any waterfall approach is that it forces feedback towards the end of the time box where it is hardest to react to. This is true for feedback on quality (through testing) and feedback on whether we have correctly understood the needs of our business and users.
The third why: We’re not doing tasks in parallel
We were then asking ourselves why we were running a mini-waterfall process inside a sprint.Not only were we doing testing at the end but we also seemed to have a problem with co-ordinating GUI (Flex) and backend (web services) work. People found themselves waiting for someone else to finish a task before they were able to pick up the next task to finish the story. Often people decided to work on the next user story rather than wait for someone else to “unblock” them.
We decided we were simply not good enough at working on tasks in parallel to get one specific user story finished.
The forth why: No TDD, test automation and stubbing
People came up with several reasons why we weren’t working on tasks in parallel to get one story “over the line”:- Lack of communication
- Only partial TDD, test automation and stubbing
- Lack of collective responsibility
- Not cross-functional enough
The fifth why: We have an attitude problem
We really went into deep discussions about why we weren’t doing things that everyone knew were good and healthy and after another dot vote amongst several candidates we decided the most relevant root cause was that we had an attitude problem.We knew what needed to be done, we knew that we needed to make it happen but somehow we hadn’t managed to just get it done yet. Probably because we hadn’t been fully aware of the consequences. We agreed to start fixing the problem immediately.
The solution
More specifically we all agreed to:- Ask for help when stuck
- Accept help gracefully
- Automate our regression testing (Flexmonkey/RiaTest), do TDD when possible
- Make more use of stubbing and mocking to be able to develop the front and backend part of a story simultaneously
- Hand over to the next person after finishing a task, i.e. don’t expect people to see progress from the task wall only; inform the rest of the team when e.g. the web service is finished or the story is ready for testing
My conclusion
Here’s the list of my personal takeaways and things I have learned:- A 5-why root cause analysis can work amazingly well for a targeted retrospective.
- To avoid any danger of a 5-why retrospective turning into something like the Spanish inquisition it needs to be very well facilitated (Hallelujah for good Scrum Masters :-)
- A 5-why analysis with a group of people will produce a decision tree as there will be mostly more than one answer to each “Why?”.
- Voting to decide on which reason is the most relevant one and should be discussed works well and speeds things up.
- It made my day that I got the opportunity to try this ;-)
I wrote this to illustrate and examplify a retrospective technique that worked extremely well for our team. I think this was one of the best retrospectives I have ever participated in and I hope other people will give it a shot and share their experiences.
10 Ways to Fail with Agile
Last week I presented at WebDU in Sydney. The conference was excellently organised by Geoff and the Daemon guys and I met lots of interesting people. And I love Sydney! In short I had a blast.
Apart from a workshop on user stories I presented on 10 ways to fail with Agile. Judging by the Twitter stream my presentation about the most common mistakes and pitfalls during Agile adoption and how to avoid them has been well received (okay, they also tweeted I looked like Starbuck in Battlestar Galactica Season 1 ;-)
As promised here is a version of my slides which more than just pretty pictures ...
Agile Undercover: When Customers don't Collaborate
25/08/10 In:Agile Product Ownership
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 ...
Not too surprisingly, one of Rashina’s main findings was that the greatest problem teams were facing was too little involvement from the Product Owner or customer.
What I found most interesting were the coping mechanisms teams employed to work around this lack of customer involvement. While certainly not ideal the following seven patterns emerged as coping mechanisms used in the “real” world.
Coping Mechanisms
1. Changing PriorityWhen teams didn’t have enough information on a user story they changed the priority and pushed stories that were awaiting customer clarification further down the product backlog until they received the required customer response.
An Indian team used a “definition of ready”: Very much like a Product Owner won’t accept anything that doesn’t fulfill the “definition of done” the team wouldn’t accept a story into the sprint that didn’t fulfill the “definition of ready”.
By “ready” the team meant that the business goals and expected outcome associated with the user story plus implementation details necessary to estimate the story had to be clear.
2. Risk Assessment Upfront
A New Zealand coach used an Agile risk assessment questionnaire to gauge the level of customer availability on the project upfront. The questionnaire included questions such as “What is the commitment of the customer rep in terms of time?”
Answers such as “Assigned to the project” or “Available as a first priority” were the best case scenario while the worst was “Just as time allows”.
The risk assessment before the beginning of the project allowed the team to discover potential problems upfront and to think about possible strategies to improve the situation or, if this wasn’t possible, to discuss strategies to work around the problem.
Sometimes the team could manage to negotiate with the customer to to free up the customer rep’s time to allow them to become a project team member for the duration of the project by providing funding from the project.
3.Story Owners
The practise of assigning story owners was an adaptation to the Scrum practice of allocating a Product Owner. Story owners were responsible for particular stories, instead of all the stories in the product backlog. Every story had to have an owner to get into prioritisation.
The strategy allowed the customer’s organisation to split the workload and time investment across several people and allowed the team to discuss stories in synchronization with the corresponding story-owner’s availability.
4. Customer Proxy
Some Agile teams used a customer proxy - a member of the development team co-ordinating with the customers - to secure requirements and timely feedback.
Most often the team member acting as the customer proxy was a Business Analyst, due to (most) BAs’ proven ability to communicate ideas.
5. Just Demos
Despite their reluctance or inability to attend other meetings, almost all customers were interested enough to attend product demos (show & tells). Often the part where the team showed new functionality would take 15 minutes but then the team and customer would use the full hour to discuss features and feedback.
6. e-Collaboration
Both in New Zealand and India the main cause of lacking customer involvement was physical distance - not only for teams and customers in different countries but also in different cities or even within the same city. Teams overcame this by using Skype, IM, wikis, Google docs and other collaboration tools.
7. Extreme Undercover
To avoid extreme consequences of lack of customer involvement such as business loss, Agile teams chose to follow Agile practices internally at the team level while keeping the customer unaware. Some teams confessed to having a “Don’t mention the ‘A’-word policy”.
I was happy to learn that Rashina had observed a clear decrease in the use of the “Extreme Undercover”-pattern over the span of her research, probably due to the increasing popularity of Agile among customers (yay!).
In an ideal world we wouldn’t have to use any of those coping strategies but having exhausted all other possibilities to convince the customer we sometimes have to use strategies to cope with a less than ideal situation.
Do those strategies make us less Agile? Probably so. But being Agile is not a binary value; it comes in varying degrees and in all forms.
I have used some of the above coping strategies myself, sometimes with greater and other times with lesser success. I found it very helpful to learn from Rashina’s research that other teams often face that same challenges and I have learned some new strategies I can try if all else fails.
Thanks
I’d like to say thank you to Rashina for giving me permission to blog about her research paper and, on behalf of the APN, for presenting. From a practitioner’s perspective I am grateful for her research as it allows us to gain insights into what we Agile practitioners actually do rather than what we should do or say that we do.
On a final note, I really recommend reading the full research paper which will be available on Rashina’s uni site soon (it’s only 14 pages).
Acceptance Criteria and the Definition of Done
18/08/10 In:Agile User Stories | Quality
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"
Example Acceptance Criteria (specific for this story):
- I can purchase an album by VISA card
- I cannot pay with a VISA card that's expired
- I cannot pay with a VISA card with a wrong number
Example Definition of Done (DoD) (valid for ALL stories):
- 0 bugs
- Passed unit tests
- Passed automated Cucumber acceptance tests
- Passed cross browser testing
- Passed UAT
- Code peer reviewed (if not pair programmed)
- Relevant documentation updated
The "Definition of Done"(DoD) is the team/project's quality statement for a user story or feature and ensures that a feature is 100% developed and tested. It is a statement that no more work is left to be done on this piece of functionality (90% done doesn't count!) and that it works without errors.
Release sprints
01/06/10 In:Agile Organisations
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.
What is in the release sprint?
Projects I have worked on and organisations I have coached usually included two types of work in their release sprints:- Work that couldn’t be performed every sprint because it was too time-consuming and/or expensive (e.g stress testing, full regression testing, getting copy text translated)
- Work that is only needed when releasing to production (e.g. bundle software, send out release notes to ops team, send comms package to change management, move code through various environments)
What is a successful release sprint like?
The following was common for successful release sprints across all projects and organisations:- Independent of how much functionality we had developed and how "big" the release was the release sprint was always the same length (e.g. always 2 weeks).
- Everyone on the team had a 100% focus on getting the release out of the door.
- We never developed any new functionality during the release sprint.
- Although sometimes unpredictable we made use of the task board and tracked our work with a burn-down.
- Sometimes, on larger teams (8-9 people), we were only a subset of the original development team but most of the team stayed on to help. (People who didn't work on the project did other work for the organisation such as e.g. R&D, "business planning", etc but that was not a project issue)
What are your experiences?
On Acceptance Criteria
09/05/10 In:Agile User Stories
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:
What’s the purpose of acceptance criteria?
Acceptance criteria:- define the boundaries for a user story/feature
- help the product owner answer what she needs in order for this feature to provide value (typically these are the minimum functional requirements)
- help the team gain a shared understanding of the story/feature
- help developers and testers to derive tests
- help developers know when to stop adding more functionality to a story
What are good acceptance criteria?
Good acceptance criteria:- State an intent not a solution (e.g. “The user can choose an account” rather than “The user can select the account from a drop-down”)
- Are independent of implementation (ideally the phrasing would be the same regardless whether this feature/story would be implemented on e.g. web, mobile or a voice activated system)
- Are relatively high level (not every detail needs to be in writing)
Can you give a good example?
Example user story:As an internet banking customer
I want to see a rolling balance for my everyday accounts
so that I know the balance of my account after each transaction is applied
Example acceptance criteria:
- The rolling balance is displayed correctly
- The rolling balance is calculated correctly for each transaction
- The balance is displayed for every transaction for the full period of time transactions are available
- The balance is not displayed if a filter has been applied
Another example user story:
As a Snapper cardholder
I want to be able to pick up my pending credit from MySnapper (Note: MySnapper is a client applications for users to top up their epurse, check their balance etc)
so that I have money on my epurse
Example acceptance criteria:
- I can see on MySnapper that there are pending credit(s) for my card
- I can choose which credit(s) to pick up
- I can see my new purse balance when I have chosen to pick up a credit
- I can’t top up my card or buy a pass when there are pending credits for my card
(Personally, I like the “I”-format for acceptance criteria to keep focus on the user perspective rather than system centric view.)
Where do the details go?
What about details such as e.g.:- The column heading is “Balance”
- The rolling balance format is 99,999,999,999.9 D/CR
- We should use a dropdown rather than checkboxes
The details the team capture before coding go into two places:
1. Team internal documentation
The purpose of team internal documentation is solely to serve as a reminder for (potentially forgetful) team members. How much of the details need to be written down depends on the team and whether people write down any details at all is entirely up to them. (Note that this is different from external documentation such as e.g. a user guide which would be part of scope)
2. Automated acceptance tests
Acceptance criteria can be expressed in (almost) plain English for use by the chosen testing framework. This means that tests provide value as documentation, automated acceptance tests and as a feedback loop for developers doing BDD (An example using Cucumber here: http://cukes.info/ )
Why Relating Story Points to Hours and Money is Risky
05/08/09 In:Agile Estimation
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
If we use an analogy of several piles of dirt in a room I can say that one pile of dirt is bigger than the other. However, if the work then consists of moving one pile of dirt from one end of the room to the other by carrying small amounts of dirt on a spade it might turn out that Peter is a lot stronger and faster than Paul and that it would take him 2 hours to move the pile while it would take someone slower and more junior like Paul 6 hours to complete the job.
Don’t assign work upfront
Therefore, in order to estimate the "how long" at the beginning of a project or iteration we would need to know which programmer will do the work at the time we estimate. This is highly impractical as it would lead to bottlenecks when developers are waiting for each other to finish their pieces of work. It could cause a chain reaction of delays triggering down the project and people being over or under-utilised.
How big?
What we can do on the other hand is to estimate the "how big" part. Using the piles of dirt analogy we can say that a pile of dirt is 40ccm with much more certainty than we can estimate how long it will take someone to move it to the other end of the room - especially if we don't know who will carry out the work yet. As software functionality is a lot harder to measure than the volume of a pile of dirt we introduced story points. Instead of saying that a piece of work is 40ccm we say that its size is e.g. 3 story points. Essentially we are applying the same principle of measuring size rather than time.
How long?
We still need to come up with a measure though for how long it will take to move all piles of dirt to the other end of the room, ie how long it will take to finish the project. One way of doing this is to size all known pieces of work and then to perform the work in timeboxed iterations of e.g. 2 weeks. At the end of each iteration we will know how many story points the team have implemented and after a number of iterations we will know that the capacity of the team is roughly X points pr. sprint.
Using this capacity number (called velocity) we have achieved the following:
- We can plan ahead in terms of time: If a team normally achieves 10 story points pr iteration for a project with 100 story points we would need 10 sprints.
- We can plan ahead in terms of budget: Given the number of resources on a project is constant we know the number of hours in an iteration and therefore the price of a sprint. If we know roughly how many sprints are needed in a project we have an indication of how much it will cost overall.
- We have managed to make estimates independent of who will be doing the work. Incorporating the "how long" into team capacity rather than the piece of work unit makes estimates independent of future work allocation.
Sizes are relative
As we, unfortunately, can’t measure the size of software functionality as objectively as piles of dirt we size pieces of work relative to each other. We have no way of saying that a piece of work is e.g. a universal size of 3 which is why we arbitrarily start with some piece of work and assign it a size. All subsequent pieces of work (user stories or features) can then be measured against this base story as being smaller, bigger, much bigger etc. For this we use the Fibonacci number scale (1,2, 3, 5, 8, 13) which helps us size all user stories relative to each other.
Which number we start out with does not really matter as the relative sizing in combination with team velocity is sufficient for us to plan ahead.
Sizes depend on context
It is important, though to note that story sizes are calibrated against an arbitrary base chosen by the team and that those sizes are by no means absolute or objective. In fact the sizes and velocity are only valid for this particular team and velocity will also change over time as the team increases capacity by getting better at what they're doing. Also, often functionality implemented by one team is assigned a widely different number of story points from another team implementing the exact same functionality (the same code might be implemented using 30 story points by one team and 140 points by another).
Overall, this system works well as long as story sizes and team velocity (ie the "how big" and "how long") remain independent of each other and as long as we keep in mind that story sizes are derived as arbitrary values relative to each other within a project.
Using story points, potentially even across projects, to equate directly to $$ is risky at best.
(Credits for coming up with the “pile of dirt” analogy to Mike Cohn)
Scrum 101
07/06/09 In:Agile Coaching
Presentation: Stories for Grown-Ups
28/04/09 In:Agile User Stories
Last night at the APN (Agile Professional Network) was the first time I co-presented in front of 80 people - a thoroughly pleasurable experience largely due to the extensive interaction with the audience and the great questions they asked.
During the session Douglas Talbot and I tried to explain what user stories are, where they come from, when they’re used and what makes a good user story.
User Stories: Stories for Grown-Ups
View more presentations from Sandy Mamoli.
When the red bus hits ... (Agile during a recession)
05/02/09 In:Agile Organisations
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:
- The project goes on with fewer team members
- 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:
Fewer team members:
Going on with fewer team members will not just result in major delays but will risk the success of the entire project.
Job roles in waterfall projects and organisations are highly siloed, i.e. testers test, developers code and a business analysts deal with requirements. A team losing several members will not just work at a lower capacity but some work simply cannot be done: If a project for example loses its testers testing will not be performed and the project comes to a grinding halt.
Canning the project:
Stopping the project has even more devastating effects and most likely the entire investment in the project is lost.
Waterfall methodologies use a phased approach: Requirements gathering, Design, Build, Testing and Deployment. Depending on which phase the project gets stuck in an organisation might end up having paid millions for a functional specification, technical design or developed but not yet tested software. All work on a product that cannot be rolled-out and used and that might never see the light of day.
If a waterfall project is stopped before the final phase the product cannot be used and the return on the (often considerable) investment is zero.
Agile
For an Agile project loss or reduction of funding can be bad news too but the risk when using an Agile methodology such as Scrum or XP, if implemented properly, is contained and the investment will not have gone entirely down the drain:
Fewer team members:
Going on with fewer team members will reduce a team’s capacity but as the responsibility and accountabililty for delivery lies within the entire team rather than individual job roles an Agile team can usually keep on delivering.
Agile teams organise around generalising specialists where people have both a primary and several secondary job roles and if one or more specialists have to leave the team other team members will take on their work. If an Agile team for example loses its testers the team’s business analysts, developers, scrum masters/project managers etc will share the workload and ensure that the software is tested and working properly.
Even at a slower pace the team will produce software that can be rolled out to end users.
Canning the project:
If the project is stopped or put on hold the damage is limited. Agile teams develop software incrementally and the primary measure of success is working software. Every 2-4 weeks (dependent on iteration length) the team delivers fully functional software, i.e. software that is fully designed, built and tested.
The basic rule to implement high priority features first ensures that, if the project is stopped, the most important pieces of functionality have been fully developed.
Unlike in a waterfall project project sponsors will never be left with just a functional specification, pieces of documentation or untested software. You might not get everything you initially wanted or set out to build but everything that has been worked on is fully functional and ready to provide value to the business and/or end users.
Real Life
Loss of funding and team members is what has happened after a change of government at my (now former :-) workplace, a New Zealand government entity.
My Agile (Scrum) project has already produced working and usable software in an incremental fashion. Even if it should get stopped we have delivered business value and a good return on investment.
In this case the organisation’s choice of running Agile has put them ahead of their peers.
The waterfall projects? I wish them the best of luck - they’ll need it.
Tools - the new kid on the block
26/10/08 In:Agile Tools
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
- Free web/phone conference with a Mingle representative to guide you through configuring the system after you have received a free hosted trial. Very helpful!
- A breeze to install the downloadable version
- Runs on all operating systems (incl. Max OSX, Linux and Open Solaris) and most database systems incl. Postgres
- It just looks nice and appealing
- Tasks can be completed with relatively few mouse clicks
- If you choose the scrum template the card hierarchy of sprints - stories - tasks is very intuitive and standard scrum
- You can create epics for your product backlog
- Given you’re willing to spend enough time playing with configuration settings and are inclined to learn Mingle’s proprietary SQL-like language you can configure the tool to fit exactly your needs. Hell, you could probably even extend their JRuby ;-)
- Mingle contains a fully fledged wiki - great for sharing project information!
- All reports are configurable on the wiki
- As expected, very easily done from Excel (For switchers it’d be great to have an automated import/export to/from Rallydev and VersionOne)
- Great that it lets you preview your import before starting the actual import.
Things I don’t like:
1. Concept of cards for everything
- Representing everything as cards is confusing: It does make sense for user stories, which in the physical world are written on story cards but using cards for releases, sprints and tasks seems forced and non-intuitive
- I don’t want to fit my mental models around a tool - it should be the other way around! Scrum concepts such as sprints and releases are a bad fit for Mingle’s generic object model of cards
- I miss the nice overview I have in Rallydev where I can see all my release and sprint dates
- Card trees fill quite a big part of the screen and it’s hard to get an overview at a glance (There’s another, smaller view but it doesn’t show the relations very well)
- Sprints and releases don’t have fields for start and end dates (I can add them myself by configuring cards but not adding them by default seems odd)
- There seems to be no standard way of getting started with a project quickly. There is no step by step process to quickly set up your releases, sprints, product backlog and user stories. Unlike Rallydev which guides you through with a pre-defined process and video documentation Mingle makes you figure it out for yourself.
- Mingle expects you to invest a considerable amount of time learning how to configure the system and how to make it work for you.
- There is no free SAAS version available (By comparison Rally Community edition is free for up to 10 users and Version One’s team edition provides similar functionality for free)
- Hosting Mingle on your own server is free for up to 5 users but I don’t want to wast my time installing tools and maintaining a server.
- The hosted trial for one project is great but only being allowed to keep the instance for 2-3 week is not enough for me to try Mingle on a real project and to make a decision to move all my projects from Rally or VersionOne
Overall, this is a promising tool with an attractive user interface.
It is nice that the tool is extensively configurable but it is way too time intensive to set up. The point is that even though I can configure everything I don’t want to: I just want to get going quickly with 80% of what I need and focus on getting my projects done. Spending time on configuring a tool seems like a waste of time.
As Mingle still seems a bit rough around the edges and does not provide a killer feature that would justify the hassle, learning curve and additional licensing cost I won’t switch from Rallydev this time.
I’ll definitely keep an eye on future releases though!
When not to run Agile
05/10/08 In:Agile Organisations | Agile Teams
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 ...
- People on the team are not fully allocated and committed to the project
- You can’t stack a great team and only get the people that everybody else wants to get rid of (Give me some of the company “stars” even if it’s just to show commitment and get me agile personalities!)
- You don’t have the courage to let the team make decisions, to allow them to learn by making mistakes and to trust them to get the job done - you’re stuck in command control
- You don’t have a business person who has the time, courage and authority to work with the team and to make quick decisions
- You expect instant success and need a silver bullet (Sorry to be the one to bring it to you but if your project is impossible or if you don’t have good people no methodology or framework is going to help you ;-)
There are of course numerous other things that are important for agile teams to succeed but usually there are work-arounds for non-ideal situations.
If I don’t meet any of the above obstacles I’ll go for Agile any time!
What’s your list of show stoppers or essential requirements for running an agile project?
How to pick a Scrum team
28/09/08 In:Agile Teams
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.
Having complete freedom I think I'd focus on:
- Personality and work attitude - people who are solution oriented, like to deliver, like to succeed, are easy to work with, can communicate and just get the job done
- People who like each other or have a chance of getting along, i.e. have respect for each other and can have fun together
- Absolutely no primadonnas: We can all be flexible and accommodate a lot but the lone genius who lives by his own rules just does not work (I usually remove them and I have never regretted it)
- People who are confident enough to handle the visibility and transparency that come with Scrum
Sure, people should be qualified and good at what they do but it is much easier to teach people skills than to perform personality transplants.
Design Chunking with Scrum
27/09/08 In:Agile user experience
When I started with agile (Scrum) software development five years ago one of the main challenges I faced was combining an agile development approach with user-experience driven website design.
Especially, as we were working on a global, consumer-oriented web site with a strong focus on product branding we needed to make sure that we could benefit from the agile development approach without losing focus on a consistent user experience (UX) and information architecture (IA) across the site.
Agile frameworks such as SCRUM and XP say absolutely nothing about the IA and user interaction design processes, which meant that we had to learn mainly by trial and error.
Most of the problems we faced originated from a clash of two fundamentally different world views:
- UX people are driven by a holistic approach (big picture)
- Dev teams focus on iterative and incremental development
Our experiments:
- Attempt 1: Concurrent IA, design and development
- Attempt 2: Upfront IA and graphic design
- Attempt 3: Post skinning
Attempt 1: Concurrent IA, design and development resulted in “piece meal” design and user interaction. We lost track of the big picture and lacked overall IA/design consistency across site. Also, our product owners found it difficult to keep an overview of the project.
Attempt 2: Upfront IA and graphic design caused problems with unused and out-of-date designs and feature specifications. Sometimes we finished an iteration or release with partially implemented features - very non-agile! We also found it difficult to adapt to feedback after the IA/design phase was completed.
Attempt 3: Post skinning (applying design after functionality has been developed) caused our implementation to drift from the design and user interaction intent and we often faced excessive and unnecessary re-coding and re-factoring work. The product owners and end users found it difficult to give feedback as non-shippable increments were demonstrated.
After three failed attempts we still wanted to utilize the advantages of an agile approach that would allow for continuous inspection and adaption and could help us to keep the focus on the most important parts of the site. Basically, we wanted to keep the agile advantages without sacrificing the overall user experience.
Attempt 4: Design-chunking - success!
(This term was originally coined by Lynn Miller)
With this approach we defined initial concepts upfront and subsequently broke the IA and user experience design apart into smaller pieces that could be delivered incrementally.
Design-chunking process:
The most important break-through came from two changes:
- We introduced an iteration (sprint) 0
- We de-coupled IA/user experience/graphic design from development
- done before development begins
- short (2-3 week) IA/user experience/graphic design only iteration to lay the groundwork
- defines “big picture” on which subsequent designs and not yet fully defined areas of the site will be based
- outcome 1: overall strategy for IA (site-wide elements such as page grid, navigation, rough placement of modules)
- outcome 2: overall design concept including site-wide design guidelines
- exact content balance between IA and design will be based on whether an IA or design led approach is used
- signed off by client (partial IA and design sign-off) and discussed with developer to assess technical complexity
- iteration 0 only covers fundamentals and potentially the details of the most important page. Details for other pages and areas of the site are still to be refined incrementally
Decoupling of IA/design and development:
- after iteration 0 decoupling IA/design and software development into two independent tracks
- tracks iterate separately but simultaneously and provide frequent feedback to each other
- the IA/design track feeds a refined design of the most important features/page(s) to the development track at the end of each design iteration
- the output from the IA/design track at the end of an iteration is used as input to the subsequent development iteration
- for the IA/design track to feed the development track the IA/design track needs to be ahead in time - ideally this would be one iteration ahead with minor refinements still possible during the development iteration (e.g. change an image)
- focus on potentially shippable increments of functionality to provide feedback opportunities for the client/users
This approach worked very well for us, we delivered nine releases to a happy client and in terms of process we felt we got the best of both worlds.
I would be very interested to hear your thoughts on this approach and particularly any experiences you may have had with similar issues in your projects - especially large and/or global web-based projects.
Also, an absolutely excellent description of this approach was done by Lynn Miller in her paper on Adapting Usability Investigations for Agile User-Centered Design. Much of my article is based on and inspired by her work. I only wish I had know about it before we started our extensive period of trial and error.