Agile as an "on ramp" to project management maturity

Three ideas came together a few weeks ago that provide the topic for this posting.

First while browsing the agile virtual community I encountered a reference to a youTube video with the headline "Learn the Agile software development methodology in less than 10 minutes. "
http://www.youtube.com/watch?v=Q5k7a9YEoUI

Second I was reading the abstracts of talks by some thought leaders that offer to clear up the multiple misconceptions about Agile.

Third, I was thinking deeply about adoption of Agile in my current situation.

I was initially impressed by the 10 minute video, it gives a nice concise definition of some common vocabulary and roles used in an Agile project. Yet, I fear it also contributes to the misunderstanding that experienced agile practitioners talk to others about. It may also lead executives with P/L responsibility to look at Agile methods with less respect and confidence.

I believe that there are also others who started their "agile journey" more recently or at a different place who tend to view Agile methods as light weight or more suited for the free spirited. They may be attracted to Agile methods as the least invasive of a variety of alternatives.

The more seasoned players my look at all of this with some degree of skepticism. They think how can something that simple support the claims being made.

In light of all this I have to offer my brief point of view. The process description is simple. Yet the organizational climate in which that process can thrive is no simple matter to achieve. Getting people to be accountable is hard. Getting out of the "it's not my job" mentality can be a challenge way beyond what one can learn in 10 minutes. How to create the foundational alignment and climate is what I'm learning and hope to continue to learn.

To do this I view presentations on motivation by people such as Dan Pink http://www.ted.com/talks/dan_pink_on_motivation.html and I listen deeply to team members who challenge me with statements like "why isn't it enough that I come to work every day and do good work".

The "agile manifesto" or the "declaration of interdependence" http://pmdoi.org/
are value statements not process prescriptions. The blood, sweat, and tears to create that type of alignment is how you pay your dues to achieve the benefits that proponents of agile methods offer. (faster, fewer defects) And in some cases your organization may not be able to fully implement an agile development methodology. It is not the "best practice" every one should adopt. In the end we must do what is necessary to create value for our organization in the current time and setting.
If nothing else agile methods should cause one to reconsider the value that any current practice or communication process brings to an organization and consider very carefully how "change" impacts the success of failure of your project.

Agile is not simple, and certainly not a quick fix. Rather it is a challenge and a cause to rethink and evolve our current current management and project management science.

My Agile Garden

I have a garden in by backyard that my lovely wife has been prompting me to work on. I tell her honey "it is an agile garden that's the way it is supposed to look". It is a flower garden, with a variety of perennials, a small tree, ornamental grass, vines, bird feeder with a water line, a low stone border. I know where all the flowers are and when they are supposed to bloom.
How ever no one would consider it an English garden with neat rows of precisely placed and cultivated plants. The ivy ground cover grew up and covered the trunk of the candy apple tree. I never planned that but it looked nice so I kept it. At the edge of my garden I noticed that one of the sunflower seeds from my bird feeder was lucky enough to germinate and grow into a sunflower plant. A more particular gardener would have pulled out this plant as a weed growing among the ground cover.
This was a special summer. I got a new daughter in law, Heather and she loves sunflowers. So I let it grow. It grew almost 4 feet tall and does not belong among the 6 inch tall ground cover. But it is like an unexpectd gift that has evoked many special memories. The wedding has past and the three blooms have gone to seed. I have been thinking about pulling it out as it still looks really odd. But sitting at breakfast I got one last kick from this plant. I just enjoyed the entertainment of pretty yellow finch trying to figure out how to get some of the seed from the big downward facing seed had that has lost all its blooms. That was a garden pleasure I would have missed if I put the sunflower in the compost heap when the bloom had passed.
This whole experience reminds me of some of the unexpected pleasant surprises I've experienced introducing agile project management in a setting where I worked many years ago.
I was leading a group of about a dozen developers and a handful of testers and writers in a group that was growing rapidly. I was serving as development manager and architect. But I was burning out and realizing that I was personally becoming the bottle neck of the development organization. It was this situation that first prompted me investigate and latter introduce FDD Feature Driven Development. My team was familiar with iterative development but this was the first time I used what is considered one of the real agile development methods. This was two years before the agile manifesto. My past colleagues at TogetherSoft will recognize the appendix in the object modeling in color book as our bible on agile. The ground was fertile for this agile seed to grow. I was blessed with good people to work with and adoption of FDD went well.
One of the key attractive points about FDD was it enabled us to scale and run multiple feature teams as the same time. I saw this as a way to enable my group to grow and adapt to the multiple ideas that were coming at us from our sales force and other technology partners. Yet it also provided me a framework to monitor and when necessary become involved and pull a "weed or two". See http://en.wikipedia.org/wiki/Feature_Driven_Development for more info on FDD.
But during the introduction of FDD to this group I had a pleasant surprise that I didn't really expect. I explained the process to my team and the various rolls I monitored and let folks pick up the various roles and responsibilities defined by FDD. I encouraged as much self organization as I could stand. Some reasonably expected things happened regarding who became class owners. But what I didn't expect was a young reasonably inexperienced engineer pick up the role of Feature Set lead. Before I decided to introduce FDD I was considering breaking the team up and designating leads for each of the sub teams. It never would have occurred to me to select this person for any leadership role. But to may amazement she took off like a star. She really blossomed and took over making may of the decisions I didn't have time to do. In many ways I think what she did was very much like the sunflower in my garden this summer. I hope she is doing well and I am grateful for what I have learned and continue to be reminded about the limits of what I can really control and what I need to let grow.

Agile patterns

I've been thinking about Agile lately as just a set of organizational patterns. There are two that gave me an ah-ha moment.

First -was in the book "How we Decide" by Jonah Lehrer. A fantastic book I strongly recommend to any one who thinks about how they think and what makes people do things. Near the end of the book he has an
antidote about a pilot and an crash that led the aviation industry to a process called cockpit resource management. (CRM) I believe that CRM is to the Aviation industry what Agile is to the software development industry. Unfortunately we've had many "crashes" in terms of projects that fail. Interesting thing is Lehrer goes on to talk about how CRM has gone on to the medical field as a practice that has yielded great benefits in the surgical operating room. And that was just one facet of the book. I believe that working on an Agile team or with a CRM culture is just so intrinsically satisfying. I just wonder why I feel that way about it that I find so cool. The accomplishment, the connection with others.... Humm. Perhaps a follow on book for Jonah Lehrer. A great example of what I'll call the shared owner ship pattern.

Second - last night I attended a Woodstock anniversary concert with the Cincinnati Pops and the rock band "Jeans n Classics". Very enjoyable and very talented people. What really struck me was how the Jeans n Classics folks all supported and complemented one another. They had a leader but each artist had special time to shine and show their own talents. The gelled as a team. Each song was a sprint and the concert was a project. I enjoyed the music and nostalgia. And I also admired the interdependent team. Each one contributing their particular talent. Usually at such a concert there a single star that is a focal point. This was a set of interdependent artists. Just like I'd like to see of a team of software developers. This is a great example of the interdependent pattern.

I think I'd like to develop this pattern idea some more. It helps to unify many of the ideas I've been bouncing around especially regarding the application of Agile to distributed organizations. More for another day.

Agile attraction and inexperienced teams

I suspect that many teams are attracted to agile development methods because it is simple to explain the methodology and understand. Some of these teams may be just inexperienced, some may be in organizations that are under extreme stress to get something done quickly or they will go out of business or be dissolved.

Speaking to a friend today we commented that there seems to be a increasing popularity of seminars, lectures, and classes related to some Agile agile method or practice. I fear a coming backlash or pendulum swing in the opposite direction as various folks pretend to adopt an agile method, get into some type of trouble and then blame agile as not living up to the hype.

My analysis is based on two fundamental beliefs. One, is the amount of formal process you need is inversely propositional to the experience and skill of the team members. Inexperienced folks need more formal process and very experienced folks need less process.
Two, an agile process will expose problems and issues with the project more quickly than a more traditional development process. What to do about those problems and issues is not always very clear for an agile team. The natural conclusion here is that serious consideration should be given before the leadership endorses the adoption of agile for an inexperienced team.

Now, but what about the adoption of agile for a team operating under stress. Perhaps that team is comprised of experienced people but due to some pathology in the organization such as "mushroom management", fear, mistrust, wide geographic distribution or some other organizational challenge. The folks on this team have a good chance of identifying what are the obstacles but they may run right into a brick wall. These walls are may often be "organizational constraints". They may be political or geographic obstacles that are beyond what any development methodology can overcome. Consider the following:

• A project sponsor that doesn't have the depth of experience to understand the challenges of a software development project.
• An organizational culture where there is rift between the users and the developers that has made mistrust and suspicion the norm for the last ten years.
• A team that is spread across 3 continents. The communication challenges make it difficult to exchange technical information or to even build a climate of trust and cooperation. With the Internet and modern collaboration tools it is possible to mitigate the challenges but not to eliminate it completely.

When a team in such a situation attempts to adopt and agile method under these circumstances failures can often be blamed on the Agile method. "It just doesn't work" or "I don't believe in things like that" is often the refrain. When in fact the failure is to properly consider the environmental and organizational factors. Identification of these factors is right out of the PMI PMBOK. Or consider the CMMI based discussions on tailoring of development processes.

My sense is the key is developing the guidelines and science to consider the "environmental and organizational factors" or the skill in tailoring a software process to a particular situation. Then we will come to view an Agile practice such as Scrum as a very nice development method but not a one size fits all solution for every development team. When going agile I'd look for heavy customer participation, high bandwidth interpersonal communication between the team members, and a organization where trust can flourish and grow.

The power of ownership

I happen to be working simultaneously on two projects at the same time. One is a close to a classic project with a project manager, a MS project plan and the traditional dynamics between a project manager and the resources working on the project. The other is a team that is taking a more agile approach with user stories and sprints and so on. This provides a real interesting learning opportunity to contrast the different approaches to getting things done.

It is a bit of an apples to oranges comparison, today I was really struck with an benefit for the agile approach that haven't really appreciated. On the classic project there is a distance or an understanding gap between the formal project plan and the people doing the work. On the classic project many people just don't have the time or care to become familiar with the schedule or the project plan. If they do, they are primarily just looking at the end date and maybe what is on the critical path to the end date. It is a project manager's job to drive the planning process and make the team aware of what is in the project plan. But most of the time they really don't care beyond the success of the project. They have developed some kind of understanding what what needs to be done and that's what drives them. Especially in a matrix organization, the project manager is often some one running ahead of or along side the project trying to keep the plan aligned with the reality of the performing team. In a matrix organization the resource manager will have language and vocabulary for talking about what needs to be done, it should be but it is often not exactly how it is described in the project plan. A good project manager will have some standards for describing tasks or doing the work brake down structure. This may be very professional and orderly but it is often not how the resources would typically describe the work to be done. IOn top of the semanict and vocablary issues the plan may be captured in a tool that not every person has due to license cost or just convenience. Consider a team of 12 where on the only the project manager and the resource manager have a tool like MS Proejct Professional and their dest top. The other 10 on the project get PDF reports, PWA access, or get to watch the project manager use an overhead projector to display the plan on the wall.

Some resources may passively resist the regimentation and structure that comes from working on a formal plan maintained by a professional project manager . I believe that all of these factors contribute to the gap between the plan and the resources.

On an agile team we have user stories that are written by a variety of people on the team. There is a template "As a I'd like so that " People tend to more or less follow the template but for the most part it is written in their own words or at least there is a more level or democratic opportunity for someone to edit the user story before it is agreed to and acted upon. If the team has tasks related to the implementation of the user story it is very likely that the tasks are written by the person performing the work. They may use a tool designed for agile teams, a Sharepoint list, sticky notes or a spread sheet. Key is that all team members are more often in the same position when it come to tools used to author the user stories or tasks. This seemingly more chaotic way of specifying what needs to get done does have it's draw backs. The big one is that we may miss and important piece of work that needs to get done due to the lack of uniformity in the specification and assumptions among the multiple people contributing to the tasks and user story definitions. We try to mitigate that risk by review and discussion of the user story list that doesn't happen as often as it should.

So in the end there are two alternatives each with their Achilles heal. A coherent professionaly maintained work break down structure that is some what distant to the resources doing the work. Or, a more chaotic structure that the resources doing the work readily understand. Generally I prefer the latter. I'd rather have a looser "plan" with inconsistnecies that people really follow than a really tight comprehensive plan that people doing the work have not internalized or even do not readily understand. In the end it is the outcome of the project that matters. On top of just understanding, there is the ownership issue. By far and away I believe that people work harder when they feel they own the plan and they have personally contributed to its creation. This ownership feeling is fosterd much more when they actually press the keys that make the plan artifact what ever form it happens to take. A perfect plan can never be achieved, however a team fully comitted to a successful out come is much more valuable than a perfect plan. In the end it is the outcome that matters. I'll trade almost every thing to get a team that owns the plan.

Wedding Agility

On occasion I judge and critique projects done by college students as part of outreach by the SW Ohio PMI chapter. It seems more often than not a wedding comes up as one of the “projects” done by a group of students. A wedding is perhaps one of the first and largest projects that most amateur project managers attempt to undertake. Some couples hire professional wedding planners, I suspect the vast majority do not. Hence a wedding is a prototypical project management experience for many people regardless of what their profession may be.
I am very close to two very important people who will be getting married latter this year. I could offer my project management services to this couple the way a photographer or a florist may contribute. They have been busy planning and it seems that they have a good handle on the tangible aspects of the day. I worry still that all of this planning may ironically become an obstacle to that perfect day they both so richly deserve. Rather, I think a more valuable offering to my son and his future wife and any other couple planning a wedding is this adaption of the agile manifesto.


A wedding is a momentous event where family and friends gather to witness the vows of the bride and groom and the start of a new life together. It clearly needs a lot of preparation and planning. This is especially true when there are out of town guests and considerable financial expenditure is involved. All that planning, especially when the bride and groom are in the center of it all can take on a life of its own and over shadow the really important things that day. Through my wedding and being a guest at many other weddings over the years experience over the years I have come to value:

• Family, friends, hugs and tears over reception hall/church guidelines and “The Knot “ check list

• Precious memories of a happy day over hours spent posing for photographs

• A multi family & multicultural celebration over a party planned by a few people

• Being present in each moment over worrying about what has to happen next

That is, while there is value in the items on the right, I value the items on the left more.


I find it relatively easy to teach and mentor people about the classic aspects of project management what I struggle with is imparting the wisdom I have gained over the years about what is really important. That seems to be true for a wedding as well as many other endeavors. How to find the right balance is the central question.

Tailor at your own risk

I signed up to speak at the next Cincinnati SPIN meeting next week. I plan to talk a bit about adapting agile methods such as SCRUM to work in distributed environments. Or just tailoring your current methods to introduce some agileness. I have a fair amount of anxiety on this topic.
What I fear is encouraging people to pick and choose from a set of Agile methods and then get in deeper trouble or further spread misconceptions. I believe processes like Scrum are the result of considering a particular development scenario and then putting it through a lean process filter. The outcome is a small tight set of processes where nothing is optional. (retrospectives, user stories, close customer collaboration, etc. ) Where some one to cherry pick a few of those processes and then claim to be doing Scrum it could be a big problem. Hence I think the difference between SCRUM and agile is like the difference between a set of values and a coherent integrated set of processes. Values are more abstract and processes are more concrete. It is like democracy and the government system of a particualr country. Agile is to democracy as Scrum is the the UK system of government.

On the other side of the coin I consider the multiple places I have worked or served as a process mentor and despite what ever label they apply: RUP, extreme programming, FDD or scrum there are still considerable variations among groups the profess to be following the same process. I believe that we tend to believe that things are more alike than they really are for groups who profess to be following a certain process. We under appreciate the tacit and implicit customizations that each group adopts. These adoptions are critical success factors.

Bottom line there is no magic bullet best practice. The art and science is in the tailoring and adaption of the broad range of best practices as identified by SEI or PMI with a values foundation as expressed in the Agile Manifesto. People over process, working software over extensive documentation, etc. Think like an agilest but make sure you have a story for dealing with scope management, risk etc.

I thought I was pretty smart 10 years ago when I had 20 years of experience. Now that I have 30 years of experience I realize how difficult this is and I have even less confidence. What I do appreciate is the wisdom I draw from all schools of thought and bodies of knowledge. Comming up with the most appropiate development and project management process is a very challenging endevor. The good news is there is now a lot of wisdom to draw from. Good Luck.