At Net Objectives, we’ve been doing Agile at the team level for over 16 years and Agile at small scale (25-150) to large scale (1000 on up) for over a decade.  It is surprising how relatively few things must be identified and managed to do this well.  It’s also interesting that many of the large scale items must be managed at small scale as well.  For example, how teams work together must be managed at all degrees of scaled agile.  That it must be managed is one thing, how this issue is managed is something else and depends significantly on where the organization is (current culture, process, business context and more).  Taking a “one size fits all” approach is the anti-thesis of Agile.  Ironically, most approaches do this indirectly by not discussing when they apply and when they don’t.

In any event, the hard part is not in knowing what to do, but rather in getting people to do it.  A big challenge here has been a lack of looking for the core set of issues that must be worked with and why they must be addressed.  Merely stating people will figure it out or that it is orthogonal to the method being proposed is insufficient as experience has more than demonstrated (Why You Should Be Concerned When a Consultant Says "That's Orthogonal).  Not addressing core issues only makes the process of adoption tougher. As people try to get certain key practices to work, they inadvertently self-sabotage themselves by ignoring other key practices that they are often not aware of (Framework Tunnel Vision).  

This blog discusses the key questions that must be asked at large scale Agile (many of these should be asked at any scale as well). We call these questions and how they are handled "inflection points" because how we ask and answer them will significantly affect how well our transitions go.  Although these questions relate to large scale transitions, not all of the questions are intended to be answered the same way across the enterprise. How one arrives at the answers to many of these issues are already on our web-site in the form of webinars or on Enterprise Agility Roadmap Essentials.  I will update this blog soon with references to solutions to these issues on our site or elsewhere.   Another blog will illustrate how SAFe^TM addresses most of these questions.

This is not intended to be a complete list, but it goes pretty far.  While some may say about 20 is too many, I believe it is relatively few when one considers the massive behavioral change one is attempting to accomplish.   After this list of questions I'll go through each one and provide a little more detail.

Enterprise Wide

• Are we doing an implementation or a transition?
• At what level should we start?
• What should the pace of our transition be?
• How should we manage the transition?
• What roles do we need to add, change or even eliminate?

Enterprise Portfolio

• What is the enterprise budgeting cycle?
• How should we sequence the work items we’re going to develop across the enterprise?
• How are you going to make the work visible?

Program Portfolio

• What is the program budgeting cycle?
• How should we sequence the work items we’re going to develop in this program?
• How will we budget and manage architecture and technical work items?
• How do we decide when to initiate work?
• How will we manage the initiation of tactical work?
• How should we decompose our work?

Program Implementation

• To what extent should we use Acceptance Test-Driven Development?
• What should our release planning cadence be?
• How should we plan our implementation at the program level?
• How should we organize our teams?
• How should we coordinate teams that must work together?
• How will shared services work with the development teams?
• How do developers work with ops?
• How will we estimate our work to be done?

Team

• What methods will our teams use?
• How should we develop our code?
• How can we avoid the tradeoff between speed and quality?

Enterprise Wide

Are we doing a transition or an implementation?

There is a big difference between transitioning to something and merely implementing a few courses.  A transition entails changing the way the organization works, the management approach, the roles present and many other items.  Taking a few courses will not accomplish what is needed for sustainable improvement.  The answer to this question should always be “yes.”  It is included in this list mostly to ensure the answer is acknowledged.

At what level should we start?

It is always best to start with executive sponsorship.  If not that, then start with those deciding what to work on. Essentially, the higher up the sequence of events that get business value delivered the better off the transition will be.  But, of course, an organization will start its transition where it can.  Starting lower than ideal simply means that there will be constraints on the transition.  Instead of authority, influence will have to be used to achieve what is needed.

What should the pace of our transition be?

The two common paces are “all at once” a la SAFe/Scrum or “in an evolutionary manner” a la the Kanban Method.  There are other options.   Our experience has shown us that big changes are often possible but must be managed carefully.   Avoiding these opportunities can lead to stagnation because not enough change is being made to sustain the transition.  Ignoring the potential pushback on too much change can have equally dire consequences as people resist doing what they should.

How should we manage the transition?

Transitions need to be managed.  This doesn’t mean telling people what to do.  But widespread change rarely comes about on its own.  If it did, why is the organization not already at their desired point?  Widespread change means that culture must change.  This requires that the management system of the organization must change.  See Why Not to Focus on a Company’s Culture.

What roles do we need to add, change or even eliminate?

If you keep on doing what you've always done, you'll keep on getting what you've always got. - W. L. Bateman

Part of the transition will be changing roles and responsibilities (not people).  How an organization goes about this should depend upon many things (culture, effectiveness of current roles and more).  If roles don’t change when they should, old behaviors will persist.

Enterprise Portfolio

What is the enterprise budgeting cycle?

How is the enterprise budget to be handled?  Annually?  Quarterly? With a beyond budgeting approach?  What is the approach to budgeting?  By product line, opportunity, last year's budget?

How should we sequence the work items we’re going to develop across the enterprise?

First notice we say “sequence” not “prioritize.”  Sequencing work requires an order.  Prioritizing allows for everything to be at the top.  In large enough organizations, it is important to establish a book of work at the enterprise level.  Different divisions are usually not independent of each other due to shared services and operations.  There are many other reasons they may compete for people and resources.  The timing and approach to creating a sequenced list of work across the organization is an important decision.  

We also need to ask what the work items are.  We have found the use of minimum business increments to be significantly superior to epics.

How are you going to make the work visible?

We have found that making both work and how the work is being done visible to everyone is important.  How is this going to be done? Will tools be mandated?  Will certain reports be required?  What tools will be used?

Program Portfolio

What is the program budgeting cycle?

This may very well be established via the question to the enterprise budgeting cycle.  But if not, the same questions need to be asked for the program.

How should we sequence the work items we’re going to develop in this program?

The same points made for the enterprise level apply here – only more so since there will be a greater contention for people and resources.   It is often the case that there is more authority here for those doing the transition than at the enterprise level.

How will we budget and manage architecture and technical items?

Architecturally and technically related work are often treated as second class citizens in both the enterprise and program portfolios.  This leads to long term decay of the system and a continual waste of effort as technical debt builds.  An agreement about how to handle this across all stakeholders must be made.  One solution is to allocate a certain amount of capacity to this type of work.

How do we decide when to initiate work?

The answer here should not merely be limit work in process (WIP).  It needs to include questions about whether the right subject matter expertise (SME) and capacity is available.

How will we manage the initiation of tactical work?

Tactical work is that work which has a shorter inception cycle than our enterprise and program budgeting cycles.  It therefore comes in to be considered throughout the implementation cycle.  Insisting this work always be put through the enterprise and/or program budgeting process is often too cumbersome and expensive.  But not having a method to manage it tends to lead to work being done either because the sponsor of it is louder than others (“squeaky wheel” phenomenon) or through “shoulder taps” (covert requests that developers are reluctant to decline).

How should we decompose our work?

How small is the work being done being decomposed? Is it being left as big chunks?  How small should the stories be when they get worked on? Are we leaving this to the teams to decide?  While this is often left to individual teams to decide, there are laws of flow that must be considered.

Program Implementation

To what extent should we use Acceptance Test-Driven Development?

ATDD to be one of the few things that virtually all development groups should do.  But how does one go about transitioning to it? How deeply is it adopted? See How To Start With Acceptance Test Driven Development.

What should our release planning cadence be?

Is release planning to be done? How often?  Who is involved?

How should we plan our implementation at the program level?

Do we plan all things together? How far out is the plan detailed?  To what depth do we plan out our work?  Just the beginning with deeper elaboration as time goes on?  Or pretty deep for the entire scope? The options basically go from pure flow with little look ahead to virtually planning everything out.

How should we organize our teams?

The ideal case of cross-functional teams working independently to achieve their delivery is virtually impossible to achieve once a development organization grows beyond 100 people.  Shortages of subject matter experts, architects, and people with knowledge of legacy code or special skills virtually always create a shortage of capabilities required.  How teams are created has a significant impact on how they should work together, so this and the next question are inter-twined. See Create Teams When Possible for more information.

How should we coordinate teams that must work together?

There are many ways for teams to work together.  Ironically, we should be trying to create our teams and managing our technical dependencies in such a way that less coordination is needed, not more.  But when coordination is required, creating a high-level view to manage it is almost always helpful.  How will this ben done while enabling teams to self-organize? See a 5 minute video on Multiple teams working together to see an effective method for coordinating 3-5 teams.  Or watch a full 60 minute webinar that discusses several ways to coordinate teams at scale Scaling Agile with Multiple Teams.

How will shared services work with the development teams?

One of the challenges of Agile is that different groups have different motivations and different sponsors.  Teams that support multiple teams that answer to different business stakeholders are often put in a situation of not knowing how to prioritize there work and therefore take on too many things.   How is this going to be resolved?

How do developers work with ops?

Developers and operations often have conflicting concerns.  How is the organization going to bridge this gap?  Should we adopt “devops?”  How will we go about this?

How will we estimate our work to be done?

Except for maintenance teams, estimation is almost always a good thing at scale.  But how it is done makes a big difference.  Although Mike Cohn’s Planning Poker is the most popular method, it takes 4-10 times longer than other, just as effective methods (e.g., Team Estimation by Steve Bockman). Other methods also have the advantage of easier to teach and more consistent regardless of the size of the work being estimated.  Which approach is chosen makes a big difference on how well it is adopted.  See our estimation page for more information.

Team

What methods will our teams use?

Most organizations have teams choose their own process.  But this leads to both inconsistencies, process wars and most teams not adopting practices they should.  How team frameworks/methods/approaches are selected will have a significant impact on the organization and how well teams can collaborate. 

How should we develop our code?

There are several questions that need to be asked here.  How should coders and testers work together (or are they the same people)?  To what extent should code quality, automated testing, and continuous integration be focused on?  Should test-first methods be utilized?  Will design and code reviews be done? Is there a minimum bar all code has to exhibit?  Or is it up to developers to set this?

How can we avoid the tradeoff between speed and quality?

Many people hold these as being opposed to each other.   But they do not have to be. Done properly, code quality and speed of delivery can go up together.  But many organizations have a built in culture of not being late at the expense of quality.  Unless there is an intention on changing this, code quality will get worse.  What is the level of commitment in the organization to achieve this?

In Closing

It’s an interesting exercise to see how your current approach, be it Scrum, SAFe, the Kanban Method or something else, answers these questions.  Which of these approaches is right for your organization?  Or should you use a combination of them?  A future blog will detail how each of the popular approaches answers these.  It is often best to consider approaches as collections of tools and select the tool that works best for you.

As always, if you want some assistance, please contact me at alshall@netobjectives.com

We are also in the process of creating a user group just for our clients and followers (and a few selected associates).   If you are interested, please ask to join.  No consultants please, this is just for our clients and practitioners.

Al Shalloway, CEO, Net Objectives

If you are interested in SAFe, check out our SAFe's Answers to Our Inflection Points.