Agile Project Leadership Network (APLN)

Leaders from the Agile community decided that something more should be said for those that manage agile and adaptive teams. Thus, Agile Project Leadership Network (APLN) was born. Here some information provided by their web site:

APLN was founded in 2004 by a group of people who are active in writing about, practicing, and evangelizing the movement towards fast, flexible, customer value driven approaches to leading projects of many types. Although this organization is separate from the Agile Alliance, our intention is to work closely with that group within the software community, but also work with people and companies outside of software and IT to help them become better Project Leaders.

This group was also responsible for their own manifesto, called the Declaration of Interdependence (DOI). A group of managers, authors, consultants, and team members from different project and product domains came together to discover common ground with respect to Agile and Adaptive Management (Similar to the Agile Manifesto meeting of 2001). This group represented people from the software development community (Alistair Cockburn, Mike Cohn, Jim Highsmith), the product development community (Preston Smith), and the general project management community (Doug DeCarlo, Robert Wysocki). Six core values emerged from that collaboration:

1) We increase return on investment by making continuous flow of value our focus.
2) We deliver reliable results by engaging customers in frequent interactions and shared ownership.
3) We expect uncertainty and manage for it through iterations, anticipation, and adaptation.
4) We unleash creativity and innovation by recognizing that individuals are the ultimate source of value, and creating an environment where they can make a difference.
5) We boost performance through group accountability for results and shared responsibility for team effectiveness.
6) We improve effectiveness and reliability through situationally specific strategies, processes and practices.

From a executive management perspective, this is great material to sell upper management on the business advantages of moving to agile or adaptive development. They think in terms of management, and understand less about the inner workings of an agile team (either because they don't relate or don't desire that level of detail). This still speaks to the core values of agile, but in terms management likes to hear (I highlighted those terms above). If you are a manager or trying to sell management on agile, check out the APLN. They have some excellent resources. If you want to attend a local chapter of APLN, you can find out if your city has one here.

Re-thinking what makes a project successful

In 1994, The Standish Group published a study called the CHAOS Report. This study was conducted to focus on what causes projects to not be "successful". Success being defined as on-time and on-budget. I have seen this report used by many Agile practitioners as a basis on why traditional waterfall develop projects do not work. Now that I have been using Agile practices for some time, I thought I would go back and review the report first-hand to get some insights.

I found the Introduction interesting, here is what it said:

In 1986, Alfred Spector, president of Transarc Corporation, co-authored a paper comparing bridge building to software development. The premise: Bridges are normally built on-time, on-budget, and do not fall down. On the other hand, software never comes in on-time or on-budget. In addition, it always breaks down. (Nevertheless, bridge building did not always have such a stellar record. Many bridge building projects overshot their estimates, time frames, and some even fell down.)

One of the biggest reasons bridges come in on-time, on-budget and do not fall down is because of the extreme detail of design. The design is frozen and the contractor has little flexibility in changing the specifications. However, in today's fast moving business environment, a frozen design does not accommodate changes in the business practices. Therefore a more flexible model must be used. This could be and has been used as a rationale for development failure.

But there is another difference between software failures and bridge failures, beside 3,000 years of experience. When a bridge falls down, it is investigated and a report is written on the cause of the failure. This is not so in the computer industry where failures are covered up, ignored, and/or rationalized. As a result, we keep making the same mistakes over and over again.

I find it interesting that in my many years of doing software projects, that there are always project stakeholders who view projects this way and compare these kinds of projects to either building bridges or houses. However, for the reasons mentioned above, this assumes that once completed the software will last forever (or at least a very long time). This kind of thinking doesn't handle change well. It assumes that you have a control over the future and can predict change. It assumes by restricting change you will have success. So, was that true? Here's what they found:

In the United States, we spend more than $250 billion each year on IT application development of approximately 175,000 projects. The average cost of a development project for a large company is $2,322,000; for a medium company, it is $1,331,000; and for a small company, it is $434,000. A great many of these projects will fail. Software development projects are in chaos, and we can no longer imitate the three monkeys -- hear no failures, see no failures, speak no failures.

The Standish Group research shows a staggering 31.1% of projects will be canceled before they ever get completed. Further results indicate 52.7% of projects will cost 189% of their original estimates. The cost of these failures and overruns are just the tip of the proverbial iceberg. The lost opportunity costs are not measurable, but could easily be in the trillions of dollars. One just has to look to the City of Denver to realize the extent of this problem. The failure to produce reliable software to handle baggage at the new Denver airport is costing the city $1.1 million per day.

Based on this research, The Standish Group estimates that in 1995 American companies and government agencies will spend $81 billion for canceled software projects. These same organizations will pay an additional $59 billion for software projects that will be completed, but will exceed their original time estimates. Risk is always a factor when pushing the technology envelope, but many of these projects were as mundane as a drivers license database, a new accounting package, or an order entry system.

On the success side, the average is only 16.2% for software projects that are completed on-time and on-budget. In the larger companies, the news is even worse: only 9% of their projects come in on-time and on-budget. And, even when these projects are completed, many are no more than a mere shadow of their original specification requirements. Projects completed by the largest American companies have only approximately 42% of the originally-proposed features and functions. Smaller companies do much better. A total of 78.4% of their software projects will get deployed with at least 74.2% of their original features and functions.

This data may seem disheartening, and in fact, 48% of the IT executives in our research sample feel that there are more failures currently than just five years ago. The good news is that over 50% feel there are fewer or the same number of failures today than there were five and ten years ago.

Would you call that success? Here we are 12 years later, yet we hear or have experienced projects that took longer, cost more, and didn't meet customers' needs. Those doing Agile have come up with a different definition of project success - "Continually producing increments of working software with the customer that is prioritized based on highest value for the cost (ROI) all while improving the software and how you produce it over time through constant customer and team feedback." Success if defined by meeting or exceeding customer expectations early and often, and not necessarily on the costs it will take to get there.

Read more of the report for yourself here.

Early observations around projects

As my previous post may have indicated, we became focused on heavy processes around software development and project management. We tried to manage these processes around tools. We did have moderate success around projects. However, we also had some fantastic failures. Here were some early observations that I had with those projects. At the time, I didn't know how to resolve them but I was able to find some interesting patterns. Here is the list of my top 10:

1) Traditional Waterfall assumes that you can figure out as much as possible early in the process. What's ironic is that we also understood the Cone of Uncertainty, which states that the reliability of estimates will become greater as you move through the process. We learned that we couldn't plan or predict the unexpected. We could prepare somewhat through risk management but not necessarily prevent things from happening.

2) Shorter range projects (less than 6 months) were more successful in meeting deadlines than larger range projects. It seemed the larger the project the harder it was to stay on track.

3) Projects that involved internal resources outside of the Development group were more successful than projects that didn't. These resources included Sales, Marketing, Technical Support, Customer Training, etc.

4) Projects that involved some interaction with outside customers were more successful than solely internal representatives.

5) Changes were harder and more resistant to make later in the process because it meant reinvesting a lot of time going upstream in the process. The process assumed that you wouldn't have to do a lot of that. Because of this, we would deliver functionality that the customer really wanted something different with the promise that we would look at it in the future (but rarely did).

6) Because of that, customers and/or customer representatives would ask for anything they could think of whether or not they really needed it because there was no other opportunity to do so.

7) Most of the projects involved managers who felt they had to have control over the project - control over what each resources worked on, control over what the customers could have, control over what stakeholders should know. However, on those rare projects where the manager was more transparent, more accommodating, and empowered the team to determine how they do the work and what work they should do; we found that everybody was happier, more motivated and produced better results.

8) Tools to manage projects became harder to use because it assumed that the work breakdowns, dependencies, resources allocated would hardly change and that the only thing that would change is time. That was rarely the case, and project managers found themselves managing the tool instead of the project itself.

9) It was assumed that estimates were reliable from those that provided it. Therefore, all milestones were expected to be hit by the stakeholders even though how we had figured out the milestones was very uncertain. Projects that were similar to those in the past fared better than those that were different. Most projects fell into the latter category and involved either domain or technical experience that was new to at least one member of the team at any time.

10) Though we had documentation for things such as requirement specification, technical design, etc, we found that as the process moved along those didn't reflect reality. It became too time consuming for people to go back to the documents. Therefore, the working solution and code behind it were the only thing that people could count on. We had thought that documentation were be used as a reference for future projects, but instead weren't used. Also, the documentation wasn't always developed by the team but many times passed around. Therefore, there were many disconnects because of misinterpretation of the documentation. These disconnects caused many of the bugs and incorrect solutions that caused much fix and test cycles as well as go back and fix the incorrect solutions sometime after the solution has been provided to the customer through a production release.

Even though we saw these patterns, and knew that something was wrong with our processes and approach to both software development and project management, we assumed that we were using the processes or tools wrong. It took us some time to finally figure out that perhaps the processes and tools were the culprit.

We started to look around to see if others were experiencing the same thing. And, that's how we discovered Agile...

Before there were projects

Though project management has been around for longer than I have been born, in the mid 80's I wasn't really exposed to the idea of software projects managed by project managers. As a programmer working in both an IT shop as well as consulting, life was much different.

I was assigned tasks by a manager (functional or account managers). Sometimes these tasks were very specific, such as "add this information to an existing report". Other times these tasks were more generic, such as "customer would like a new report that shows this kind of information". The requirements were always clear, but there was always flexibilty in the design. This applied to everything from traditional maintenance tasks (bug fixing, smaller enhancements) to major new product or system development from scratch. As a junior developer, I appreciated the extra support I had as I was learning the tools and systems necessary to excel at my job. Once I got there, I appreciated the flexibility that my manager gave me to figure out the solution with the customer more on my own. In other words, the tasks moved from specific to generic as my experience increased. It became my job to get to the details.

The manager was the initial "go-to" person when there were any questions. He or she needed to have a certain level of knowledge about what the customer wanted. However, they weren't the customer so their responsibility was to get clarity from the customer when needed. Sometimes, that could be done "off-line" so that I could focus on other things. Other times, it was determined that I needed to be there if the discussion became more technical in nature.

Another key difference is that there was little or no specifications. Essentially, most requests if written were a simple one page form providing some high-level information enough to get the conversation going. Other requests were verbal in nature. There were no project plans to review, drafting and review of a large functional specifications document, etc. So where did you capture this information, you ask?

Most of the conversations involved at that point were verbal, with the occassion taking of notes to go back to my desk. However, and here is the important part, the code WAS the specification. It represented the requirements and design. It was expected that you would go through several cycles of the changes. These weren't prototypes, but early looks at the finished product. At first, some things weren't finished or even developed yet. However, the point was to get feedback not just from the manager but many times from the end customer. "Are we on the right track?" "Is this what you were expecting?" In the process, we learned technical limitations such as "we had to redesign the report because the new data would not fit" and couldn't have expected some of those things until we got into the code.

As I progressed in my career, I look back to these early years and wonder if things are better now. Sure, technologies have changed but so have other things that perhaps have gotten in the way. All I know is that things seemed much faster in those days even though the technology was slower. But I have to believe that with improvements of technologies that things should be screaming now. However, they aren't. But that's a discussion for another day...