PMI regularly surveys project practitioners to identify trends in the practice and needs related to project management. One of the practices that PMI has monitored over the last several years is the continuing growth and usage of Agile practices in project management. Since Agile is a topic of growing importance in project management many project professionals are eager to gain Agile techniques to apply on the job. Similarly, organizations that utilize project management to serve both internal and external clients are seeing value in Agile methods to deliver projects for these clients more quickly.

Because of these changes in the project management environment, PMI is developing an Agile certification. This certification will complement the existing PMI offerings in Agile, such as our Agile Community of Practice, SeminarsWorld and eSeminarsWorld classes, and Global Congress area of focus sessions.

My entire focus over the last decade has been responsibly connecting Agile and Project Management to help organizations deliver technology that makes a different to the business. I am passionate about where PMI is going with this. Over the past year or so, I have invested significant time and travel in the groups that are helping connect Agile and the PMI community.  These efforts include:

• Core team member of the Agile Community of Practice
• Key member of the team advising PMI on the best way to offer an Agile certification to serve project practitioners and the organizations for which they work
• Presenting Kanban at SeminarsWorld
• Chairing (with Mike Cottmeyer) the Agile Track at this year’s Global Congress
• Launching the Atlanta Agile PMI Local Interest Group

Agile Certification Overview

I have talked about why I value certification and what certification means previously. I am an advocate of communities generating shared language and exploring how to do what they do better. And I believe that a certificate that exposes a basic understanding with that community is valuable. There is a HUGE gap in understanding between the traditional Project Management practitioner and project management based on an Agile foundation.

PMI’s Agile Certification builds on six key competency areas. Here are the six key areas and a conceptual view of how they may contrast with traditional thinking. Pragmatically, these all exist on a continuum. The key is that most organizations lean toward the traditional side of the equation and that most Project Management implementation put up barriers to delivering projects with practices that lean toward the Agile end of the continuum.

1. Value Driven Delivery

Agile: Deliver value by understanding and prioritizing what is important to the customer and the business, continually refining the smallest and simplest thing that might possible work, delivering quality results incrementally, and obtaining feedback to improve the result.

Traditional: Define the project up front. Use robust change management to protect against / prevent change.

2. Stakeholder Engagement

Agile: Establish and maintain mechanisms that ensure that all current and future interested parties are appropriately participating throughout the lifecycle of the project.

Traditional: Throw projects over the wall across Analysis, Design, Development, QA, and Production. Engage end-users at the end. Leave significant strategic decisions to the interpretation of the development organization while the project is in the black-box of development.

3. Boost Team Performance

Agile: Boost team performance through creating an environment of trust, learning, collaborative decision making, commitment and conflict resolution, thereby enhancing relationships amongst individual team members.

Traditional: Focus on resource optimization. Form teams around projects. Share resources across multiple projects simultaneously. Take power away so people just do what they are told according to the standards. Put all decision making into the hands of few key managers.

4. Adaptive Planning

Agile: Work with the team and the stakeholders to produce and maintain an evolving plan from initiation to close based on goals, business values, risks, constraints, and stakeholder feedback.

Traditional: Plan the work and work the plan. Stick to the Gantt Chart.

5. Problem Detection and Resolution

Agile: The team identifies problems, impediments, and risks; determines strategies for dealing with them; and executes the strategy.

Traditional: Management identifies problems, impediments, and risks; determines strategies for dealing with them; and executes the strategy.

6. Continuous Improvement

Agile: Improve the quality, effectiveness, and flexibility of the product, process and team and influence the organization in order to better deliver value now and in the future.

Traditional: Perform lessons learned at the end of the project. Use those to update organizational processes and standards.

Summary

If you are a traditional and experienced project manager you may not agree with the dichotomy between Agile and Traditional that I presented above. This is either because you view the Agile approach as irresponsible or because you believe you apply Agile in situation specific ways without having to call it Agile. In theory, I agree. In practice I see way more traditional project management than agile project management. Right now, most organizations don’t even have language or feel it is safe to discuss how Agile fits in.

Having open and responsible discussion around the concepts of value drive delivery, stakeholder engagement, boosting team performance, adaptive planning, and continuous improvement can do nothing but help organizations improve performance.  I don’t believe PMI has gotten it perfect in this effort. They have made great progress toward establishing language around the important conversations and have expressed a desire to evolve this body of knowledge rapidly. Creating the Agile Certificate will create safety for organizations to explore the Agile options responsibly.  I am excited about the where the Agile Certification today and where it is heading in the future. But, within five years – I hope that these Agile concepts aren’t controversial. I hope they just become part of the generally accepted way of delivering projects.

Follow the conversation on Twitter at #PMIAgileCert

On February 11-13, 2001, a group of 17 people came together and created the Agile Manifesto. This launched a decade of dramatic change in the way software projects are delivered in many organizations. A decade later, on February 11-12, in the same resort in Utah, 33 people got together to discuss the Agile Manifesto and talk about what is next. There was a lot of  great discussion and a lot of agreement. What was interesting to me was that there was a lack of agreement on what the last bullet,

“Maximize Value Creation Across the Entire Process”

even means.

Working Code as Value

The first principle behind the Agile Manifesto is:

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

To many in the software development community – including many of the attendees at the 10 Years Agile workshop, value means working, tested, deployed code. I agree that this is important, but this is not value. Working, tested, deployed code is captured in the first bullet:

“Demand Technical Excellence”

But does this deliver any value? Quality software is necessary but not sufficient for value delivery. Some in this community view quality software and software craftsmanship as the final purpose. There are some that feel that this was all that in the control of the members of the Agile community. I don’t share this perspective. Value not only has a broader meaning than this, but this limited perspective can actually be value destroying.

Organizational and Personal Values

When we were defining Value-based Development – it was marked up to be Values-based development by someone. Within the agile community, there is a metaphor of software development teams as pigs surrounded by chickens and seagulls. The pigs are committed to development the chickens are involved and the seagulls just fly in a crap all over everything.  The pigs are management and the seagulls are management.  This metaphor comes from the difficult organizational environments that many developers have worked in.  There are some in the community that consider value to be improving the conditions that people work in every day. This is captured in the second bullet:

“Promote Individual Change and Lead Organizational Change”

This is valuable, but does this deliver any value? Improving the environment that individuals work in is really important. Software development is a creative endeavor, it is critical to create an environment where people feel safe and motivated so they can do great creative work. Some in the community view this as the real motivation behind the Agile community. They feel that Agile software development is about what’s in the best interest of the developers. Organizational and Personal values are key – but they aren’t value. In fact, a singular focus on improving personal values can be value destroying.

Value as Customer Value

There is a strong movement emerging in the Agile community, or the post-agile community, that agile is about customer experience. Customer experience is critical to get people to use your product. Customer value is the difference between what a customer gets from a product, and what he or she has to give in order to get it. Customer value is really, really important. Google is my favorite search engine. They absolutely understand what customer value is. But they don’t stay in business on customer value. They make money from advertising and a lot of other things other than search. Again, customer value is necessary but not sufficient. Too narrow of a focus on customer value can lead to a failure of the business. I agree that customer experience is underserved in the Agile community. I believe that Customer Value is a key component of the fourth statement “Maximize Value Creation Across the Entire Process.” But, it is not the entire story.

Value as Economic Value

Eli Goldratt, in “The Goal” defines the making money today and into the future. This is about economic value. There are multiple views of economic value.

Business Value: Increase or Project Revenue, Reduce or Prevent Costs, Improve Service, and Maintain Compliance in alignment with the organizations strategy.

Cost of Delay: the cost to bear as a result of delay in investment.

Risk: An obstacle to Business Value.

Businesses are economic enterprises. Any view of Value that doesn’t acknowledge this is short-sighted. Agile is about quality software, organizational and personal value, and customer value. But at the end of the day, Agile is about improving the ability of the organization to improve economic outcomes.

Summary

Just like Agile, value is not well defined. And different people have different perspectives of value. Even when faced with the options, they decide that some of them are not important. I am a strong advocate of all the aspects of value – and Agile organization’s must setup guard rails to ensure that technical, personal, economic, and customer value are held in high regard. But they are a means to an end – not  an end unto themselves. There are parts of the Agile community that not only view these as an end unto themselves, but that promote the idea that a focus on economic value is actually bad. I don’t share this perspective. Agile is about improving economic outcomes. Technical, personal, economic, and customer value are enablers of this end. Doing these right helps deliver economic outcomes. Focusing on these outside the context of economic value is destructive.

This weekend, about 33 people got together at the Snowbird Cliff Lodge to celebrate the 10th anniversary of the Agile manifesto. This group was invited and hosted by Alistair Cockburn. The goals were to have a celebration, talk about the successes achieved and the problems facing the community, and hopefully contribute something back around the problems that we can sensibly address.

This is not a replacement or an extension for the Agile Manifesto. It is more of a focusing statement relevant to our understanding of today’s problems and needs. There was a lack of alignment at some levels – although the expected disconnects, Kanban vs Scrum vs XP or whatever, didn’t arise. The biggest lack of alignment I saw was between those that feel we need to address Agile across the business and the group that believes Agile is about only software development, asking “Who are we to be describing how the organization should be designed?” I believe this gap has at it roots the different perspective of the people who attended. Some work within software development teams. Some help organizations adopt Agile. And some help organizations exploit the Agile ability to rapidly deliver working increments of value to update business models and deliver on new value propositions.

But there was a ton of alignment on some issues. There was great energy and flow in the room. There was some negativity and cynicism that came from our focus on what problems exist. But that was the exercise – identify problems that we can sensibly address. I found the entire weekend to be valuable and enjoyable. And I believe we came up with something of value as well.

Process

The facilitators had identified seven categories of questions or issues that had been identified through pre-session interviews with some of the attendees.

• The Future
• Training
• Technical
• Culture
• Enterprise / Other Communities
• Value
• Agile Backlash

After an initial group warm up, we broke into seven groups with each being assigned to an area. We worked to identify the gaps or issues that need to be addressed in the industry today in our assigned area. We then we rotated around the room in our teams to review the other areas, adding any additional issues we identified and moving some issues from one category to another. We then went back to our original categories and identified underlying themes from the issues. These became the big problems that needed to be addressed. This was great conversation within our groups and the underlying themes were pretty clear and consistent. We then did a read out of our themes to the bigger group and had some additional discussion.

Then we took a five hour break.  Some people stayed and did more work, some napped, some when skiing. I went up on top of the mountain with Alan Shalloway, Joshua Kerievsky and Ahmed Sidky. The view was awesome and I really enjoyed the company and the conversation.

When we reconvened and worked to consolidate the big problems under the following headings.

1. What problems in software or product development have we solved?
2. What problems are fundamentally unsolvable?
3. What problems can we sensibly address — problems that we can mitigate either with money, effort or innovation?
4. What are the problems we don’t want to try and solve?

We then grouped the problems under “What problems can se sensibly address” into themes and dot voted to identify the biggest issues. Finally, we worked to craft a sentence to address the four top themes. This became a challenging process as there were 30 strong willed people with different perspectives all trying to influence the sentences. As we narrowed this down through our consensus process there was a lot of discussion and debate. At the end of the allotted time we had the following.

We, the undersigned, believe the Agile community must::

1. Demand Technical Excellence
2. Promote Individual Change and Lead Organizational Change
3. Organize Knowledge and Promote Education
4. Maximize Value Creation Across the Entire Process

Demand Technical Excellence

At the end of the day, you can’t deliver value through technology if you are not delivering quality. This category brings in aspects of architectural, engineering, and design. This is still a pressing issue and must be addressed in the community to deliver on the promise of the Agile Manifesto.

Promote Individual Change and Lead Organizational Change

Here is an example of a sentence that we had a broad range of perspectives on. Without adoption by individuals and alignment of organizational governance and management models, Agile won’t deliver on its value proposition.

Organize Knowledge and Promote Education

This isn’t just about the practitioners, it includes the broader business context as well. The community needs to build on the broad body of knowledge that exists within and outside the community – we have to avoid reinventing everything. Diversity of thought is important to the ongoing growth of the community – but we don’t actually do a very good job of intentionally building on the body of knowledge.

Maximize Value Creation Across the Entire Process

Software Development is not an end unto itself. Too many organizations moving toward Agile are focused on just the software development team. This is only valuable to the point that the software development team is the constraint in the organization. We need to learn how to do a better job of defining value and aligning the cadence across the organization and improving the flow of value from concept to delivery.

Closing Thoughts

This was a dynamic crowd with a lot of experience. In this group, there was very little contention between flavors of Agile. Everyone was open and working to address the needs of the industry and the broader needs of the communities we live in. There are lots of problems – I am sure there will be a lot of talk about “The Elephants” – problems that didn’t explicitly make the list. There will be some dissenters. And I think there may be some work to refine the sentences. Hopefully without losing the meaning of the points.

I believe that Alistair’s goals were achieved. We had a nice celebration – we came to consensus (although not unanimous agreement) on the big issues in front of us. And we shared a lot of energy and community. I got to meet and develop relationships with a number of amazing people. And we ate and drank a lot both nights. I don’t know what comes out of this effort in the bigger community. Now, let’s see how the Agile community responds to the outcome.  I hope we rally around the big issues and continue to improve where we work and the value we deliver.

Attendees

Here are the people that are in Snowbird for the 10 years Agile celebration.

• Pekka Abrahamson
• Scott Ambler
• David  Anderson
• Mike  Beedle
• Tracy Bialik
• Alistair  Cockburn
• Rachel Davies
• Michael Feathers
• James Grenning
• Robert Holler
• Jonathan  House
• Erik Huddleston
• Michael Hugos
• Zhon Johansen
• Kay  Johansen
• Ralph Johnson
• Nate Jones
• Joshua Kerievsky
• Jon Kern
• Phillipe Kruchten
• Janice Linden-Reed
• Todd Little
• Ryan Martens
• Eric  Olafson
• Jeff Patton
• Russ Rufer
• Alan  Shalloway
• Ahmed  Sidky
• Andrew Shafer
• Dennis  Stevens
• Jeff  Sutherland
• Arline  Sutherland
• Ghennipher  Weeks

Friday Morning

I spent the morning with Ahmed Sidkey and Alistair Cockburn working on some ICAgile activities. We are trying to get the Business Analysis and Project Management tracks up now that Agile Fundamentals has launched. I am working with the Business Analysis community to coordinate the BA track and bringing the PM work from the recent (and ongoing) efforts of Alistair, Ahmed, Mike Cottmeyer, Mike Griffiths, Michelle Sliger, Jesse Fewell and others with PMI to define Agile PM.

Pre-Cocktail Party

After riding up to the conference, I got to meet and spend time with Tracy Bialik, Alistair, Ahmed, David Anderson, Alan Shalloway, Janice Linden-Reed, Phillipe Kruchten, Erik Huddleston and others greeting, catching up and talking about our expectations for the weekend.

Cocktail Party

At 8, we had a cocktail party where we met Janet Danforth and Robert Moir. Janet and Robert will be facilitating the Saturday morning discussions. There were questions spread around on tables that had been solicited from attendees by the facilitators prior to the event. They were divided into several categories for us to review and discuss. I spent some time at a table with a number of people including Ahmed Sidkey, Jon Kern, Erik Huddleston, and Scott Ambler. The discussion started off around how to get other communities (BA, PM, QA, etc) involved in the Agile. We ended up talking about resting heart rates and food densities – so while it was interesting at the moment I’m not going to blog about it here.

I then spent about half an hour in a discussion with Erik about his approach to scaling agile at his organization. He has courageously built on Dean Leffingwell’s model. He is implementing small fungible teams (high performing teams with the ability to deliver a working increment of software across the portfolio) and is using Kanban at the Program level to feed and coordinate the teams and to dynamically match capacity to demand. Then he is using Kanban downstream from the teams to coordinate integration testing, implementation, and production. This is a pattern that I have seen work well and have seen emerge from multiple directions. Mike Cottmeyer and I have been using this model as a kind of reference architecture for businesses and have had success. I believe this is an organizational adoption pattern that we will see more of.

Later I was involved in conversation with Jeff Patton and Rachel Davies talking about various topics. One was how hard it is to define explicitly how to apply certain practices when coaching teams since we tend to morph them to the moment and are always applying new concepts and ideas. Jeff is gently introducing A3 type thinking into his clients – something that we are starting to do more of – so it’s a validation of a pattern that makes sense. Jeff and I talked about how capability analysis and story mapping share some underlying patterns that seem to make sense. Rachel talked about how hard it is to to get organizations to change and how organizations seem to get stuck in destructive behavior. Jeff brought up this video as something he shows in his class to help people to recognize how they participate in their organizational dysfunction. It is pretty funny.

After Party

We had an after party from 9:00 – 11:00 where we drank Cockburn port and had more conversations. I spent some time talking to Alistair and then got to spend a while with Joshua Kerievsky and Mike Beedle talking about how important the underlying enabling technologies were to doing anything agile.  We also talked about how Scrum and XP have morphed and how implementations must be situation specific.

Summary

There are a lot of people here from various communities. Lean, Scrum, XP, etc. It would be fun to do social network map of who is connected to who in this group and what those communities look like. There was a lot of engagement and energy last night and I didn’t see any conflict. The themes of post-agile, situation specific morphing of practices, and scaling patterns were pretty common place. Today, we have a four hour facilitated session that should be interesting.

Wednesday night I did a 15 minute talk to Scrum Atlanta on Wednesday night. This was part of a series of talks on “How to do Agile Analysis”. I talked about deciding what to build. Mike Cottmeyer talked about how to break down & chunk the work. Bob Vincent talked about Progressive Elaboration & Specification. This was followed by a 45 minute fish bowl discussion. This topic is becoming increasingly important to organizations as Agile becomes more common in organizations and the session received good feedback from attendees.

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

This is the 5th principle behind the Agile Manifesto. The way this often gets translated is “take the top 10% of developers – put them in a room – and get out of their way.” This is great for the small groups of people that can build teams of entirely top 10% developers.  The question is, what do the other 90% of organizations do?

I believe this is a little chicken and egg. Do we build projects around motivated individuals – or can we design the work environment so that we end up with motivated individuals to build projects around? In the book, Understanding and Managing Organizational Behavior (George, J. M., and Jones, G.R. (2005). Understanding and managing organizational behavior, (4th ed.). Upper Saddle River, NJ: Prentice Hall.) there is a chapter entitled “Creating a Motivating Work Setting”. This chapter discusses the models and research associated with answering this question.

The Job Characteristics Model

In the 1970’s Richard Hackman and Greg Oldham attempted to identify which job characteristics contribute to intrinsically motivating work and what the consequences of these characteristics are. The thought process is that, when employees are intrinsically motivated, good performance makes them feel good – so they strive to achieve at a a high level and good performance becomes self-reinforcing.  Their model, called the job characteristics model, identifies five core dimensions that affect intrinsic motivation:

• Skill Variety: The extent a job requires an employee to use a number of different skills, abilities, or talents.
• Task Identify: The extent a job involves performing a whole piece of work from beginning to end.
• Task Significance: The extent a job has an impact on the lives and work of other people in or out of the organization.
• Autonomy: The degree a job allows an employee the freedom and independence to schedule work and decide how to carry it out.
• Feedback: The extent performing a job provides an employee with clear information about his or her effectiveness.

There has been significant research done around this model. It turns out that jobs that are high in these characteristics have the psychological effect of increasing the experienced meaningfulness of work, increasing the experienced responsibility for work outcomes, and increasing the knowledge of results. In return, these psychological states have a high correlation with the job outcomes of high intrinsic motivation, higher job satisfaction, lower absenteeism and turnover, and higher job performance.

This is exactly what we want, highly motivated individuals to build projects around. While the psychological states and the job outcomes are emergent outcomes that we can’t cause directly, Hackman and Oldham have shown that when we design jobs based on the job characteristics model we can improve the likelihood these psychological states and the resulting desirable job outcomes with emerge.

The Motivating Potential of Kanban

When implemented well, Kanban creates a work setting where the job design delivers on the five core dimensions of the job characteristics model.

• Skill Variety: In Kanban, the team members are involved in the daily planning of their work, engage in discussions around how to get the work done, perform their specific work, and may swarm on other related work.
• Task Identity: In Kanban, the entire focus is on the flow of work. The team members see the work flow from start to end.
• Task Significance: One of the focuses of Kanban is to improve the lives of the team members themselves.  The focus on flow of value also helps the team understand how they are improving the the work of the customer and/or the people their organization.
• Autonomy: Kanban allows teams to schedule their work through the pull mechanism. The self-organizing nature of the work also helps them decide how to care it out.
• Feedback: Managing Cycle Times, explicitly tracking defects, and the rapid feedback cycles associated with the limited WIP create feedback on effectiveness at multiple levels.

Kanban inherently results in job design that improves intrinsic motivation and the resulting high levels of performance.

Kanban and the Perfect Job

Hackman’s and Oldham’s job characteristic model provides insight into how the work environment can increase job performance. We tend to focus on the benefits that Kanban delivers by improving the flow of work. In addition to improving the mechanics of flow, Kanban also has the potential to result in job designs that are high in all five job characteristic domains.  These result in psychological states that correlate with desirable job outcomes including higher job performance. 

There is a risk in implementing Kanban that we end up focusing on just the mechanics associated with the flow of work. Forgetting that software development is knowledge work would be problematic. But, by leveraging the work environment of a Kanban implementation we can create an intrinsically motivating work environment. Combing improved flow with an intrinsically motivated work environment results in a much more productive organization. Focus on the human and work environment aspects along with the benefits of flow when we implement Kanban to create the perfect job for team members.

I recently posted a presentation, Agile Foundations and Agile Myths, at www.slideshare.net/dennisstevens. My goal in the presentation is to juxtapose destructive behaviors arising from a predictive approach and destructive behaviors from an agile approach. This is a deliberately provocative presentation – finding flaws with the common interpretation of both sides of the discussion. Glen Alleman over at Herding Cats responded to my presentation in his post More Agile Claims. He took offense to my “strawman” arguments against the predictive approach.

Predictive Approach to Improving Software Development

What I am calling the Predictive Approach addresses the “mental scaffolding” or underlying assumptions I see everyday in companies practicing what they believe they are guided to do in the PMBOK®, OPM3®, CMMI and DoD . The Predictive Approach describes the practices that arise from the overzealous and misguided belief that the following approach is the best way to improve software delivery.

• Standardize processes
• Optimize resource utilization
• Perform rigorous up-front design
• Produce comprehensive documentation
• Get up front commitment to a definitive Scope, Cost and Schedule
• Enforce strict adherence to the detailed plan

This is where Glen takes offense. He points out that nowhere in the PMBOK®, OPM3®, CMMI or DoD literature are we instructed to apply these in the value destroying way that I discuss. In fact, he charges that I am just “making it up.” But, Glen misses the point. I am not arguing about the literature – I agree with Glen’s interpretation. And I am not making it up. Every day I go into companies that are applying this approach in value destroying ways. In the last year I have been in multiple companies whose documented methodologies prescribe:

• linear-document driven "over the wall" process thinking
• assigning resources to multiple projects
• comprehensive upfront design with detailed documentation
• commitment to definitive scope, cost, and schedule, and
• strict adherence to precise start and stop dates for individual tasks

I am not debating the literature – it is an issue of practice. Glen suggests in our discussion in the comments to his post that even the government sometimes exhibits this value destroying behavior.  My points aren’t straw man arguments against the literature – they are attacking a common set of misguided underlying beliefs that the value destroying practices arise from.

In fact, the Agile Manifesto itself arose as a response to common practice – not as a set of new practices. As of the writing of the Agile Manifesto, the writers (and many others including Glen Alleman and myself) had been practicing software development in an “agile” way for a decade or longer. Read the agile manifesto as a response to value destroying practice that is trying to bring attention back to what is necessary to successfully deliver software projects.

The Agile Manifesto

• Individuals and interactions over process 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.

Agile Approach to Improving Software Development

And now, … the rest of the story.

The Agile literature rails against too much planning, non-value added documentation, misguided change control, de-humanizing linear process, and layers of bureaucracy.  There is clear recognition in this faction that these are value destroying. But the overzealous and misguided application of these beliefs lead to the other common set of value destroying practices I frequently run into.

• No Planning
• No Documentation
• No Estimating or Commitments
• No Process
• No PM, BA or QA

Again, I don’t see the core agile literature advising these practices either. Alistair Cockburn, Jim Highsmith, Mike Cohn, Jeff Sutherland and Kent Beck all prescribe effective practices that support appropriate and progressively elaborated planning, documentation, commitment, and process. They all support the roles of project management, business analysis, and quality assurance when they aid in managing complex products. So the second part of my presentation addresses these misguided practices and presents finding a responsible and situation specific approach to delivering software that focuses on responding to change, enhancing flow and delivering value to the customer.

The Core Discussion

Glen’s response highlights an interesting challenge. My suggestion that current project management practices are value destroying brought out a strong response against agile. I have had the same response from the agile community when I suggest that agile beliefs result in value destroying behavior. Businesses need to be able to make informed business decisions – so we need predictability and planning (Check out Glen’s immutable principles). At the same time we need to manage the work in a way that protects and optimizes value. What is missing in many organization’s is a way to have the responsible discussion exploring underlying assumptions. Companies need to finding ways to make the situation specific changes necessary to balance predictive planning and agile execution.

I presented my presentation on Agile Foundations and Agile Myths twice this week. First to the PMI Atlanta Professional Growth event. Then today to the Enterprise Application team at Turner. I am pretty happy with the presentation and both were well received. One of the things I promised to both groups was to point people to some of the Agile Project Management resources available in Atlanta.

First, PMI has launched a Virtual Community for Agile Project Management. Both Mike Cottmeyer and I are involved in the core leadership of this team. This community has discussions groups, and with our our new efforts going into next year, the site will have new webinars, a newsletter, and papers.

There is an Agile Atlanta group that meets the first Tuesday of every month at the Matrix Resources offices. This group focuses on Agile development.

There is a Scrum Atlanta group that meets the 4th Wednesday of each month – except November and December sometimes. This is a broader group than the Agile Atlanta group – including project managers, testers, business analysts, and Scrum advocates.

Mike and I are also in the process of forming a PMI Agile Local Interest Group. Follow me here for more information. We hope to have details on where and when we are meeting pretty soon. This group will focus on Project Management for Agile Organizations and Scaling Agile into the Enterprise.

To all the people who attended my talks this week, thanks coming out and for the great feedback. Please come participate in the Agile community here in Atlanta.

I really enjoyed Agile 2010 this year. My workshop, “Feeding the Agile Beast”, and presentation, “Using Lean and Agile to Lead Business Transformation”, were both well received. We found good interest in the Agile Extension to the BABOK. ICAgile was a topic of conversation and for the most part we found an appetite for a solid certification model. I also got to spend time with people I consider to be in my tribes. Just to name a few – note: if I fail to mention someone it is not intentional, just tweet me and I will add you to the appropriate clan(s)

• The Agile Project Manager clan: Mike Cottmeyer, Pat Reed, Michelle Sliger, Brian Bozzuto, including ICAgile visionary Alistair Cockburn
• The Kanban clan: Karl Scotland, Chris Shinkle, Eric Willeke, Mike Cottmeyer, and Brandon Carlson
• The Enterprise Agile clan: Alan Shalloway, Dean Leffingwell, Jim Highsmith, Portia Tung and Mike Cottmeyer
• The Agile Business Analysis clan: Pascal van Cauwenberghe, Shane Hastie, Kevin Brennan, Steve Adoph, Ellen Gottesdiener, and Mary Gorman
• The Agile Testing / Quality Assurance clan: Liz Hendrickson and Lisa Crispin

While some of these people, like myself, may have come from coding backgrounds, none of these people are primarily heads down technical resources. All of these people have spent years – some of us decades – improving our craft. All of these people bring deep experience, passion and knowledge to an area that is deeply necessary to deliver Agile projects to organizations.

It isn’t just about code

I was rankled by comments that came out at the end of the conference from people that I deeply respect that there wasn’t enough technical content at the conference. It wasn’t so much the comments as the context that they were delivered in. The troubling perspective was encapsulated in a post that said, “too much of the content was not technical. It was simple content that could be easily understood and digested.” I have tremendous respect for developers. I used be one – and I was pretty good. But about 15 years ago or so I realized that I could create more value in organization’s by removing the organizational constraints that create difficult environments for developers.

When you get beyond pretty small organizations, just writing code is not enough. In fact, without the capabilities practiced by my Agile Project Management, Kanban, Enterprise Agile, Agile Business Analysis, and Agile Testing clans, you can’t deliver value to customers. And the craft of being great at these in organizations is just as challenging, evolving, and important as any line of code anyone ever wrote.

Excuse me, but are you kidding me

Does anyone really think that the work of these clans is easily understood and digested? Getting organization’s to focus on strategy, then translate the strategy into work that can be developed, then coordinate that development across functions, then ensuring that what is needed is what is delivered, and then implementing the changes necessary to ensure the business receives value is not easily understood and digested. As a matter of fact, I think it is at least as interesting and difficult a problem as writing good code. And I think in the context of leveraging Agile software development in organization’s it is just as valuable and not as well understood.

My Job is Hard, Yours is Easy

A common bias in organization’s is the fundamental attribution error. This is also known as the self-serving bias. This manifests itself when people attribute different circumstances to their experience than they do to the experience of others. I see this all the time when coaching organization’s.  People devalue the contribution of others and overvalue their contribution. This attitude leads to bunkering down in silo’s, organizational conflict, and obstacles to improvement and flow of value.

I have written code in an organization. It is hard. But I have also been responsible for business analysis, project and program management, quality assurance, process improvements, training, organizational design, and change management aspects of projects. All of these are important, all of them are hard. Delivering value for the business requires cadence and flow among these disciplines. As you are making assessments of how simple and easily digestible non-technical content is remember this tendency. Just saying, “My job is hard, and yours is easy”, doesn’t make this assertion true. And it results in value destroying behavior.

Over the last month I have presented or participated in several user groups and conferences. There was Southern Fried Agile in Charlotte, Agile 2010 in Orlando, a PMI Atlanta professional growth event, meetings of Agile Atlanta and the Atlanta Scrum Meet-up, and Product Camp Atlanta (not surprisingly in Atlanta). These conferences give me an opportunity to meet with people doing, or attempting to do agile in the enterprise. There are a lot of common patterns that I am seeing. One of the most common patterns is that we are doing QA all wrong in most companies.

Imagine if someone approached you up front and said “I have an idea. Let’s design our product development system like this. First, development is going to take in less then precise requirements. Then development is going to build something from the requirements. Then we are going to deliver this to a separate group that will then figure out how to test it for accuracy. Then that team will test it. When the product doesn’t pass the test we just defined we will return it to development for them to fix it.”   Is this the way that your test organization operates with your development organization? Does the relationship between QA and development seem reasonable? Why are challenges between QA and development so prevalent in our organizations?

We Don’t Understand Quality Assurance

Quality Assurance and Quality Control are different things. We have Quality Assurance organizations – but most often they are involved in Quality Control control activities.

Quality Control: Find defects. These activities are focused on validating the deliverable. They are performed after the product (or some aspect of the product) has been developed. It also enforces fit to specification. This protects production and our customers from getting defective deliverables that do not meet the specification. But when done on a completed product it isn’t doesn’t enable flow and defects found downstream of the deliverable result in rework in development.

Quality Assurance: Prevent defects. These activities are focused on the process used to create the deliverable. They are performed as the product is being developed. So, Quality Assurance should be helping us improve our processes so we don’t create defects in the first place. A key point to this is that creating a common understanding of the specification and how we will validate it up front is really important to eliminating defects.

If your Quality Assurance activities are primarily focused on finding defects and ensuring fit to requirements after the fact then your QA group is primarily doing Quality Control. Getting QA involved in improving the specification communication process through is a good place to start. A specific technique might be exploring communicating acceptance criteria to development with the same examples QA will use to perform acceptance tests.

We Don’t Understand the Cost of Rework

Finding defects after the product has been delivered ensures that you will generate rework. Rework from failed QA tests are extremely expensive to flow. Sending work back into development interrupts work in process. This has a dramatic effect on cycle time across the system – which results in increased cost of every item in the system.

After the fact testing is also typically done in batches when a release or iteration is delivered to QA from development. Defects uncovered in these batches create bottlenecks at development.  Just like when traffic backs up on the highway, bottlenecks in product development result in a long term cost to the overall system.

We can dramatically reduce the cost and adaptability of the system by reducing this rework. One way to address this defect bottleneck is to perform quality control frequently – not in batches. Another way is to prevent defects through effective quality assurance in specification understanding and in development. This will reduce the number of defects produced that escape to Quality Control.

We Have Designed the Product Development System Wrong

We used to teach that there needed to be a separation of testing and development. Having them both report to the same person was like having the person that wrote the checks in accounting also reconcile the check book. It was too easy to cheat.  We created QA teams that were completely separate from development – and that reported up through different management structures. I was talking to the director of development at a company where the QA and development chains of command meet at the CEO. When you design the organization to QA and development in different silo’s you will make it very difficult to have effective Quality Assurance involvement. You will ensure Quality Control behavior.

This separation made sense at one point (I think). It doesn’t make as much sense today – especially as the resulting silos result in slower delivery times and increased costs. What has changed in the last 10 years is:

• the cost of setting up testing environments is much lower
• our ability to rapidly and frequently produce testable deliverables for these environments is much greater, and
• our ability to perform acceptance, integration, regression, performance, load, and stress testing frequently is enhanced.

Quality Assurance needs to be part of the development team and process. We need to change our thinking around this.

So we need to integrate Quality Assurance very early in the process. We need to ensure early arrival of acceptance test examples to development. But, we still need independent test teams when we are doing large or complex projects that require integration of many team’s outputs. Independent test teams can be running parallel testing or test-immediately-after delivery. When they are getting high quality components, they focus on user experience, performance, load, and stress testing.  Move everything you can into the development teams (enhanced with quality assurance) so you can produce low defect escape rates. Then eliminate the defect bottleneck and increases in cycle time by treating most of the defects at the independent test team as new specifications to development.

We have the Wrong Expectations

We Expect Perfection – Not Improved Value

Our QA organizations tend to be focused on defect identification and perfection in delivery. The focus of QA, and everyone in the organization, needs to be on producing value-add and delighting the customer – not on defect-free code. This doesn’t mean that defects are okay – but every application has some defect or limitation. Unless you are building aircraft navigation systems or other critical systems you are going to deliver some defects. Make sure the defects don’t block business value – but there is a point where it is more important to the customers and business to deliver value.

We Expect Local Optimization – Not Flow

Rather than perfecting Quality Control, QA can add a lot of value helping the organization enhance the flow of value through the entire product development system. Delivering a unit of value requires analysis, development and testing. There is no value delivered internally. The local optimization problem of improving one area at the expense of another is not useful. Crossing the boundaries between analysis, development, and testing is needed to optimize flow of value. The various teams need to figure out how to do it together – not just improve their area.

Expect our Current Constraints to be Permanent

Organizations labor under the belief that their constraints are fixed. Find a way to break down the barriers that lead to your constraints. Don’t accept the current constraints as permanent. Increase thinking at the system level to find ways to improve the product development process.

We Don’t Use the Tools Available to Us

There is an impressive amount of automation and related techniques available at very low cost to help build the QA environment that allows for fast feedback, building on progressively tested levels, and improving opportunities for frequent testing. Developers should be using tools that support automated unit testing and only checking in code that passes all their unit tests. This provides a basis for validation and refactoring. Test driven development or test  just after development should be ubiquitous – but it is not. Continuous Integration environments that ensure that each check-in results in a valid and testable platform help teams perform integration and build validation. This helps everyone work on a stable build and ensures that no one gets way off track. There are automated tools for acceptance testing and some levels of UI testing. When the tools are combined you can build a very powerful regression testing environment that can also rapidly perform performance, load, and stress testing.

The lack of general adoption of these tools probably has multiple roots. Sometimes it can be difficult to leverage all of them with legacy systems. They require new skill sets and generate new artifacts that have to be maintained. On the surface, they automate tests that are currently performed by QA groups and so their is fear and organizational threat. But some subset of these tools should be broadly adopted by each team. QA teams can focus their efforts on valued added items like Exploratory Usability Testing and Release Validation.

Summary

Most organizations are doing QA all wrong. It is time to start doing it right, the cost of low quality in dollars, time, customer satisfaction, and the engagement of employees depends on it.

• Switch their primary focus to Quality Assurance
• Help the organization reduce re-work
• Integrate QA and QC with analysis and the development organization and work to eliminate defects – not just identify themF
• Enable value, flow, and ongoing improvement
• Leverage proven tools and techniques across the Product Development Organization to increase the value delivered

The status quo is not sufficient to meet the needs of most organizations. While not all of these approaches will be right for every situation, the rate of adoption is too low to be justified. There is far too much latent value being tied up in organizations because we are doing QA all wrong.. What obstacles do you see in your organizations?