One does not have to go far to find companies struggling with realizing the anticipated benefits of agile delivery.  Go to a conference, meetup or even a networking event (whether the theme is agile or not) and you’re likely to hear statements like:

“We’re trying to do agile, but we’re not getting anywhere…”  or “We’ve been using Scrum for six months now and it seems that we’re still struggling with the same problems.  We can’t get anything done…”

From a systems view, these statements are not surprising at all.  In fact they are expected, depending on the organization and their approach to the principles and practices.  In simple terms they are expecting Agile (big A) results with an agile (little a) investment.  Let me explain the difference between the two.

• Agile is a proper noun. A mindset, philosophy and approach.  You don’t do Agile, you become Agile over time by changing the way you approach work, people, problems etc.  It has more to do with who you are than what you do.  It is a journey, not a destination.  This is what delivers the much touted benefits
• agile is an adjective.  It describes nouns (events, ceremonies, roles, etc) associated with things that result from an Agile mindset.   These things are done in support of becoming Agile.

The point is that a lot of companies believe that they can ‘do’ Scrum, or some other process and that will make them more collaborative, produce more value and achieve higher quality; just some of the benefits of an Agile mindset.  While adopting these practices can certainly help start the journey, it takes more than just training, understanding and following a set of practices to become Agile.   Agile is not something that is applied to a team, division or organization.   If you do agile things but don’t support them with an Agile mindset friction, frustration, confusion, waste etc. result.  (See “We’re trying to do agile, but we’re not getting anywhere…”)

It takes real change for most companies to become Agile.  Often times they don’t have an Agile mindset.  Their management, HR structure, physical work spaces, titles and sometimes even identity are rooted in the current mindset.  (Think about your organization and how important your title or HR code is to what you earn and do.)    Thus the ability to develop one is rooted in changing their culture.  This is more involved than just introducing an agile process like Scrum.

To address the question “Why we are struggling with agile?”  is usually best answered with the a conversation around “How do we become more Agile?”

 

It happens frequently, but it never gets old.  Recently as part of a post training coaching session one of the senior leaders of a client organization said after a day of working with the team, “We’ve gotten more done in the last six hours than we did in the last two months….”  She was working on the same project, with the same people in the same company.  The only difference was that we helped them define, establish and follow a common process for doing the work.

This is a common experience our coaches have with our clients.  W. Edwards Deming put it this way “If you can’t describe what you are doing as a process, you don’t know what you’re doing.”

We regularly come across teams and organizations that believe they have a process and that everyone understands the process.  Yet when we start asking some questions it quickly becomes apparent

• They don’t really have a process
• They have a series of activities that people do, but the order is not clearly called our and the roles and responsibilities are not defined and/or followed
• Or worst of all, they have a process with roles and responsibilities, but only a few people know what it is (and it’s rarely the people doing the work). I’m looking at you PMO’s of the world…

That’s why Scrum and Agile are so powerful and have become best practices for organizing teams.  Scrum is a process that is easy to understand, has only a few roles to be filled (Scrum Master, Product Owner, Team Member) and helps people organize around what is most important, THE WORK!  That’s why it’s so important your team’s process matches your organization and why investing in a couple of days of continued education (training) is as close to a sure thing as you can get in this ever changing market.

How about your team?  Can everyone on your team describe what your process is?  Is it a consistent definition?

As Agile at scale continues to gain momentum, the need for a better understanding of Lean is becoming more important.  The reason for this is due to what each body of knowledge is primarily focused on.

As part of any of our education efforts dealing with Agile at scale (or even across a couple of teams), Silicon Prairie Solutions includes the following as a means to establish a common understanding of the what and why for Lean and Agile.

It’s a pretty simple concept when considered visually against the different planning horizons and organization has.

 

Planning Horizons

These planning horizons exist regardless of the process the company is following (Agile, Lean, SAFe, Hope and Prey, etc.)  The typical planning horizons are:

• Vision (1-2 years)
  • Where the company wants to be in the future. Typically defined by Minimum Business Increments (MBI’s) or Portfolio Epics in SAFe.
• Roadmap (6 – 18 months)
  • This could would relate to the Program Level Roadmap in SAFe (http://scaledagileframework.com/roadmap/) or a similar initiative plan.  The contents of the road map are derived from the Vision and other work items the teams must do (Dev Ops, maintenance, etc.)
• Release / PI in SAFe (~3 months)
  • Getting working software into production and the end users’ hands. Ideally this is done on a frequent basis (the is frequency defined by maximizing value to the customer) but certainly should be done in as short increments as possible to increase feedback.
• Iteration (2 weeks)
  • A typical team Sprint.
• Daily
  • Daily Stand up.

 

After establishing these planning horizons we can now do two things:

• Define alignment
• Differentiate between Lean and Agile

 

Define Alignment

Alignment in this model simply means that the planning for a subsequent level (e.g. Roadmap to PI) supports the same strategy, prioritization and expectations.  You can see from the illustration that alignment should exist from the Vision to Daily.    This also means that alignment encompasses all the activity at the Portfolio\Program\Team levels.   Thus if the teams are not aware of the Roadmap (longer term planning and strategy) they are at a disadvantage because they will try to fill in the gaps of their understanding from a planning horizon based in week not months.  This is one of the reasons why the PI Planning (http://scaledagileframework.com/pi-planning/) event is SAFe is so beneficial.

 

Lean | Agile

Finally, we can establish a common understanding of Lean and Agile to help grow the organizational intelligence.   If one considers Lean and Agile to be related, and there are some overlapping principles and practices (Kaizen in Lean and Retrospectives in Agile, small batch size in Lean and right sized user story in Agile, etc.) we can associate Lean with the broader time horizons and Agile with the more immediate planning and execution.

In this case Lean is all about systems thinking, flow, maximizing value delivery and the overall process that the organization follows.  This level of planning typically falls to leadership in a traditional organizational structure.  That’s why SAFe and other frameworks can be so effective, it helps define the roles and responsibilities for traditional leadership.

At the other end of the planning spectrum lives the team and Agile principles and practices.  Here adaptability, collaboration, stable teams and executing on the work in a consistent manner are critical.

This model also shows the importance of the Program level in SAFe (http://scaledagileframework.com/program-level/) and if applicable the Value Stream Level.  One of the main functions at these levels is to tie the work between larger planning horizons to actual execution and delivery (Lean planning and Lean leadership to Agile teams).  Again, another benefit of using a framework like SAFe to organize around the work at scale.