Real Agility – Self-Organizing Team Creation Event for Large-Scale Agile Enterprises

In 2005 I had the privilege to participate in the first occurrence of this fantastic technique for organizing large numbers of people into Agile teams.  It happened at Capital One in Richmond Virginia and my colleague of the time, Kara Silva, led this successful experiment.  The problem was that the “teams” that management had set up didn’t make much sense from an Agile perspective.  They were functional teams (e.g. a team of testers).  But to do Agile well, they needed cross-functional, multi-skilled teams that could work well together to deliver great results each iteration.  So Kara and a few other senior people got together all the staff in the department into a big room with a big whiteboard and facilitated a 3 hour meeting to sort out who would be on which team.  Everyone was involved – all the people who would be on the teams were in the room.  Those teams stayed together with the same membership long after that meeting.

This “team creation event” was a fantastic success for that particular department.  What made it a success?

  1. Everyone participating already had Agile training and experience.  They knew what they were getting into and why they were doing it.
  2. Everyone was encouraged to participate through the way the meeting was facilitated.  No one felt like their opinion was ignored.
  3. The meeting was long, but also time boxed.  It wasn’t an open-ended discussion that could go forever.
  4. It was in-person!!!  Everyone was physically present so that not just abstract facts, but also feelings were clearly visible to everyone else.
  5. It was honest: tough things were discussed including potential personality conflicts.  This open discussion required expert facilitation.
  6. Management was not involved in the decision-making during the meeting.
  7. The overall purpose of the exercise was clear: here’s the business we’re in, and here’s the people we have to work with – how can we organize ourselves to be most effective?
  8. A big diagram of the proposed teams and their membership was constantly being updated on a whiteboard: visual and concrete for everyone to see.
  9. Preparation: the meeting was scheduled far enough in advance that everyone could make it and management was informed about how important it was (don’t schedule over top of it!)

In the Real Agility Program, the team creation event is used to launch a Delivery Group.  The key people at the meeting include all the potential team members as well as the three Real Agility Coaches from the business, from technology, and from process/people.  Depending on the number of people involved, the team creation event can take anywhere from two hours up to a full day.  Longer is not recommended.  For larger Delivery Groups, we recommend that the team creation event be held off-site.

Facilitation of the team creation event is usually done by the process/people Real Agility Coach.  If you wanted to use this process with other enterprise Agile frameworks such as SAFe (Scaled Agile Framework) you would have the “equivalent” person such as SAFe’s Release Train Engineer as the facilitator.

The team creation event should only be done when the business is ready to get a Delivery Group started on actual product, project or program work.  If there is any significant delay between the team creation event and the launch of the Delivery Group on it’s work, then the teams can fracture and you may need to run the event again.  A few days should be the maximum delay.

One client we worked with ran the team creation event but had some significant problems afterward because they weren’t really ready.  In particular, they still had to make staffing changes (primarily letting go of some contractors, hiring some new full-time employees).  As a result, the teams created in the team creation event were not really properly stable.  This caused a great deal of disruption and even significant morale problems for some teams.  It is essential that the Leadership Team be committed to keeping the team membership stable for a significant period of time after the team creation event.  That includes any necessary means to encourage people who are thinking of leaving to reconsider.  It also includes a commitment from leadership to respect the self-organizing choices made during the team creation event unless there is an extremely urgent problem with the results.

So, to make it systematic, here are the steps required to run a team creation event:

PREPARATION

  1. Make sure that everyone who will participate has Agile training and has been on an Agile team for at least a few iterations/sprints/cycles.
  2. The Leadership Team needs to publish a notice (usually through email) explaining the upcoming team creation event and their unqualified support for the event.
  3. The people/process Real Agility Coach needs to schedule the time for the event, and if necessary, book the venue.
  4. In the weeks and days leading up to the event, some communication should be provided to all the participants about the overall business purpose of the Delivery Group.  Is it for a specific Program?  If so, what is the objective of the program from a business perspective?  It should not just be a one-time communication.  This should come from the business Real Agility Coach.
  5. The Leadership Team needs to decide which management stakeholders will attend the team creation event and make presentations.  These presentations should be about setting a vision for the Delivery Group, not about assigning people to teams.

TEAM CREATION EVENT AGENDA

  1. The team creation event starts with the people/process Real Agility Coach welcoming people and reiterating the purpose of the event.
  2. Management stakeholders make their presentations to ensure that participants have a clear vision.
  3. The business Real Agility Coach summarizes the vision presented by the management stakeholders.
  4. The people/process Real Agility Coach provides instructions about the constraints for a good Agile Delivery Team:
    • Cross-functional
    • Multi-skilled (see the Skills Matrix tool for ideas here).
    • Correct size (usually 7 +/- 2).
    • People who want to work with each other.
    • People who want to work on that particular team’s goal (if such is set).
    • Everyone must be on a team.
    • Every team must choose the people who will fill the Agile Delivery Team roles (e.g. ScrumMaster and Product owner for Scrum Delivery Teams).
  5. Everyone starts self-organizing!  Usually the three Real Agility Coaches circulate through the teams as they are working to organize themselves to offer gentle guidance, to answer questions, and to see if there are opportunities to optimize across teams.  These optimization opportunities should always be offered as suggestions rather than being directive.
  6. As the self-organization is happening, the people/process Real Agility Coach needs to clearly indicate the passage of time so that people are “finished” when the time has run out.
  7. Once the self-organizing is done, the Leadership Team (or a representative) thanks everyone for their work in creating the teams and agrees to let everyone know within a short period of time if there are any changes required (to be done before the teams start working).
  8. The people/process Real Agility Coach closes the meeting.  It is critical to record the final results of who is on which team.  It may be easiest to get the teams themselves to do this before leaving the meeting.

FOLLOW-UP

  1. The people/process Real Agility Coach makes sure that the Leadership Team receives a complete and accurate record of the results of the team creation event before the end of the day.
  2. The Leadership Team reviews the results and makes any (minor but critical) adjustments within a few days, at most, and publishes the final list to everyone.  Failure to do this in a timely manner can deeply demoralize the staff who will be in the Delivery Group.
  3. Any updates to org charts, management tools, time tracking tools, job descriptions, etc. that need to reflect the new team organization should also be made immediately and certainly before the Delivery Group starts working.
  4. A final thank you message from the Leadership team should be delivered immediately prior to the start of the Delivery Group doing its work.

Have you experienced an event like this? Did it work? What was different from what I described?

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Enterprise Agility – Pragmatic or Transformative – Presentation to PMI South Western Ontario Chapter

Last night I had the honour of giving a talk at the PMI-SWOC. It seemed well received and I really enjoyed the opportunity. The slides from the talk are attached to this post.

20141202 PMI SWO Chapter – The Agile Enterprise [PDF]

There were quite a few people in attendance who were new to Agile and I spent a bit of time talking about the Agile Framework before really getting into the slides of my talk.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: PMI Chapter Talk – The Agile Enterprise

On Tuesday Dec. 2, Mishkin Berteig will be speaking about The Agile Enterprise and the five different approaches to implementing Agile at the enterprise level.  The talk will also include some details about two frameworks used at the enterprise level: SAFe (Scaled Agile Framework) and RAP (Real Agility Program).

This talk is hosted by the South Western Ontario chapter of the PMI.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scaled Agile Framework: I Learned about Weighted Shorted Job First (WSJF)

Among the great things I learned last week in London UK at the Scaled Agile Framework (SAFe) Program Consultant training is the concept of using the Weighted Shortest Job First method of prioritization for backlog items.  The concept is similar to the Relative Return On Investment (RROI) that I teach in my Certified ScrumMaster and Certified Scrum Product Owner courses, but adds a bit of sophistication both in the background theory and in the actual application.

Weighted Shortest Job First is a numerical score where the larger the score, the sooner the job (feature, product backlog item) should be done.  Scores therefore give a sequence to jobs.  The score is based on the ratio between two estimates: the estimate of the “cost of delay” and the estimate of the “duration to complete”.  The cost of delay is a more sophisticated version of business value in that it takes into account customer needs, time criticality and risk reduction or opportunity cost.

In SAFe, the WSJF is calculated at the level of the team’s backlog on user stories through estimates of effort by the team and estimates of the cost of delay that are done by the product owner in collaboration with program management and business owners.  The effort estimate is considered a reasonable proxy for the measure of duration, but there is explicit acknowledgement that this may not always be a reliable relationship.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Scaled Agile Framework: I Learned about ROAM

The SAFe SPC training last week taught me quite a few interesting and useful new things. In reviewing my class materials, I noticed this little acronym: ROAM.  The way it is used in the SAFe training is that it is a mechanism for categorizing risks that teams identify as they are doing release planning.  ROAM stands for Resolved, Owned, Accepted, Mitigated.  The members of an Agile team or Agile Release Train identify risks and collaborate to decide how to handle them.  These risks are then place on a visible grid that has each of the four categories marked.  In this way, the whole Agile Release Train and their various stakeholders can have an open discussion and shared understanding about the risks to the Program Increment that they are planning.  Cool!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

SAFe Program Consultant Training – Review

I want to give some perspective on SAFe and the training that I have been attending these last few days.  The training itself is not actually over, but we are very near the end.  Just one day left, but it is dominated by the SPC exam and open Q&A on advanced topics.  In other words, we have covered the essence of SAFe.

Ad Hoc, Pragmatic and Transformative

When I think about organizations or departments trying to become Agile enterprises, I generally categorize those efforts into three approaches.

The “Ad Hoc” approach is typified by a grassroots movement or an executive decreeing “be Agile” with no one really knowing what that means.  A lot of organizations have some teams in this condition – they try Scrum, try some other Agile-ish things, and have modest successes.  When the enterprise is large enough, these ad hoc approaches reach a natural limit of effectiveness before they become severely blocked by organizational considerations.  Then, the leadership of the organization must turn to systematic approaches to becoming an Agile enterprise: the Pragmatic approaches or the Transformative approaches.

The “Pragmatic” approach acknowledges the difficulty of change, particularly for those in middle management.  There is still a deep acknowledgement of the Agile values and principles, but the pragmatic part is to say that the organization will take quite a long time to adopt those values and principles end-to-end, top-to-bottom.  These pragmatic approaches typically have low risk and good results.  SAFe (Scaled Agile Framework) falls into this category along with DAD (Disciplined Agile Delivery) and possibly others that I’m not aware of.

The “Transformative” approach acknowledges the deep nature of Agile as a cultural transformation that can be done quickly when there is urgency to do so.  There is still an acknowledgement that Agile can be difficult for many people as it requires a change in mindset and deep habitual behaviours.  These approaches are transformative because they require all protagonists in the enterprise to be open to this deep and fast change to a new culture.  LeSS (Large Scale Scrum) and RAP (Real Agility Program) are both systematic transformative frameworks.

SAFe, as a pragmatic approach, has a number of excellent features that will help an organization accomplish its business and technology goals.

Scaled Agile Framework – Practical, Pragmatic, and Still Pure Agile

One big concern I had about SAFe, based on other people’s comments, was that it somehow was compromising the values of the Agile Manifesto.  I want to say clearly and unequivocally that SAFe is most certainly true to Agile.  This fact was demonstrated multiple times and in multiple ways throughout the training:

  • Explicit statements that SAFe is based on the Agile Manifesto.  At one point, Dean Leffingwell emphatically repeated several times that “we live or die by the Agile Manifesto!”
  • Clear examples of SAFe implementations making choices based on the values and principles of the Agile Manifesto.  It was common to talk about situations where SAFe ScrumXP teams, Agile Release Trains and the people involved made decisions based on “individuals and interactions”.
  • Practices and guidelines that implement the values and principles of Agile are pervasive throughout SAFe.  The Inspect and Adapt meeting, Program Increments, daily business collaboration with SAFe ScrumXP teams, customer collaboration through various forms of backlogs, reviews and demos, focus on simplicity and technical excellence with Architectural Runway, Test-Driven Development and other Agile engineering practices.
  • The instructors (not just Mr. Leffingwell) often mentioned their own philosophy of being flexible with the SAFe “framework” by making appropriate context-specific changes to the details.
  • Even participants in the class who have already started using SAFe in their organizations shared stories that clearly indicated a strong emphasis on the values and principles of Agility.

At the same time, SAFe manages to create a relatively simple interface with a traditional management organization.  This is critical and what makes it really effective as a pragmatic approach to enterprise agility.  For example, at the Agile Release Train level, there are nine roles identified (e.g. System Architect, Product Management, Business Owners).  The explicit acknowledgement and identification of these roles and how they interact with the SAFe ScrumXP teams through meetings, artifacts and other processes and tools helps an organization to map Agility at the staff level to traditional concepts at the middle-management level.  This interfacing is also pervasive throughout the SAFe framework and occurs at all levels of effort from individual team members up to high level business leaders.

Some people have grumbled about the complicated diagram as “proof” that SAFe can’t be Agile.  But a different way of looking at the diagram is that it is comfort for management.  I really appreciate this.  Back in 2004 and 2005 when I was consulting at Capital One on their first enterprise attempt at Agile, one of the coaches I was working with shared a story with me about the importance of comfort.  The project manager for an important project was very nervous that there was no Gantt chart in Agile.  At a personal level, she needed the comfort of having a Gantt chart to track the work of the team.  The coach for this project told the project manager “please, make your Gantt chart – just make sure that you let the team organize themselves without being disturbed to help you with the Gantt chart.”  Most Agilists are anti-Gantt.  This was a real eye-opener for me.  That project manager went on to gain confidence in the Agile team and was able to eventually discard the Gantt chart.

SAFe isn’t just a framework, it’s actually a scaffolding.  When you build an arch, you need a scaffold to keep everything in place until the keystone is in place.  In creating an Agile enterprise, you use SAFe as a scaffold to get you to Agility.

Lean, Agile and Leadership

This training has also spent a lot of time discussing Lean thinking, Lean product flow and Lean leadership.  SAFe asserts four principles of Agile Leadership:

  1. Take a systems view
  2. Embrace the Agile Manifesto
  3. Implement product development flow
  4. Unlock the intrinsic motivation of knowledge workers

I like this list.  I might change the wording slightly, but in going through the details of what these mean, it is clear that if leaders could adopt these principles, every organization would be a much better place to work.

There is a fair amount of time spent on helping leaders make the shift in thinking from traditional “scientific management” to “Agile leadership”.  There are a lot of good reading references given in these discussions including “Five Dysfunctions of a Team”.  There is also a lot of time spent on value stream thinking including some great discussion exercises.

Organizational Structure in SAFe

SAFe does not define all the structures throughout the whole organization.  By design, it is not end-to-end, top-to-bottom.  It does define a structure for three levels of activity: the team level, the program level and the portfolio level.

At the team level, SAFe relies on a slightly modified version of Scrum and Extreme Programming (XP) that it calls SAFe ScrumXP.  As a Certified Scrum Trainer, I’m confident that the Scrum described is “good enough” to be legitimate Scrum even if there are small variations.  One example is in the idea of commitment.  Scrum espouses the value of Commitment.  In “old” versions of Scrum, the Scrum Team was required to commit to the work of the Sprint (the business scope).  SAFe keeps this concept.  However, if you look in the most recent version of the Scrum Guide, this concept is no longer present.  One thing that I think is absolutely fantastic is that several of the XP technical practices are required practices in SAFe: Test Driven Development, Continuous Integration, Pair Programming, User Stories, Acceptance Test Automation and Refactoring.  I wish that Scrum would get around to officially requiring these practices.  This set of canned answers is sometimes an irritant for Scrum folks, but the fact is that, again, middle managers are often made more comfortable by being provided with concrete answers.  And, in my not-so-humble opinion, SAFe is providing the right answers.  Since all this is at the Team level, middle managers are even more comfortable because they can tell all these staff-level people how to work.

At the program level, SAFe scales the basic concept of a Sprint up to a larger “Program Increment” (PI) concept.  The core concept that holds the program level together is the Agile Release Train which is based on a limit to the number of people who can work effectively in a social network (Dunbar’s number ? 150).  Again, SAFe is quite definitive about process at this level: Sprints are 2 weeks long and PIs are 5 Sprints long (10 weeks).  Timeboxing is explained effectively with the concepts of cadence and synchronization as a way to ensure predictability at the program level.  Unlike the simplicity of the Team level, the Program level in SAFe introduces a number of important connectors to transitional organizations.  This is done through defining several roles that have extremely close analogues to traditional roles (and even use a lot of the same names), and through other artifacts such as vision, roadmap, non-functional requirements, and features.  There are even a number of recommended metrics for evaluating the performance of the program (not the people).

At the Portfolio level, SAFe simplifies again somewhat in that there are no new aspects of cadence or synchronization introduced, and the number of defined roles and artifacts at this level is relatively small.  One important difference at this level compared to the Program and Team levels is the introduction of a Kanban approach used to feed “Program Epics” to the Agile Release Trains at the Program level.  At this level, Kanban is used to drive the flow of value, but there is not as much emphasis on continuous improvement here (although there is when SAFe discusses leadership).  At all three levels, there is a constant emphasis on the lean concept of focusing on value rather than cost.  This comes in many of the details, but may be a bit difficult for middle managers.  Fortunately, the Portfolio level  includes some excellent advice on working with budgets and allocating those budgets to business vs. technical needs and based on the effort required at the Program level with the Agile Release Trains.  SAFe recommends revisiting budgets every six months (I believe this is meant to be every 2 Product Increments) and is the only aspect of cadence and synchronization at the Portfolio level.

The Training

I’ll admit that overall I didn’t particularly enjoy the training.  I love SAFe.  As a trainer myself, I’m too critical perhaps.  Certainly, the training I deliver has evolved over ten years of work with lots and lots of feedback and mentorship.  However, in the Agile community, the overall standard for training has improved greatly over the last 5 years and I would love to see our three trainers who helped with this course improve their delivery.

There are a also some general comments about the training that I would like to make that are about personal preference.

First, I would prefer more small exercises that are experiential.  For example, there was a great deal of time spent on centralized vs. decentralized decision-making and leadership which could have been compressed greatly with a simple exercise like the “Command and Control Walking Simulation” which takes about 5 minutes to drive home the point unequivocally.  The first two days were largely lecture with a couple big exercises (both the lecture and the big exercises were generally good).

Second, the slides.  The slides.  The slides.  The slides… and more slides!!!  Too much by far.  And using the slides for lecture made it very difficult to stay on track for time with lots of slides missed or touched on only very briefly.  This is anxiety-inducing and boredom-inducing for me.  Some people like lots of slides, but most people don’t.

Third, not enough breaks for a 9 to 6 training session.  Usually just one break in the morning and one in the afternoon as well as a short lunch.  Two breaks and a longer lunch would have made it much more tolerable from a personal comfort level.  At one point on the third day I just had to take an extra break and I ended up missing about 30 minutes before I felt ready to come back.

Final Words

I’m happy I invested in this for both myself and for Travis.  We have learned a lot about SAFe, a little about Agile and Lean, and we are both excited about offering SAFe-related services to some of our clients.  At this point I am convinced that it is appropriate and good under some common (but not universal) conditions.

I will probably write several more articles about SAFe as I process the information and start to relate it to more specific aspects of Agile, Lean, organizations, management, leadership, productivity, and, of course, our own Agile Enterprise framework, the Real Agility Program. I’m excited and happy to see that the two frameworks are not competitive or exclusive in any significant way… more about that of course!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

About SAFe – Lyssa Adkins

Lyssa Adkins, the “Agile Coaches’ Coach” has written a fantastic article sharing her feelings and perspective on SAFe.  (Thanks to Gerry Kirk for bringing this article to my attention!)

As you know, dear readers, my colleague Travis and I are at SAFe Program Consultant training with Dean Leffingwell this week in London, UK.  I have lots of notes even after my first day and I will write one or two articles this week giving you my impressions and highlights.  I have already reviewed all the course materials including appendices, ahead of the actual training. I can say this so far: SAFe has a lot of great things in it, and overall, I think it is a fantastic example of a Pragmatic approach to Enterprise Agile Adoption.  I will definitely be writing more on this idea of Ad Hoc, Pragmatic and Transformative approaches.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Going to SAFe Program Consultant Training – London England

Travis Birch and I are going next week to the SAFe Program Consultant (SPC) training with Dean Leffingwell.  For Berteig Consulting, this will be an opportunity to expand our knowledge and to, perhaps, offer some new services including training and consulting.  Of course, there have been many articles written about SAFe from a Scrum perspective, but I’m hoping to write an article about it from an enterprise Agility perspective.  I have been involved as a coach and consultant in a number of such transformations, and I’m interested to see what I can learn from SAFe and perhaps how it can help to improve our Real Agility Program.  I currently consider SAFe to be a “pragmatic” approach to enterprise Agility vs. a “transformative” approach.  This perspective is based on some light reading and 3rd party reports about SAFe… clearly not a good enough base of knowledge!  I’m looking forward to bridging that gap!

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Re-launch of Real Agility Newsletter

Hi Everyone!  Berteig Consulting is going to re-launch their monthly newsletter starting this month!  We’re excited about it because, although it is partly due to a legal change around commercial email here in Canada, we are considering this a great opportunity to change the style of our communication with our customers and our colleagues.  Like before, we plan to have a few regular segments:

  1. A message from me, Mishkin Berteig, that shares my personal experiences with Agile, with running an Agile consultancy, and other things that I hope will be interesting.
  2. A “Coaching Corner” article written by one of our coaches, or by a guest author, about how organizations, teams and people can become more Agile.  Topics will range from technical to people-oriented, practical to theoretical, cutting-edge to deeply retrospective.  We hope these articles will become a great resource – and they won’t be cross-posted here on Agile Advice.
  3. A listing of our upcoming training.  We’re excited that in the fall and in the new year we are going to start offering some things besides just ScrumMaster and Product Owner training including training on Agile Coaching, SAFe (and maybe even other enterprise agile frameworks), and topics closely related to Agile such as leadership, communication, etc.
  4. And of course, a “special offers” section that will promote new products or services from us or from close partners that we think will be helpful.

Please subscribe to our Real Agility Newsletter by clicking on the link:

SUBSCRIBE

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail

Updated: Reviews of SAFe (Scaled Agile Framework)

I just finished attending my SAFe Program Consultant (SPC) training and I wrote a review of the Scaled Agile Framework 3.0 and the SAFe Program Consultant training.  I won’t quote myself here :-)

Lyssa Adkins

Also, Lyssa Adkins has recently published her own review on InfoQ.  I enjoyed reading it because Lyssa is so gentle, fair, and insightful.  She puts a lot into connecting the Scaled Agile Framework with the Agile Manifesto and shows that there is a fantastic level of alignment between them.  Her article is called “Agile Coaches’ Coach Shares Her View on SAFe“.  Here’s a bit of a teaser from her article:

Based on the way the SAFe Big Picture looked to me, I walked into that class very concerned that SAFe would take away the teams’ creativity by “pre-chewing” the stories into requirements a la my project management days. I thought I might see the rebirth of “The system shall…” statements. I was also worried that SAFe would take away teams’ autonomy and reverse our still fragile belief in emergence; the diagram just looks so top down! These concerns put me on alert for anything that appeared to undermine the Agile Manifesto or the Scrum values.

 

A surprising thing happened in that class…..

Peter Saddington

Although I don’t know him well, the few small interactions I’ve had with Peter have engendered in me a great deal of respect for him.  His fundamental philosophy of Agile and organizations is courageous and principled.  I found out yesterday that Peter wrote a review on the Scaled Agile Framework back in February 2014.  Please check out “The Scaled Agile Framework (SAFe) – A Review“.  It is interesting and insightful.  Great quote:

What SAFe is Far Better At Than Most

- Marketing

Ron Jeffries

SAFe (Scaling Agile Framework) is gaining in popularity.  Ron Jeffries recently attended a SAFe training session and has written a great review.  I particularly like what Ron says about the idea of being properly Agile:

SAFe will be successful in the market. People will benefit. They just won’t benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

 

SAFe is good. It’s just not good enough. It provides some benefit, but endangers an organization’s progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It’s fast food. You can do better.

 

Mike Cohn

Mr. Cohn has written a really fun April fool’s parody of SAFe that, given the comments, surely counts as a review as well.  It’s called “Introducing the LAFABLE Process for Scaling Agile“.  Although it starts on a very humorous note, the comments are quite extensive and contain lots of great discussion.  Here’s an important comment from Mike Cohn about the whole concept of scaling that gives you a taste of the discussion:

I don’t think “agile at scale” is a bad word. I’ve consistently maintained that projects should be as agile as they can be but no more. A project that requires let’s say 500 people will never be as agile as one that requires 3 people. But I can’t imagine the 500 people and 3 people being competitors. And, if they are, the bigger mistake made by the 500 person project is involving the other 497 people, not the process they choose.

Neil Killick

Neil Killick seems to have even stronger opinions about SAFe, and is quite direct about them.  I like what he says in one of the comments on his blog post:

So you can go the SAFe path or the Scrum and Agile path. All you need to do i[s] figure out how big a cliff you want to deal with down the road.

I don’t personally have any experience with SAFe so I won’t make any big claims about it either way.  However, I do appreciate that the popularity of SAFe, like the popularity of Agile/Scrum* will probably lead to studies showing modest qualitative improvements of 20% to 40% increases in productivity.  Is this just the Hawthorn Effect at work?

When I help an organization with Agile principles and methods, I hope and expect dramatic measurable improvements.  Sometimes this results in people losing their jobs.  Sometimes this means people have nervous breakdowns.  It can be very painful in the short term.  SAFe, by it’s very name, seems to be anti-pain.  That doesn’t bode well.

Here are a few other interesting links to information about the Scaled Agile Framework:

Has SAFe Cracked the Large Agile Adoption Nut? – InfoQ

Unsafe at Any Speed – Ken Schwaber

Kanban – the anti-SAFe for almost a decade already – David Andersen

* There is no such thing as “Agile/Scrum” but that’s what lots of people call Scrum when they don’t do Scrum properly.

Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to information

Please share!
facebooktwittergoogle_plusredditpinterestlinkedinmailfacebooktwittergoogle_plusredditpinterestlinkedinmail