PMI Atlanta Chapter Agile Local Interest Group

Posted on March 16th, 2011 by Dennis Stevens  |  4 Comments »

Last night was the inaugural meeting of the PMI Atlanta Chapter Agile Local Interest Group. This group will meet on the third Tuesday of every month to provide Agile speakers and events to support the Agile Project Management community. I am heading up the LIG with a great group of volunteers including Phyllis St John – who has been instrumental in getting the LIG up and running. Cox Enterprises provided that space and John Kosar from CCCI sponsored dinner and coordinated the space.

I was the presenter last night. I did an introduction to the roots of Agile and talked about Knowledge Domains around the new PMI Agile Certification.

Thanks to everyone who attended and provided input on what you would like to see from the LIG.

Mike Cottmeyer will be presenting next month. I will post details here on the location as we get that sorted out.

PMI Agile Certification

Posted on February 25th, 2011 by Dennis Stevens  |  7 Comments »

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:

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

Reflections on #10yrsagile – What is Value?

Posted on February 20th, 2011 by Dennis Stevens  |  4 Comments »

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.

Deciding “What” To Build

Posted on February 20th, 2011 by Dennis Stevens  |  No Comments »

This is my presentation from Product Camp Atlanta. I address two big issues facing product management. First, establishing an approach to connect product strategy with business strategy, customer value, and risk. It provides the structure for feedback and rapid reassessment of the product road map (backlog). Second, the presentation demonstrates how to leverage the model to reduce the miscommunication, over analysis, over design, and over engineering that leads to scope creep and misalignment between the desired solution and what is actually delivered.

What’s Next for the Agile Manifesto

Posted on February 13th, 2011 by Dennis Stevens  |  11 Comments »

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.

10 Years Agile–Friday Night

Posted on February 12th, 2011 by Dennis Stevens  |  3 Comments »

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.

Agile Business Analysis – Deciding What to Build

Posted on January 28th, 2011 by Dennis Stevens  |  2 Comments »

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.

kanban and the perfect job

Posted on January 16th, 2011 by Dennis Stevens  |  2 Comments »

“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.

Standing By My Agile Claims

Posted on November 25th, 2010 by Dennis Stevens  |  2 Comments »

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.

Agile in Atlanta

Posted on November 10th, 2010 by Dennis Stevens  |  4 Comments »

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.