Succeeding with Agile: A guide to Transitioning

Mike Cohn gave a talk at Agile 2007 about how to succeed in Agile based on his experiences with different clients transitioning and successfully transforming their organization.

Mike starts out by addressing why organizational change is hard:

1. It’s not top down where a strong leader sets a vision and people follow it, and it is not bottom up where team start and others follow until you run into groups that are powerful enough to squelch transition.

2. Best practices are tempting, but once we identify something as best, we stop changing. We have to keep inspecting and adapting otherwise we are not agile.

3. The transition has to also go with a transition in the development process

4. We cannot predict how the organization is going to respond. We want to effect the organizational change in an incremental manner.

Mike describes how if we break things up into small pieces, work on the smaller more manageable pieces and then try to put them back together we do not necessarily get the whole picture. We need to think of organization as complex adaptive system. We need to look at success as achieving a good fit with the environment instead of as closing the gap with the desired state. We have to acknowledge that agents are closing local goals and closing local gaps. They are thinking about their own job security and their own vacation schedule. It is ok to set vision, but each agent is pursuing their own local goals and they are taking local actions and they all interact.

Mike next contrasts the traditional model of change vs. the complex adaptive model for change.

1. Traditionally, behavior is controllable and predictable. In the complex model we cannot control behavior.

2. Traditionally, we can establish directions. . In the complex model direction is established by the moving groups.

3. Traditionally there is clear cause and effect. In the complex model, there is a ripple effect.

4. Traditionally, relationships are directive. In the complex model, relationships are empowering and can go in both directions.

5. Traditionally, focus is on efficiency. In the complex model we are more interested in responding to change.

6. Traditionally, decisions are based on fact and data. In the complex model, decisions are based on patterns and tensions between groups.

7. Traditionally, leaders are the experts. In the complex model, everybody can help lead. Leaders are there to facilitate and support.

Introduction to Agile for Traditional Project Managers

At Agile 2007, Stacia Broderick mapped the PMBOK process groups and knowledge areas to agile practices. She started by defining agile as a value driven approach to building working software by collaborating with customers and embracing change. The characteristics of agile are:

1. Iterative, incremental

2. Risk mitigation via use of timeboxes

3. Continuous improvements

4. Team ownership of quality

5. Value based prioritization of requirements

6. Dedicated self managing teams

7. Collaborating with customer

8. Embracing change

9. Modern engineering practices

Next she went over the Agile manifesto and the principles of:

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

She then mapped the PMBOK process groups of Initiate, Plan Execute, Control, and Close to the agile practices of Envision, Speculate, Explore, Adapt, and Close. She described how the traditional iron triangle of Scope, Time, Cost or Budget has a fixed scope from which a date and cost is derived where as in agile, the triangle is reversed with the date and cost fixed and the scoped varied or derived based on a prioritized product backlog.

Agile in the Waterfall Enterprise

At Agile 2007, Michelle Sliger discussed some hurdles that agile teams face in a waterfall enterprise and how to clear them:

1. Resistance: There will be resistance from management, the business and the team. Don’t try to sell agile to management. Instead fly under the radar, operate in stealth mode and just go ahead and product working software of high quality. When talking to management about agile, advocate using their language. Avoid using terms like agile, xp, scrum sprints and use terms they are already familiar with like ROI, cutting costs, increasing quality, earlier to market, or share success stories that prove increase in productivity. When dealing with resistance from the business, try to get them involved early on and suggest trying things for 30 days and then have a retrospective. Try to get a client or at least a proxy on site. It is easier to start out with XP technical practices. When facing resistance from the team, try to get the right people on board and empower them.

2. Culture: Review the companies mission statement and see if there are values mismatch between what is stated and what goes on a daily basis. Try to clear up misconceptions of Agile. It’s a new methodology but not a fad.

3. Resource management: What if the organization has a matrix environment. Agile teams are collocated and dedicated to the project. But agile can be distributed, but it won’t be as effective and efficient as collocation. Dedicated is different from devoted. Dedicated means team sticks to the project through completion. Use a release plan or quarterly plan to help resource manager in allocating people. Use release plan and product roadmap to assist project managers in the allocation of the budget.

4. Vendors and Contracting: If a vendor is not agile, evaluate the duration of the relationship. If it is short term, then there is no need to explain agile, but if it is longer, then you should explain it. If customer is not agile, then think about how to present the contract. Start a conversation with them. Would you like us to show you progress on application every 2 weeks? Would you like to change or adjust your requirements after reviewing the progress? Work through time and material contract with option to renew or cancel every 30 days.


5. Facilities and Tooling: Use what works for you. Ask the team and find a solution, create or find an open space, make it a war room, use a whiteboard. Use open source tools.

6. Cost accounting and reporting: How are we going to do the budgeting without a BUFD (Big upfront design document)? You have to do it, but you do it differently. Find out cost per iteration. Find out cost per story points. Find out what metrics need to be tracked. If GANTT chart is still needed then you can give it but duration will always be the same, task assignment will always be ‘TEAM’. Are you capitalizable or an expense?

7. Auditors: talk to auditor and find out what they are looking for. Add those to the product backlog and include them in an iteration to create these docs. Be barely sufficient in your documented proof.

8. Communication is key. Agile is a silver bullet but only if it is implemented properly.. Inspect and adapt and communicate. Have a communication plan in your transition rollout plan. Provide support for sharing knowledge and experience and continued education. Define escalation and issue resolution.

9. Miscellaneous:

• a. passing off code to production (add one iteration to make it production ready – get sign offs, get help desk up to speed, get training materials, get docs).
• b. Reward and recognition: Not about individual performance but about the team making its commitment. How do we do that? Ask the team. As agile team become more and more performing, they will level off. We need to keep them consistently challenged and motivated. Organizational change will happen. Instead of silos, there will be groups around product lines.

Next, Michelle lists 10 tips for an agile/waterfall cooperative:

1. Find an executive champion that will help you by pulling those hurdles out of the way.

2. Socialize, don’t evangelize

3. Use the power of the backlog It should include more than just coding items.

4. Do not wait until everything is figured out and perfect. Just get started. Later you can inspect and adapt

5. Use barley sufficient guideline. Do the simplest thing possible to satisfy a request

6. Invite non agile reps to all agile planning meeting

7. Establish a rhythm of inspection and adaption

8. Start sending the ideas up the chain. Help your managers become more agile

9. Pay attention to your behaviors and your team’s behavior. It is easy to revert back to the old ways especially under stress and pressure.

10. Include everybody in project retrospective. Improve things in the team and across the organization

Finally, Michelle concludes that Agile and waterfall can coexist. You need to build the bridge together. Invite everyone who is interested to help you with the transition to agile.

This presentation is available on InfoQ at http://www.infoq.com/presentations/Agile-in-the-Waterfall-Enterprise-Michele-Sliger

The Agile Enterprise: Real World Experience in Creating Agile Companies

Jeff Sutherland discussed some real world scrum successes at Agile 2007. He starts by defining some of the characteristics of real scum as companies having agile as a strategic imperative, institutionalizing scrum and xp and not only in development, passing the Nokia test, and having senior management and developers totally involved.

He defines the Nokia iteration test as having timeboxed iterations of less than 6 weeks with tested and working software at the end of the iteration (unit and functional testing). Also, the iteration must start before the specification is complete.

Then there is the Nokia Scrum test which mean you know who the product owner is, the product backlog is prioritized by business value, the estimates are created by the team, they generate the burndown charts and know their velocity, and there are no project managers disrupting their work.

Next, Jeff gives several real world examples of companies he consulted with that are doing real scrum and are producing incredible results.


One company only hired an experienced scrum product owner and managed to cut their product cycle from 18 months to 2 months.

Another was too hyper productive that management ask developers to slow down. Sales could not keep up with the products. They needed a way to get the whole company agile.

Another company was distributed with 567 developers in many locations:

Jeff discussed outsourcing and gives an example of a 2 million project that would cost around 1.6M if outsourced (usually outsourcing save about 20%). Instead, the project was implemented with a local scrum that increased productivity by 240% (can probably even get up to 400%). The local cost was 0.83million without the risk associated with outsourcing such as inability to stadd the project on time, inability to keep staff on project once it starts (turn over running between 35% to 50%), and poor communication due to distance, time zones, lack of formal process, and language barrier.

Jeff gave another example of a company that created a team in Russia doubling the development team size and as a result doubled productivity. The company used distributed agile with teams split between US and Russia. At the end of the project, the company cut the Russian team, but was able to retain knowledge because the US team members remained. This was an example of a distributed, outsourced hyper productive team that resulted in linear scale when using Scrum. By doubling the work force, productivity doubled. On the other hand, in the waterfall model, it is well known that increasing team size when project is late will decrease productivity and make the project even later.

Role of Leadership Mary Poppendieck

At Agile 2007, Mary Poppendieck gave a talk entitled ‘The Role of Leadership’. Mary started out with a little history going back to 1911 and the book ‘Principles of Scientific Management’ by Fredrick Winslow Taylor. The book came out about the same time as the 1st Ford assembly line of 1913 and addressed how to make workers more efficient. Mary totally disagrees with the book. Its premise is that workers will do as little as possible, do not care about quality and are not smart enough to know the best way to do the job. To improve efficiency, experts need to define the best way to do a job by breaking down the job into parts and finding the best way to do each part. Workers get paid extra to follow the method determined by the expert. The workers are very happy because they get a higher pay and the employers are very happy because they get higher profit. A lot of these early management thoughts have made their way into current western management practices.

Next Mary covers Charles Allen and his 4 step method of industrial training (Preparation, Presentation, Application, and Testing). To train, get ready and figure out the job, present it and have them do it then do some testing to make sure they know how to do it and follow up on a regular basis until the workers get it. If the learner hasn’t learned then the teacher hasn’t taught. On job training is the best. Let’s train supervisors and teach them how to train the people working for them and cascade it down. This method was tested in the war and proved successful.

20 years later (1940), there was another war and Training Within Industry (TWI) was used. It adapted Allen’s approach to take an incredibly inexperienced workforce and train them. The idea was to train line supervisors 1st by teaching them on job instruction (how to train), job methods (how to improve), and relations (how to treat people/solve problems). The method resulted in impressive productivity, but was abandoned in the US after the war ended. However, it got exported to Japan to help rebuild the economy.


The premise of TWI is the 5 skills of a good supervisor:
1. Knowledge of work: Have to know how to do the job.
2. Knowledge of responsibility: Have to understand policy, regulation, rules, etc
3. Skill in instructing: Have to be skillful instructors to pass knowledge onto others.
4. Skill in improving methods to enhance quality and quantity
5. Skill in leading

Next Mary moves to 1950 and the Toyota Production System. Taiichi Ohno studied US auto manufacturing and realized that Japan has to improve its manufacturing to catch up with the US but also realized that Japanese workers are not dumb and can figure out the best way to do the job without being told. The Toyota Production System was based on 3 keys:

Why I don’t like Mondays

Jean Tabaka gave a talk at Agile 2007 entitled ‘Why I Don’t Like Mondays’. Most hate Mondays because of long meetings. The talk is mainly about managing and facilitating meetings. Jean starts by listing 10 common meeting dysfunctions:

1. Meetings are repetitive: They are all the same. If the same topic is being discussed over and over again, it means that decisions from last time are not being tracked.

2. The same people do all the talking: This leads to others thinking why am I here?

3. Subjects are beaten to death again again: Decisions need to be honored.

4. We come to decisions just to get the meeting over.

5. I don’t have time to code because I am in too many meeting: Notion is that if I am not coding I am not working. In Agile, part of your job is not to code.

6. We have too many people in our meeting: The meeting should include the necessary people needed to get to yes or make a commitment. Having too many people is a sign of distrust and a need for control. These people are standing in the way of commitments.

7. We have too few people in our meeting: Missing product owner, customer representative, tester are too busy. Database developers cannot attend meeting. If all these members are important to decision making they should be in the meeting.

8. With constant stream of meetings, we are treated like machinery not people.

9. Our demos and reviews never bring about anything new: These meetings are not for acceptance. Acceptance should have occurred before hand. The demo is to demonstrate progress. It’s an opportunity to act like a team. What are we doing and where are we heading?

10. All decisions were made outside of the meeting. We just had the meeting to be told what we are doing and what to agree to: This indicates that there is still a lot of control going on. Technical architect is deciding what plan should be and what estimates are. Moving from command and control to collaboration is required.

Agile Styles: Crytsal

Alistair Cockburn introduces us to Crytsal in a presentation give at Agile 2006. He starts by discussing Japanese Ikido and the concepts of Shu, Ha, and Ri. He states that people learn things in 3 stages:

1. Shu or following: Show me one way that works. Once I know it, I’ll move on to others
2. Ha or breaking away: Learn limitations of technique A and look for others that complement it or competes with it
3. Ri or fluency: Improvise, slice, shift, or combine techniques in a moment

Alistair recommends getting the starter level kit for all the agile styles. He mentions that a methodology is a reflection of the methodology author and people pick a methodology because the style of the author resonates with them.


Alistair then introduces us to Crystal be stating that it aims to be the lightest, least intrusive set of rules that puts a project in the safety zone. Its purpose is to keep people informed and keep them from hurting each other. Its nature is enable people to follow a set of conventions that gets updated regularly. Its philosophy is that people differ in their working styles, projects differ in needs, and software development is communication-intensive, experiment-based, needs lots of feedback in all directions, less is generally better, techniques and technologies change over time, and people learn in class or on the job and not from methodology.




Alistair shares a study he conducted which concluded that people centric methodologies do better than process centric methodology. Methodology is nothing more than a set of conventions that people agree to follow. He recommends adjusting a methodology based on the team and project like having a meeting every month and tuning the methodology based on what was learnt. As the people on the team change, the conventions of the team change. As the project evolves from beginning, middle to end, the strategies and conventions also change.


Alistair then defines the Crystal family of methodologies Clear, Yellow, Orange, and Red. Each one is better suited depending on the project needs.


Crystal is a family with genetic code:
1. Mindset: Not modeling, but cooperative game where people help each other to succeed. There are 2 goals: The primary is to delivers software, and the secondary is to setup for the next game. These two goals conflicting with each other.
2. Design priorities: Project safety (first and foremost), then development efficiency process habitability (tolerance). Will people use the suggestions.
3. Principles:

• a. interactive face to face communication is most efficient,
• b. methodology weight is costly,
• c. use heavier methodology for large groups,
• d. use more ceremony for more criticality,
• e. use more feedback and communication instead with fewer intermediate deliverables
• f. Discipline, skills, understanding counter process, formality, documentation
• g. Efficiency is expendable at non bottleneck activities

4. Crystal’s Project Properties

• a. Part of genetic code: Frequent delivery, close communication, reflective improvement.
• b. Good ideas: Personal safety (freedom to speak without fear of reprisal), focus (knowing what to develop and having time for it), easy access to expert users, technical environment with frequent integration, automated testing, configuration management.

5. Starter Techniques:

• a. Methodology shaping
• b. Reflection workshop (2 columns 1st: keep these, problem areas, 2nd :try these)
• c. Blitz planning

6. Crystal sample methodology: Crystal clear, Crystal orange


To get started with crystal, Alistair recommends finding your place on the project chart, picking a frequency of delivery, focusing on the top 3 properties, starting work, and every month doing a reflection workshop and deciding what to change.


Alistair concludes by mentioning that to know if you are doing Crystal look for close communication, see users every week, deliver software every 1 to 3 months, monitor project by quality of communication and moral of community, actively reflect on team quality and working habit.
This presentation is available on InfoQ at http://www.infoq.com/presentations/fdd-crystal-agile-overview