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.

Availability & Consistency

At QCON London 2007, Werner Vogels gave a talk about Availability & Consistency and how the CAP theorem ruins it all. Werner defines scalability by as adding resources and getting a performance improvement proportional to the resources added. Also, if you add resources to improve redundancy, it must not hurt performance. A scalable service is resilient, becomes more cost effective when it grows, is capable of handling heterogeneity (as tech improves, architecture needs to improve), and is operationally efficient (# people necessary to run a node needs to go down as you scale up).

Next Werner explains the principles for scalable service design:

· Decentralize: avoid single point of failure. No centralized components.

· Asynchrony: Make progress under all circumstances even if some parts are not working. Work locally and not worry about the rest.

· Autonomy: Each node should be able to make decision purely based on local state.

· Controlled concurrency: Reduce concurrency as much as possible. Funnel things through single points, change data design to avoid fancy locking.

· Controlled parallelism: Control traffic going to each node so that there is capacity both in CPU and I/O left to do other tasks.

· Decompose into small well-understood building blocks. Same with teams. If it takes more than 10 people then the team is too big (2 pizza team). Knowledge gets shared automatically. If larger, need to have meetings.

· Symmetry: All nodes should do exactly the same thing.

· Failure tolerant:

· Local responsibility:

· Recovery built-in:

· Simplicity:

Agile Styles: Lean

Mary Poppendieck covers Lean Software Development at Agile 2006. She mentions that Lean came into being in 1990 based on book ‘The Machine that Changed the World’. The book compares and shows the advantages of Japanese auto manufacturing vs. USA manufacturing. Most of the Lean practices trace their history back to Toyota. Originally it used to be Just In Time (JIT) and then later it became Lean. It’s used it manufacturing, operations and supply chain. We can’t apply it directly to software development, but we can use the Lean principles and look closed at Lean practices in product development. These principles end up deriving the agile practices.

Next Mary discusses some fundamental principles of Lean. She starts with eliminating waste. The trick here is to decide what waste it. She states that it is the customer’s view of waste that matters. MUDA is Japanese for waste or anything that does not add customer value.

Then Mary mentions that Testing is not for finding defects. In lean the job of testing is to prevent defects. If you have a quality process, you are building quality into the code. If you routinely have test and fix cycles, it means you are testing too late. Your process is defective. Final verification should be used to verify that something is working as expected and not for debugging. Defects are a management problem. We should look at defects as caused by a system which allows defects instead of just caused by developers.


A fundamental principle of Lean is to respect people. Toyota’s success was based on their ability to harness intellect of ordinary employees.

Lean looks at the whole picture. Software by itself is useless. It needs to be embedded in a business process, hardware, or an activity to become useful. The goal of software development is to support the development of a complete product (a process that helps customers get job done). The team should include business people not just developers.

Next Mary covers the process of iterative development. She also mentions that if churn or requirement change is as high then you are writing requirements too soon. You should move requirements gathering later into the process.

Lean has quality built in by having:
1. Standards: Architecture, Conventions, Tools. These should constantly be challenged and changed.
2. Continuous improvement: Improve the process, refactor the code.
3. Synchronization: Merge early and merge often. Configuration management, automated build, one click build, continuous integration, nested synchronizations, stop and fix if something is wrong
4. Frequent deployment. Small releases, automated deployment, automated installation.

Agile Styles: Dynamic Systems Development Method - DSDM

Jean Tabaka gave an overview of DSDM at Agile 2006. Jean begins by giving us some background on DSDM which stands for dynamic systems development method. DSDM has 9 principles. There is nothing remarkable about them other than that business people sat together and agreed on them.

1. Active users involvement is imperative

2. The team must be empowered to make decisions

3. The focus is on frequent delivery of products

4. Fitness for business purpose is the essential criterion for acceptance of deliverables

5. Iterative and incremental development is necessary to converge on an accurate business solution

6. All changes during development are reversible

7. Requirements are baselined at a high level

8. Testing is integrated throughout the life cycle

9. Collaboration and cooperation between all stakeholders is essential.

Collaboration and cooperation is one area of differentiation of DSDM. DSDM is very specific about having very clear stakeholder relationships that are explicitly brought in. This is really built into the method and it is not just be hopeful that stakeholders will like it.



Jean then presents the ‘3 pizzas and the cheese’ picture which represents the phases of DSDM. It has phases beyond development. There is the pre-project phase which is a feasibility study and a business study that addresses thing like how a project gets started and where the funding is coming from. Then there is Functional Model iterations, Design and build iterations, and Implementation iterations. Finally there is the post project phase which addresses things like what happens after deployment.

Next, Jean talks about the core agile components of DSDM. They include the 9 principles, the fixed time box, the collaborative and facilitated workshops, and the Prioritized requirement list or PRL. Like other agile methods, in DSDM the iron triangle is flipper over. Time and resources are fixed. Requirements are managed through prioritization and inspection and adaptation. Requirements are baselined at a high level usually using MoSCoW technique (Must have, Should have, Could have, Would like to have it) and delivery is between 2 and 6 weeks.

Other aspects of DSDM include being founded by business owners as opposed to software developers or engineers. It has specific integration points with business processes. It is phase driven. It is consortium-based which gives access to continuous growth of the method. It has licensing fees and multiple certifications which seems appealing to large enterprises.

Some of its benefits include documentation since 1995, continuously evolving, guidance maintained and updated in multiple languages, certification recognized worldwide, and provides a nice enterprise wrapper.

Jean wraps up by pointing us to the source as www.dsdm.org

This presentation is available on InfoQ at http://www.infoq.com/presentations/agile-styles-lean-dsdm

An Introduction to Agile Leadership

At Agile 2006, Tim Lister gave a talk on Agile Leadership. Tim starts by defining a process. It is what you do not do naturally. Process is interesting when your instinct to do something natural is not optimal. Tim makes an analogy with swimming. Our natural instinct in water is head up and paddle like mad. Afterwards, we learn to sip air, put our head in the water, and come up when we need to. In freestyle competitions, most swimmers choose the crawl technique because it has become a proven process for short distances. A true test of a process is what happens when we are under stress and pressure. What do we do? How do we behave? How to we build? How do we deliver? We should follow the process when things get rough and not only in the good times.

Next Tim defines a leader as someone who by dint of words or deeds influences the behavior of others. A leader inspires, or leads by example. Leadership is not by position. It moves around based on the topic or problem at hand. It will naturally flow to the appropriate person. Position is mostly irrelevant. A PMs jobs is to cultivate leadership.

Tim then moves on to give his own interpretation of the Agile Project Leadership Network’s Declaration of interdependence.



1. We increase return on investment by making continuous flow of value our focus.
At least with the time we had, we delivered as many of the most valuable features as we could. All features are accepted, even low value features. However, they just get added to the log and sit there because the client prioritizes items of higher value.

2. We deliver reliable results by engaging customers in frequent interactions and shared ownership.
Deliver reliable results means we make pace visible early. Agile makes work rate or velocity obvious with small increments. You know when you are behind schedule. This eliminates surprises. Engaging customers means we force interaction into a partnership. Knowledge of the customer is always needed. Team needs customer domain expertise.

3. We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
Requirements emerge. They are not gathered. Systems need a gestation period. Anticipation: Why anticipate that the customer always knows what they want. It is rare that we know exactly what we need.

4. We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
This means pushing decisions down and out and making the workplace safe. That is, find the right home for every decision. Don’t make a decision that you are not competent to make even though you have the authority to make it. Some decisions need to go down to the developer. Some decisions need to go out to the customer.
Great creativity and innovation is when people start working together on half baked ideas. One person has an idea and others jump in with their own ideas to complement it.
The teams recognize their performance. They don’t care what the outside world thinks.

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