We’ve all seen this. A one-year project in its 13th month, and the Project Manager has been reporting 80% of the tasks at 90% and has been doing so for the last 120 days. There’s no end in sight, and the customer is leaking cash every day the product fails to go into production. What can be done? Agile project management principles can help this all-too-frequent scenario.
I have just run across a web site about applying agile practices, specifically from Extreme Programming (XP) to architecture. This site, called “Architectural Practices – Extreme Project Management for Architects” has a great deal of information.
I read an article in Wired yesterday that was modified from a book “Freakonomics“. The article talks about real-estate agents and motivation to push the price of houses they are selling $10,000 higher. The observation was that the $150 incremental gain for the agents (1.5% of $10,000) doesn’t make it worth their holding out an extra three weeks to get the higher number. Their interest is in closing quickly and moving on. They can often convince (through fear) the poor seller of a price that suits their interest. He wasn’t even sure if it was conscious, but it naturally flowed out of the asymetrical knowledge levels between the agent and the client. (I’m reminded here of the saying “A System’s Purpose Is What It Does”.) This asymmetry of knowledge is highly important in the Agile community’s current situation, in that it gives early practitioners the “expert” status, and lots of power to help or hurt the client.
Index cards are an excellent tool to use to optimize communication. There are two primary types of use for index cards.
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.
This link was seen on a scrum-toronto list, referring to an e-book called Stealth Methodology Adoption. The title is brilliant, and reflects, in my view, a significant means of adoption of Agile technologies at this point in the maturity of this market.
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)