Agile Zone is brought to you in partnership with:

Allan Kelly has held just about every job in the software world, from sys admin to development manager. Today he provides training and coaching to teams in the use of Agile and Lean techniques. He is the author of "Changing Software Development: Learning to become Agile" (2008) and "Business Patterns for Software Developers" (2012) and a frequent conference speaker. Allan is a DZone MVB and is not an employee of DZone and has posted 81 posts at DZone. You can read more from them at their website. View Full User Profile

Scaling Agile Heuristics - SAFe or Not!

08.19.2013
| 3631 views |
  • submit to reddit

If I’m being honest, I feel as if I don’t know much about scaling agile. But when I think about it, I think the issue is really: What do you mean when you say “scaling agile?”
It seems to me you might mean one of three things:

  • How do you make agile work with a big team? Not just 7 people but 27 people, or 270 people
  • How do you make agile work with multiple teams within an organisation? i.e. if you have one team working agile how do you make another 2, or 20 or another 200?
  • How do you make a large organisation work agile? - it's not enough to have a team, even a large team working agile if the governance and budgeting systems them work within are decidedly old-school
When I rephrase the question like that I think I do have some experience and something to say about each of these. Maybe I’ll elaborate.

But first an aside: why have I been thinking about this question?

Well David Anderson pushed out a blog about the Scales Agile Framework (SAFe) which prompted Schalk Cronje to ask what I thought - and at first I didn’t have anything to say! But then Schalk pointed out that Ken Schwaber has blogged about the SAFe too. It's not often that David and Ken find themselves on the same side of the argument… well, actually… they probably do but too many people are willing to see Kanban and Scrum as sworn rivals. I digress, back to SAFe and scaling.

I still don’t have anything original to say about SAFe, I simply don’t know much about it. However the points David and Ken make would worry me too.

I’m not about to rush out and read SAFe. I find I’m more likely to be told by my clients: “I can see how agile works in big companies, but we are a small company, we can’t devote people like that.” And while I do have, and have had, some larger clients I think that statement says a lot.

I have over the years built up some rules-of-thumb, heuristics if you prefer a fancy term, for “scaling agile”. I’ve never set them down so completely before so here you go:
  1. Inside every large work effort there is a small one struggling to get out: find it, work with it
  2. Make agile work in the small before you attempt to make it work at scale; if you can’t get a team of 5 to work then you won’t find it any easier to get a team of 10 or 100 working. Get a small team working, learn from it, and grow it...
  3. Use piecemeal growth wherever possible: start with something small and grow it
  4. Don’t expect multiple teams to work the same way - one size does not fit all! A new project team might be perfectly suited to Scrum, a maintenance team to Kanban and a BAU+Project team to Xanpan. Forcing one process, one method, one approach one different teams is a sure way to fail.
  5. Manage teams as atomic units, aim for team stability, minimise moves between teams
  6. Split big teams into multiple small, independent, teams with their own dedicated work streams, product focuses and even code bases 
  7. Trust in the teams, delegate as far down as you can; give teams as much independence as possible; staff teams with all the skills they need - vertical teams, include testers, requirements people and anyone else
  8. Minimise dependencies between teams; decouple deliveries, decouple teams and again, vertical teams, staff the team so they don’t need to depend on other teams
  9. Use technical practices to automate as much of the dependencies between teams as possible. e.g. a good TDD suit and frequent CI will by themselves allow two related teams to work much closer together
  10. Overstaff in some roles to reduce dependencies - overstaffing will pay back in terms of reduced dependency management work 
  11. Learn to see Supply and Demand (a future blog entry is in the works on this): supply is limited and is hard to increase, you need to work on the demand side too
  12. Recognise Conway’s Law: work with it or set out to use it; again piecemeal growth and start as small as possible will help
  13. Use Portfolio Management to assess teams, measure them by value added against cost. Put in place a governance structure that expects failure and use portfolio management to fail fast, fail cheap, fail often
  14. Ultimately embrace Beyond Budgeting and change your financial practices
  15. Big projects, big teams are high risk and likely to fail whatever you do; some things are too big to try. Some big projects just shouldn’t be done
 
There is no method, framework, tool out there that will be your silver bullet, but if you think for yourself, and if your people are allowed to think and act then you might just be able to create something for yourself.

Doing back to the three questions I opened with:
  • How do you make agile work with a big team? When the team gets too big split it along product lines or product subsystems; if you can’t then don’t do anything that big
  • How do you make agile work with multiple teams within an organisation? Use multiple independent teams, minimise decencies, decouple and use technical practices
  • How do you make a large organisation work agile? Portfolio management and beyond budgeting
And remember: Don’t do big projects, do small ones and grow success. If that is not an option for you then brace.
Published at DZone with permission of Allan Kelly, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Ian Mitchell replied on Tue, 2013/08/20 - 8:37am

> Don’t do big projects, do small ones and grow success. If that is not an option for you then brace.

Alas, many organizations do indeed have to brace.

This is because they can find it too hard to succeed even in the small, due to dependencies that inhibit any given team from bringing a Sprint Backlog through to completion. Most "small" teams in an enterprise at scale don't truly own their process. Raise a Scrum or Kanban board for such a team, and it soon fills with work that is "blocked". Moreover, getting it "unblocked" requires authorizations and organizational culture changes that no one Scrum Master or Agile Coach can bring into effect without top-level support. Guerrilla Agile, although laudable and useful in some cases, can take an enterprise-level transformation only so far.

Agile scaling frameworks attempt to provide some sort of brace position for dealing with this, in that a "whole organization" response is generally prescribed for breaking the back of such interdependent problems. This is the rationale behind the establishment of the SAFe Release Train, for example. Other frameworks (such as DSDM) have analogous processes.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.