Posts Tagged ‘Enterprise Agile’

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.

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.

Linked to Strategy

Posted on September 7th, 2010 by Dennis Stevens  |  1 Comment »

What is keeping corporate executives up at night? Is the CxO laying awake wondering if her company is good at project management or software development? Probably not. AMA says that the top issue facing executives is executing their strategy.

“The practice representing the largest difference between higher and lower performers is demonstrating the ability to quickly and effectively execute when new strategic opportunities arise.”
~ AMA, The Keys to Strategy Execution, 2007

So what are the keys to executing strategy? Recent research from PMI shows that when we align projects with the business strategy and clearly communicate the strategy to the team, then projects are delivered at a much higher rate.

“The single most important factor influencing project success is the project’s link to the organization’s business strategy and the project manager’s understanding of how the project supports the business strategy.” 
~ CIO Magazine-November 2009: Business Strategy: The "Best Determinant" of Project Success

So it sounds easy, we need to focus on executing the projects that advance our business strategy. And we need to communicate this strategy across the organization and the project team. How well do the ways that we select projects and communicate their strategic significance accomplish this?

How Do We Select Projects?

So how do most organizations decide where to invest? Projects are selected for the portfolio based on local ROI’s calculated by business managers, or by spreading investment across the organization based on head count like peanut butter, or by charging IT organizations to run IT like a business with departmental reimbursement. Are these the best ways to handle this? Probably not. None of these connect the projects to strategy – and none of these make the connection between strategy and the project explicit.

ROI’s are almost impossible to estimate. Local ROI’s don’t equal organization level benefit. For example, one organization spent $10 million implementing an automated solution to allow them to scale for seasonal demand. The $10 million was justified through service improvement and reduced labor in the department but it shifted significant costs from departmental budget to the IT department for customizations, maintenance, and ongoing licensing. In addition, ROI’s don’t provide an effective way to communicate the underlying assumptions about how the project supports the business strategy.

Spreading investment based on head-count assumes that all improvements are equal or that we can do enough in each area to raise the whole ship. The is no way we can make all the improvements in the organization, there is a limited amount of capacity for change and there is a limited amount of resource to invest. It is extremely unlikely that all problems will result in the same benefit to the business. In fact, this approach, while extremely common, ends up being destructive. It spreads limited resources too thin, it creates excessive demand for the enabling functions (IT, training, project management, support). And it obfuscates business strategy.

Running IT like a business sounds great, but it is another case of local optimization. IT is an enabler of business value. Some of the investments the business needs to make will have short term costs but they will return long term value for the business. When IT is run from the view of short term profitability you will often miss out on the most important investments. In this case, IT’s strategy – making profit from its resources from the business – it not aligned with the business strategy itself.

Based on numerous studies, the leading obstacles to project success are related to scope creep and shifting requirements, inadequate and/or disappearing resources, and a lack of effective executive sponsorship. All of these are related to organization’s trying to execute strategy without a clear alignment between strategy and the projects in the portfolio. Local ROI’s, equal distribution of investment, and local optimization of IT don’t solve these problems. They don’t clearly connect project efforts to the business strategy. And they aren’t resilient to the real changes in the market that businesses have to be able to adapt to.

So What Do We Do?

We need a way to reflect the business model and the where the strategy impacts the business model. We need to be able to clearly articulate what changes need to take place to deliver on the business strategy. And we need to be able to adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily.

We use capability mapping to achieve this. A capability map, as discussed in an article I co-authored June 2008 Harvard Business Review "The Next Revolution in Productivity" http://hbr.org/2008/06/the-next-revolution-in-productivity/ar/1 addresses these challenges. It clearly articulates the business model in a stable way, let’s you directly connect the business strategy to the business model, and let’s you connect project efforts to the capability map. This provides traceability from project to business model to strategy in a powerful visual management tool.

Five Steps to a Powerful Capability Map

1. Articulate the Near Term Business Strategy.

We frequently use a model we have developed based on Patrick Lencioni’s “Silos, Politics, and Turf Wars” called a Thematic Goal Model. It is straight forward, powerful, and communicates clearly. We can provide input to this from a SWOT analysis, a balanced score card, or multiple empirical methods like QFD to determine strategic themes. The outcome is a clear statement of a limited set of the near term strategic themes. The next set of “big rocks” that need to move to advance the business strategy. The important thing here is to make it visible and to get buy-in from the organization.

2. Decompose the Business into its Constituent Capabilities.

Decompose the business into the activities or functions of the organization. The activities are performed for a purpose, to achieve some outcome or transformation the business needs to accomplish.  Then, interpret activities as capabilities. Capabilities are independent of how they are done, who does them, and the organizational structure. They are named in a “Verb-Noun” form and express the underlying business purpose. A common mistake is to treat a process, or a “how”, as a capability. For example, “Produce Invoice” is not a capability. The business purpose is not to produce an invoice. The purpose of producing an invoice is to “record a customer charge”  and to “request payment from the customer”.  You can decompose the capability map to whatever level is interesting for your particular situation. We will do a limited drill down to start and then build out a more detailed view as the business strategy dictates. This can keep you from getting stuck in an analysis paralysis. Develop the map collaboratively, you will want buy-in from the organization when it is time to make the tough calls about what to invest in.

3. Evaluate the Capability Map in the context of the Business Strategy.

For each capability you can ask a few questions determine the strategic significance. Is this capability directly related to the business strategy? Would a significant change in this capability directly help the business execute its strategy? This can be an interesting exercise because different people will have different perspectives on what is important. Be rigorous in the assessment. Everything in a business is connected at some level. You are looking for direct relationships between capabilities and strategy. When you get down to determining how to address any interesting capabilities you will get a chance to explore the other related capabilities. Keep bringing the focus back to the strategic connection – not to individual functions. Rank the capabilities on a scale of 1-5 with 1 being directly and 5 being not at all. The capabilities that end up being a 1 or a 2 are strategically interesting.

image4. Determine Performance Gaps at the Strategically Interesting Capabilities.

Now, look at the strategically interesting capabilities. Determine the performance gaps you would need to close to achieve the business strategy. You are not looking to identify every potential improvement at the capability – you want to be specific about what improvement is needed at which capability to achieve the specific business strategy. Again, you have to be rigorous. The goal is to identify the smallest subset of changes needed to achieve the business strategy. Remember, this is a focusing effort.

5. Determine a Road Map to Achieve the Strategy.

Now, you have a very clear set of improvements to focus your improvement efforts on. Drive your portfolio decisions from here. Articulate these as a specific performance improvement, at a specific capability, to achieve a specific strategic outcome.  Initially, all of this is done at a relatively high level. Once you have your specific initiatives you can do more detailed discovery about the best way to accomplish the objectives. Lay these initiatives out across all the enabling functions. You want to balance the efforts against capacity to optimize time to strategic value.

Summary

Now we have a way to reflect the business model where the strategic impact is explicit. We can clearly articulate what specific changes need to take place to deliver on the business strategy. This model can keep us focused when we start to get pressure from multiple directions. But we can also adjust this model rapidly and communicate the real shift in strategy to everyone in the organization easily. Better than ROI approaches, better than a bottom up local optimization model, better than running IT as a business, we can focus our efforts on executing the projects that advance our business strategy. We can synchronize efforts across the various enabling functions to optimize time to strategy. And we can communicate this strategy across the organization and the project team. Each activity on every project can be clearly linked to strategy.

My Job is hard, Yours is easy

Posted on August 30th, 2010 by Dennis Stevens  |  1 Comment »

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)

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.