Monday, June 30, 2008

Project Rescue at Internet Briefing

Carrot and Stick ( or "Zuckerbrot und Peitsche" ) is the title of my talk tomorrow at Reto Hartinger's Internet Briefing Group on saving flagging projects.

My indoctrination to Scrum was through the trial by fire of taking a flailing project, getting it back on track, getting results quickly, getting the customer happy, and restoring trust between the customer and the supplier. That's what project rescue is all about. (Actually, then we have set the stage for setting up the next project properly, so it doesn't get adrift in the first place).

So I am going to talk about these things and the tools that worked for me and the project I was charged with.

The best part of Reto's events is the information exchange after the formal presentation So it's always an honor to speak to Reto's group. It was the model for the Scrum Breakfast in Zürich...

You can download the presentation to my talk on project rescue and I look forward to some good questions and discussions tomorrow!

Sunday, June 29, 2008

New Domain Name:

Well, I'd been meaning to do this for a long time, but the painfully long is now just (and as soon as the last DNS update takes place, just "" will work too).

I've also started two sister blogs:
Why do the change now? Well google made me do it.

I discovered that is actually a very nice "poor man's CMS". A couple of nice layouts, easy RSS feads, nice customization. With tag searches, I can create links to groups of articles, like "next scheduled Scrum Courses" or "next Scrum Breakfast". The only disadvantage was kind of long domain names, like "". Or so I thought.

Yesterday I looked at google analytics and discovered I wasn't getting any referrals from google any more. Huh? Previously, I was getting at least 30 per day. What happened? I tried a search for peter stevens scrum, sprint zero or even scrum blog, queries which usually produced a top 10 placement, and discovered I was no longer in the top 200 results. :-(

It looks like the domain names, layouts and contents of scrum-breakfast blog and the new blogs were too similar, and google decided they looked like SEO spamming sites, sites which pretend to look independent but really only have the purpose of artificially inflating their page ranking. Or perhaps google decided to rank the newer blogs higher, even though they have virtually no content.

So I have not only put everything under one domain (so the relationships will be clearer), but also made the content more unique and minimized linking back and forth between the sites. Hopefully google will realize they've done me wrong and reinstate to its previous standing.

If anyone has any ideas on how to fix this problem, I'd really appreciate the help! Thanks.

Wednesday, June 25, 2008

What's the difference between a Project Leader and a Scrum Master?

This is a serious question ;-)

I just led a workshop for a medium size company which was considering (and is now planning) to start using Scrum as the organizing principle for their SW Development efforts. And exactly this question arose.

As it was, we had a classically trained project manager in the room, so he provided much insight into what is expected of a project manager:
  • Select Team Members
  • Select Tools
  • Plan Tasks
  • Monitor Progress and Sucess
  • Define and Impose Standards
  • Coordinate Work between Team Members
  • Budget
  • Scope
  • Set Priorities
  • Assign Tasks
  • Communicate with the Customer
Explicitly not part of the Project Manager's job is removing impediments.

How is this work distributed among the players in Scrum?

Select Team Membersinitialonce established
Select Toolssharedshared
Plan TasksX
Ensure satisfactory implementationsX
Define and Impose StandardsX
Coordinate Work between Team MembersX
Set PrioritiesX
Commit to Delivery Datessharedshared
Assign TasksX
Communicate with the Customer (for realization)X
Remove ImpedimentsX

So a Scrum master actually has very little in common with a classically trained project manager. The most important job of the scrum master is to remove impediments, something which is explicitly not part of the project manager's job.

The Scrum master is a 'servant leader' -- his primary job is to ensure that his team can work and that everyone is playing by the rules. He will also be an agent if not the agent of change in his organization: identify what prevents to organization from advancing and eliminating that impediment.

If you are looking for the difference between RUP and Scrum, waterfall and Scrum, or almost anything and Scrum, look first at the roles. Here is where the fundamental differences are to be found.

Tuesday, June 24, 2008

Target Process announces a Free Community Version

TargetProcess announced yesterday on their product blog the availability of the "Free Community Edition" of TargetProcess:

You may request and download On-Site version with 5-users licenses included....

[T]he Community Edition has no restrictions at all! It is a full featured version (yes, you have ALL features included: integrated bug tracking, test cases management, subversion integration, time sheets, Web Services API, etc). Moreover, Community Edition has no expiration date.

Read the announcement on thier product blog
This is a nice concept. I just today had chat with a colleague of mine who manages venture funded (and pre-venture funded) start-ups and asked me what software he should use. In a start-up, once the ball is rolling, you don't have to worry so much about money. It's available from revenue. Before that point, money comes from investors and is extremely tight. This concept let's him use a tool and get his processes down without any limitations or cash-out. When he is larger, he can pay his fair share...

Version One now Conducting 3rd Annual Survey on Agile

Joe Little wrote on the Agile Annoucements list:
Version One is doing its 3rd annual survey on Agile.

As they say in Chicago, home of Barack, vote early and often.
My Quick Poll on Scrum Management Tools produced some very surprising results - in particular that it appears that there has been a dramatic rise in the preference for software based solutions over cards and paper, at least compared to the agile poll taken on the scrumdevelopment group in January 2007. I am very curious to see if this poll confirms the results from this blog (which you can see in the right column and I plan to compare shortly with the 2007 results).

There was also some debate as to whether my quick poll was being influenced by a 'get out the vote' action by the Software suppliers, a concern which has to be even stronger when the supplier is sponsoring the poll.

Still, it's one of the few sources of long term data there is, and last year the claimed to have received 1700 filled questionnaires, so I will join with Joe and encourage you to vote!

P.S. Polls close on July 21st.

Scrum / Agile Training in Zürich in German

I will be offering two agile courses in German this September:
Agile Project Management with Scrum offers the substance of a Certified Scrum Master training without the expense of certification. How to plan, manage and control the Scrum software development process. A hands on introduction to the concepts needed by and tasks performed by the agile Project Manager (Scrum Master) and Customer or Program Manager (“Product Owner”) and the development team.

Sprint Zero with TargetProcess: You have done the Scrum training and read the book. Now it's time to roll up your sleeves and start your first sprint. What now? A hands on workshop, going though the entire process of planing, estimating, starting and reviewing a sprint. Not just for TargetProcess users.

On-Site Training

All Scrum Breakfast Training courses can be performed on your company site in English, German or French. You can also sponsor an open course near to your location by guaranteeing a minimum number of participants and helping with the logistics. The first step is easy: contact us for more information.

Juli Scrum Breakfast in Zürich:
Scrum? That will never work here!

The series of reports from the trenches continues at the Scrum Breakfast in Zürich. François Bachmann, one of Switzerland's most experienced Scrum Masters will give us a preview of his talk at the Agile 2008 in Toronto. He will talk about the challenges that companies face, when they elect for Scrum:
Scrum is not a Methodology Module, that can simply be plugged into a company. Adopting an agile approach is accompanied by profound changes for the Teams, Process and even the corporate culture. Change & Risk Management, Team Responsibility, Transparency and Learning Organizations are transformed from Buzzwords into routine for every staff member.

This talk will show how companies approach the introduction of Scrum, what challenges result and how these can be utilized to best advantage. Concrete examples from my experience introducing Scrum into Organizations will ensure that this talk doesn't get stuck in the theory....
Just like at every Scrum Breakfast, we expect the discussions after the talk will assure a vibrant information exchange and stimulating learning experience.

Location: namics zürich, konradstrasse 12/14, 8005 Zürich
Date: 2. July 2008
Time: Doors open at 8.00, Talk starts at 8.35, Finish by 10.00 (once again "Breakfast"-Time!!)

Registration throgh Xing the Contact Page.

Friday, June 20, 2008

Scrum Alliance Quietly Changes Certified Scrum Trainer Requirements

It appears the the Scrum Alliance has quietly changed the requirements for becoming a Certified Scrum Trainer (CST).

Last fall, when I was planing the transition to becoming an independent Scrum coach, I checked out the requirements for becoming a CST and was quite disillusioned to discover that a 5 year apprenticeship was required. May 2007 + 5 years = 2012. Sigh.

This goes a long way to explain why only 54 trainers have emerged from the pool of 25'000 CSMs and probably has a very positive impact (from the trainer's point of view) on the cost of certified Scrum training.

But now, the career path has been shortened. I could not find a press release, but now, according the Scrum Alliance, a CSM can apply to become a Certified Scrum Practitioner (CSP) after 1 year — this is not new. What is new is that a CSP can apply to become a CST after another year.

I think this is a good thing. First of all, the CSP rating now has a purpose in life. Before, someone like me might do it for marketing reasons, but there was no career path associated with it. Now there is clear justification for the journeyman certification (and I'm motivated to do it!).

Second, this is a sign that the demand for Scrum training (and coaching and consulting) will continue to rise (probably accompanied by a price drop, but the market will be bigger). If the demand for Scrum training were to remain constant, there would be no need to increase the pool of trainers. Call it a sign that agile is moving into the mainstream.

So my prediction: a lot more trainers, many more Scrum masters, and a lot more companies doing Scrum. (I just hope most of them really do Scrum!)

Thursday, June 19, 2008

Managing Scrum with Dedicated Tools

...So we started hitting limitations using spreadsheets to manage the Scrum process. What did we look for in a dedicated tool?

First we wanted to manage user stories, the product backlog, the sprint backlog. We wanted to record the conversations with the customer about stories. We wanted to keep information about a story (e.g. the results of an analysis, draft screen designs, test results etc.) together with the story. We wanted to be able to access the information from our office, but also from our customer site or while sitting in the train between sites.

I think the integration of the entire planning and development process is the major arguement for a dedicated tool. You enter stories, maybe group them into Features, Projects or Releases. Then you estimate and prioritize them. Then they are assigned to a Sprint (maybe a team member too) in the course of the Sprint Planing. The team (or a developer) breaks the stories down into tasks.

A virtual Task Board let's you see at a glance how work is progressing on the sprint. The team members' dashboards tell them what their top priority tasks and stories are.

Test features let you create tests which can be associated with one or more stories. Combine test cases into test suites, then peform test runs against a particular release or version. Record and report the success or failures (you did define the tests before starting to develop, didn't you?). Integration with Subversion or other source code control mechanism let's you associate modified files with particular stories or bugs. So if you 'fix' something, but something else breaks, it is relatively easy to identify what could have caused the problem.

Help Desk functionality lets you take requests from your customers or users, convert them into bugs or stories (or just send a response back to the originator).

In short, you get support for an integrated process (Lean Principle At Work: Eliminate Waste, in particular, searching for information), starting from preparation through deployment and operations.

What is the downside of an online tool? Mostly reduced flexibility compared to cards. A physical taskboard is a much effective Information Radiator than a web page. And cards are extremely productive for the kind of group work that occurs in Scrum - brainstorming stories, sprint planing and the retrospectives. A program structures information the way it was designed to. If your needs are different or simply not envisioned by the tool, then you have to figure out a work around. With cards, just write what you want and pin it on the wall where it goes.

Home Grown Tools

By the way, we did consider home grown tools. If you buy something, you invest money to save time. If you have more time than money (or if the products out there really don't do what you want), you invest time.

My team decided that this was not a good trade off. We would not be able to invoice the time to build the tool. The author is a single point of know-how loss (This point was confirmed when the author of the home grown tool we decided not to use decided to leave the company). The tool will do exactly what we want, but if we want it to do more, we have to invest more time to make it do more.

An active community or a support contract means (or at least should mean) the product will do more next year than it does today, without your having to do something (except install the upgrade). If your development effort is trivial, then this issue doesn't really apply. But if your effort is substantial, well, be sure to think about where you are going to get resources to meet new requirements on the tool.

[Previous: Managing Scrum with Wiki and Office]
[Next: Managing Scrum with Traditional Project Management Tools]

Wednesday, June 18, 2008

Managing Scrum with Wiki and Office

For my first Scrum project, I consolidated all of the wish lists into one spreadsheet which became our product backlog. Initially, I had 4 columns: Name, Effort, Priority and Estimate. I quickly added a "reference number" column to make it easier to find individual stories.

We set up a Scrum area on the wiki. It had hierarchical structure:
  • Sprint 1
  • Sprint 2
  • ...
  • Sprint n
    • Sprint Contract
      • Product Backlog at start of sprint (xls and pdf, as sent to the customer)
      • Status Overview from the Planning Meeting (current burndown chart, estimated resources for next sprint, definition of done, time/location of next demo meeting, etc.)
      • Sprint Backlog at start of Sprint (pdf - this is the actual contract)
      • Daily Scrum Spreadsheet (xls - updated daily)
      • Status Review from the Demo (stories/points accomplished, costs etc)
    • Sprint Stories
      • Story 103 Some story -> all project documents related to that story
      • Story 105 Some other story
      • Story 106 yet another story
      • ...
The daily scrum spreadsheet had 4 Columns: team member, yesterday plan, yesterday was, today plan, and impediments. "Yesterday plan" I copied from the previous days' "today plan' column, the rest corresponded to the three questions of the daily scrum. I updated the spreadsheet every day, adding one sheet per day in the sprint, copying "today plan" into "yesterday plan" and updating the remaining fields according to the results of the daily scrum. Then I uploaded the file into the wiki. There are pros and cons to recording data this way (particularly related to its impact on the flow of the daily scrum), and today I would do the daily scrum differently, but the traceability was awesome.

All other documentation gets uploaded into the corresponding task for within the Sprint. Confluence had a very nice feature that it would take first sheet in the daily scrum .xls file and display it directly in the browser from a Wiki page, saving the media break of having to download the spreadsheet and opening it in a dedicated program.

The advantage of this approach is self evident: you have these tools and you know how to use them (well, actually we had some user acceptance issues with the wiki). A spreadsheet is very flexible, so you can slice and dice the data as you see fit. Data reuse is not a problem per se. Backup is handled by whatever mechanisms you have in place for your PC. (You do have a backup, don't you?! If nothing else, copy the data to a memory stick and store it separately from your PC).

The wiki requires a lot of discipline so that you can find things. The basic Scrum flow was relatively easy, but data which did not obviously belong to a single sprint were always somehow special cases and finding them later was hard. A good search tool is a prerequisite for using the Wiki.

What finally drove us to a tool based solution was the need for a better tool manage the product backlog. The Wiki was too inflexible as a data structure and the spreadsheet was too flexible. The customer, when he had the data, could too easily change the structure of the spreadsheet. Assuring the quality of the input was a problem and we had "file locking" problems: Either the customer could update or we could update, but we could not see changes made be other until we got the spreadsheet back, nor could we update unless we had agreed with the customer that we had the writable copy.

[Previous: Managing Scrum with Paper and Cards]
[Next: Managing Scrum with Dedicated Tools]

Tuesday, June 17, 2008

Managing Scrum with Paper and Cards

The beauty of cards is threefold: 1) They are flexible and 2) they are easy to use when working in a group. Used to manage the sprint, 3) they are part of an extremely easy to understand overview of the state of the project.

So whether you are brainstorming on stories, planing tasks for the current sprint, or reviewing the sprint in a retrospective, cards are easy, let people work in parallel, and a very effective for communicating and prioritizing information. Even now, I prefer to use cards for the Sprint Retrospective, despite their drawbacks.

The drawback of cards are also threefold - reusing data, backup and distributed access to the data. So if you use cards to create your product backlog, that's fine. But now your CEO wants a report on which stories have been completed and which are forecast to be completed by which sprint. Easy to do if you have a spreadsheet, but first you have to enter all the data by hand, a job which usually falls on one person. Related to reuse is backup (and possibly other security issues): what happens if you loose the cards? (Anybody remember what a floor sort is?)

What do you do with distributed teams? Everybody needs to see the task board. In a meeting, everybody needs to not just read, but also post cards on the wall. How do you send the sprint contract to your customer? I have heard of teams using web cams and Skype connections to broadcast the task board to remote sites, but even that seems like a weak alternative. The remote sites have read only access to the cards, if they are even legible...

Using cards to manage the Scrum data (backlogs, taskboards, burndown) does not address how to manage other documentation, e.g. design documents, program documentation. What do you do with the rest?

And finally, how well does the approach scale? When you have hundreds or thousands of stories?

Personally, I use (and love) cards for the Sprint Retrospective and for the initial product brainstorming. For your first sprints, this is a good place to start, if not the place to start, but I think most teams will quickly reach the natural limits of this approach.

[ Previous :Paper, Office or Dedicated Tools? ]
[ Next :Managing Scrum with Wiki and Office ]

Monday, June 16, 2008

Managing Scrum: Paper, Office or Dedicated Tools?

My first real Scrum Project was trial by fire. I didn't have much time to get organized or to learn new tools and techniques. While I did consider paper and cards, and The Book sings the their praises, I had never worked with them before nor had I ever actually seen someone using them. So when it came to the choice of tools for managing the backlogs and the daily scrum, there was really one alternative: the spreadsheet (better the devil you than the one you don't!). And that's how we got started.

Very quickly, we discovered the limitation of a standard software based approach. That spreadsheet becomes an impediment. In our case, keeping the spreadsheet synchronized between my version and the customer's version was a problem. The customer would change the layout in ways I did not want (and probably the other way around as well). And getting the updated product backlog back in time to plan the next sprint was also a never ending challenge. So we needed a tool.

Actually, the team decided they wanted a tool, so they evaluated several tools and eventually chose TargetProcess.

Much later, I attended two different CSM courses, once with Mike Cohn and once with Boris Gloger. Both teachers showed how to do cards and what cards are really good for.

So what is the value of the three alternatives to managing Scrum teams? What are the strengths and limitations of each?

I'll look at these options over the course of the next few days.

[ Next: Paper. ]

[BTW - A part of me wants to call this 'Rock, Paper, Scissors', but I digress.]

Sunday, June 15, 2008

Quick Poll: Scrum Management Tools

Back in January 2007, a poll went out on the scrumdevelopement mailing list, asking its members how they managed their Scrum projects.

Scrum has come a long way since then (there are now some 25'000 CSMs worldwide) and judging by attention in the mainstream press, seems to be picking up steam in Europe as well.

So I thought it would be interesting to revisit the poll taken by the scrumdevelopment group:

Which tool / software do you use to manage your Scrum projects?
  • Paper (Cards, Sticky Notes)
  • Paper with a Webcam
  • Excel or OpenOffice Spreadsheet
  • Google Docs Spreadsheet
  • Jira
  • Microsoft Project (or other "classical" PM software)
  • Mingle
  • Rally Dev
  • Scrum for Team System v2.0
  • ScrumWorks
  • TargetProcess
  • VersionOne
  • Other Propietary
  • AgileTrack
  • XPlanner
  • Other OpenSource
  • Own Tools/Other
  • Don't know/don't care
As usual, I will post the results on the blog.

Results: Quick Poll on Scrum Training Needs

Last week's Quick Poll on Scrum Training Needs produced a lot of interest. The poll was divided into 4 sections. The 31 repondants voted on:
  1. What kinds of courses are needed?
  2. What advanced topics are needed?
  3. What language do they what the training in?
  4. What location/kind of course do they want?
Given the number of participants, I would not call this anything like a representative sample (and strickly speaking, an internet poll cannot be representative). Still...

The Certified Scrum Master Training seems to be well accepted among Scrum practioners. 48% of the respondants expressed a need for certified training. Scrum training however is expensive, and almost as many — 42% — felt the need for lower cost training (or at least would accept non certified training). Advanced topics (with out specifying which ones) and Getting Started courses were desired by only 26% of the respondants.

Under the advanced topics, (and more people checked these boxes than said they needed "advanced topics") Agile Planning and Estimating was the clear favorite: 48%, followed by Agile Contracting at distant 2nd — 42% —, followed by XP and Lean Workshops for Management (19% and 16%).

Interestingly, it seems the need for onsite training is larger than for open courses (or perhaps the demand for open courses is sufficiently satisfied): 35% wanted company courses, 19% each wanted open courses and webinars. Podcasts must be considered exotic with only 9% wanting podcasts.

The questions on language were interesting. The percentage wanting training in German was virtually identical to the % of visits coming from German speaking countries. The percentage wanting some other language was the same as the number coming from other non english speaking countries. Surprise.

On the other hand, 54% said English would be OK I suspect this result is a bit self-selecting, because this blog is written in English....

@jp - would you like to run this poll in german on your site?

One the whole, the demand looks healthy, particularly for on site training and training in local languages. (And Scrum Trainers know what they have to do to improve their training offerings...)

Next week, I want to revisit the poll on managment tools from January 2007.

Saturday, June 14, 2008

Scrum and Job Satisfaction

At the end of Stuart's talk on Guidewire, he noted that employee turnover is quite low at Guidewire. People who come just don't want to leave. And so he posed us one last tantalizing question: How much are the following workplace characteristics worth to an employee?
  • Enough time to finish
  • Using high skills
  • Variety in your job
  • Trust in management
My first reaction: That sounds like an Open Source project. There people work for free. So I don't know what the individual results are, but I'll bet the total is 100%!

And so the last slide, which gives IMD customers as well as anybody else managing software teams serious food for thought. Well-Being and Trust in the Workplace [pdf, 152KB] by John F. Helliwell and Haifang Huang, answers the question:
  • Enough time to finish: 11%
  • Using high skills: 19%
  • Variety in your job: 21%
  • Trust in management: 36%
Doing the math, we find the total is 87%. A Scrum culture has the same value as an 87% salary increase.

Monday, June 9, 2008

Successful Growth, but how?

Last week, I attended Basler Insurance's Forum for Small and Medium Enterprises. This year's theme was "Successful growth, but how?"

One talk stood out for me: Dr. Martin Strobel, CEO of Basler/Switzerland presented, 'Delighting your Customers: Profitable Growth through Value-Added Solutions'.

Here is the problem: Your market is saturated. Your product is not sexy. You are losing market share to more competition from other industries who are perceived as more dynamic. How do you turn this trend around? Or: You are a small player in your market. There are 7 or 8 players who are bigger than you. You can't attack all of them, so how do you grow in the face of tough competition?

These are exactly the problems Basler faced. The Swiss insurance market is quite saturated, but the banks have been gaining market share with high return (but high risk) investment instruments. In Austria they were barely a top 10 player.

In both cases, the answer was to get in the shoes (or more precisely in the heads) of their customers: Understand the customer, who he is, what he wants to do and why wants to do it.

Yes, a family father wants an attractive return in a industry with exciting potential. But he also wants security that his money will be there when he needs it. Yes, a homeowner wants the financial loss covered if his house burns down. But he also wants to be sure he gets out of the house if it does catch fire and he is probably interested in preventing a fire in the first place.

Kano Diagram, modified by StevensIn Austria, they identified doctors as a niche market and set out to understand what doctors need. They even went so far as to hire doctors to help them design their products. They came up with a customized product, which extended beyond the boundaries of a traditional insurance product but met the deeper needs of their target market.

Results: In Switzerland, first months sales for their combined product (with a 60/40 split between security and high return) were double their expectations. In Austria, they have been able to take a 40% market share in their target market niche (doctors and dentists) -- and networking with their customers is driving them to carry the product to other countries and markets.

Those of you who came to my talk on in the World Trade Center on Lean Software Development and Scrum will recognize the principles of product success (represented by the modified Kano diagram, above):
  1. Excite your customers. This is our highest goal in product design.
  2. Understand your customers. Deeply.
  3. Design your products to meet their needs, even the ones they don't about yet.
Thank you Dr. Strobel! This was a beautiful confirmation that the principles of lean product development can produce successful products on a grand scale!

Quick Poll: Scrum Training Needs

Since the last Quick Poll (Nokia Test) showed most teams not really doing Scrum, the question arises, how do companies see their need for Scrum training?

Presently most Scrum Training is organized as a kind of Guild. The first step is to become a Certified Scrum Master, this is the basis for all the higher ratings, the most important of which is Certified Scrum Trainer. CST's are authorized to train CSM's. As I write this, there are some 25'000 CSMs, but only 54 CST's. (Among other requirements, a CST must have been a CSM or better for 5 years).

The core of the program is the CSM training, but most trainers are offer additional courses for specific niches. As far as I know, Boris Gloger, Andreas Schliep, Joseph Pelrine and Roman Pichler are the only German speaking CST's (and even they do not offer all of their public courses in German).

So the question arises, does this offering meet the demand? What are the needs of your company for Scrum related training?

I've put together a list of alternatives — somewhat tailored to the needs of companies in my home country of Switzerland — please check all that apply in the list to the right.

My/my company's training needs include:
  • Certified Scrum Training for Scrum Masters
  • Lower cost, non-certified Training for Team members
  • Getting Started Workshops
  • Advanced Workshops for Experienced Scrum Masters
  • Agile Estimate and Planning
  • Agile Contracting
  • Lean Strategy Workshops for top managment
  • XP (SW Engineering) courses for developers and testers
  • Open courses to train a few individuals
  • On Site (company) training for an entire team
  • Web based training (webinars)
  • Podcasts
  • Training in English
  • Training in German
  • Training in French
  • Training in other language
  • English is OK
  • English is not OK
  • my company doesn't need agile training
  • don't know/don't care
Privacy: while I am not uninterested in the results of this poll, the polling software doesn't record information about individual voters (or if it does, it doesn't tell me about it). So I won't be contacting you on the basis of your vote (unless you actively contact me).

As usual, I will summarize the results after the poll closes.

[Update - I made a multiplication error, there are only some 25'000 CSMs, not 250'000 as previously reported. Furthermore, the Scrum Alliance has changed the requirements for becoming a CST. More in a future blog entry. ]

Sunday, June 8, 2008

Nokia Test Results: Is anybody really doing Scrum?

Last week, I challenged the Scrum community to take the Nokia Test: a Scrum litmus test to deterimine whether a team is agile and doing Scrum. How did the Scrum community fare?

Protecting Team Members from Management is clearly the biggest challenge faced by Scrum Teams. Only 51% of the respondants claimed that their team members were well protected from Project Managers or others disrupting work.

Prioritized product backlog and burn down charts are second and third from the bottom at 72% and 74% respectively.

Interestingly, all three points are issues relating to managment and the product owner (who is likely part of management), suggesting that management buy-in is a challenge. Either Scrum adoption is coming bottom-up or management is "talking the talk" but not "walking the walk".

On the total test score, only 26% of the respondants claimed an 8 on the Nokia scale. 36% claimed 7 points (total of 62% for 7 or 8 points). At least 7% did not meet the minimum definition of "agile"

Without question, doing Scrum is difficult. There was some discussion on the Scrum development group as to whether the Nokia test is hard enough. But even with this simple test, 3/4 of the teams in question are not doing Scrum. Or are they?

I have three issues with the Nokia test:

  1. "Software tested" is too specific to software development. I would ask the question "Is there a definition of 'done' which is consistently applied'?

  2. Continuous improvement is completely missing. Iterations don't necessarily imply retrospectives. I would add a question "Does the team perform retrospectives every sprint and implement top priority improvements?"

  3. Intent is also missing - Is the team actively trying to use Scrum to better realize the project? I think even if a team had to compromise on some points for tactical reasons (e.g. "the customer said no"), it should earn points for trying.

Friday, June 6, 2008

Guidewire: Waterfall is more expensive - 2

[Need proof that direct verbal communication is more effective than written communication? Stuart's talk Wednesday lasted about 1 1/2 hours. I've spent twice that time writing it down, and I am only half finished, and I am still remembering things I should have put into the first half! ]

Part one: Would you want to work for Guidewire?

Next question: Would you buy from Guidewire?

The fear was great that customers would perceive Guidewire as too chaotic to produce standard software. So how do you convince the customers to buy? A long discussion ensued which led to the conclusion that the sales process is the same, regardless of how you produce the software: Speak the language of the customer. Build trust: Deliver continuously and deliver what you promise. And avoid the customer's controller — he doesn't want to know about the details of IT anyway ;-).

And yet, standard software requires customization, so the customer and Guidewire must work together on projects to realize their solutions. Can Guidewire stay with Scrum or do they have to adapt to the customer the methodology?

The service companies in the room quickly agreed on the answer: you give the customer what he wants, right? Yes, you do. But according to Stuart, if the customer insists on a waterfall like model, Guidewire informs the customer that this will cost more. Stuart did not say how much, but enough to encourage most customers to not only accept Guidewire's using Scrum but also to use it themselves.

As the company approached 300 employees and started thinking about going public (necessary so that employees could cash out), it had the feeling it had reached certain limits to growth.

Can Guidewire go public as a Scrum company? How to explain to Wall Street that the company reorganizes every month and that the COO changes every month? Can it grow further? The company had three choices: Continue with Scrum the way they had been doing it. Modify Scrum in some way, or introduce a layer of management hierarchy for the benefit of Wall Street. What do you do?

We discussed a number of alternatives, and particular discussed the case of Gore-Tex. This company has several thousand employees, but is organized as a holding company with some 30 independent subsidiaries, each one doing some specific application of the Gore-Text technology, but with no more than 150 people.

Interestingly, Guidewire's management did not trust the Scrum process enough to handle discussions of serious change. People were too happy the way they were, and a serious change, even the potential of serious change, could be very demoralizing.. (More on this in a separate blog entry). So the change did come top down, presumably based on input coming from the Scrum teams.

According to Stuart, they seriously considered the last alternative (classical management) and even went to far as to hire a "gray hair" - a senior executive from IBM. But the culture was so different, that he didn't last in the job. And this convinced them to stay the course with Scrum. Continue doing what had made them successful.

One change they did make: they reduced the teams down to so-called "pods". A pod is a group of 3 to 6 developers. Bigger teams were seen as counter productive.

At the end, Stuart Presented us with an interesting study on the relationship between Job Satisfaction under Scrum and pay scales, which I will present in a separate blog entry.

All in all, a very interesting discussion about a very interesting case.

The question which I wish I had asked was about how these "pods" are coordinated. The role of the Product Owner was a bit unclear. The Product Owner are at least somewhat outside of Guidewire's modified Scrum process with it's continuous reorganizations. A Product Owner is responsible for each of the 5 product areas, but there still between 50 and 100 teams. How to organize and coordinate the work between the teams? Time didn't really allow us to get to this question.

Next: Scrum and Job Satisfaction

Stuart, thank you very much for coming!

[Update: JP has published a summary, in german, on his blog, with emphasis on the workings of Guidewire pods. I suppose I'll have to translate this (back) into english....]

Thursday, June 5, 2008

What is Scrum?

Xing just opened up an agile forum in their German Speaking Project Management Group. Some 30'000 members. First topic of discussion: Is agile mainstream? Before they could answer that question, they needed to ask, what is agile, what is Scrum? So here, in ten points or less, what is Scrum:
  1. use good people
  2. play by simple and clear playing rules
  3. develop in small increments
  4. measure progress exclusively in terms of finished functionality
  5. have a clear definition of 'done'
  6. enable direct communication between customer and developer
  7. have a defined rhythm of planing, doing and evaluating
  8. remove impediments ASAP as they arise
  9. assure continuous improvement through regular retrospectives
Sounds simple, doesn't it? People will try to tell you they've been doing just that for years.

But they haven't. Scrum is radical, it's so different that only companies who are facing serious pressure will really embrace Scrum.

Many companies will do it part way (and that's OK - they'll get some of the advantages, if they do enough of it), but innovative companies with visionary thinkers or in those pressure situations will be the companies who really profit from Scrum: the start-ups, the project rescues (my trial by fire) and the companies facing enough competitive pressure or structural change that it really hurts. These will be the full adopters who get the full value from scrum.

There's more to it than that, of course, but this should help you get started.

Guidewire: Waterfall is more expensive - 1

Scrum is in fact being used as an organizing principle in large and growing companies. Yesterday, Stuart Read came to the Scrum Breakfast in Zürich to tell us about Guidewire, probably one of the first companies ever to have adopted Scrum from top to bottom.

Guidewire is a no longer-quite-so-small start-up (350+ employees) which provides core IT technology to the insurance industry. The entire company is organized with Scrum, even the top executives are part of Scrum teams, and Stuart prepared what is probably the first documented case study of a such a company.

Stuart's method of presenting the material was most unusual. Instead of relying on a presentation to convey information, he divided the case study into an A Part and a B Part. The A part provides the background, describes the company, its successes, what's unusual about the company, etc. The B Part, which was only made available during the workshop, brings the reader up to a point where the company is faced with a challenge, which is then the subject of discussion in the workshop.

Everyone got to read the A part in advance. Then we discussed the situation and some interesting questions about the company. (Unfortunately only a limited version of the A part of Guidewire case is available on the net). Then he posed a series of questions to the group, only after discussion did he present the solution which Guidewire chose.

Guidewire was founded in 2001, in the wake of the Dot-Com boom/bust and just as the Agile Manifesto was being finalized. Company management decided early on to use Scrum as the organizing principle of their company. Why? Because the founders did not know the insurance business and needed a way to learn quickly. [Lean Principle at work: Maximize Learning]. Guidewire added some interesting twists to the basic Scrum structure. The entire company applied Scrum from day 1. So not just software development but also finance, marketing, etc. The Scrummasters rotated every month. So in essence, the company re-prioritized and reorganized(!) every month.

First question: Would you want to work for Guidewire? For Scrum evangelists (and the 30 or so participants in yesterday's event), no question, but for MBA students/executives in training? Not so obvious. Reorganizing every month can be traumatic. [And let us remember that MBA Students are being trained to work their way up quickly through middle management which, as Parkinson's Law explains, exists to preserve law and order — otherwise known as itself -- not to reinvent itself every month]. So does all this reorganizing really make sense? And this lack of obvious hierarchy is really quite threatening — How do I defend my Senior VP title? So either you love it at Guidewire or you hate it (and this later proved to be challenge when looking for Senior executives).

Who do you hire to work in a Scrum environment? We can (and did) talk about the personality types who are suitable for Scrum. Self Motivated, Team Players, Sense of Humility, Sense of Passion. But Guidewire applied the Scrum Principle of self organization to hiring as well: Let the teams pick. There is no interview process, just a 1 day on the job trial. If the team wants the candidate, s/he stays. In Switzerland, we call this a "Schnuppertag" — a day to sniff noses and get the feel of each other. (Seems like there ought to be résumé screening process: According to Jürg Stuker, the ratio of résumes to hires at namics is 100 to 1! )

Next question: Would you want to buy from Guidewire? Again, initially a difficult sell. The development process seems chaotic. The predictability of a 2 year road map is missing, so there is an impedance mismatch between the big customers (and all insurance companies are big) with a 1 to 2 year planning cycle and a supplier with a 2 month turn around cycle.

When we are honest, this two year roadmap is a kind of fairy tale - whether it will really come to pass is anybody's guess. But this roadmap subsitutes for trust, or perhaps simulates trust. So Guidewire started selling to second tier companies — hungier and less complicated than the biggest, most established players. With time, working software and responsiveness to customer needs wins out. Trust is really about track record and relationships, both of which are built over time.

Part 2: Would you buy from Guidewire?
Part 3: Scrum and Job Satisfaction

[ Update: Jürg Stuker has published an excellent synopsis in German on the namics blog. ]