Feature Driven Development (FDD) employs a smart way of rolling up development progress that provides an easily digested summary of project status using Parking Lot diagrams. Yet, their appreciation and use outside of FDD is quite rare. I taught an Agile Project Management class last week and nobody had seen or used them before, which is a shame because, especially for large projects, they are a great dashboard tool to illustrate overall progress and pain points.

Parking lot diagrams are not just for FDD projects, they can be used equally as well on XP, Scrum, or DSDM projects and this post will introduce them and provide you with a sample Excel spreadsheet for creating them.

As projects get larger the number of features (user stories) you likely have to manage increases. Small to medium size projects with a few hundred features can be managed fine with decks of cards, task boards, and burn-down charts, but as projects scale this information becomes hard to manage and difficult to digest by stakeholders. Parking Lot diagrams roll-up features into functional groups and then these groups into functional areas to better illustrate overall progress against business areas.

Let’s say we have 15 features associated with our order entry functionality. These features could be rolled-up under an Enter Order Details group and reported using a Parking Lot diagram as shown in the annotated example below.

There is a lot of information here. FDD promotes the idea of a chief programmer, an individual who is responsible for a piece of functionality. Their initials “FB” can be shown above the parking lot diagram. If a stakeholder has a question about this area, then they know (Fred Blogs) is the person to speak to. Alternatively, if you are working on an XP project with shared code ownership it may not be appropriate to display initials, in which case simply don’t. Inside the main box the feature group is named (Enter Order Details) and in brackets the number of individual features that make up this group or set is shown (in our case 15).

The colour of the box indicates status. With our colour scheme White for not started, Yellow for work in progress, Green for complete, and Red for late. Standards vary, some people use Blue for work in progress, Yellow for nearing the due date, and Red for late, but as long as all the project stakeholders agree on what each colour means you should be fine. The main box also contains a percent complete figure based upon the combined status of each of the (15) features within it.

The bottom portion of the box contains a progress bar that duplicates the percent complete figure to give a more visual measure of this number and the target completion month for this group of features.

The real power of this technique comes when these feature groups are combined into feature areas and an overall dashboard for the entire project is created.

Converting effort estimates into project durations and team sizes is an important part of project planning. How this is done varies from project manager to project manager, to some it is an art, others a science, and to many a case of living with everyday constraints. Today I will focus on the science and its implication to pair programming.

If your initial project estimates indicate 72 person months of effort how do you best resource it?

1 person for 72 months?
72 people for 1 month?
6 people for 12 months?

Intuitively we know that 1 person for 72 months might work (providing they had all the right skills) but typically business wants the benefits of a project as soon as possible. 72 people for 1 month is extremely unlikely to work, unless the project is simple and massively parallel, like cleaning oil off rocks on a beach. Usually adding more resources beyond an optimal level provides diminishing rates of return. As the old saying goes, “You can not make a baby in one month with nine women, (although it might be fun to try.)”. Also as Fredrick Brooks stated in, The Mythical Man Month ”Adding resources to a project that is already late will make it later”. So, given an effort estimate how do we determine the optimal team size and schedule to deliver quickly and keep costs down?

While adding team members to a project increases costs in a linear fashion, the project timeline is not reduced in a corresponding linear way. Research by Putnam Norden found that for projects that require communication and learning (like software projects), the effort to time curve follows a Rayleigh distribution. Putnam confirmed that this curved applied to software projects in his article “A General Empirical Solution to the Macro Software Sizing and Estimation problem”, IEEE Transactions of SW Engineering, July 1978 and the curve became known as the Putnam Norden Rayleigh curve or PNR Staffing curve as shown below.

How quickly we make decisions and the team member’s level of agreement to these decisions impacts project performance and team cohesion. Software development is an exercise in information exchange and decision making. Also, since software projects have no tangible, emerging product moving down a production line, the communication and decision making process becomes more critical to keep everyone informed and engaged.

Agile methods utilize many tools to promote effective communications including: co-location, daily stand-up meetings, planning workshops, retrospectives, etc, but less is written or taught about decision making. However, if team members are not canvassed for their opinions we run the risk of alienating portions of the team leading to reduced levels of commitment and participation, and potentially missing an important new perspective that could help avoid pitfalls further on. This post outlines the importance of team based decision making and outlines a couple of simple tools to get you started.

Agile methods favour more team empowerment and less command-and-control direction. This increases satisfaction and productivity, but raises the need for effective decision making. Without a project dictator, how do teams make decisions and move forward?...

The rising misapplication of agile methods and the trend of everyone claiming to be “agile” is probably a good indicator that agile methods have well and truly crossed the chasm into the mainstream. I wrote the attached “Crossing the Agile Chasm” paper in 2002 and it was published in the Agile Times in 2003. At that time agile adoption was predominantly the realm of early adopters, keen to understand and adopt new techniques.

Download crossing_the_agile_chasm

With the adoption by the majority segment we see a different usage pattern including “me too” and “panacea seeker” (faster, cheaper, and easier) groups in addition to well intentioned users. Vendors are keen to cash in too, and we see “agile-this” and “agile-that” tools and product descriptions as they jump on the band wagon.

While this may seem a sad trend and a threat to agile methods as they are increasingly misapplied, watered down, and then criticised when project fail. It is nothing new and just the logical next step in Sarah Sheard’s “Universal Technology Adoption Lifecycle” (pictured above). The lifecycle has the following phases:

1. Discovery
2. Successful Application
3. Publicity of success
4. First (slightly modified) replication
5. Confirmation by early adopters
6. Proceduralization and implementation by uninformed middle management
7. Insufficient funding and misapplication
8. Diminished returns due to devolution of the original idea
9. Denigration of the original idea
10. Demise and new discovery

1. Discovery – the new approach is pioneered and worked through to find a solution in the original setting. In the agile world this happened for each methodology. The Borland Quattro Pro project was the inspiration for several methods.

2. Successful Application – Methods are used with enough success to convince the originators that it is reliable and applicable framework. For instance the Chrysler C3 project for XP, the Easel for Scrum, the Singapore project for FDD, and the ECGD project for DSDM, etc.

3. Publicity of success - The technology or approach is publicized by the organizations and technology creators internally and externally. For instance the first XP and Scrum books emerge.

4. First (slightly modified) replication – Authors and fast-followers try the approaches, modifying them if necessary, but crucially, paying close attention to the original intent of the approach and often working in close collaboration with the initial team members. These were the early projects in the late 1990’s when agile by name still did not exist and the methods were below most people’s radars.

5. Confirmation by early adopters – The early adopters succeed and rightly trumpet the benefits of the new technology/process. For agile this has been a long stage as many thousands of companies and projects have adopted agile and found benefits.

6. Proceduralization and implementation by uninformed middle management – In some organizations the process is adopted and swallowed up by mis-aligned procedures. What was meant to be a flexible, light touch, becomes a cookie-cutter process applied with little regard to the context it was intended for.

7. Insufficient funding and misapplication – Just because a process or technology can save money when used well, it does not automatically follow that it will somehow miraculously rescue doomed projects, impossible deadlines, or under estimated confusions. Unfortunately when faced with a tough problem, the promise of the latest great-thing can become an appealing solution. However, no process can bend the physics of time or budget, some endeavours are just poorly conceived. Unfortunately, agile is sometimes seen as the solution to a wayward project and applied (usually poorly) in an attempt to compensate for insufficient funding (with predictable results.)

8. Diminished returns due to devolution of the original idea – As a wider population of majority companies begin to adopt new technologies/approaches they do so with less regard and consultation to the original creators and guidelines. An “everyone seems to be doing it so how hard can it be?” mentality seems to appear in the majority groups that is not as prevalent in the earlier adopters. With this comes erosion of the original values and ideas. In the agile world we see “agile in name only” projects claiming to be doing agile, but really just working without documentation. Not the same thing at all.

9. Denigration of the original idea – As more and more of these misapplications of the approach fail, criticism of the approach rises. Failed instances are held up as “proof” of the technology/approach’s shortcomings by competitors and sceptics. The good name and original successes are called into question and mixed messages spread throughout the community.

10. Demise and new discovery – Like fashions, most new approaches decline in popularity only to be revised with a slight twist a few years down the line. There will be some die-hards who continue to follow the approach and the encouraging thing is that these are usually the people who adopted it more completely and convinced themselves by its benefits. The wave of hangers-on however, who were there to cash-in and follow-suit will be off onto the next new thing (which they will probably screw up too).

Obviously, the software industry is a complicated ecosystem that can not be readily reduced to a 10 step model. Where models can help though is by creating an easier to understand view of trends in the market and help identify patterns that can be useful to us. So while we can not point to an individual phase step and say that, as on February 8th, 2007, the software industry is at step X, we can identify movements in the market and predict what may happen next.

Individuals and organizations move through the cycle at different speeds. Cycles also overlap and merge, the Rapid Application Development movement of the 1980’s and early 90’s went through this cycle and got a bad name as being synonymous with hacking while its origin, pioneered by James Martin, was nothing like hacking. Many of the iterative incremental elements of RAD were reborn into agile methods. Other approaches have been through the cycle too. The originators of CMM cringed as they saw how it was abused by the “process police” of consulting companies – this was never their intent, it was misapplied, devolved and denigrated beyond their recognition.
So, is history set to repeat itself with agile? I expect so, but it is likely to take another 4-8 years in my estimation. Hopefully by then the good practices will be ingrained into common work methods and will propagate into the next emerging trend. Until then we can come to expect more and more misapplications, but don’t take it personally, it is a natural growing pain!

This post is not meant to sound too negative, the fact that people start suing Segway because they are falling off scooters, or suing McDonalds because they get fat, is a great sign that you are reaching the masses, just what the agile community wanted by promoting these methods.

Here is a shameless plug for a public two day Agile Project Management course I will be teaching on February 22-23 in Calgary, Alberta. It is an intensive, practical based, small group class that covers the full lifecycle of managing agile projects in the real world.

There are lots of hands-on exercises and project case studies. It employs proven adult learning techniques and a visual learning style to bring the topics to life and help them stick in your mind. The course is accompanied by a comprehensive workbook and a CD of tools, templates and resources.

The next CAMUG meeting looks very interesting. Jonathan Kohl will be presenting "Don't Drink the Kool-Aid! Avoiding Process Pitfalls". Here is an excerpt from his presentation outline:

“… merely applying an Agile (or any other) process is not a guarantee of success. As with anything else in life, there are trade-offs, and unintended consequences when applying a tool or process. This talk will explore some common Agile process practices that may work well in some contexts, and have unintended consequences in others.

The intention of this talk is to encourage us all to keep striving to build the best software we can. It's tempting to think we have the formula for success, but in a rapidly changing industry, we must adapt and change accordingly. “

Amen to that, there is no standard recipe for successful projects, instead, as the DOI advises, solutions need to be “context specific”, or as Alistair Cockburn reminds us, a new methodology per project.

This is not to say we should discourage passionate implementation of agile methods. Following my Agile Project Management Assessment Quiz post I was contacted by Simon Baker of Think Box who scored an impressive “Uber Agile” score. You can read an account of his project team practices and successes following the quiz and I commend him and his team on their work.

Rather, the point I want to make, is that our intent should focus on successful stakeholder engagement and better software. If this is achieved via agile methods then great, or if, say, via better communications, then so be it. We run the risk of ignoring the “Individuals and Interactions over processes and tools” value if we focus only on process.

For the last couple of months I have been reviewing draft chapters from Preston Smith’s new book “Flexible Product Development” due to be published later this year. I met Preston through the APLN board and I have learned a lot from reading the draft chapters. A portion that really hit home for me was his description of people over process...

I have just returned from the Agile Alliance board meeting in Portland, OR. The objectives were to develop the goals and objectives for the Agile Alliance for 2007, work through some conference planning details, and discuss research funding and other initiatives.

The meetings were held at the Kennedy School which is a very cool hotel, come arts and entertainment facility that houses a theatre, restaurant, several bars, and a movie theatre. The whole place has been preserved/restored to a historic school setting and decorated with a wide variety of art installations and period fixtures. The hotel rooms are old class rooms, complete with chalk boards, heavy baseboards and devoid of modern trimmings like TVs. The meeting rooms are old libraries, home economic labs etc. It really was a creative and inspiring setting and I believe helped contribute to a very productive set of meetings. If you are ever near Portland I would recommend you drop in for a look around.

Many of the items under review still require refining so I can not describe them until they are approved, but I think it is safe to outline some of the topics and themes discussed.

The Agile 2007 conference in Washington D.C. sounds like it will be a great event. It is good to learn that the Open Space sessions will be given a higher profile this year. They ended up a little buried away last year which is a shame because they can generate great energy and innovation. 

The conference submissions have now closed and many tracks received over 150 proposals. Unfortunately, some of the tracks only have room for about 50 presenters which means many good submissions will have to be turned down. We discussed other ways of harvesting this wealth of experience and information and I hope we can get some kind of knowledge-base CD of extra tracks or contributions into the Agile Narratives programs to recognize and make use of all these excellent submissions. From a lean perspective it seems like a lot of muda (waste) to let this information pass by the agile community as also-rans. Who knows, maybe there is an experience report or research paper out there that is just the solution you are looking for.

The venue for the Agile 2008 conference has not been selected yet, but planning is in progress. Major hotels and conference centres book up early and so preparations are already underway. Possible venues discussed included: Seattle, Toronto, Vancouver, Atlanta, and Santa Clara amongst others. Not only is the city important but so too is the conference site, we want somewhere that can not only house the large group, but also provide many gathering areas to promote discussion and collaboration.

It was also good to discuss the certification debate so more. I had a productive chat with Ron Jefferies, Brian Marick, Jutta Eckstein, and Ryan Martens and we all seemed to agree that if certifications are to exist they should be skill based and hard to obtain.

The sessions were well facilitated and productive. It is great to have a these face-to-face sessions it is just a shame that we are not located closer to one another so that we could easily (and responsibly) have more of them. My next planning trip is to Salt Lake City on Wednesday when the APLN board will be conducting a similar exercise for its planning year. Surprisingly the only overlap between these two groups is Todd Little and myself, otherwise we could have all gone to the Kennedy school which would have been a lot of fun.