Pair programming appears to be the most controversial of all the Extreme Programming (XP) practices. It invokes such a violent emotional response in some people that they quickly dismiss all of XP just because of this one practice.
Plan driven methodologies which attempt to mechanize the process of doing work are in opposition to the three Agile Work Principles.
We are Creators
A plan methodology attempts to define intermediate and end work products independently of the input and effort of those who perform the work of creating the work products. This disenfranchises people from their work and leads to low morale. It also establishes a heirarchy of value for the people working on an effort where those who create the plans are perceived as more important or valuable than those who execute on the plans.
Change is Natural
This principle is usually acknowledged, but is usually described as a “problem” to be dealt with rather than as a basic principle to be fully embraced. A plan methodology has “change control” or “change management” and “risk management” and puts the whole notion of change in a negative light. This approach also disenfranchises people because they are constantly placed in opposition to reality.
Reality is Perceived
Plans attempt to legislate reality. “Thus and so must the project go” results in a constant struggle between the plan and peoples’ perception of reality. Plans marginalize the importance of perception on the belief that reality can be objectively understood. If reality can be objectively understood, then it can be mechanistically manipulated. Thus results can be pre-determined without regard for the perception of those results.
Waste is the result of activities or environmental conditions that prevent a team from reaching its goal. The opposite of waste is something that adds value (more, faster or higher quality) to the desired result.
A few more words are in order about how Truthfulness is the foundation upon which the three Agile Axioms rest. Taking them one at a time:
Mishkin Berteig, the founder of Berteig Consulting Inc. and the Agile Advice blog has been listed on the Control Chaos web site as a Certified Scrum Master Practicing. This certification represents acknowledgement of Mishkin’s real-world experience as a Scrum Master. Scrum is a collection of management patterns used to implement agile principles and practices for new product development.
An article called Are You Ready for the Agile Future presents a brief discussion about the role of HR in an agile organization. There are several very good ideas. The basic idea is that the HR function must adapt to the nature of agility. This in turn means, for example, hiring people that are agile, nimble, adaptable etc.
There are however some mis-steps in the article.
Two interesting visual presentations of the progress of adoption of Scrum practices. These are marginally software-specific but could very easily be adapted to non-software agile work situations.
The Agile Manifesto, aimed squarely at software development, is inaccurate when considered against the more general target of Agile Work. The Agile Software Manifesto reads in part:
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Summary: In this well-written, engaging book, author Jim Collins describes six critical factors that he and his research team found common in companies that transformed themselves from a long period of mediocre or bad results to a long period of great financial results. Although focused on publicly-traded companies in the United States, the results of this research can easily be extended to apply to other types of organizations.
Good to Great describes the following six concepts:
- Level 5 Leadership: personal humilty and professional discipline in an organization’s leader are the starting point for the transformation.
- First Who… Then What: don’t worry about what to do until the right people are in the right positions in an organization.
- Confront the Brutal Facts (Yet Never Lose Faith): careful and honest examination of an organization’s current situation is the foundation for finding a path forward.
- The Hedgehog Concept (Simplicity within the Three Circles): discover a simple business concept that people can be passionate about, that works with a single key economic driver and that the organization can be the best in the world.
- A Culture of Discipline: disciplined people removes the need for heirarchy, disciplined thought removes the need for bureaucracy and disciplined action removes the need for excessive controls.
- Technology Accelerators: pioneer the application of carefully selected technologies without relying on technology for transformation.
Some of these concepts are very close to the underlying principles of agile work. For example, in the Scrum methodology, the first five principles are all represented. The Scrum Master embodies some of the attributes of level 5 leadership. A self-organizing team gets the right people in the right position. The daily scrum and the sprint planning meetings are designed to help the team confront the brutal facts. The sprint goal embodies at a local level the simplicity of the hedgehog concept. And the practices in general are a manifestation of a culture of discipline.
Who Should Read this Book? Anyone interested in creating a lasting positive transformation in an organization should read this book. In particular, individuals who are coaching teams or organizations should read this book since the concepts also appear to apply at a sub-organizational level.
Queues of work form at three types of levels in an agile organization.
At the largest level is the project portfolio. The queue for this level contains all the projects that are not yet being actively worked upon by project teams.
At the intermediate level is the backlog of project functionality. The queue for this level contains packages of business function or infrastructure components necessary to implement business function. These packages are selected by a project team to fit into a single iteration.
The packages in turn are also elements in a queue. This smallest level of queue contains individual tasks required to implement all the business function and infrastructure that make up a selected package of work. The team members select tasks off this queue based on priority and dependencies.
In many agile methods, the queue management approach is fairly explicit at the intermediate and small levels. However, very little is said about the largest level. Some organizations have solved this by limiting the size of projects:
To be successful, high-tech CIOs recommend biting off projects in small chunks…. Gregoire notes that Dell is growing so fast that at the end of an 18-month project, the company would be significantly different from when it began. “A project has to take less than six months [to complete]. That’s the only way we can make sure [it stays] with the business,” he says. (http://www.cio.com/archive/120198/tech.html)
Four weeks ago my wife, Melanie, reviewed a paper I was writing about Agile Work. When I talked to her about it, she asked me why we aren’t using these practices for managing our household.
The online CIO Insight has a great article/interview about a forthcoming book: “The World Is Flat: A Brief History of the Twenty-First Century”. Choice quote:
What I am trying to do is say that something important really is happening. The value-creation model is moving away from a vertical silo model to an increasingly collaborative horizontal model, from command and control to collaborate and connect, and that’s going to change everything.
This comment alone is a fairly close hit at the essense of Agile Work. The rest of the article is very interesting and touches on many topics of interest relating to globalization, business, information technology, outsourcing and politics.
There is an interesting article at The Economist also about this book. It is very critical.
At this time, the word “agile” is often associated with software development. Many web sites and resources about agility have this focus (see www.agilealliance.org). However, the concepts and practices that are focused on software (see www.agilemanifesto.org, www.extremeprogramming.org, www.controlchaos.com), are also in use to various degrees under various names in other fields: Lean Manufacturing, Just-in-Time Logistics, The Scientific Method, Creative Problems Solving, and Organizational Learning, among others. Agile Advice and it’s sister web site (AgileMasters.com) aim to bring the notion of agility to all types of work: Agile Work.
The Agile Advice blog is meant to be an attractive resource for people exploring the use of agile principles and practices in all aspects of work, community and personal life. Agile coaches, consultants, practitioners, trainers, novices and any other interested people are all invited to participate by submitting suggestions for topics to email@example.com.
Agile Advice aims to be practical, useful, and relevant on one hand, and exploratory, thought-provoking, and ground-breaking on the other hand. With that in mind, entries in the Agile Advice blog will fall under five categories: Agile Work Practice, Agile Work Theory, Agile Work Stories, Interesting Stuff, and Announcements. We will also be open to any suggestions, criticisms, or questions about the work we do here. Please feel free to contact us at firstname.lastname@example.org.