Thursday, July 24, 2008

Who Manages Risk in a Scrum Project?

I'm not sure if there is a simple answer to that question. There are lots of different kinds of risk, so who manages what may well change over time.

Even before the team is founded or designated to the project, there is the sponsor. S/he may be the person with the vision, the instigator of the project, or s/he may just be the person with for the money. In either case, s/he is or will eventually designate the product owner, whose primary responsibility is financial.

I think it is legitimate for the project owner to ask risk oriented questions right at the beginning: What are the big risks in the projects? What will cost us money if they happen or if we don't prepare for them properly? How do we mitigate those risks, keep our options open, and handle the issues gracefully when they happen? Once the team is consituted, these are questions for them to think about as well.

There are many risks, some more likely than others. Some "risks" are not risks at all, they are certainties. Changing requirements is high on the list. Scrum embraces these risks as part of the process.

A classic risk question in any user facing application: 'What happens when the usability people decide they need to redesign the UI late in the game?' Call it a special case of changing requirements, but you don't want to caught without a solid test suite if you have have to completely refactor the back-end.

Other risks are more subtle. Teams or individuals that do not have the necessary training or that don't work well together will make slow progress. This can be seen in the Product Burndown Chart. The Product Owner will see quickly that he has a time/scope/money problem, but figuring out the cause will need support from Team and Scrum Master.

What I don't like to see in a bid is boiler-plate text which can be "safely" ignored during the actual project.

Once the team is constituted and an initial product backlog has been created, the P-O and the Scrum Master and maybe the team will get together to prioritize the stories. There are many ways to do this, including bang for the buck, value to the P-O, deal with hard problems first, put off difficult and unclear issues until later (when they are better understood)... And yes, some of the strategies are contradictory.

So somebody makes a decision, and that someone is the Product Owner.

The Scrum Master and Team should help the P-O optimally prioritize the backlog so minimize risks. The team can be particularly helpful with technical risks and the Scrum process should help identify blind spots. But since ROI is the responsibility of the P-O and the consequence of risk is cost, managing Risk is fundamentally the P-O's responsibility.

Wednesday, July 23, 2008

When I started blogging, my (personal) objective was to make it easy for people who might be interested in my services to find me -- I figured they can find me easier than I can find them.

As the Scrum Breakfast blog has developed, it has taken on a life of its own, leading to invitations to do interesting things with interesting people. One such invitation came from Artem Marchenko, publisher of, the online journal of Scrum and XP software development.

Today I start as a regular contributor to ASD, focused on Scrum and Scrum coaching. My first article, Start with Trust, Start with a Retrospective is now online for your reading pleasure.

Thank you Artem for this opportunity, I'm really looking forward to interesting articles and interesting discussions! To your readers, I look forward to their comments and their suggestions for topics!

P.S. You can view my ASD blog online or subscribe to it.


Archem informs me that there is a DZone widget on all the ASD articles including including mine — just on the web site, not on the feeds. Obviously you are free to vote or not, but I wanted you to be aware that just 5-7 votes are typically needed for the promotion to the DZone front page. Such a promotion typically means 100-500 extra readers. And with such a small number of votes needed, every vote counts. So please vote if you like the article! Thanks!

Tuesday, July 22, 2008

Thought for the day: Venture Capitalists Should Only Invest in Agile Companies

In a new talk, Scrum cofounder Jeff Sutherland makes a compelling argument for Scrum, XP and Lean as the basis for "hyper-productive" companies. The potential improvement is on the order of a factor of 10(!). But to get those gains, you have to adopt Scrum and adapt yourself to Scrum, not the other way around.

The actual competitive advantage which can be achieved by consequently deploying the principles and practices of Scrum, Lean and XP have coincided with substantial revenue gains for the companies concerned:
  • Excellent Scrum - annual revenue up 400%
  • Good Scrum - revenue up 300%
  • Pretty Good Scrum - revenue up 150% - 200%
  • ScrumButt - revenue up 0-35%
BTW - "ScrumButt" companies score 7 or less on the Nokia test.

His recommendations to investors:
  • Invest only in Agile projects
  • Invest only in market leading, industry standard processes – this means Scrum and XP
  • Ensure teams implement basic Scrum practices
His recommendations to managers:
  1. Get your teams to pass the Nokia test. 
  2. Get management totally involved.
  3. Use communication saturation as a competitive advantage.
    • What backlog item will drive the earliest appearance of a high priority feature that can be tested?
    • Entire team decides this and it is the first thing selected to be worked on. 
  4. Extend the definition of done
A fascinating talk, which he will repeat at Agile 2008

Tuesday, July 15, 2008

Next Event/Cooperation with Jugs and /ch/open

Today the Swiss Open System User Group and Java User Group Switzerland announced a cooperative agreement for Scrum Breakfast Training Courses this September.

Members of either organization will receive a 20% discount on their registration fees if they register on the /ch/open registration page.

Furthermore, I will speak at an event hosted by jugs: Introduction to Agile Project Management with Scrum. Participation is free for Jugs and /ch/open members.

These should be good events and good courses. I am proud to work with both groups and look forward to see you at one of these events or courses!

Thursday, July 10, 2008

Books for Getting Started With Scrum

A collegue of mine asked me yesterday, "As a CIO, what books should I read to get up to speed on Scrum?" Here are my recommendations:
  1. Agile Project Management with Scrum by Ken Schwaber. The Basics, so start here.
  2. Agile Estimating and Planning by Mike Cohn  - How to plan the project
  3. User Stories Applied by Mike Cohn - how to gather requirements and size the project 
  4. Implementing Lean Software Development by Mary Poppendieck and Tom Poppendieck -- 7 principles to guide you from Concept to Cash
  5. Lean Software Development: An Agile Toolkit by Mary Poppendieck and Tom Poppendieck -- 22 Tools from Seeing Waste to Contracting alternatives to get you from Concept to Cash.
These books are focused on strategic and operational management.

What are your suggestions for engineering practice books?

Wednesday, July 9, 2008

Google'd ergo Sum

Traffic referred by Search Engines 
June 16 to July 9, 2008

I can be google'd, therefore I exist.

12 days ago, google delisted my blog from their index. No warning, no comment, no explanation. But the effects were immediate and dramatic. And no suggestions on how to get back in their good graces.

I got some help on LinkedIn - the most important of which was a suggestion to submit a request for reconsideration through Google web tools. It worked; 4 days after submitting the request, my site is once again receiving search traffic.

Of the web sites to which I have access to statistics, about 95% of visits from search engines originate from Google. was no exception. Just how important is Google to today's web site?

The questions for this week's poll (admitedly off-topic, but I can't resist):
  1. How much of your traffic in last 30 days originated from search engines?
  2. How much of that search engine traffic originated from google?

Next Scrum Breakfast in Zürich - September / October

The next two Scrum Breakfasts in Zürich will be dedicated to the theme, Scrum meets reality.
  • Case 1: Scrum and Offshoring: Scrum emphasizes communication and collocation. Offshoring is by defniition not collocated and communication is limited by distance, language and cultural barriers. Fredi Schmidli of SwissIT Bridge, a software development company with development resources mostly in Vietnam will present how the business works, what has been successful, where there could be improvement. Then we will discuss as a group how Scrum can be applied to the problem.
    September 3, 2008,  8.00 to 10.00 at namics.
  • Case 2: Scrum meets RUP: One company, one established process, one up and coming newcomer. How do we deal with the problem? Daniel Tobler of Zühlke (a company with long RUP tradition) will discuss how they position the two frameworks and where Scrum is gaining adoption and where not at Zühlke.
    October 1, 2008,  8.00 to 10.00 at namics.
I will send out invitations as we get closer to the events.

Not recieving notifications? Subscribe to the blog or request notification by email.

New Toys - Rate Articles

Blogspot now has a feature so that you can rate blog entries from 0 to 5 stars. I've turned it on, so please let me know which articles you like!



Managing Scrum: The Right Tool for the Job

So what is the best tool for managing Scrum? Well, it depends. It depends on you and your situation. Michael Dubakov recently asked When is a whiteboard a better choice? He proposes a decision matrix to evaluate the choices, based on a list of 9 criteria:
  1. Planning process
  2. Plan visibility
  3. Plan update
  4. Velocity tracking, Time tracking
  5. Burn Down Update and other charts update
  6. Communication
  7. Reporting
  8. People involvement
  9. Cost
Agile Tools Decision Matrix

I've captured Michael's Agile Tools Decision Matrix in a spreadsheet which you can download and modify to suit your needs. Just as an aside, he also stumbled upon a great name for cards, post-its and manual burndown charts: tangible tools. Even though he didn't really use it, I love it! It's succinct and correct, and the inherent advantage of tangible tools just jumps off the page - I will use the term moving forward. 

When to use tangible tools

Tangible tools are great for learning the processes and principles. Hung on the wall, they radiate information for all to see. They are extemely flexible for structuring and displaying information. Use them to get started with Scrum. Use them as long as you are happy with them.

I like to use tangible tools for initial planning (getting personae & and first cut at the user stories in a group workshop) and retropectives. In both cases the volume of information which needs to be permanently recorded is small and the flexibility and collaboration requirements for creating the information are high. I would also think about complementing a dedicated tool by hanging burn down charts on the wall: either printouts or manually maintained copies, especially if management is collocated.

When to use Office and Wiki

The use of office tools as a primary agile management tool appears to be on the decline. The dedicated tools are better.

Office tools are really good for slicing, dicing and presenting data. Dedicated tools can be great and do many wonderful things, but there is always something they won't be able to do or won't do the way you want it, and for that you need the flexibility of an office tool suite. So the data import/export is an important feature of these tools.

While using Target Process as a primary management tool, I have used Excel or OpenOffice to record the Sprint Contract, allocate costs between two parallel projects, and do preliminary scheduling. The Wiki has been useful for storing information about the project which does not readily belong to a story, feature, release or sprint (although this is a very small amount of information).

When to use Dedicated Tools?

When you need to. ;-) The advantages of dedicated tools range from information reuse, handling multiple or geopgraphically far-flug teams. A customer of mine wants to have one tool and one process for coorindate work and information flow across 3 suppliers.

How to decide for yourself

Start with Michael's Agile Tools Decision Matrix. Think about the importance of the various criteria. Perhaps there are others which are important to you. But feel free to tweak the weightings and the scores to get a result that you like. (uh - the politically correct phrasing is 'get a result that applies to your situation').

What do I do? I start with cards for teaching Scrum. I like cards for the initial concept and planning workshops and for the sprint retrospectives. I also use cards to manage my own work (just me planning my work a scrum coach and trainer).

Beyond that, I like web based tools. Available everywhere, even on the train. Manage workflows, find information effectively, reuse information. The bigger the project (and the longer the product should live), the more important these advantages. I think these factors explain the growth in dedicated agile project management tools over the last 18 months.

Tuesday, July 8, 2008

Managing Scrum: Traditional Project Management Software

From the moment I started working with Scrum until I wrote the quick poll on agile tool usage, it never even occurred to me to consider using classical project management tools like Microsoft Project. Why not?

Just as Neo knows that there is no spoon, and managers need to learn that there is no box, agile project managers know that there is no critical path. The world view, basic concepts and individual responsibilities in a Scrum environment are different and so the needs of the underlying software are different as well.

The Product Owner negotiates with the team on the basis of functionality to be realized, not in terms of tasks to be accomplished. The Scrum master eliminates impediments and helps assure that everyone is working on the highest priority stories in the current Sprint. The team members look to the task board to know what to do, to inform their colleagues of what they are doing, and to update their status and their estimates daily. The state of the project is visible for all to see at every step of the way.

What does classical PM software do? According to Wikipedia, the purpose of project management software is to:
  1. Schedule a series of events,
  2. Mangage dependencies between events
  3. Schedule people and resources
  4. Deal with uncertainties in the estimates of the duration of each task
  5. Arrange tasks to meet various deadlines
  6. Calculate critical paths
  7. Reporting
Do these functions correspond to the needs of an Agile Team? There is no critical path, so Gantt charts don't help much. The schedule of events is largely determined by the priorities of the Product Owner and are negotiated from sprint to sprint with the developers.

The estimates are handled in two levels of detail - 1) seat of the pants 'story points' for rough sizing and scheduling at the release level, and 2) very detailed task estimates for monitoring progress through a sprint. The only deadlines are sprint demos and they are fixed by the sprint rhythm.

Really the only thing left is reporting, but given that all the underlying concepts are different, of what use will be the reporting from such a tool ?

[Previous:Managing Scrum with Dedicated Tools ]
[Next: Managing Scrum: the Right Tool for the Job ]

Monday, July 7, 2008

Directory of Scrum Management Tools

Where do you find Scrum Management tools? Here are links to the suppliers mentioned in the poll on Scrum PM Tools:
Other tools (added thanks to comments or direct feedback):
Open Source:
If I've missed anything important, please add a comment, and I'll put it in the main article

Saturday, July 5, 2008

Scrum Management Tool Poll Results: Moving Away From Cards?

The poll on Scrum / Agile tools usage was the most popular Scrum Breakfast poll to date — 100 responses, of which 63 were using a dedicated agile project management tool. A market leader seems to be emerging in the agile project management space. I've finally gotten a chance to compare the results of this Poll with those of the Scrumdevelopment poll on the same subject from December 2006. The results indicate significant changes in what tools agile teams are using to manage their work. I wanted the results to be comparable with the Scrumdevelopment poll, so respondants could only pick one tool. So even though they might use several tools, they had to choose which one was the most important.
The data indicates a significant shift towards dedicated agile project management software (from 7 to 63%), away from Spreadsheets ( down 38% to 9%) and Wiki &Other/Homegrown tools (together down from 33% to 6%), and to a lesser extent cards (down from 36 to 18%). Open Source solutions and traditional project management software(with 4% of the respondants) do not appear to play a significant role in this market. Dominant Player? Under the commercial suppliers, VersionOne was the most top ranked response (54% of those voting for a commercial tool), followed by ScrumWorks at 17%, and TargetProcess and Scrum for Team System (8% each).
The question was raised in the comments whether one manufacturer might have orchestrated a high response rate. It's hard to know for sure, but I don't think so. Three reasons:
  • Representative of two suppliers other than the winner left comments on the blog while the poll was running and so were aware of the results as they developed. If they had wanted to orchestrate a get-out-the-vote campaign, they could have (and maybe they did!).
  • I did put out a get-out-the-vote reminder on the scrumdevelopment list. It produced little if any effect.
  • As I watched the voting progress, the development seemed organic: the pattern was established early and subsequent voting did not change the percentages much.
It will be interesting to see how these results compare with VersionOne's study, which will be published next month.

P.S. For those of you who want the details: the poll data can be downloaded as an ODF spreadsheet.
[Update: July 7: I have published a Directory of Scrum Management Tools with links to all the suppliers]

Wednesday, July 2, 2008

Scrum: "That won't work here!"

This morning, François Bachmann gave us a preview of his talk for Agile 2008 in Toronto. He talked about the problems of Scrum adoption, showed us some ways how the adoption can fail ("Yes, we want to do Scrum, but the customer shouldn't notice any change") and also some approaches on how customers can adopt Scrum sucessfully.

Today, customers say what they want (good). Then engineering estimates it (OK), then that estimate because the basis for cost calculation and scheduling, usually bound into a contract (inflexible = bad). He argued for the customers communicated vision, permissible cost & time, then the deveopers should convert that vision into reality -- something which excite the users as much as possible -- given the budget constraints.

So, instead of estimate the project at a 6 months and 1 Million CHF, allocate 4 months and 500'000. Build what you can. Examine the results. If it's good, release it, if it needs work, do more until your happy. The customer stays in control, but over the total costs and when release occurs.

This was really only a small fraction of his talk. The presentation is now online -- and for those of you who will be in Toronto, he will give the final version in the 'chanson française' track.

German Scrum Meeting

The German Scrum Group ("deutschescrum") is holding a get together in Munich next Friday, July 11. A full program of talks and discussions is planned, so it should be a very interesting day.

The event is being hosted by Allianz Deutschland (Dieselstr. 6, Unterföhring bei München). You can register either via Xing or via the Wiki, but registration is required to get past reception.
Personally, I'm really looking forward to this event. It looks like the perfect opportunity to meet interesting people and discuss interesting topics around Scrum.