Radical Management Gathering

Revolutionizing The World of Work

When I talk to large organizations about Scrum, I frequently hear "this is great, but what do we do in fields like hardware development or pharmaceuticals, where we can't produce potentially shippable product every thirty days?" Radical Management provides an interesting answer while building on the strengths of Scrum, Agile and Lean:

The purpose of work is to delight your customers. 

So "delivering" every Sprint means something other than delivering a good or service in a finished state. It means delivering an increment of Delight to your customers.

This May, Steve Denning (The Leader’s Guide to Radical Management) and Seth Kahan (Getting Change Right) will be hosting a two day gathering where "coolness, innovation and serious fun intersect." And I am proud to be a Practice Partner!

We want people who are tired of a world in which people are being treated as things, where employees are seen as “human resources” and customers are seen as “demand” that has to be manufactured.

We are offering here more than a set of tools. We are seeking to create a state of mind that starts with a change of heart.

This is about locating that sweet spot where coolness, innovation and serious fun intersect. The fact that it also happens to be ultra efficient and productive is another big plus, because that means that the economics will drive it forward.

This is about creating stuff that people must have. And in the process, we stop wasting time on stupid things, spinning wheels, going through useless routines, attending management prayer meetings and spending endless amounts of time and energy on second-guessing what the boss wants.

I hope that you will join us! Check out Steve Denning's blog for more information or jump straight to registration...

Details:

• What: Revolutionizing The World of Work 
• When: From 8.30am Thursday May 12 to 5pm Friday May 13, 2011
• Where: Downtown Washington, DC
• Registration: online

Scrum in a Management Consulting Context

When the topics is hot, people will come. And so it was for the first Scrum Breakfast in Zurich this year. 38 people came to learn and discuss the case of an early adopter of Scrum outside the Software context.

Michael Stump spent three months working with a consulting company -- that had nothing to do with software -- coaching them through a pilot project. On the face of it, consulting seems like a logical application for Scrum. By definition, consultants solve complex problems. Quality is important. And the problems are big enough that they can't be solved by one person alone.

On the other hand, internal competition is intense ("up or out"). Many practices around Scrum were established in a software context (user stories, potentially shippable product). So what does a backlog entry look like? What is the definition of done? How was the customer involved in the project. Many questions!

Michael presented his experiences introducing Scrum into this organization. Really interesting were the discussions around the definition of done, what impediments arose and how they handled them (for example team work and the trust culture vs. up-or-out), and the bottom line value doing Scrum.

What was the bottom line? Everyone had more fun on the job. The quality was substantially better. And the team was a factor of 3,4 more productive (although there was a lot of discussion about what this actually meant).

You can download Michael's presentation on the leanagilescrum.ch website. And Micheal is planning to repeat his talk at the Scrum Breakfast in Bern. Watch for it on the SwissICT Events page.

P.S. We started a new idea: Lean & Scrum for Newbies (dare we call them "Beginners?"). Mischa Ramseyer gave a 15 minute introduction into the practices and values for the benefit of the people coming for the first time. Probably a third to half of the participants shorted their morning coffee to listen in before the main program started. So we'll be repeating this in the future...

Moving forwards with V-Model

I recently worked with a VP of Quality Assurance.  His system needed high quality: it transported 10s if not 100s of Millions of CHF every day. It had to work and the consequences of it not working were horrendously expensive! He genuinely believed in the V-Model. Introducing the V-Model had substantially improved the quality of the system. His QA department was the last guardrail before the cliff.

In retrospect, I am not sure if his inspiration was the German government V-Modell, or the more general V Model.  In any case, the developers wanted to do Scrum and he wanted to preserve the essential aspects of the V Model which had enabled the level of quality they had achieved. How can he do that while moving forward in a Scrum context?

For him, three facets of the V Model were essential:

1. Tester and developer roles should be separated ("4 eyes principle")
2. Requirements should be matched with Acceptance tests
3. A quality gate between QA and Production is essential to prevent poor quality code from entering service.

Applying the V Model mapped naturally to their organizational structure (roughly: Business, SW-Dev, QA, Production). This had improved the software from where it had been previously, but had caused substantial rivalry between the organizations, especially between Dev & QA:

A development manager was fond of telling people "75% of the time spent in the QA phase is not a about fixing bugs, but agreeing on the right version of the spec, the right interpretation of the spec, the right test data, etc. Most 'findings' aren't really findings, but misunderstandings."

The test manager responded: '3/4ths of the genuine findings do not get fixed before the system goes into production.' 

Both of these statements were correct. How can you fix this the problem? The short answer is for the stakeholders to agree on the acceptance tests before the developer starts to write the code. This is what Scrum helps you do.

Separation of tester from developer role

An side-effect of having a QA department do acceptance testing is that the Business people who defined the requirements are not the necessarily the people accepting the results (until it is put into production). So the tester has to interpret the spec -- possibly, but not necessarily the same spec that the developer is working to -- and this leads to differing interpretations. Who knows the answer? The customer, user or stakeholder: "Business."

Scrum does not say how to test. It does say that 1) Product Owner represents the interests of all the stakeholders (and is free to involve them directly when appropriate), 2) the Team has all the skills necessary to get to Done -- which surely includes analysis, coding and testing, and may include other skills, 3) that the Team is responsible for the Quality of its work, and 4) that the Product Owner and Implementation team must agree on a Definition of Done to ensure the quality of each feature as it is produced.

This definition often includes some form of pairing, e.g. Design Review, Code Review or Pair Programming or and independent test. Many teams automate the execution of their test suites. The discussions which occur in preparation of and during the sprint ensure all questions related to a feature get raised and captured in some form of acceptance test.

So adhering to the "4-eye principle" is ensured explicitly by the planning process and strengthened through the definition of done.

Requirements should be matched with Acceptance tests

The latest version of the V-Modell ("XT") was developed in 1997 and it has not been updated since. Therefore modern thinking about 'test-first' strategies, such as Test Driven Development, has not been incorporated into the V-Modell.

In Scrum, every entry on the Product Backlog represents a requirement and either is, or can be mapped to, an acceptance test. The corresponding acceptance test(s) are defined no later than the Sprint Planning Meeting, and probably somewhat earlier. The definition is moved to the front of the process, and the developers have a fixed target to work toward.

Quality gate between QA and Production

The Definition of Done is in essence an internal quality gate for the team. It is passed by every function that is completed in every sprint. Teams often include test automation in their definition of done, so that running, tested features in this sprint stay running and testing in future sprints.

I like to compare software production with auto production at this point. When Toyota has finished building a car, they do a quality check to make sure there are no defects. They don't expect to find any, but they check anyway. Why? Because it will be more expensive to fix it in the field, and they want to prevent the mistake from reoccurring.

In software it should be the same. The initial quality gate in Scrum is the definition of done, which is checked by the team.

So your teams work on improving their quality though automation and test first strategies. The definition of done always includes verifying the that the acceptance tests pass. At each Sprint Review, the Product Owner confirms that the implementation is doing what the stakeholders want.

If the team has achieved the level of quality which is possible through automated testing, then a relatively quick sanity check should be sufficient to ensure the system will work properly in production. There should be no question whether the features will meet the requirements; that has already been verified by the stakeholders themselves. (Actually achieving this level can be a substantial challenge and may take months or years to achieve - in the meantime you will have no choice but to do manual regression or integration tests).


So Scrum addresses all of the key points of his V Model while recognizing the chaotic, creative nature of software development. The organizational structure around the development organization may change, but happy users of the V Model will recognize many of their core principles in Scrum.

---

Update: Thanks to James Christie for pointing out that there are really two V-Models - the very specific German V-Modell (which was the subject of yesterday's article) and the vaguer 'V Model' which is familiar to most testers. For an excellent article on the history and context of the V Model(s), see The Dangerous and Seductive V Model.

Scrum and V-Modell

One the participants from my last in-house course (at a bank) found that I was unfairly grouping the V-Model with "waterfall." So let's look at what is the difference between Scrum and the V-Model, see where the two come into conflict, and see where they can complement each other.

Update: It turns out this comparison is not as simple as I thought - there are actually two V-Models: a German government project management methodology, das V-Modell and much vaguer V Model that testers are familiar with. In researching this, I landed on the German government version, not realizing that there are really two versions of it. The following discussion is related to the German government model. Thanks to James Christie for pointing this out!

Scrum is a simple, team-based framework for solving complex problems. Its roots are in product development. It assumes that solving complex problems (like creating a software product or system) is a creative process, which by definition, cannot be defined in advance. This class of problems requires an empirical approach, with much interaction and feedback between the developers, users and stakeholders in the project. Therefore Scrum says nothing about how to do the work, but defines a few roles, rituals and artifacts to ensure effective communication.

The V-Modell is "designed as guidance for planning and executing development projects.... It defines the results to be achieved in a project and describes the actual approaches for developing these results. In addition the V-Modell specifies the responsibilities of each participant. Thus, the V-Modell describes in detail, 'who' has to do 'what' and 'when' within a project."

A key feature of the V-Modell flow is the Decision Gate, which indicates "a milestone in the project sequence, where the current state of the project has to be evaluated. For every decision gate, the V-Modell defines a quantity of products which must be submitted in state Finished..."

So looking at these descriptions, I must say, V-Modell looks pretty Waterfall to me: a defined approach, with clearly defined phases and strong gatekeepers between the phases.

So philosophically, Scrum and the V-Modell are on different planets:

Scrum = empirical

V-Modell = defined

Often this phase based approach is reflected in the organizational structure. Requirements phase comes from Business, Implementation from Development, Test from QA, and Deployment from Operations. Each group of course has its own Vice President, which is helpful for the cooperation... not!

If they are so different, is there value in the V-Modell and how can a V-Modell practitioner so a future for himself in a Scrum managed environment? I'll look at this question tomorrow.

How we do Sprint Planning 2

Many people think Sprint Planning 2 (the second half of the Sprint Planning meeting) is just about creating and estimating the list of tasks for the selected product backlog. This cannot be a bigger over-simplification! Here is simple approach to conducting an effective Sprint Planning 2 Meeting.

In Sprint Planning 1, the Implementation Team and the Product Owner negotiated which "stories" would be implemented in the coming sprint. The team made sure it understood the stories, in particular the acceptance criteria (I recommend agreeing on 'How to Demo').

During Sprint Planning 2, the Implementation Team must figure out how to solve the problem it took on in Sprint Planning 1. This consists of two parts:

1. A solution concept - a design, architecture or whatever, which explains how the problem is to be solved/feature is to be realized.
2. A list of tasks - what steps must the team do to get each selected backlog item to the state 'done'.

The goal is not an absolutely perfect design or task planning. It's about getting a clear enough concept that the team can start work.

In my coaching, I have found it effective when the team members work in pairs in a solve-present-solve-present sequence. They brainstorm the technical concept, then present it to the team. Depending on the feedback, they may need to enhance, modify or possibly even rethink the concept. Again working in pairs, they then create task cards, showing the route to "done." Finally, each pair presents these tasks to the entire team.

Let us assume the team has committed to 6 stories, that there are 6 team members, and that the team is doing 2 week sprints. So the Sprint Planning 2 is time-boxed to 2 hours. The team forms 3 pairs and each pair works on two stories. So the agenda for the meeting is as follows:

Agenda for Sprint Planning 2

14.00 - 14.05 Start - pair off and divide the stories among the pairs.
14.05 - 14.35 Concept - each pair brainstorms on the technical concept (producing a diagram, text or something which can be presented to the rest of the team)
14.35 - 15.05 Present - each pair presents their solutions to rest if the team. The presentation and Q&A time for each story is time-boxed to a total 5 Minutes (30 Minutes / 6 Stories )
15.05 - 15.35 Tasks - each pair creates a set of tasks to get their stories to 'done'. Each task represents a goal for the day. The tasks are not estimated, but should be completable in one working day or less. This saves a lot of effort!
15.35 - 16.00 Present - again, each pair presents the tasks needed to get their stories to done. In the course of discussion, they may discover missing or unnecessary tasks. Each story is time-boxed to 4 Minutes (25 Minutes / 6 Stories ).

This approach ensures that at least 2 people have thought intensively about each story. It gives structure to the meeting, so the team can accomplish the meeting within the time-box. And by presenting and discussing the solution within the whole team, the rest of the team is much better positioned to help out during the execution of the sprint.

Scrum Breakfast March: Tips for Working Virtually

Virtual, distributed teams are becoming more and more commonplace, especially in the IT sector, where the necessary communications infrastructure is generally available. Wireless LANs are available nearly everywhere and the capabilities of Notebooks, Cellphones and PDAs are increasing daily. These developments enable virtual teams, not just for agile projects but in just about any field. Although the technology is a prerequisite, the interpersonal cooperation is of primary importance and that is the subject of this talk.


Dr. Deasún Ó Conchúir is an experienced project leader, consultant, trainer and author. Currently Deasun is focused on Collaboration and Virtual Working for Scatterwork GmbH. His book "Overview of the PMBOK® Guide" is has been published by Springer-Verlag.

He will discuss the principles of effective virtual collaboration and provide tips and tricks, that you can put to use right away.

When: Wednesday March 2, 2011, 8.00 to 11.00
Where: SwissICT, Vulkanstrasse 120, 8048 Zürich

As usual, the event is free and the SwissICT will provide Coffee and Gipfeli.

The registration form is not online yet, but you will be able to register with the SwissICT here as soon as the form has been activated.

Venue for Lean Leadership Course with Mary & Tom Poppendieck

Readers of this column know that Tom & Mary Poppendieck will return to Switzerland for a reprise of their successful Lean Leadership Course. Last year we had a mix C-level executives from medium to large companies and operational ScrumMasters, Project Leaders and Product Owners. A high point was the idyllic location and the opportunity to exchange ideas and experiences at dinner (and afterwards)!

This year, I am pleased to announce the course will be held at the historic Karthause Ittingen. For participants who wish to spend the night, we have reserved a block of rooms at the Hotel Domicil. And we plan to invite everyone for dinner after the first night...

Check out the details for more information on Tom & Mary Poppendieck's Lean Leadership Course... May 26 & 27 at the Karthause Ittingen.

Beyond Scrum? Radical Management

Six years ago (wow!) while browsing a bookstore in Seattle, I picked up a book called 'Agile Project Management with Scrum' by Ken Schwaber. For me, this book was a revelation! Finally an approach to project management which made sense! It focused on people, communication, and producing (quality) results. I was immediately convinced by the approach and, well the rest is history. Today, Scrum is the center of my professional life.

I frequently teach my Scrum Team Jumpstart to companies wanting to free themselves from the chains of their own organization. What feedback do I get after such courses? Here are the top three comments:

1. Our management should take this course!
2. Don't just talk about software development.
3. What comes after Scrum?

Last spring, I had the privilege of reviewing a draft of The Leader's Guide to Radical Management, by Stephen Denning. My reaction was the same as the to Ken Schwaber's book: Wow! Simple principles and practices for leading modern companies. I immediately incorporated key lessons from his book into my teaching (which I think is major contributor to feedback item #1). His book is out now, and I highly recommend it.

Denning observes that management has been unable to respond to the changed conditions of the 21st century economy. For example, since 1985, large, established companies have produced virtually no new jobs in the USA -- compared to start-ups who have produced 40 million new jobs in the same period. 75% of workers world wide are not fully engaged in their jobs. And Dilbert haunts the hallways of major companies around the world.

In the course of his research, Denning looked for companies and individuals who were especially engaged and productive. He was surprised to discover two areas that were over-represented among the engaged and effective: Software Development and Manufacturing! Software development meant companies doing Agile and Scrum and manufacturing meant mostly Toyota and Honda, i.e. the role models of Lean. He also found people in many other branches applying the same principles and achieving similar results.


Seven principles of Radical Management

Denning avoids using Scrum and Lean terminology to better transport the principles out of their original context. He identifies 7 principles (and some 70 practices) of these enabling environments:

1. Delighting Clients
2. Self-Organizing Teams
3. Client-Driven Iterations
4. Delivering Value to Clients in Each Iteration
5. Radical Transparency
6. Continuous Self-Improvement
7. Interactive Communication

Practitioners of Scrum, Lean and Agile will of course recognize the principles and practices as their own.

So where do I think Scrum is going? I think Scrum is expanding beyond software development into more general management. Why do I think this is case? Besides my own empirical experience, Steve's book provides many answers.

As Scrum expands into into general management, Scrum may or may not keep its name and strict practices. It might morph into something closely related but divorced from its software roots. In any case, I recommend Steve's book highly!