Archives For Enterprise Agility

Dzone just wrote a great article on why to considering using the Scaled Agile Framework (SAFe). The five considerations are:

  1. Scaling agile from teams to programs
  2. Handling obstacles, delays, and failures from team dependencies
  3. Providing clarity on management roles in a scaled environment
  4. Aligning a consistent strategy from the division & portfolio levels
  5. Reducing lead times across the enterprise

Check out Josh Fruit’s blog at:

At the end of the day SAFe attracts attention because it continues to provide the mission benefit that clients in both government, business, and non-profit organizations are seeking.


Let’s face it, technology systems are getting bigger and bigger.  Big data systems have moved beyond the lab and entrenched themselves in today’s market place as viable value drivers.  These systems and their supporting ecosystems are extremely complex.  They are more like aircraft carriers than small gun boats!  To build large, complex systems we (the software industry) need to refactor our product development practices.

We often see the following pattern when large (50+ people) programs kick off.  Their energy and enthusiasm to use cutting edge technologies drives them towards more modern development practices.  That is Agile practices.  Unfortunately, they usually try to apply low complexity Agile frameworks and practices to their high complexity environment.

What does that mean?  Our experience is they try to apply Scrum and a select few XP engineering practices to manage and deliver their system.  Inevitably, this breaks down for a variety of reasons and they revert back to BUFD, Waterfall methods.  #FAIL

Their approach to organizing and managing delivery at scale was flawed from the start.  We need tools and practices that map to high complexity environments in order to realize value at scale.  While Scrum is part of the solution, it is not the whole solution.  Its our opinion that the Scaled Agile Framework (SAFe) is currently the best and most mature tip revision of our industry’s current thinking to deliver at scale.

Here are some SAFe practices we must rebaseline when scaling agility:

  1. Product Owners don’t have complete autonomy anymore.  They must work from the program backlog that is managed by Product Management.  This is necessary to bring value alignment across the whole system.
  2. System designers don’t have complete autonomy either.  They must work within the constraints of the enterprise architecture.  Otherwise significant refactors will cause poor economics.
    • Note – Agile Architecture is significantly different than traditional ivory tower, BUFD architecture.
  3. Continuous Integration must occur at the system level.  Since these systems realize value at the system level, system level CI practices are necessary.
  4. Local team demo does not equal system demo.  Demos must scale to the system level on the same cadence as the teams so that our system stakeholders can provide valuable system level feedback necessary for maximum agility.
  5. Quality can’t be built in later.  Software quality breaks down exponentially as systems scale.  Just one system component with substandard quality can bring the whole system to its knees.  To maximize the economics(agility) of system development, we can’t wait for a refactoring sprint.  Quality must be built in as we develop across every team!


In the previous post in the Twilight Zone series we outlined some pretty serious issues in product development when Batch Sizes increase.  Since we aren’t bomb thrower consultants we hope to provide some practical advice to help reduce batch size.  Of course many of these ideas come from Don Reinertsen’s book, Principles of Product Development Flow, which YOU should read!

We also will showcase the connection between reducing batch size and business areas beyond development.  Our aim is to highlight the need for Lean|Agile thinking to bring agility to the whole organization.

Reduce Batch Size

  • Large batch sizes have a lot of bad stuff associated with them.  Some of them include: project slippage due to higher utilization; long feedback loops; high rates of shelfware; and redundant defects.
  • So what combats this?
    • Collocation – Batch sizes are proportional to physical proximity.  Close proximity communication among teams encourages smaller batches of information sharing.  You may need to engage Facilities Support to make this happen.
    • Infrastructure – Faster compile, build, integration, and test cycles encourage work in smaller batches.  Think about it, if it takes 30 minutes for a developer to get feedback on his/her most recent committed change, they are likely to batch more changes per commit.  We will probably need to engage Ops for infrastructure support and possibly Architecture to help create more modularized designs.
    • Limit Work in Process(WIP) – WIP is shelfware and any work not delivered to production.  In manufacturing this is equivalent to inventory that clutters the factory floor.  In software, this is equivalent to designs, code, …etc that clutters our minds.  To get rid of this we need Management to understand the cause and effect of limiting WIP.  We also need upstream buyin, because when we Limit WIP downstream, you will cause traffic jams upstream, which will cause Executives, Requirements, Architects, …etc heartburn.
    • Continuous Flow of Value Discovery – Many defects in product development can be attributed to poor value discovery.  Large batches create significant time delays between value discovery and actual development.  The accuracy of the assumptions or information captured during the discovery of value tends to decay over time.  So this time delay introduces bad information into the development process, which leads to defects.  Worse yet, an assumption or piece of information may be redundant across many design decisions which causes a widespread defect.  Therefore, the upstream participants involved with discovering value, typically the Customer, Requirements, Executives, Marketing, Sales, and Product Management, must do this on an ongoing basis to provide as much value information to the development teams.
      • This requires a standardized set of business practices to take in, analyze, prioritize, decompose, sequence and validate work.

So far we’ve identified several business areas beyond Development that influences batch size and ultimately the business agility of the whole organization.  They include:

  • Facilities, Ops, Architecture, Management, Executives
  • Requirements, Customers, Marketing, Sales, Product Management

While Batch Size is just one of many principles that influences enterprise agility, we hope the Twilight Blog series has showcased how an entire organization influences enterprise agility.  So next time someone suggests that “Agile” only concerns Development…point them to this blog series.



In the previous post in the Twilight Zone series we highlighted the misconception that Agile is for software development only.  In this post and subsequent posts we will highlight how Batch Sizes are effected by many areas across an organization beyond development.  Put your chin strap on…this may get a little heavy!

Don Reinertsen’s book, Principles of Product Development Flow(YOU should read it!) lists Reducing Batch Size as one of the eight principles of product development flow.  Before we jump to how you can reduce batch size, lets take a look at the cause and effect of large batch sizes.  By the way…much of this content can be found in Reinertsen’s book.  Did I mention YOU should read it?

The Cause

Today most project management is focused on wringing out efficiencies by institutionalizing large batch sizes.  This leads organizations to functionally align into big batch silos – Requirements, Architecture, Development, Test, and Operations.  The thought is that we can gain efficiencies through economies of scale and uninterrupted work.  And guess what…its true!  There are local efficiencies gained by pushing large batches of work through functional silos.  But how does this effect the agility of the whole organization?

The Effect…let the games begin!

  1. Increased cycle time(i.e. slower delivery speed.)
    • Its gonna take longer to build more stuff – duh!
  2. Increase variability of flow
    • What’s that mean?  It means there will actually be more frequent and larger interruptions in work.
    • Think about it, every time a big batch of work enters a silo a flurry of activity must happen to service it.  When a big batch leaves a silo, activity subsides.  Hot, cold, hot, cold, …etc.
  3. Slower feedback
  4. More risk
    • The longer it takes, the more could change(requirements, customer, technology, …etc)
    • Big planes are harder to land than small planes  (btw…in the English language we call that an analogy 😉
    • Slower feedback increases the consequence of errors.  i.e. the later we learn about a problem, the more it costs to fix it.
  5. More overhead
    • More uncertainty in process means more status meetings so we can get updates on our uncertainty.  Making sense yet folks?
  6. Reduces efficiency
    • Wait I thought it gained efficiency?  Well…yes…locally!  However its at the expense of destroying important feedback loops that cause defects to grow exponentially as batches are pushed through each functional silo.
      • I know this never happens…but what if a redundant defect is found by Test or Ops?  Perhaps an assumption was wrong, the customer changed their mind, …etc.
    • Think of how this effects the efficiency of the whole organization!
  7. Lowers motivation and urgency
    • Are you more likely to feel an urgency to deliver on day one of a two week sprint or on day one of a 100 day milestone?  Me thinks two weeks. 🙂
    • Which scenario would you feel more motivated by responsibility?
      • If you are responsible for shepherding a capability from concept to consumption…oh lets say…something like a USER STORY.
      • You were just capturing the requirements for a capability, but you knew several other groups would share in the responsibility to deliver it. (Arch, Dev, Test, Ops, …etc)
  8. Increased project slippage
    • More uncertainty in process…means more uncertainty 😉
  9. Leads to Larger Batches
    • Often called Death Spiraldevelopment.  Here’s what the customer is thinking
      • “If I’m not getting a capability for 6 months or a year I’m giving you everything I got!  Prioritization…what’s that?  Everything’s a P1!”
  10. The entire batch is limited by its weakest link
    • If 1 out of the 30 requirements in the batch has a security relevant change then we will treat the whole batch as a security relevant change.
    • For those of us who have dealt with security relevant changes, we know this can be a huge pain and often leads to large delays.

Whoo!  That was a mouth full.  In the next post we’ll describe some practical steps you can take to reduce batch size so that you don’t have to deal with the stuff above.  And I promise we will outline specific areas of your organization that will be involved to Reduce Batch Size!



One of the preconceived notions that we run into while consulting is that Agile is only for software development teams.  As if Agile is some Twilight Zone that only applies to developers.  If we lived in the Twilight Zone, that might be true.  But we live in the real world, and we have to deliver value to our customers.  Agile practices and methods usually start cropping up on software development teams first, but quickly expose the lack of agility in other areas of the organization.  If you want to deliver software at scale with agility, you must consider how you do business outside of development!  

This is what Lean|Agile is all about.  Lean|Agile goes beyond development and addresses the organizational impediments that stand in the way of agility.  Our Lean|Agile service teaches and trains the essential practices needed to discover and deliver increments of value in a sustainable, predictable way. This means we must consider all stakeholders involved with the creation of value – Customers, Requirements, Architecture, Management, Development, Operations, …etc.

We’ve found that this common misunderstanding, has required us to do a lot more upfront training.  Essentially we need to baseline the thinking of our clients so that we are able to help our clients achieve agility at scale.  In the next week’s post we will begin to describe how one specific principle of Lean|Agile development, Reducing Batch Size, effects organizations outside development.  Stay tuned!