Category Archives: Uncategorized

How Do You Choose Between Software Lifecycles?


As you know the Disciplined Agile framework supports several delivery lifecycles – Agile, Lean, Continuous Delivery: Agile, Continuous Delivery: Lean, Exploratory.  We do this because solution delivery teams face different situations, so one lifecycle will not fit all.  This begs the question of when would a team adopt each lifecycle?  That is the focus of this blog.

This blog explores the following topics:

  1. What lifecycles does DAD support?
  2. What criteria should you consider when choosing a lifecycle?
  3. Who chooses?

What Lifecycles Does DAD Support?

The delivery lifecycles we will explore are:

  1. Agile/Basic. DAD’s Agile/Basic lifecycle which extends Scrum’s construction lifecycle. We call this the basic/agile lifecycle because it’s likely where you’re going to start. Common scenarios for adopting this version of the lifecycle include situations where you’re extending Scrum to be sufficient for your needs or you’re transitioning from RUP to a disciplined agile approach.
  2. Lean/Advanced. The Advanced/Lean lifecycle encompasses lean strategies such as minimizing work in process, maximizing flow, a continuous stream of work (instead of fixed iterations), and reducing bottlenecks. New work is pulled from the work item pool when the team has capacity.
  3. Continuous Delivery: Agile.  The Continuous Delivery: Agile lifecycle  is a natural progression from the Agile/Basic lifecycle. Teams typically evolve to this lifecycle from the Agile/Basic lifecycle, often adopting iteration lengths of one-week or less. The key difference between this and the Agile lifecycle is that the continuous delivery lifecycle results in a release of new functionality at the end of each iteration rather than after a set of iterations.
  4. Continuous Delivery: Lean. DAD’s Continuous Delivery: Lean lifecycle is basically a leaner version of the Continuous Delivery: Agile lifecycle where the product is shipped into production or the marketplace on a very regular basis. This could be often as daily, although weekly or monthly is quite common too.
  5. Exploratory/Lean Startup.  DAD’s Exploratory lifecycle is followed by agile or lean teams that find themselves in startup or research situations where their stakeholders have an idea for a new product but they do yet understand what is actually needed by their user base.
  6. Waterfall/Serial.  Although this is not supported by Disciplined Agile, we do recognize that some teams will still follow this more traditional way of working.  For more thoughts on this subject, please see the blog posting When Does Traditional Software Development Make Sense?


What Criteria Should You Consider When Choosing a Lifecycle?

The following table compares the lifecycles, suggesting when you would choose to follow each one.

Lifecycle Team Type Time to Market Advantages Disadvantages When to Use
Agile/Basic Project Medium
  • Straightforward lifecycle based on Scrum that is easy to learn due to its prescription
  • Iterations (sprints) motivate teams to build functionality in multi-week batches
  • Releases into production typically months apart
  • Tends to fall apart when requirements change often
Teams new to agile
Lean/Advanced Project Fast
  • Functionality is released into production when it`s ready to go
  • Work can be prioritized via a variety of criteria
  • Small batches of work lead to quick flow
  • Requires greater skill and discipline compared to the Agile lifecycle
Disciplined teams with quickly evolving requirements
Continuous Delivery: Agile Product (long lived) Fast
  • Functionality is released into production regularly at a steady flow (typically weekly)
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running teams
Continuous Delivery: Lean Product (long lived) Very Fast
  • Functionality is released into production continuously, typically one or more times a day
  • Requires significant skill and discipline
  • Requires automated testing, integration, and deployment
Long-running, disciplined teams
Exploratory/Lean Startup Experimental Fast
  • Quick and inexpensive way to run business experiments
  • Low-risk approach to validating potential new business strategies
  • Requires a way to target a subset of your (potential) customer base
  • Often not applicable in regulatory compliance situations
  • Often perceived as a strategy for startup companies only
Identification of a new product or service offering for the marketplace where there is a high risk of misunderstanding the needs of potential end users
Waterfall/Serial Project Slow
  • Comfortable approach for experienced IT professionals who have not yet transitioned to an agile or lean way of working
  • Tends to be very high-risk in practice due to long feedback cycles and delivery of a solution only at the end of the lifecycle
  • Associated risks are often overlooked by management due to façade of predictability and control provided by the paperwork produced
Low-risk situations where the requirements are stable and the problem has a well-known solution.  For example, upgrading the workstations of a large number of users or migrating an existing system to a new platform


Who Should Choose the Lifecycle?

The team.

They will often do this with the guidance of an experienced Disciplined Agile coach, particularly when they are new to DA.  It’s tempting to have your portfolio management team to make this choice, and they may often make a (hopefully solid) suggestion when the first initiated an endeavour, but in the end it needs to be the choice of the team.  As you see in the table above there are common considerations for when to use each lifecycle, but the primary considerations are always the skill and preferences of the team itself.


Related Reading

True Enterprise agility

The Lean Enterprise genie has been out of the bottle for some time now, but for most organizations he’s still a long way from granting three wishes


The Lean Enterprise … Enterprise Agility … DevOps 2.0 …  BizDevOps … the list of monikers and descriptors for this concept is becoming a lengthy one, but there’s no denying that lean and agile concepts and practices are now mainstream, and pushing to break out of their former boundaries within software development.

Reflecting on this, I came across a very apt description (in, of all things, a conflict simulation design blog) of what seems to be happening in this realm of late:

“Most new ideas, however fresh or spontaneous they may appear at first glance, usually represent an evolutionary synthesis of previous ideas; in other words, when it comes to most things, history really is “preamble”.1

The idea of bringing business, development and operations people to the same table to act as a tripartite coalition from the very start of product development has been gaining exponential momentum of late. As far as ideas go, it is not an entirely new one of course. Encouraging collaboration from the get-go has long been a hallmark of Agile approaches – in development for example, George Dinwiddie is believed to have coined the term “the three amigos” around 20092 to describe the interplay of developers, testers and business analysts / product owners from an Acceptance Test Driven Development (ATDD) perspective. However, other than describing a tripartite arrangement, the 3 amigos analogy differs from the most recent crop of expressions in that contrarily to say, BizDevOps, it only actually plays on two of the required three planes.

Another oddity that struck me is that one of the first high visibility discussions that I can remember describing the interplay of business, technology and operations actually framed the debate in terms of an antipattern: to wit, a July 2011 Forrester whitepaper which coined the expression “Water-Scrum-Fall”3 as a way of describing the very lack of cross-enterprise collaboration which bedevilled most organizations’ agile efforts.


The need for systems thinking

Unsurprisingly, a silo mentality is the biggest single impediment to achieving true Enterprise agility. Everyone involved in the creation and delivery of business solutions needs to collaborate across the breadth and depth of the organizational structure. Team-level agility in the delivery space alone will not deliver on the promise of the Lean enterprise; nor is DevOps enough. Business, IT and operations all need to break out of their silos and embrace systems thinking.

In both my practice and my teaching, I constantly strive to come up with metaphors that can convey the underlying meaning of concepts in ways that overcome resistance by reframing the issue at hand in a very different manner than what people may be used to. I would now like to share a metaphor that I have recently been using which has shown a lot of promise in terms of getting everyone thinking in terms of the whole system when it comes to the concept of the lean enterprise.

As discussed above, the system in question can be simplified as having three planes:


This however is merely … a triangle, and does nothing to convey the importance of intense collaboration. We need something more evocative.

Something with three parts, yet an indivisible whole. There is actually quite simple that we can use to convey this:



That’s right. True Enterprise agility is neither a sprint, nor a marathon … it’s a Triathlon.

What makes this metaphor work is simply this:

Although a triathlon is made up of three events, it is performed by a single athlete who must excel at all three to win. In this case, the “athlete” is not an individual nor a team, but the whole enterprise.

So, if our organization is reaching a point where it is proficient in delivery, there isn’t much more to be gained by continuing to concentrate all of our improvement efforts in IT alone – the Business side of things must be brought into the game as a full partner. The same goes for operations – even careful, collaborative prioritization backed up by competent delivery will not win the day if ready solutions must then linger for months in pre-production environments. Nothing ground-breaking here, just a fresh way of looking at the issue … no serious triathlete would sign up for the Ironman in Hawaii knowing that she faced daunting challenges in terms of her swimming, or was a less than competitive cyclist. The same must go for our “lean” enterprises. Until we can let go of the silo mentality and learn to act as a single “athlete”, we will continue to be bound by the shallows4 of Water-Scrum-Fail.



  3. Available at
  4. Shakespeare of course. Julius Caesar, Act 4, Scene 3.



For the want of a whiteboard….

For the want of a whiteboard the vision was lost,

For the want of a new vision the release was lost,

For the want of a new release the product was lost,

For the want of a new product the customer was lost,

For the want of a new customer the company was lost,

And all for the want of a whiteboard.

With a nod to Benjamin Franklin.

Do Agile Teams Pay Down Technical Debt in Practice?

Technical debt is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”. Technical debt can be compared to monetary debt in that if it is  not repaid, it can accumulate ‘interest’, making it harder to implement changes later on.  Important questions to ask are “How common is it for agile teams to run into technical debt in practice?” and “When they do run into technical debt, are they paying it down?”

The following diagram summarizes responses to our question from our 2016 Agility at Scale study around technical complexity.  As you can see 84% of agile teams are working with legacy functionality and 51% with legacy data sources (so yes, the vast majority of teams are working in environments that are likely to have some form of technical debt).  More importantly, 38% of teams are actively paying down functional technical debt and 32% are paying down data technical debt (48% are paying down one or the other).

Technical Debt in Practice


Related Posts



Can You Outsource and Still Be Agile?

We often hear that agile software development is fine for small co-located teams, but that you couldn’t possibly take an outsourcing approach with agile.  The customer organizations would love to do agile but are convinced that vendors are unable to do so, and the vendor organizations typically say they’d love to be agile but that the customers don’t ask them to work that way.  It’s a fair question to ask if agile and outsourcing are being combined in practice, so we decided to look into this issue.

The following diagram summarizes the responses to our question from our 2016 Agility at Scale study around whether agile teams were organizationally distributed (one of the tactical scaling factors potentially faced by agile teams).  As you can see, over half of agile teams are organizationally distributed in some way, with 58% of agile teams including contractors, consultants, or outsourcers in some way.  Interestingly, about one agile team in six includes outsourcing.

Agile and outsourcers, contractors, and consultants

Answering the question of how to be successful at agile and outsourcing is worthy of a detailed article in its own right, something we’ll do in the near future.  Until then, here are some initial thoughts based on our observations at multiple organizations around the world:

  1. It starts with procurement.  If you want a service provider to provide a team that is capable of working in an agile manner then that is what you need to procure.  A traditional procurement process that is looking for a team to work from a detailed requirements specification up front, that is expected to focus on development and then hand off their work for another team to perform “final testing”, is pretty much hobbled from the very beginning.  It is very possible, and highly desirable, to have a procurement process that is capable of procuring agile software development services.  In fact, there is a wealth of knowledge out there about agile contracting if you choose to look into it.
  2. The customer must work in an agile manner.  There are several key strategies to support this:
    • Negotiate how you will work together up front.
    • Take a light-weight, evolutionary approach to requirements.
    • Provide a technical roadmap.
    • Fly a few key people to the service provider.
    • Consider co-locating your Product Owner with the service provider.
    • Provide your development guidelines to the service provider.
    • Actively govern the team.
    • Respect the service provider.
  3. The service provider must work in a disciplined agile manner.  There are several key strategies to support this:
    • Be trustworthy.
    • Be truly transparent.
    • Have one-week iterations/sprints.
    • Include code analysis tools in your builds.
    • Provide the customer access to your team’s automated dashboard.
    • Align your culture to that of the customer.

We will write a more detailed article that expands on these points in the near future.  Stay tuned!

Related Posts

Vertical Slicing for a Data Warehouse (DW)/Business Intelligence (BI) Solution

There are several strategies that you can choose to employ with vertically slicing the requirements for a DW/BI solution. These strategies are described in the following table. There are example stories for each strategy as well as some advice for when to apply each strategy.

Table 1. Vertical slicing strategies for a DW/BI solution.

Slicing Strategy Example Stories When to Do This
One new data element from a single data source
  • As a Professor I would like to know the names of my students so that I know who should be there
  • As a Student I would like to know what courses are taught at the university
Very early days when you are still building out fundamental infrastructure components. Very common for the first iteration or two of Construction. These slices still add real business value, albeit minimal.
One new data element from several sources
  • As a Professor I would like the student list for a seminar that I teach
  • As a Student I would like to know what seminars are being taught this semester
Early days during Construction when you are still building out the infrastructure. These slices add some business value, often fleshing a DW data element to include the full range of data values for it.
A change to an existing report
  • As a Professor I would like to know the standard deviation of marks within a seminar that I teach
  • As a Student I would like to know how many spots are still available in a seminar
Evolution of existing functionality to support new decision making
A new report
  • As a Professor I would like to know the distribution curve of student marks in a seminar that I teach so I may adjust accordingly
  • As a Registrar I would like to know what Seminars are close to being full
Several iterations into Construction when the DW/BI solution has been built up sufficiently.
A new reporting view
  • As a Registrar I would like to know what the prerequisites are for a seminar so that I can advise students
  • As a Professor I would like to know the current course load of each student within a seminar that I teach
Several iterations into Construction when the DW/BI solution has been built up sufficiently.
A new DW/DM table
  • As a Chancellor I would like to track the revenues generated from parking pay meters to identify potential profits to divert to supporting students
  • As a Professor I would like to recommend suggested readings to help people prepare before taking a seminar
Several iterations into Construction when the DW/BI solution has been built up sufficiently.

There are several interesting things about the stories in the table:

  1. They are written from the point of view of your stakeholders. They aren’t a technical specification. For example, the first story describes how professors want a list of student names but it isn’t saying from what data source(s), what the element names are, … These are design issues, not requirement issues.
  2. They always provide business value. The first story appears to be the beginnings of an attendee list for a seminar. Having something as simple as a list of names does in fact provide a bit of value to professors.
  3. Sometimes that business value isn’t (yet) sufficient. It may take several iterations to implement something that your stakeholders want delivered into production, particularly at first. For example, although a list of student names is the beginnings of a class list it might not be enough functionality to justify putting it into production. Perhaps professors also need to know the program that the student is enrolled in, their current year of study, and basic information about the seminar such as the course name, time, and location of it. The decision as to whether the functionality is sufficient to ship is in the hands of your stakeholder (this is one of the reasons why you want to demo your work on a regular basis).

I’ve written a detailed explanation of vertical slicing for a DW/BI solution, and of course there is a wealth of information about agile database techniques in general for those of you interested in greater detail.  You may also find our one-day Disciplined Agile Data Warehousing/Business Intelligence Workshop to be a valuable learning experience too.

How Geographically Distributed Are Agile Teams in Practice?

Many people, particularly those new to agile, will tell you that agile teams must be small and co-located.  That is certainly a smart way of organizing a team, but is isn’t required.  In fact agile teams are more likely to be geographically distributed in some way than they are to be co-located.  In practice, not theory.

In November of 2016 we ran the 2016 Agility at Scale survey.  It was targeted at people who were currently working on agile teams, or who had recently worked on agile teams, and we asked them straightforward questions around the size of the team, how distributed it was, what complexities they faced, an so on.  The following graph summarizes the responses around geographic distribution.

Geographic distribution and agile teams

The survey found that less than one-third of agile teams are near-located, where all of the IT members are either co-located or at least in a shared open space.  Previous studies have found that this number drops to one-in-ten teams being near located when you also include primary stakeholders.

Don’t let anyone tell you that you can’t do agile with a geographically distributed team because others are clearly doing so in practice.  Yes, geographically distributed agile is different than near-located agile, which is one of the reasons why you need to take a pragmatic, context-sensitive approach to agile solution delivery.  The Disciplined Agile framework provides the foundation from which to scale your approach to solution delivery to address a range of scaling factors, including geographic distribution.  In fact, you may find our article around geographically distributed agile teams to be an interesting read.

Related Posts:

How to Choose an Agile Release Cadence


One of the things that a delivery team needs to do, often in collaboration with product management, is choose the release cadence of their product. This is an important aspect of, you guessed it, release planning.  Your release cadence defines how often you release your solution both internally and externally into production (or the marketplace). The issue is how to determine how often the product should be released into production. In this blog we explore:

  1. Where are you deploying to?
  2. What affects release cadence?
  3. What release cadence choices do you have?
  4. What do we recommend?


Where Are You Deploying?

There are several target environments that you might choose to deploy to. These environments include:

  1. Demo environment(s). Many teams maintain a demo environment for their solution so that their stakeholders can see what has been developed to date at their leisure. Demo environments support transparency with your stakeholders, reduce the number of “one-off” requests by stakeholders for demos (because they can simply see the solution for themselves), and of course they provide a stable environment in which your teams can run demos.
  2. Testing environment(s). Many teams have their own testing environments, or they work with independent test teams with their own testing environments, or both. You should strive to test as often and early as possible, an implication being that want to deploy into your test environment(s) as often as you possibly can.
  3. Production/marketplace. Some teams will release their solutions into their production environments (or to someone else’s cloud) where end users will use the systems. In the case of commercial software companies they will release their solutions into the marketplace where they are then sold to customers. Throughout this blog whenever we use the term production we also mean the marketplace.

For the sake of terminology, deploying into demo or testing environments are often referred to as internal releases and into production as an external release.


What Affects Release Cadence?

There are several factors that affect the choice of release cadence:

  1. Stakeholder needs. How often do your stakeholders, and in particular your end users, want your solution to be released? This can be a difficult issue because very often your stakeholders might not be able to perceive what is appropriate for them. We’ve seen stakeholders ask for quarterly releases, be delighted when then get monthly releases, and then start asking for weekly releases once they realize the potential of modern agile strategies.
  2. Stakeholder capability to accept change. We like to think that more often is better, and in the vast majority of situations it is. As difficult to believe as this may seem, at the far extreme we’ve also seen some systems where the natural release cadence is once every three or four years because that’s the rate at which stakeholders are able to accept change. In this case the product was a transaction processing (TP) system infrastructure product, but we’ve heard similar stories about major database management systems (DBMSs) products too. Granted, a release cadence this long is very rare but it does happen in a small number of situations. Far more common is the mistaken belief by IT professionals that their stakeholders are unwilling or unable to accept shorter release cycles. We’ve seen numerous organizations where the IT people tell us that their stakeholders can’t handle anything more regular than a quarterly or bi-annual release, yet these same stakeholders regularly use commercial software that is updated several times a week.
  3. Your organizational culture. Some organizations, particularly those with an existing traditional release management team, often have release cultures that lean towards larger and less frequent releases. These organizations often have significant investments in legacy systems and insufficient investments in automated regression tests/checks. As a result releasing solutions into production tend to be seen as a risky endeavour. At the other extreme we’ve seen companies with more of a continuous delivery mindset that have a “release as swiftly and often as you can” culture. These organizations have typically invested heavily in code quality, automated regression testing, and automated deployment thus making deployment a simple and virtually risk-free effort.
  4. The team’s ability to deliver. Of course a primary determinant of your release cadence will be how often you’re able to actually produce a potentially consumable solution. This is affected by the skills of your team members, your ability to collaborate, your ability to vertically slice functionality into small features, and your delivery infrastructure.
  5. Your delivery infrastructure. How easy it is to release a potentially consumable solution into production is determined in part by your technical environment. This includes the extent of your automated regression tests, your automated deployment scripts, and your capability to monitor production. In general, the greater the level of automation the more often you can release.
  6. Your solution architecture. Is your solution architected to be released incrementally? Is it possible to enable/disable functionality at a granular level (perhaps via feature toggles or a similar technique)?
  7. The cost/risk to release.   Cost and risk tend to go hand-in-hand when it comes to releasing solutions into production. This is because the more manual your release/deployment processes the more expensive they become and the more likely there are to be problems somewhere in the process. Conversely, the more you automate the overall deployment effort the cheaper it is to deploy and the less risky it becomes as you’re more likely to run into, and then automate a solution to, deployment problems. The less expensive and less risky it is to release your solution the more viable it becomes to release more often.
  8. Release cadence of other teams. Like it or not your team is likely dependent on the work of other teams. For example you may need web services being built by another team, and you can’t fully release your solution until those web services are available in production.  We’ve written detailed articles about how to manage dependencies between agile/lean and traditional teamsdependencies between agile teams, and dependencies between agile and lean teams.


Release Cadence Choices

Table 1 lists many common release cadences, from more than annual to several times a day. It also lists the potential tradeoffs of each approach and indicates when you may want to adopt each one.

Table 1. Comparing external release cadence options.

Strategy Potential Advantages Potential Disadvantages When to Apply
Many times a day Enables very short time to market

Enables teams to adapt quickly to changing stakeholder needs

Enables granular release of functionality

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Your solution architecture must support toggling of features to enable deployment of larger functions as a collection of smaller features

Effective for high-use systems, particularly those used by external customers in highly-competitive environments
Daily Same as above

Provides a regular (daily) release cadence that is predictable

Same as above Same as above
Weekly Provides a regular (weekly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Same as above Effective for high-use solutions, particularly e-commerce or BI/reporting systems

Appropriate for teams following the Lean lifecycle

Monthly Provides a regular (monthly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Requires extensive continuous integration (CI) and continuous deployment (CD) automation

Requires high discipline to maintain quality

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one-week iterations or the Lean lifecycle

Quarterly Provides a regular (quarterly) release cadence that is predictable

Enables quick time to market and responsiveness to changing needs

Enables simpler requirements management practices (compared with longer release cadences) due to lower impact of a feature moving to the next release

This is a major milestone for teams moving towards an “advanced” lean-agile strategy as it motivates greater discipline.

Requires continuous integration (CI)

Requires automated deployment strategies

Effective for medium-priority solutions

Appropriate for teams following the Agile/Basic lifecycle with one or two week iterations

Variable Works well with a project mindset (although that’s questionable in and of itself) Teams need to be able to judge when their work reaches the minimally marketable release (MMR) stage and the business value added exceeds cost of transition. This decision point is captured in the DAD project lifecycles by the “sufficient functionality” milestone

Politics can hamper this decision point. You should put an upper limit on the acceptable time between release

Project teams

Stable teams assigned large “projects”

Bi-annual Good starting point for teams new to agile who are currently working on traditional projects with longer release cadences because it motivates adoption of disciplined strategies Can be difficult for stakeholders who are used to less frequent releases The team may need significant agile coaching as they will run into many of the “but we’re different and that agile stuff can’t possibly work here” type of problems
Annual Provides a regular (annual) release cadence that is predictable


Very risky, the team is likely to miss their date

Requires internal releases to obtain feedback

The deployment has likely become high risk because you do it so infrequently (self fulfilling problem)

Appropriate for low priority systems or for high-risk deployments (note that the deployments may have become high-risk because you do them so infrequently)
More than annual See annual


See annual

This is common for infrastructure systems, such as a database or transaction managers, that have many other systems highly dependent upon them


Our Recommendations

When it comes to releasing your solution, we have several recommendations for you to consider:

  1. Automate, automate, automate. The more you have automated, the lower the cost of deployment and the lower the risk. This enables you to release more often with confidence.
  2. Release internally very often. This is your opportunity to get good at releasing your solution, at squeezing out the cost and the risk.
  3. Release externally as often as possible. The faster and more often you can release into production the more competitive your organization will be.
  4. Always look for ways to release more often. Impressed with your ability to release once a month? Aim for bi-weekly. You’ve now releasing bi-weekly? What’s stopping you from releasing weekly? Weekly releases? Meh! Release daily! Your team is releasing daily grandpa? How about automatically releasing many times a day every time you have a working build?


Further Reading

Lean Thinking Provides a Philosophical Foundation for Scaling Agile

Little ideas add up

Lean thinking is important for scaling agile in several ways:

  1. Lean provides an explanation for why many of the agile practices work.  For example, Agile Modeling’s practices of light weight, initial requirements envisioning followed by iteration modeling and just-in-time (JIT) model storming work because they defer commitment to the last most responsible moment.  These practices also help to eliminate waste because you’re only modeling what needs to be built at the point in time that it needs to be built.
  2. Lean offers insight into strategies for improving your software process.  Lean principles such as optimizing the whole and delivering quickly motivate you to look beyond your existing specialized processes to explore how everything fits together and to streamline it.  Identifying and understanding the sources of waste in your IT processes can motivate you to improve the way that you work and thereby eliminate the waste.  The lean principle of building quality in
  3. Lean thinking provides a philosophical foundation for scaling agile approaches.  No methodology, process, procedure, or framework is ever complete.  Nor can they be because you can always capture more detail for a wider range of situations.  Because of this incompleteness you need a collection of higher-level principles or philosophies to guide people when their process/procedure/… proves to be incomplete for the situation that they face.  Lean thinking has proven to be a very good source of such philosophies, as do other sources (Steven Covey’s principles come to mind, as does the work of Peter Senge).
  4. Lean provides techniques for identifying waste.  Value stream mapping, a technique common within the lean community whereby you model a process and then identify how much time is spent on value-added work versus wait time, helps calculate overall time efficiency of what you’re doing.  Value stream maps are a straightforward way to illuminate your IT processes, providing insight into where significant problems exist.  I’ve created value stream maps with several customers around the world where we analyzed their existing processes which some of their more traditional staff believed worked well only to discover they had efficiency ratings of 20-30%.  You can’t fix problems that you are blind to.

The Lean Governance Mindset


The mindset required to govern IT in a lean or agile manner is very different than the traditional mindset. In this blog we review the key aspects of a lean governance mindset. These aspects are:

  1. Lead by example. People take their cues from their leadership teams. If your governance strategy is streamlined and light weight then whatever it governs will inevitably become streamlined and light weight. Conversely, an onerous and heavy governance strategy will lead to onerous and heavy strategies by those being governed.
  2. Be a servant leader. The primary function of governance people should be to prevent roadblocks, and if not to get rid of them as soon as they arise. You should strive to get teams the resources that they need and then get out of the way. Wait a minute, isn’t that the job of the Team Lead in Disciplined Agile (DA)? Yes, but who do you think that they work with to actually get that done?
  3. Motivation over management. IT professionals are intellectual workers, and intellectual workers generally don’t respond well to being told what to do. But they can be motivated, and once motivated will actively work on what they’ve been motivated to do. So motivate them to do the “right thing”. One way to do this is to communicate very clearly what your organization is trying to achieve. Another way to motivate people is to ask tough questions such as: What value is there in doing that? What can we do to increase value? How can we eliminate waste in what we’re doing? and What will we learn by doing that?
  4. Enablement over audit. Psychology shows that people, when given the choice, will usually take the easy path. This tells us that if we want people to do something, or to work in a given manner, then if we make it very easy to do so then they likely will. For example, if you want developers to follow common coding conventions then provide easy to understand and straightforward guidelines. Better yet, provide code analysis tools that they can include in the continuous integration (CI) tooling that provides feedback that they can act on. The traditional approach would be to rely on code inspections or code audits to ensure that conventions were being followed. This approach is not only onerous, and thus less likely to be followed, it has a long feedback cycle which means that any feedback resulting from the audit will be much more expensive to act on (on average) than the code analysis tool which has a very short feedback cycle. Yes, you may need to run the occasional audit, particularly when you’re working in a regulatory environment, but you should do so only as a last resort.
  5. Communicate clearly, honestly, and in a timely manner. Effective governors communicate what the priorities of your organization are and what is expected of people. It is crucial to set realistic expectations in an open, honest, consistent, and continuous manner.
  6. Streamline collaboration. Governors should help teams collaborate effectively with others. This not only helps them to achieve their goals but also supports enterprise awareness.
  7. Trust but verify. Agile is based on trust, but to ensure that the right thing is happening within your organization there needs to be verification of that. Governors can do this by monitoring teams via several strategies. These strategies include asking people what’s going on, automated metrics (via team dashboards), looking at information captured by information radiators, attending team demos, and as a last resort asking teams to produce status reports to address questions that can’t be answered via automated metrics.
  8. Focus on mitigating risk, not just reviewing documents. A primary goal of your governance strategy should be to mitigate risk. Sadly, many governance strategies have fallen into the bureaucratic trap of relying on documentation reviews to provide insight into what a team is doing. For example, your “architecture quality gate” might be based on the review and acceptance of an architecture model or document, the idea being that if some knowledgeable people assess the content of the document they will be able to determine whether the described architecture strategy will work. Unfortunately this isn’t the case. We’re sure you’ve seen several IT project teams who had a well-documented architecture, which was reviewed and signed off on, yet the technologies didn’t work well in practice, or perhaps they didn’t perform well, or perhaps they didn’t even integrate easily. The only thing that the review and acceptance of a document tells you is that a document was created, reviewed, and accepted.
  9. Learn continuously. Good governors learn as much as they can about what they’re governing so that they can make better decisions and can make effective suggestions to the people being governed.
  10. Consider both the long and short term. Governance must balance short-term needs with the long-term strategy of growing and enhancing your organization.
  11. Be a great host. People who have fun at work, who enjoy what they do, are much more productive than people who don’t. In this respect being an effective governor is like being a good host at a party – as host it’s your job to see that everyone has a good time and gets along well with each other, and to swiftly deal with any problems that arise.

Having a lean governance mindset, as described above, helps you to increase your effectiveness at governance. In the next blog we will describe what IT governance encompasses.