Agile Work and the PMBoK – Definition of “Project”

Learn more about transforming people, process and culture with the Real Agility Program

This is the first in a series of articles comparing Agile Work with the knowledge and practices “generally recognized as good practice on most projects most of the time” as described in the Project Management Body of Knowledge Third Edition (PMBoK) published by the Project Management Institute.

Definition of “Project”

The PMBoK starts out with a discussion of the question, “What is a project?” and immediately answers: “A project is a temporary endeavor undertaken to create a unique product, service or result.” (page 5) The PMBoK then elaborates on the ideas of “temporary” and “unique product, service or result”.

The PMBoK also contrasts projects with operational work. It states that “operations are ongoing and repetitive” (page 6) in contrast to projects. Further, the PMBoK states:

Projects are different because the project concludes when its specific objectives have been attained, while operations adopt a new set of objects and the work continues. (page 7)

Agile Work: Project or Operation or …?

If we accept the definitions given by the PMBoK for project and operational work, then we can conclude that Agile Work divides a goal up into many small projects (iterative delivery), that are managed operationally (adaptive planning).

Do iterations really count as projects? According to the PMBoK, they do indeed! An iteration is certainly temporary as it is a time-constrained effort with a definite beginning and end. And an iteration also creates a unique product, service or result by delivering valuable results.

And do Agile Work endeavors really count as operational efforts? Again, according to the PMBoK, there is little doubt: Agile Work adopts a new set of objectives between each iteration. In fact, like operations, an Agile Work endeavor continues for exactly as long as it is valuable to the organization or sponsor.

The Roots of Agile: Software Development

Software development is often conceived as project-based work. However, there is much evidence and commentary to suggest that this is not really the case. A software product company like Microsoft, or a software development community like that associated with Linux, both work in a fashion that is much more like an operational model than a project model. The core value that these organizations deliver is rooted in the actual software they build… and they never stop building it (unless it turns out to be a market failure).

In the book “Software Craftsmanship: The New Imperative“, the author, Pete McBreen, describes the lifecycle of software as being on the order of several years and sometimes decades. This extended lifecycle is long enough that the project perspective does not fit very well, particularly since the lifecycle only ends when the software is no longer delivering value (as opposed to projects which end when they deliver value).

The Value of Projects

To be clear: operations end when they stop delivering value, and projects end when they do deliver value. Project work is all non-value-added until the very end, whereas operational work is (as much as possible) all value-added.

The consequences of this are clear. Make projects as short as possible!!! If all the work of a project is NVA up until the delivery date, then in order to maximize value, we should be finding ways to make projects as short as possible, eliminating every last little bit of unecessary non-value-added work.

Agile Work, using iterative delivery and adaptive planning, describes a means to treat an endeavor as operational work and therefore as delivering value early, continually, and for as long as desired.

Please share!

Agile Advice Recommended Materials

Learn more about transforming people, process and culture with the Real Agility Program

This page contains a number of links to recommended web sites, books or tools relating to Agile Work. This page will be updated from time-to-time and as this is done, announcements will be posted on the Agile Advice blog. As such, this page will always be “under construction”. If you have links to suggest, I will examine them and put them up in my own time. Please feel free to email suggestions to

Update 20070115: 1 new reference!

Continue reading Agile Advice Recommended Materials

Please share!

Iterations Stories and Velocity

Learn more about transforming people, process and culture with the Real Agility Program

Alistair Cockburn has written a very important article called “Are Iterations Hazardous to Your Project?“. Alistair has some of the most clear thinking I have encountered in the agile community. His book “Agile Software Development” is one that I recommend highly to most people who are actually using agile methods.

Please share!

Cynicism, Apathy and Agile

Learn more about transforming people, process and culture with the Real Agility Program

I am currently one of those consultants working in a large organization that is trying to implement Agile.

Without a doubt there is huge, mostly unconscious, resistance to the cultural change that Agile requires of a highly-regulated command and control organization. Yet even with that, introducing a few simple agile practices in a reasonable fashion such as iterative delivery, daily status for self-organization, colocated teams and a few information radiators has made a huge difference in teams’ ability to deliver and in their satisfaction with their work. The jury is still out about this change at this organization: will it be permanent? or will it be another fad? or will it remain a weak version of agile?

Like almost any idealistic movement, Agile cannot succeed in the short term. People’s hearts need to be transformed, their habits changed and their thoughts changed. This can happen quickly for some, but for most it is a long process often preceded by the pain of doing things badly. For the most part, Agile is a movement that is being driven by the grassroots: folks in IT who see it as the better way. However, even if every programmer and project manager in an organization decideds that Agile is the way to go, it could still fail before it wins. The corporate culture change required to fully adopt agile can take years and years and can be scuttled at any time by the whim of those in power. If that happens, some of those folks who wanted Agile will become cynical and immunized to the idealistic pull of Agile.

The faster we go, the less patience we have, the more people will become immunized.

The attraction of the financial side of things for consulting, training, publishing, all threaten to poison our community. In the Baha’i Community, to which I belong, our religious laws prohibit “professional” Baha’is. The mix of money with an ideal would destroy the goals of our community: peace, unity. Of course, that means it takes hundreds of years if not thousands to build our capacity, to demonstrate to others the bounties we have to offer.

In the Agile community, like in many other places, there is no sense that this is a movement to span hundreds of years, nor even decades. It is a young set of ideas and has only been visible for six or seven years. We don’t have the patience to wait decades, partly because we are excited, but also partly because we all need to earn a living and I don’t think any of us really want to be economic martyrs to the cause of Agile. Nevertheless, sometimes we do have to have courage and walk away from a bad deal.

Thanks for Tobias Mayer for a message on the ScrumDevelopment Yahoo! group. That message inspired this one.

Please share!

Amplifying Learning Through Fostering Critical Reflection

Learn more about transforming people, process and culture with the Real Agility Program

I have written previously about the tendency we have to limit future learning based on previous learning. This tendency has aptly been termed by Mezirow as the central learning problem of adulthood: “that we fail to notice that failing to notice shapes our thoughts and deeds.” In Transformative Learning literature a central method advocated for overcoming this learning problem is critical reflection. Critical reflection is the act of becoming conscious of our beliefs and assumptions (Where do they come from? Are they valid? What are their limitations? etc.) and either expanding, validating or discarding them.

Stephen Brookfield has written extensively about critical reflection and the following is a brief summary of a part of a chapter he wrote in a text on adult and continuing education entitled “The Concept of Critically Reflective Practice.”

Brookfield outlines Four Traditions of Criticality found in different fields:

Ideology critique

It is based on a premise that uncritically accepted and unjust dominant ideologies are embedded in everyday situation and practices. The purpose of ideology critique is to examine these assumptions in order to effect change at the social and institutional level. An example of this kind of approach to learning is found in the work of American popular educator Myles Horton. As the founder of Highlander Folk School, during the civil rights movement he started literacy program for African Americans. Study groups would learn to read while engaging in ideology critique in their own lives and communities using the Universal Declaration of Human Rights as a the text.

Psychoanalytic and psycho therapeutically inclined critique
These are traditions that work on identifying and reappraising limitations created through childhood traumas. This tradition advocates individual and group therapy for personal learning and development for the purpose of integration of all aspects of self.

Analytic philosophy and logic
This is the tradition that for most is closely associated to critical reflection. Here critical reflection means to recognize logical fallacies and see the difference between bias and fact and opinion and evidence, and become effective at using different forms of reasoning.

Pragmatic Constructivism
This tradition is based on the premise that reality is perceived, that is, we construct our own meaning out of experiences. The focus here is how people interpret their experience v.s. universal and recognizable truths. There is also a strong emphasis on creating new realities together.

Brookfield proposes that to engage in reflection is not the same as engaging in critical reflection. His understanding of critical reflection is centered on ideology critique rooted in the pragmatic constructivist approach. Renowned Brazilian educator Paulo Friere speaks of a similar process by which adults “achieve a deepening awareness of both the sociocultural reality which shapes their lives and… their capacity to transform that reality through action.” Ideology critique is rarely used in the work place. For the most part a culture of conformity and obedience is promoted by organizations.

Brookfield presents a picture of what the process may look like: “The adult educator’s task is that of helping people articulate their experience in dialogic circles and then encouraging them to review this through the multiple lenses provided by colleagues in the circle. On the basis of these collaborative critical reflections on experience adults reenter the work to take critically informed actions that are then brought back to the circle for further critical analysis.”

To engage in collaborative critical reflection based on a rhythm of action and reflection is not only a process of building collective knowledge and consensus, but also strong foundations for both trans formative learning in the work place and thriving self-organized teams. It is also a way to discover appropriate forms of metrics because it helps people apply multiple lenses of analysis to their work.

Critical reflection should be taught to teams through modeling. For example the coach disclosing his/her won process of critical reflection. Critical reflection should no be associated with self berating and putting others down or the culture of “telling it like it is” without regard for others.

Try the list of questions in the extended text to get a sense of how your work as an Agile practitioner (or whatever work you do) can be enhanced by critical reflection.

Continue reading Amplifying Learning Through Fostering Critical Reflection

Please share!

A Metric Leading to Success

Learn more about transforming people, process and culture with the Real Agility Program

I just recently read the article by Ron Jeffries: A Metric Leading to Agility. It’s a good, well written, well thought out article. If you are in the software business, check it out if you haven’t already.

However, much as it is good advice, I believe that I must add a cautionary note.

Continue reading A Metric Leading to Success

Please share!

Salutogenesis and Agile

Learn more about transforming people, process and culture with the Real Agility Program

Twenty-five years ago American-Israeli Medical Sociologist, Aron Antonovsky developed the theory of salutogenesis. As opposed to the traditional pathogenic model of medicine focused on the study of disease, salutogenesis is the study of health. Since then, his work has been integrated into the field of public health and health education. This asset or strength based type of approach to individual or institutional development has been found in other fields such as organizational development and community development. In organizational development the field of Appreciative Inquiry and in community development the Asset Based Community Development model share the essential premises of salutogenesis. Quoting Garmezy, Antonovsky highlights the medical professions focus on deficits:

our mental health practitioners and researchers are predisposed by interest, investment and training in seeing deviance, psychopathology and weakness wherever they look.

This type of approach to work based on weakness and deficit can be found in most of our organizations. It seems to me that although Agile exposes inefficiencies and problems in organizations, it’s focus never-the-less is to build on strengths and assets. It is in this light that I have been thinking about Antonovsky’s work and what it can offer to Agile.

Antonovsky came to this theory of salutogenisis when he carried out a study on Israeli women going through menopause. He found that there were a number of women who, according to all indications of the pathogenic model, should be suffering severe symptoms (because they faced severe stressors which cause illness). But they were not suffering at all. To his surprise he discovered that these women happened to be survivors of concentration camps. He found certain qualities in these women that resulted in what he called a higher “Sense of Coherence” than the other women.

Sense of Coherence is made up of three factors; comprehensibility, manageability, and meaningfulness.

Comprehensibility means that whatever happens to a person, she is able to make sense of it and understand it, that is, the challenge is in some way “structured, predictable, and explicable.” Manageability means that either the resources are available to one to meet the demands posed by the stimuli,or one has a way to find them. Meaningfulness involves having a sense of meaning in the important areas of one’s life or recognizing “these demands are challenges, worthy of investment and engagement.”

Antonovsky found meaningfulness to be the motivational factor of the three, although he also found that all three mutually reinforce one another. For example if one has a high sense of comprehensibility but is low on the other two, one ends up not having the motivation to find resources and soon after this causes comprehensibility to be lost. If one is high on meaning and missing the other two, Antonovsky explains that there is a good chance to find the other two.

The theory of Salutogenisis may provide researched and proven reasons why Agile is so empowering for people. This research may also provide more insight into how to deepen Agile experiences to higher levels of empowerment. Agile methods help people to make sense of the market place by allowing for iterative delivery and adaptive planning, thus increasing their level of comprehensibility. Iterative delivery, adaptive planning and the concept of amplifying learning are all conducive to increased sense of manageability. Because people spend most of their time at work, it is quite important that they feel a sense of meaning in their work. The concept of empowering the team and the practice of self-organized teams and appropriate metrics can contribute to increased sense of meaning in one’s work.

Salutogenic food for thought for the Agile practitioner:

Antonovsky associated comprehensibility with consistency which he defined as “the extent to which one’s work situation allows and fosters the clarity of seeing the entire work picture and ones place in it, provides confidence in job security, and supports communicability and feedback in social relations at the workplace”.

How can the concept of consistency be promoted in Agile projects?

Manageability is related to under load/overload balance which is defined as “the availability of resources to the individual and to the collectivity within which there is interaction to get the job done well” and “…the extent to which the work situation has room for allowing potential to be utilized in substantively complex work.” The opposite of the former results in overload and the opposite of the latter is a situation of under load.

How can Agile projects guard against overload? How can an Agile coach and Agile teams fully utilize the capacities of its members?

Meaningfulness is closely associated with participation in shaping outcomes. Antonovsky explains beautifully the relationship between these two concepts:

When others decide everything for us-when they set the task, formulate the rules, and manage the outcome-and we have no say in the matter, we are reduced to objects. A world thus experienced as being indifferent to what we do comes to be seen as a world devoid of meaning.

In light of the concept of meaningfulness how can the principle of self organized team and shared decision making be deepened in Agile work?

Antonovsky, Aron (1988). Unraveling the Mystery of Health: How People Manage Stress and Stay Well (Jossey Bass Social and Behavioral Science Series)

Please share!

Call for Contributors

Learn more about transforming people, process and culture with the Real Agility Program

I’m looking for two people to volunteer to write about Agile for this site. In particular, I’m interested in stories about Agile being used outside of technical fields and Agile being used in management. Of course, if you have a burning desire to write about something else, please let me know:

Continue reading Call for Contributors

Please share!

Agile Work Axioms – Discussion

Learn more about transforming people, process and culture with the Real Agility Program

It’s taken a while to get the phrasing for the Agile Work Axioms to the point that it is currently at. I’ve had personal conversations, one-on-one with a few people that I trust in order to see if what I have written makes sense. But the time has come to ask you, dear reader, for help.

I am trying to formulate a really simple way of describing the underlying assumptions and beliefs about life, the universe and everything that are driving the success of Agile. Right now I have this:

Agile Work Axioms:
We are Creators
Reality is Perceived
Change is Natural

I’ve written just a bit more than that and it can be found at the Agile Work Axioms web site.

What do you think? Do these relate well to what we find in the Agile Software Development Manifesto (notice the “software development” stuck in there… I’m hoping the Agile Work Axioms apply to other types of work besides software development)? Is there anything missing? Do these make sense? Why?

Please share!

Asset Based Community Development and Agile

Learn more about transforming people, process and culture with the Real Agility Program

What Is ABCD?

It is an approach to community-based development, based on the principles of:

* Appreciating and mobilising individual and community talents, skills and assets (rather than focusing on problems and needs)
* Community-driven development rather than development driven by external agencies

It builds on:

* Appreciative inquiry which identifies and analyses the community’s past successes. This strengthens people’s confidence in their own capacities and inspires them to take action
* The recognition of social capital and its importance as an asset. This is why ABCD focuses on the power of associations and informal linkages within the community, and the relationships built over time between community associations and external institutions
* Participatory approaches to development, which are based on principles of empowerment and ownership of the development process
* Community economic development models that place priority on collaborative efforts for economic development that makes best use of its own resource base
* Efforts to strengthen civil society. These efforts have focused on how to engage people as citizens (rather than clients) in development, and how to make local governance more effective and responsive.

Please share!

Agile Work Business Case – Pragmatic Reasons for Using Agile Work

Learn more about transforming people, process and culture with the Real Agility Program

Time to market/process cycle time is improved, possibly to reducing the time to that of a single iteration. This reduced time to market can produce an incredible competitive advantage both by increasing an organization’s ability to respond to change and by proactively instigating change that other organizations will not be able to respond to adequately.

Using Agile Work practices and focusing on Agile Work disciplines improves the chance of projects being delivered under budget. In fact, the whole notion of budget becomes meaningless when agile projects are delivering incredible value incredibly quickly. Profit-oriented organizations will see their budgets expand as their profit grows and non-profit organizations will see the value they deliver grow far beyond expectations with a constant budget.

Stakeholders, in particular end-users have ownership of the solution and are more likely to accept it. Whatever system or result Agile Work is used to create, that result will have very low levels of waste due to non-acceptance. This is also a reduction of the risk that the wrong solution or a poor solution is delivered.

Improvements in staff development and retention by providing a positive learning culture. In some industries and sectors staff turnover is a major expense or source of waste. Agile Work is interesting, exciting and satisfying. People who have experienced Agile Work actively promote it and seek it out because it creates a situation where their talents are valued and used effectively. Adopting Agile Work will attract talented team players to your organization.

Please share!

Agile Planning

Learn more about transforming people, process and culture with the Real Agility Program

I recently read a great little article about agile planning by Martin Fowler. I find that one of the more difficult tasks to do early on in an Agile project is to get the team to as a whole, take responsibility for the amount of work taken into an iteration. Often, individuals will take on work that is role-specific (e.g. Dev work) without consulting the whole cross-functional team and the product owner.

I haven’t read it yet, but I suspect that Mike Cohn’s new book, Agile Estimating and Planning, might have some excellent ideas about all this.

Please share!

Agile and Defined Processes

Learn more about transforming people, process and culture with the Real Agility Program

People who are organizationally minded, or who are risk adverse often have difficulty understanding the benefits and safety afforded by Agile as opposed to defined processes. This often manifests in a desire to standardize tools or processes so they become defined.

For example: an organization may wish to standardize on a spreadsheet template to use for iteration backlogs for all Agile teams. This seems innocuous. While I understand the desire to standardize, I believe even doing this would be detrimental to an organization. Some Agile teams may not use spreadsheets at all. In fact, using spreadsheets is considered a last resort used only if you have an extremely complex project. Generally speaking, user story and task cards along with a burndown on a white board are meant to be sufficient. Standardizing on spreadsheets would _impose_ process where it is not necessary and would be taking us all back along the path of a non-agile approach to projects.

In one instance where I have coached, we did in fact use a spreadsheet because we have up to 300 tasks per team per two week iteration. It would have been very difficult to manage all these tasks manually. Additionally, we customized our spreadsheet to work for our circumstances which are unique. Agile specifically encourages the values of simplicity and adaptability. I am perfectly happy to share our spreadsheet for other people to learn from, but the whole notion of standardizing the spreadsheets seems to be against agile principles. Think of it this way: would anyone be happy if an organization decided that everyone needed to drive the same car to work? Each person’s car serves their own transportation needs. In exactly the same way, each team’s spreadsheet/whiteboard/cards serves their needs… and not necessarily the needs of anyone else. It is true that everyone needs transportation, and in the same way an organization needs every team to track their user stories and tasks, but how exactly it is done should be left up to the teams.

Please share!

Agile Work Uses Lean Thinking – Empirical Process Control

Learn more about transforming people, process and culture with the Real Agility Program

This is Part 2 of a 3 part series.
Part 1
Part 3 – not posted yet 🙂

Some work processes cannot be perfectly controlled nor perfectly defined. There may be non-linear interactions between steps in a process or there may be creative input from a human required. Processes with these qualities require empirical process control.
The basic attribute of empirical process control constitutes a continuous cycle of inspecting the process for correct operation and results and adapting the process as needed. A simple example of this is detecting impending failure of equipment by constantly monitoring the operation of that equipment. For Agile Work, the book Agile Software Development with Scrum provides an excellent chapter about this topic of Empirical Process Control.

In human processes like those to which Agile Work applies, the frequency of inspecting and adapting must match the needs of the process. Many projects occur in the context of constant change. This constant change makes long-term planning a wasteful effort. Rather, short-term planning with constant feedback provides a simple inspect and adapt cycle. This cycle can play out at different levels: daily for a team, monthly for a client of the team. The team inspects and adapts daily at the level of the tasks that it is performing. The client inspects and adapts monthly at the level of the team’s actual delivered results.

Both lean and agile methods claim to increase both speed and quality. Many people believe that there are four constraints in a system that can be controlled: speed (or schedule, or time to market, or process cycle time), quality (number of defects), scope (how much functionality), and cost savings (how much to spend on the work). Frequently, management believes that one has to trade off between these four constraints; spend more money, get more scope; lower quality, go faster. But in fact, lean and agile strongly support the idea that as you increase quality, you also increase speed… you just have to do it right.

In Agile Work, increasing speed and quality is done in three ways. First, increase the frequency and quality of communication among team members so that errors are detected early or avoided altogether. Second, drive the work with the creation and execution of automated testing. No work is done without a test in place to check if it is done correctly. This constant testing means that work is always defect-free and therefore very little time/money is spent on fixing defects. Third, eliminate wasteful work steps or obstacles to performance of work. This last one is difficult to do an bears closer examination.

Wasteful work is done in every process, no matter how efficient. Lean tells us that there are several types of waste in a manufacturing process. Those types of waste have analogies in Agile Work. For example, documenting something you plan to do instead of just doing it is wasteful. Another example is waiting while someone completes work that you depend upon. Any step or task that does not add value to the final product of an effort is waste. This standard is very high and most organizations have about 80% of their efforts going into wasteful tasks. An organization that has done an initial cut of wasteful work might stand at about 50% waste. The leanest organizations, such as Toyota, stand at about 20% waste.

Agile work eliminates waste in the form of barriers or obstacles that come up when a team is trying to go fast. Sometimes this is in the form of waiting for another group to do something for the agile team… an outsourced request for service. Sometimes waste is in the form of corporate standards or policies around documentation of work. The Process Facilitator role in an agile team has responsibility for working with the team and others to help overcome these obstacles.

Please share!