Archives For Scaled Agile

Five Reasons to Consider the Scaled Agile Framework

July 17, 2013 — Leave a comment

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:

http://www.davisbase.com/5-reasons-to-consider-the-scaled-agile-framework/

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.

In Enterprise Agility, Scaled Agile
permalink

Second Generation Agile

April 11, 2013 — Leave a comment

family

Over the past few years we’ve heard some of the thought leaders in the Agile community start referring to “second generation” Agile methods.  Most notably among these thought leaders are Dean Leffingwell and Al Shalloway.  While there are many others, these two leaders have writing, teaching, and implementing these second generation methods.  Its no surprise that they are principle contributors to the Scaled Agile Framework.

Second generation Agile methods really refers to Lean|Agile methods.  Agile had tremendous success as delivering high value(PO – thx Scrum), high quality(thx XP) software rapidly.  However the typical context was across a small group of teams(< 50).  The industry is now scaling these efficiency gains to the enterprise.  We are now building systems with hundreds and in some cases thousands of people.  Our context has changed and our methods are changing to meet the demand.  This is where the phrase Lean|Agile is rooted.

Lean|Agile methods are rooted in Lean.  What does that mean?  Well that’s a long story.  We recommend reading two books to get an understanding of Lean.  First The Toyota Way(history/origins of Lean) and second Principles of Product Development Flow(Lean principles for product developers) by Don Reinertsen.  The latter is an extremely tough read because it is just a set of principles and you have to bridge the gap to application.  However really provides the foundational principles of Lean applied to product development that big enterprises desperately need to make sense of why Lean|Agile practices work.  It also helps us reason about solutions to really hard problems we encounter day to day.  I guess you could say its “True North.”

The Scaled Agile Framework(SAFe) is built on Lean and applies many of the principles from Reinertsen’s book.  For instance, SAFe is driven by Reinertsen’s economic principles.  It largely does this by applying Weighted Shortest Job First(WSJF).  Why is this important?  As enterprise frameworks and methods plow into larger and larger enterprises, the complexity scales exponentially.  Lean scales as well.  It’s the language of business.  Best of all for agilists, agile practices are aligned with Lean principles.  For instance backlog wish lists allow for shallow queues and cross functional teams allow for small batch sizes.

So simply enough, as we bring agility to enterprises we need to change our toolset.  Second generation Agile methods…aka Lean|Agile methods provide the toolset that allows agility to scale.  We recommend checking our the Scaled Agile Framework(SAFe) to learn more about these methods because it is not only rooted in Lean principles, it applies them as well using Lean and Agile practices.  Enjoy!

In Agile, Lean Agile, Scaled Agile
permalink

Rebaselining for Agile at Scale

April 4, 2013 — Leave a comment

small-gun-ship

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 Enterprise Agility, Lean Agile, Scaled Agile
permalink

Merry Christmas

December 24, 2012 — Leave a comment

Slide1

Santa’s workshop is almost finished!

Merry Christmas from LeanOrange!

In Agile, Kanban, Lean, Lean Agile, Scaled Agile, Scrum
permalink

Welcome to…the AGILE ZONE!

December 7, 2012 — Leave a comment

TWILIGHT ZONE

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!

In Agile, Enterprise Agility, House of Lean, Kanban, Lean, Lean Agile, Scaled Agile
permalink