Disciplined Agile Applied

Image source: Getty

Quick answer:

On the surface yes, but in practice no.

Detailed answer:

Here are some observations that I suggest you consider:

1. Choices exist, like it or not. In about 99.9% of situations, there are multiple ways to do things.  Consider ways that you can go about making coffee. You could add instant coffee crystals to hot water, you could percolate your coffee, you could do a pour over using a mug filter, you could use a french press, you could use a Keurig machine, or many other options.  But I bet that you have one or two ways of making coffee in your household at most, likely to keep things simple. Fair enough. Now step back and observe how you've gotten to this point.  At some point in the past you narrowed down the myriad of choices to the one(s) that work well for you given your situation.  Perhaps you simply do what you were taught by your parents, perhaps a friend introduced you to a new technique which you then experimented with and eventually adopted, or perhaps you investigated your options and choose what made the most sense to you.  My point is that options always exist, whether you're aware of them or not, and that in some manner you will make the best choice that you can.

2. Disciplined Agile (DA) makes the choices explicit. This can be confusing at first, particularly if you still believe in the idea of best practices that describe the one "right way" to perform an activity.  But the "right way" depends on your situation.  Once again, consider making coffee.  Some people will tell you the best way is to use an expensive espresso machine that are used in cafes. Although I've had baristas make me incredible coffees with such machines it's not the best way for me because I don't have that level of skill (right now, maybe one day though).  But I can make a pretty mean coffee with a French press, so that's my preferred approach.  But the fact is that most days I use a simple one-cup coffee machine because that's easier.  Different situations motivate me to follow different strategies, but I can only choose the current "right way" if I know what options I have available to me and the skills and tools to adopt those strategies. Because I find myself in different situations, some mornings I have a lot of time so a French press strategy is viable, some mornings the power is out so I have to use a percolator pot on my gas range, sometimes I use my one-cup machine, and maybe one day I'll learn to use the fancy machine that we have sitting in the closet right now.  My point is that one approach isn't going to fit all situations, that to be effective you're going to want to choose the most appropriate strategy for your current context.  Concepts such as the goal diagram below, which captures many of the planning options available to you, can be daunting at first.  We get that.  But as I said earlier, these options exist whether you like it or not, and if something straightforward such as making a cup of coffee requires you to make choices then certainly you will also need to choose wisely in your work setting.

Figure 1. The Plan the Release process goal.

3. DA suggests potential starting points to potentially simplify your decision process.  When you're new to making coffee, you don't want to be presented with twenty different options to do so.  Instead you want to be shown one way of making coffee, likely a simple one at first that reflects your current level of skill. You need a starting point from which to get going.  So we do that in DA.  As you can see in Figure 1, some of the options are highlighted.  That's an indication that those techniques are a good starting point for any team that is reasonably small and in a reasonably straightforward situation.  These highlighted choices are based on what we've seen agile project teams do in practice over the years, once they've struggled through making a method like Scrum actually work for them. By starting with the highlighted options, rather than going through the harder work of figuring things out on their own, teams starting with DA are much further ahead of the game because DA covers the full range of challenges faced by agile teams.  In my experience is a much simpler approach.  But of course, if your team isn't in a relatively straightforward situation then you'll need to apply the tool kit to choose your own way of working (WoW).

4. Choosing a fit-for-purpose approach is simpler. I fully understand why people like defined frameworks - when you're new to something, such as learning how to work in a more agile manner, it's comforting to be told what to do.  But what if the framework, or the highlighted strategies I described above, really isn't that good a fit for you?  What if someone else in your organization decides to inflict their "best practices" on your team, such as your finance department insisting that you provide a detailed up-front estimate before they'll fund your project, which really doesn't mess well with an agile WoW? When you adopt a WoW, or have one forced on you, that isn't appropriate for your situation that's a lot of unnecessary work and frustration that you just don't need.  It might be a simple decision for you to make, but it's not a simple way for you to execute. 

5. What works today might not work tomorrow. Even when a framework is a good fit, or the highlighted DA options are, your situation will eventually change and there will no longer be a good fit.  For example, I currently have room on my kitchen counter for a coffee maker.  But what if we buy a new kitchen gadget that requires counter space, which we don't have any to spare. The coffee machine might need to go, which means I need to resort to my French press (granted, not such a hardship) or instant coffee (that's not going to happen).  Changes in my context require changes to my morning coffee process.  Similarly, your agile teams were forced to change their WoW in early 2020 when COVID-19 forced people to work from home.  Many teams had to scramble to figure things out, DA teams could look over the options for coordinating between locations called out by the coordinate activities process goal.

6. You can do this, it really isn't that hard.  It clearly takes a bit more skill and knowledge to choose your own way of working (WoW) compared with just following a defined framework. Luckily, you can easily gain these skills by earning PMI's Disciplined Agile Scrum Master (DASM) and Disciplined Agile Senior Scrum Master (DASSM) certifications. After a bit of learning you can easily apply these skills to improve your WoW for many years to come.  You've got this.   

One of the seven principles behind Disciplined Agile (DA) is Context Counts. Every person is unique, with their own set of skills, preferences for workstyle, career goals, and learning styles. Every team is unique not only because it is composed of unique people but also because it faces a unique situation. Your organization is also unique, even when there are other organizations that operate in the same marketplace that you do. For example, automobile manufacturers such as Ford, Audi, and Tesla all build the same category of product yet it isn’t much of a stretch to claim that they are very different companies. These observations – that people, teams, and organizations are all unique – leads us to a critical idea that your process and organization structure must be tailored for the situation that you currently face. In other words, context counts.

CONTEXT FACTORS

Figure 1 overviews the potential factors that you should consider regarding the context of the situation faced by your team.  We’ve organized them into two categories:

1. Selection factors that drive your initial choices around your high-level way of working (WoW) and in particular your choice of initial lifecycle.
2. Scaling factors that drive detailed decisions around your team’s WoW.

Of course it’s never this straightforward.  Selection factors will have an effect on your detailed WoW choices and scaling factors will also have an impact on your initial decisions.  Our point is that in general the selection factors have a bigger impact on the initial choices than do the scaling factors and similarly the scaling factors have a bigger impact on your detailed tailoring decisions than do the selection factors.

Figure 1. Potential context factors (click to enlarge).

Context factors are interdependent.  Figure 2 shows the major relationships between the context factors.  For example, you can see that:

• As domain complexity rises the skills required to address that complexity also rise (harder problems require greater skill to solve).
• As team member skills increase the size of the team required to address the problem it faces can shrink (a small team of skilled people can do the job of a larger team of lower-skilled people).
• Your organizational culture and your team culture tend to affect one another, hopefully positively.
• Your team culture will vary by organization distribution (your team will have a different culture than that of teams in a different division of your organization, or of teams in a different company).
• The more organizationally distributed your team becomes the greater the chance that it will be geographically distributed as well.  For example, if you are outsourcing some of the work to another organization the people doing that work may be in another, lower-cost country.

Figure 2. Relationships between context factors (click to enlarge).

TACTICAL AGILITY AT SCALE

Let’s explore the scaling factors a bit. As we mentioned earlier, the scaling factors tend to drive your detailed decisions around your way of working (WoW). For example, a team of eight people working in a common team room on a very complex domain problem in a life-critical regulatory situation will organize themselves differently, and will choose to follow different practices, than a team of fifty people spread out across a corporate campus on a complex problem in a non-regulatory situation. Although these two teams could be working for the same company they could choose to work in very different ways.

Figure 3 depicts the scaling factors as a radar chart, sometimes called a spider chart. There are several interesting implications:

• The further out you go on each spoke the greater the risk faced by a team. For example, it’s much riskier to outsource than it is to build your own internal team. A large team is a much riskier proposition than a small team. A life-critical regulatory situation is much riskier than a financial-critical situation, which in turn is riskier than facing no regulations at all.
• Because teams in different situations will need to choose to work in a manner that is appropriate for the situation that they face, to help them tailor their approach effectively you need to give them choices.
• Anyone interacting with multiple teams needs to be flexible enough to work with each of those teams appropriately. For example, you will govern that small, co-located, life-critical team differently than the medium-sized team spread across the campus. Similarly, an Enterprise Architect who is supporting both teams will collaborate appropriately with each.

Figure 3. Tactical scaling factors faced by teams.

ENTERPRISES REQUIRE ENTERPRISE-CLASS SOLUTIONS

The leading agile method Scrum provides solid guidance for delivering value in an agile manner but it is officially described by only a sixteen page guide. Disciplined Agile recognizes that enterprise complexities require far more guidance and thus provides a comprehensive reference framework for adapting your agile approach for your unique context in a straightforward manner.  Being able to adapt your approach for your context with a variety of choices (such as those we provide via goal diagrams) rather than standardizing on one method or framework is a very good thing.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile

One of the seven principles behind Disciplined Agile (DA) is Optimize Flow.  Your organization is a complex adaptive system (CAS) of interacting teams and groups that individually evolve continuously and affect each other as they do. The challenge that we face is how do we ensure that these collaborating teams do so in such a way as to effectively implement our organization’s value streams? How do we ensure that these teams are well aligned, remained well aligned, and better yet improve their alignment over time?

The implication is that as an organization we need to optimize our overall workflow. The DA toolkit supports a large number of strategies to do so:

1. Deliver continuously at a sustainable pace. The Disciplined Agile Manifesto advises teams to deliver consumable solutions frequently, from a couple of weeks to a couple of months, with a preference to the shorter time scale. This philosophy is one of four, in this case Deliver, promoted by the Heart of Agile. Similarly it is one of four philosophies of Modern Agile, in this case Deliver Value Continuously, and it is a fundamental strategy of Disciplined DevOps. Since 2001 agilists have shown that it is possible to deliver high-quality systems quickly. By limiting the work of a team to its capacity, which is reflected by the team’s velocity (this is the number of “points” of functionality which a team delivers each iteration), you can establish a reliable and repeatable flow of work. An effective organization doesn’t demand teams do more than they are capable of, but instead asks them to self-organize and determine what they can accomplish. Enabling these teams to delivering potentially shippable solutions on demand motivates them to stay focused on continuously adding value.
2. Optimize the whole. Disciplined agilists work in an “enterprise aware” manner – they realize that their team is one of many teams within their organization and as a result they should work in such a way as to do what is best for the overall organization and not just what is convenient for them. More importantly they strive to streamline the overall process, to optimize the whole as the lean canon advises us to do. This includes finding ways to reduce the overall cycle time, the total time from the beginning to the end of the process to provide value to a customer, is a key part of doing so.
3. Make work flow. The 14th principle of the DA Manifesto is to visualize work to produce a smooth delivery flow and keep work-in-progress (WIP) to a minimum. This strategy enables teams to identify and then remove bottlenecks quickly and is adopted straight out of Kanban.
4. Eliminate waste. Lean thinking advocates regard any activity that does not directly add value to the finished product as waste. Waste includes time waiting for others to get something done, creation of unnecessary work artifacts or product features, and collaboration churn resulting from crossing organizational boundaries. To reduce waste it is critical that teams be allowed to self organize and operate in a manner that reflects the work they’re trying to accomplish.
5. Improve continuously. As a leader you want to promote a culture of continuous improvement, including the sharing of skills and knowledge between people and teams, within your organization. This is seen as a fundamental philosophy of agile – The 12th principle behind the Agile Manifesto is “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly” and both Improve and Reflect are principles of the Heart of Agile. A key technique that supports continuous improvement is “double-loop learning” that promotes the idea that you modify your approach based on what you learn from your experiences.
6. Experiment to learn. Probably the most significant impact of Eric Ries’ work in Lean Startup is the popularization of the experimentation mindset, the application of fundamental concepts of the scientific method to business. This mindset can be applied to process improvement following what Ries calls a validated learning strategy. From a process point of view, the strategy is to first identify an improvement hypothesis along the lines of “We think doing X will improve Y”. Second, run a short experiment by trying it out in a controlled manner, with measurements in place to see the effect of the change. Third, observe what happens to determine the efficacy of X and whether you need to evolve X and run a follow up experiment (double-loop learning). An experimentation mindset reinforces and often speeds up the strategy of continuous learning. As we pointed out earlier, to enable an experimentation mindset within your organization as a leader you must establish a safe environment where experimentation is encouraged and rewarded.
7. Measure what counts. When it comes to measurement, context counts. What are you hoping to improve? Quality? Time to market? Staff morale? Customer satisfaction? Combinations thereof? Every person, team, and organization has their own improvement priorities, and their own ways of working, so they will have their own set of measures that they gather to provide insight into how they’re doing and more importantly how to proceed. And these measures evolve over time as their situation and priorities evolve. The implication is that your measurement strategy must be flexible and fit for purpose, and it will vary across teams.
8. Prefer long-lived stable teams. A very common trend in the agile community is the movement away from projects, and the project management mindset in general, to long-lived teams. Such teams evolve over time, people occasionally join the team and people occasionally leave the team, but the team itself may run for years. For example, Microsoft has had a team developing and sustaining Microsoft Word since 1981 with no end in sight.  It’s important to note that this move away from project management in the agile community is not a move away from management but instead from the inherent risks and overhead of projects.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile

Enterprise awareness is one of the key principles behind Disciplined Agile (DA).  The observation is that DA teams work within your organization’s enterprise ecosystem, as do all other teams.  There are often existing systems currently in production and minimally your solution shouldn’t impact them.  Better yet your solution will hopefully leverage existing functionality and data available in production.   You will often have other teams working in parallel to your team, and you may wish to take advantage of a portion of what they’re doing and vice versa.  Your organization may be working towards business or technical visions which your team should contribute to.  A governance strategy exists which hopefully enhances what your team is doing.

WHAT IT MEANS TO BE ENTERPRISE AWARE

Enterprise awareness is an important aspect of self discipline because as a professional you should strive to do what’s right for your organization and not just what’s interesting for you. Teams developing in isolation may choose to build something from scratch, or use different development tools, or create different data sources, when perfectly good ones that have been successfully installed, tested, configured, and fine-tuned already exist within the organization. Disciplined agile professionals will:

• Work closely with enterprise professionals. This includes working closely with enterprise technical architects and reuse engineers to leverage and enhance the existing and “to be” technical infrastructure; enterprise architects and portfolio managers to fit into the overall business ecosystem; senior managers who should be governing the various teams appropriately; operations staff to support your organization’s overall development and operations (DevOps) efforts; data administrators to access and improve existing data sources; IT development support people to understand and follow enterprise IT guidance; and business experts who share their market insights, sales forecasts, service forecasts, and other important concerns. In other words, teams should adopt a “whole enterprise” mindset.
• Adopt and follow enterprise guidance. Your organization may have, or hopes to one day have, a range of standards and guidelines (guidance) that it wants delivery teams to adopt and follow. This may include guidance for coding, user interface development, security, and data conventions to name a few. Following common guidance increases the consistency and maintainability of your solutions, and thus your overall quality.
• Leverage enterprise assets. There may be many enterprise assets, or at least there should be, which you can use and evolve. Disciplined agile teams strive to work to a common infrastructure; for example, they use the enterprise-approved technologies and data sources whenever possible, and better yet they work to the “to be” vision for your infrastructure. If your organization uses a disciplined architecture-centric approach to building enterprise software, there will be a growing library of service-based components to reuse and improve upon for the benefit of all current and future solutions. To do this DA teams will collaborate with enterprise professionals throughout the lifecycle and particularly during Inception during envisioning efforts. Figure 1 summarizes the Inception phase goal Align with Enterprise Direction which summarizes the strategies you may choose to follow. Read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure 1. Inception Goal: Align with Enterprise Direction.

• Enhance your organizational ecosystem. The solution being delivered by a DA team should minimally fit into the existing organizational ecosystem – the business processes and systems supporting them – it should better yet enhance that ecosystem. To do this, the first step is to leverage existing enterprise assets wherever possible as described above, often working with enterprise architects or other enterprise professionals to do so. A Disciplined Agile Delivery (DAD) team, one that is focused on software development, will also work with operations and support staff closely throughout the lifecycle to ensure that they understand the current state and direction of the organizational ecosystem. DAD teams will often be supported by an additional independent test team that will perform production integration testing (amongst other things) to ensure that your solution works within the target production environment which it will face at deployment time. Furthermore, experienced DAD teams will even fix problems that they run into via proven refactoring techniques. Figure 2 summarizes the general goal Leverage and Enhance Existing Infrastructure which summarizes strategies for how DAD teams may accomplish this.

Figure 2. General Goal: Leverage and Enhance Existing Infrastructure.

• Adopt a DevOps Culture. DAD teams will work with operations and support staff closely throughout the lifecycle, particularly the closer you get to releasing into production. DevOps culture and strategies are baked right into DA.
• Share learnings. Disciplined Agile teams are learning oriented, and one way to learn is to hear about the experiences of others. The implication is that DA teams must also be prepared to share their own learnings with other teams. To do this organizations might choose to support agile discussion forums, informal presentations, training sessions delivered by senior team members, and internal conferences to name a few strategies.
• Adopt appropriate governance strategies. Effective governance strategies should enhance that which is being governed. An appropriate approach to governing agile delivery projects, and we suspect other types of efforts, is based on motivating and then enabling people to do what is right for your organization. What is right will of course vary, but this typically includes motivating teams to take advantage of, and to evolve, existing corporate assets following common guidelines to increase consistency, and working towards a shared vision for your organization. Appropriate governance is based on trust and collaboration. Appropriate governance strategies should enhance the ability of DA teams to deliver business value to their stakeholders in a cost effective and timely manner. Unfortunately many existing IT governance strategies are based on a command-and-control, bureaucratic approach which often proves ineffective in practice. Our book, Choose Your WoW!, explores appropriate governance, the impact of traditional governance strategies, and how to adopt an appropriate governance strategy in detail. The article Adopting Agile Governance Requires Discipline also provides greater insight.
• Open and honest monitoring. Although agile approaches are based on trust, smart governance strategies are based on a “trust but verify and then guide” mindset. An important aspect of appropriate governance is the monitoring of project teams through various means. One strategy is for anyone interested in the current status of a DA team to attend their daily coordination meeting and listen in, a strategy promoted by the Scrum community. Although it’s a great strategy we highly recommend, it unfortunately doesn’t scale very well because the senior managers responsible for governance are often busy people with many efforts to govern, not just your team. Hence the need for more sophisticated strategies such as an “development intelligence” approach supported via automated dashboards.

WHY IS ENTERPRISE AWARENESS IMPORTANT?

Agile has done a great job of helping the IT profession refocus from individual to team awareness. But if we want to be effective as professionals we at least need to promote the philosophy of enterprise awareness, so that we’re optimizing the work that we do for our organization. Agile teams that are enterprise aware will work closely with enterprise professionals, such as enterprise architects and operations staff, to ensure that they are leveraging and better yet enhancing the existing infrastructure. Their architectures will reflect their organization’s technical roadmap and similarly the scope of their effort will reflect their organization’s business roadmap. They will follow existing development guidelines and enhance them where appropriate.

By working in an enterprise aware manner DA teams enjoy:

• Higher levels of productivity because they are less likely to reinvent the wheel
• Quicker times to deployment/market because they have less work to do
• Higher return on investment (ROI) because they have less work to do
• Higher levels of quality through following common conventions and reuse

CHALLENGES TO ENTERPRISE AWARENESS

Unfortunately there are two main challenges to supporting enterprise awareness on agile teams. First is the cultural challenge within the agile community that some “agile purists” perceive this as unnecessary overhead. Reasons for this misunderstanding include a lack of understanding of the overall enterprise picture or some agilists who have previous experiences with enterprise professionals who struggle to work in an agile manner. This points to the second challenge that enterprise professionals often don’t understand how to work effectively with agile teams. Sometimes this is because the agile teams they’ve been working with until now haven’t been sufficiently disciplined to work with them effectively, but more often than not it’s because they still choose to follow older, more traditional approaches to their craft.  With Disciplined Agile we are actively working on describing an agile/lean workflow for enterprise IT.

These challenges are cultural in nature, and thus difficult to overcome. Agilists and enterprise professionals need to respect one another and strive to learn more about what the other group is trying to accomplish. They must strive to work with one another and thus learn from each other. Furthermore, they must build a culture of shared commitment and responsibility to the organization. Not only is this possible it is highly desirable.

SUMMARY

Disciplined agile teams and more importantly DA practitioners are enterprise aware. They recognize that enterprise aware strategies improve their ability to provide value to their stakeholders both within the scope of a solution as well as at the organizational level. To coin an environmental cliché: Disciplined agilists act locally and think globally.

SOURCE

This article is excerpted from Chapter 2 of the book An Executive’s Guide to Disciplined Agile: Winning the Race to Business Agility.

RELATED READING

• Principles Behind Disciplined Agile

One of the seven principles behind the Disciplined Agile (DA) toolkit is Choice is Good. Let’s assume for a minute that your organization has multiple teams working in a range of situations, which in fact is the norm for all but the smallest of companies. How do you define a process that applies to each and every situation that covers the range of issues faced by each team? How do you keep it up to date as each team learns and evolves their approach? The answer is that you can’t, documenting such a process is exponentially expensive. But does that mean you need to inflict the same, prescriptive process on everyone? When you do that you’ll inflict process dissonance on your teams, decreasing their ability to be effective and increasing the chance that they invest resources in making it look as if they’re following the process when in reality they’re not. Or, does this mean that you just have a “process free-for-all” and tell all your teams to figure it out on their own? Although this can work it tends to be very expensive and time consuming in practice – even with coaching each team is forced to invent or discover the practices and strategies that have been around for years, sometimes decades. Luckily, the Disciplined Agile toolkit provides a better way.

Different contexts require different strategies – teams need to be able to own their own process and to experiment to discover what works in practice for them given the situation that they face. This is why the DA toolkit presents people with choices through the application of process goal diagrams, see the figure below for an example of options for addressing changing stakeholder needs throughout solution delivery. The rounded rectangle indicates the name of the process goal, as in this case, or the process blade/area.  The square rectangles indicate process decision points, issues that you need to consider in your way of working (WoW).  The lists to the right of the process decision points are options, typically practices or strategies that your team may choose to adopt.  When there is an arrow beside the list that is an indication that the strategies towards the top of the list are generally more effective than the strategies towards the bottom of the list.  When a strategy is bolded it is an indication that it is a likely choice for a team that is new to agile, that is addressing a fairly straightforward problem, and that is near located (working on the same floor of a single building).  If that's not your situation then you may find you need to make other choices. Please read Disciplined Agilists Take a Goal-Driven Approach for more information on DA’s goal-driven strategy.

Figure. The goal diagram for Addressing Changing Stakeholder Needs.

The idea of goal diagrams is to make important decision points explicit, such as when to accept changes, and then present teams with their options and the tradeoffs surrounding those options. This enables teams to make better process choices given the situation that they face. To make these choices, teams need to know:what each option is, the tradeoffs associated with each one, and in what situations the option is and isn’t applicable. DA takes a similar, goal/choice-driven approach to IT process areas such as Data Management and Reuse Engineering as well as enterprise process areas such as Enterprise Architecture and People Management (often called Human Resources or Talent Management).

This choice-driven strategy is a middle way. At one extreme you have prescriptive methods, which have their place, such as Scrum and SAFe which tell you the one way to do things. Regardless of what the detractors of these methods will tell you these prescriptive strategies do in fact work quite well in some situations, and as long as you find yourself in that situation they’ll work well for you. However, if you’re not in the situation where a prescriptive method fits then it will likely do more harm than good. At the other extreme are experimental methods such as Spotify that tell you to experiment and learn as you go. This works well in practice but can be very expensive and time consuming and can lead to significant inconsistencies between teams which hampers your overall organizational process. Spotify had the luxury of evolving their process within the context of a product company, common architecture, no technical debt, and a culture that they could grow rather than change.  DA sits between these two extremes – by taking this process goal driven approach it provides process commonality between teams that is required at the organizational level yet provides teams with the flexibility required to tailor and evolve their internal processes to address the context of the situation that they face. Teams can choose from known strategies the likely options to then experiment with, increasing the chance that they find something that works for them in practice. At a minimum, it at least makes it clear that they have choices, that there is more than the one way described by the prescriptive methods.

There is a catchy phrase in the agile world called “fail fast” or better yet “learn fast.” As described earlier leadership should encourage experimentation early in the interest of learning and improving as quickly as possible. However, we would suggest that by referencing the proven strategies in Disciplined Agile you will make better choices for your context, speeding up the learning process and failing less.  We have developed a technique called Guided Continuous Improvement (GCI) that describes how to do this very thing.  I will blog about GCI in future postings and we will soon have PMI-certified workshops that teach GCI.