We have to scale agile when more than one team is required to get a thing delivered. Each team not more than 10 members. There will be adjacent topics which belong to an agile organization, but when we focus just on delivery, that´s it: multiple teams working on one thing.
Agile is about culture and cultural change. Scaling agile means essentially, to scale cultural change. This is an incredible difficult thing to do. Peter Drucker coined the phrase “culture eats strategy for breakfast”. You better prepare for the long run. Is it clear, why you want to change? You are: managers, who define how the system works, product managers who define what kind of product to build, research and development people who explore possibilities, engineers who build the product, salesforce who will drive sales, project managers who are in charge of leading one-of-a-kind endeavors - you will identify even more people and roles for your organization.
Do your leaders have a sense of urgency that agile is the way to go? Can they argue for it and will they? Do your leaders know what problem they want to solve by being agile?
You have to change, you know that, because the first rule of life is adapt or die. Do you think it can happen by implementing some new release train processes that you have seen in the latest scaled agile book? Or disseminating a slide deck to your subordinates, giving order to work in Sprints and counting Sprints as being unsuccessful if some tasks are left undone at the end of the Sprint? By letting the Project Management Office give instructions to standardize Scrum Boards in the entire company with predefined columns? Or printing sticky note templates to have them all look the same on the boards, without referring to your workforce? These top-down communications are patterns of how to get agile wrong. If you think this is scaled agile and will lead to cultural change, then you are heading for scaled snake oil. Mentally, your people will step aside and identify the entire thing as some kind of theater communication. If you understand agile as the current way of working to only squeeze more results faster out of your knowledge worker people, because your engineered waterfall projects seem to fail too often without delivering the desired outcome, you did not get the idea of agile.
Agile is not implementing a process and then follow. Agile has to be earned, not given.
Every organization is unique
Though, every organization is unique and has to find answers to questions like “what delivers value?”, “What is success?”, “How would we know we achieved success?” and, of course, “Why to be agile?” and “What does it mean to be agile?” - there are some general properties which I believe characterize agile organizations.
Find out, if this is something for you: Center around people and results, not processes. Processes are servant, not master. Still continuously improve processes and focus less on improving the monitoring of people. Identify what brings value to your customers and organize around delivering that value. Money is not the goal, it is a result which comes from achieving value for delighted customers. Have a straight line from your product strategy to your release strategy to the delivery order of the features within a release. Things are ordered in a way to regularly deliver the highest value first, in small increments. The people are oriented about that and understand. Transparency on all levels with everyone seeing the same figures, whether it´s the progress of value delivery or costs and earnings. The workforce is emancipated and authority is brought to where information lives and not information is brought via monitoring chains to “authorities”. Give control to people and not take control. Decentralize and find ways to let information and energy flow easily to the places where needed. Be clear about the goals and intent, but leave space for the workforce to find ways how to achieve the goals. Grow competency to perform. Strive for a learning attitude on all levels to enable the organization to get better and to lead change. Team and personal growth are not only lip service and to be a leader is about duties and responsibilities and not necessarily about privileges. Leaders are cultivators rather than controllers [Mayer 2013:63]. Instead of one-way top-down commanding communication, the horizontal discursive approach is default. Top-down is only used where really needed. This organization is more of a leader-leader type instead of playing the leader-follower game (compare with [Marquet 2013]). You want leaders on all levels and not people with their brains off and only following given procedures.
The agile organization is a failure resilient, success seeking, cooperative, status quo challenging, potential growing, knowledge worker organization. It is not a failure avoiding routined good behavior following procedures company.
Not for mummy´s boys
You may want to “use” agile only for a single project with 8, 20 or even 50 people and don´t think about your entire organization at first hand. That is ok, growing natural makes sense and to understand how things work in the small and then scale will give some chance for any scaling endeavor to function. Chances are, you try to go the agile way because your project currently is about to sink. This may also work, because then you have some pressure for clarity and right decisions - but no guarantee that you will make the right decisions of course.
Now, even being agile in a team of 8 people is incredibly difficult if you haven´t done it before. It is likely the most disciplined way of working you ever had to, or, better, wanted to achieve in your work life. It is not easy going. You have to be unafraid and explore. But it is not all hard stuff, it is mostly about people and purpose and real collaboration, about engagement, choice and fun at work, about trust, freedom, ownership and a sense of self [Mayer 2013:29]. I suppose no one ever achieved something great only because it was told him to do. You can achieve great if you see a purpose, if you are convinced, if you reinforce the spirit of your team, by making and learning, making and learning. As managers, you can not buy such behavior and attitude, nor can you give orders to do so. You have to set suitable constraints to give self-organizational forces a direction and give people authority to act as human beings. Be prepared to learn and adapt, because you will have to.
That said, why would you want to do that? Isn´t it better for the organization to be robust, reduce room for surprise and have people following orders?
I can identify four angles to assess the topic: the market, the problem class, the process model and the people.
Remark: The following paragraphs on market have been taken from the text “The art in our work”.
The centralized planning, disassembly and automation of work brought us to the integration of human work into precise production timing and to an understanding of companies as automatic production machines. Wohland and Wiemeyer explain the concept with their model of the Taylor-Tub.
In the Taylor-Tub the thoughts of the individual are not of importance, because all workflows, procedures and processes are already defined upfront and have to be followed. This makes the system robust, but inflexible. We have been educated for this world of working, which means we have been educated to follow. This brought up disruptive productivity growth and inert mass markets during the last century. Biggest problem to solve for these markets: how to produce as much as possible at the cheapest price.
Todays markets are more and more characterized by their narrowness and/or complexity. This complexity requires a better understanding of customer needs, higher flexibility and often interdisciplinary approaches. Those companies that can create and live up to such dynamics, the top performers, set the less capable companies under pressure. Biggest problem to solve for these markets: how to connect to the customer, identify what delivers real value and be able to do it fast. Companies that can not create the dynamics will suffer the pressure.
The necessary momentum is being created by dynamic people, by experienced and skilled workers who responsibly and self-organizing produce results. People who can bear with complexity. For those people values and leadership are of much higher importance than centralized control and management.
Agile values support dynamic and skilled knowledge workers. For your organization to be able to cope with current market requirements, you may be forced into an agile working style, whether you like it or not.
Any innovative endeavor will challenge knowledge workers with uncertainty about the problem space and the suitable solution space. To pick up a slightly modified Stacey Matrix, it is this uncertain complexity space where knowledge workers are at home and that´s where agile is positioned.
In this complex area we talk about dynamic, self-organizing systems with non-linear behavior. An environment, where more is unknown than known. The a-priori definition of all states of which the system can be in - and how to move the system from any of these states into a desired other state - is not possible. One has to work through this environment to get a grip on it. Therefore the a-priori definition of a detailed step-by-step execution process will not function and to put more effort into upfront planning will only consume more effort but won´t improve the outcome.
This leads to the next, tightly coupled angle on the agile topic: the process model to use.
Being positioned in dynamic, competitive markets that are characterized by uncertainty of both, problem space and solution space, we have to ask for a suitable process model to support and guide the workforce to achieve results. The detailed upfront planning of execution steps, the defined process model, does not bring any advantage, instead even the disadvantage of false safety and effort consumption. The waterfall process follows such a defined process model.
Consider the following questions:
- You already spent 30% of your available time and effort and just finished your design phase. Are you 30% done? Probably you can´t tell, because you are sitting on a stack of unvalidated paper. No working code.
- Do you have something of value for your customer or yourself? Can your customer do something with your paperwork? I assume not, again, only a stack of unvalidated paper. Reality will correct that when you start to write working code.
- Let´s say you learn during your implementation phase and something has to be reworked which makes a design change necessary. Will you proceed a change request? How long will you try to avoid it? Usually, a change request in the waterfall process is treated like a failure which is being tried to circumvent as long as possible. That´s why change requests are so expensive in this process model. And that´s why learning is so expensive in the waterfall process.
In the agile world, we respond with the empirical process model.
Working in short iterations of 1, 2, 3 or 4 weeks length and delivering working software at the end of each iteration will give you the security net that is comparable to what mountain climbers do when they climb and secure, climb and secure. At the end of each iteration you reach a safety point that clearly tells you what is and what not.
Picking up the same questions I already asked for the defined process model:
- If you have spent 30% of your time and effort, you can exactly compare that with the list of already done pieces of software. Your measurement for progress is no longer spent effort or time, but done work compared to missing pieces yet waiting to be delivered. This is clear and simple. Possibly you are 30% done at that point. Your customer decides and you can tell him exactly what is done.
- Do you have something of value for your customer or yourself? You should. If you have build working software in each iteration, even if not delivered to the customer, you have something to show and to learn from and to rely on.
- Now you learned something after 30% of your effort is spent (of course, you did even before). Can you change direction easily? Probably, because after each iteration you can decide what the next most important move is and go ahead while delivering software. And I have two additional questions:
- Is it difficult to work this way? Of course. The team has to master the culture shift to deliver done software by following the value, and completing the stuff that brings the most value first. In addition, the technical skills of the team have to grow to support this agility. Without automatic tests and automatic build of software in short intervals you won´t get there. All your systems need to be aligned towards giving feedback as fast as possible.
- Will this way of working help you to deliver appropriate results? Sure. Feedback and learning are an inherent part of this model. This responds directly to the uncertainty of the complex problem class that you are in. To deal with a world where more is unknown than known requires us to “cut through the noise by taking action” [Beedle and Schwaber 2002:27] and continuously validate our mental models against reality - as we go.
In this short enumeration from market over problem class to process model, the last mentioned are the people. Last, not least. People are most important. Everyone counts, it is no longer that people are being told what to do and simply follow. With the follower mental model you will not survive in dynamic, competitive markets or in complex problem situations. The only way to survive is with dynamic leaders at all levels in the organization, people who explore problem and solution spaces and find ways to achieve things, artists, status quo challengers with excellent skills. These people have a drive to achieve and strive for purpose, autonomy and mastery. Of course, in job advertisements all companies seek for this kind of folks, but after the hiring process, in the “real life”, these talents are being treated like if they were all the same and interchangeable, average, like resources, often without any sense and respect. To make it clear, the agile mindset asks for creativity, attitude, know-how, opinions and cooperation. We want people in their entireness and give them space to grow. We want them to ask “why” and insisting on answers. I believe, everyone in current corporate structures has the ability and the wish to act like a whole human being, but when people are treated day-in and day-out as interchangeable resources, it doesn´t take long and they behave accordingly, switch brains off and do something interesting in their spare time. You know - setting constraints directs self-organization!
To sum it up, agile does help in competitive dynamic markets. It does help to solve complex problems by leveraging an empirical process model and reinforcing the self-awareness of people as whole human beings.
It is driven by programmers
The agile movement started in the IT industry. It is driven by programmers and engineers at first hand, by people who are in the process of making and delivering. That kind of people who know since long how hard it is to get an idea to life and build something which other people like to use (and pay for). I assume the agile mindset found its first expression in Extreme Programming and Scrum in the second half of the 1990s, followed by the Agile Manifesto in 2001. And to me, when talking about agile in terms of frameworks, still I mean Scrum + XP, I don´t see we need more.
The ideas, values and principles of agile are pro people and pro results. The central working unit is the team, at max 10 persons, cross-functional and being able to deliver results. The team is emancipated, has authority to decide, the competency to act and clarity in the goals to achieve.
Agile is about letting people make things that deliver value now, while being connected to their work and validating results. The people are value focused and have the technical expertise to deliver frequently.
Agile delivery goes with the least possible process that is expected to work. This process is a servant, not a master. For example, the Scrum framework can be drawn and explained on a beer coaster - which does not mean it´s easy to live up to.
If you have not achieved this way of working for a single team in your organization, why would you believe you can overstep this level and try to work “agile” within the entire organization, in multiple locations, continents, timezones, social cultures?
You don´t solve problems by making them harder to see. You have to use the fast failure that is being promoted by agile instead of hiding it under an additional process layer. A thing like SAFe (Scaled Agile Framework) will put such layer between the delivery folks and management. It allows the management to ignore change and see the world like they have always seen it - only with a different decoration. And yet (or because of), there is a market for this kind of stuff. SAFe is not alone, to get an impression I´d like to point you to this article by Ron Jeffries. One of the “best” scaling frameworks is the LAFABLE process, which Mike Cohn introduced on the 1st of April 2014.
Even the simple Scrum framework, in the wrong hands or misunderstood, so that the enforced transparency is used to take control over the team, will lead to micromanagement and annoyed developers.
Ken Schwaber once suggested to use a transition team to address the organizational change which is being demanded by the delivery units [Schwaber 2007].
As managers, you don´t need to invent new structures upfront - the problem spots will easily be indicated by the agile delivery teams. Just pick up those indications and handle them with care. As managers, if you don´t find a way to show up for your people, to make clear that you care and are serious about agile, if you can not make visible that you catch dysfunctions and find ways to solve problems, simply to deliver the organizational change that is needed, if you can´t do that, you can´t do agile. It is clearly not enough to expect people to deliver working and valuable software at the end of each iteration and the management does not do more than counting velocity points and staring on product burndown charts.
Personally, if I don´t see managers dealing proactively with the dysfunctions that are clearly indicated by the delivery folks, for example by leveraging a transition team like described by Ken Schwaber, I can´t take anything what comes from management about agile for serious. Then agile is only lip service and decoration. How would you expect the delivery people to build valuable stuff every two weeks, make everything transparent, while the management isn´t committed and organized to deliver necessary organizational change with a similar pulse?
To implement large scaling frameworks and not using a transition team instead is introducing “agile” (by name, not by meaning) like a waterfall (yes, with a defined process model). Start with the transition team to scale agile and invent your own mechanisms and solutions. Show that you care. See what works for your organization, be self confident and do not copy others.
In the world of sports, when you start running for example, it is not important to have a pulse meter, fancy clothing and the like. Instead you only need a pair of running shoes and - of course - have fun and run regularly. When scaling agile in your organization, it´s the same. The core is to build and make things right. If you can do that in the small, in one team, think about growing larger. Learn while you are doing.
Scaling agile beyond the first team is the first step of scaling. Is there an end? What size can you reach or want to reach? How long does it take?
The general answer is, keep it as small as possible and, again, try to find the least solution that can work. Attacking the topic from the start as a scaling endeavor will not help you. Agile will scale itself when you allow it to truly work on a team level. Your organization will learn from such achievement and find a natural way to scale. Scaling is not the primary goal, it is a result of a curated successful agile implementation in the tiniest cells.
The more people are included, the more communication work is imposed on the people, because communication effort will grow quadratic and not linear.
Here is the simple math: Communication lines among people grow in terms of n(n-1) (with a team size of n). By this you come to 20 communication lines for a team size of 5, 30 lines for a team size of 6 and a team with 9 people will have 72 lines that need to be maintained among senders and receivers in the team.
That´s the reason for not letting a team grow beyond 10 people. If more people are needed to achieve things, split into teams with reduced dependencies between each other. The best concept to reduce dependencies, we know so far, is to have cross-functional teams where each team is able to deliver an entire feature that makes sense to a customer, end-to-end. You then have developers, front-end, back-end, QA, UX and so on in one team - shortly everyone who needs to be there to come to a result.
The other way around, having teams grouped by architectural components or skills, like front-end, back-end, UX and the like in separated teams, will increase dependencies and lead to teams blocking each other when delivering end-to-end features. No team alone can deliver and the people will have to maintain not only the communication lines inside of their team, but in addition to all people in other teams who are needed to to deliver the feature.
Focus on this: have a team to be able to deliver done software by the end of each iteration, always doing the most valuable things first, and let them work together as a real team. From that point on the people are in a self-carrying upwards movement. As managers you only need to move barriers out of their way, the rest they will go alone. Scaling before you reached that point will only let you scale up a mess.
Let´s assume you do daily standup´s with component- or skill-formed teams (I hope you do standup´s, doing it not is a very bad idea). Considering the purpose of a daily standup is to ensure the delivery of a feature by the end of your iteration and to unhide the necessary adjustments to reach that goal, usually a daily standup with only the people who belong to a single architectural component doesn´t support you at all. You will find communication without direction and the impression of wasting time among the participants. This is not fruitful.
Instead, if all the people who deliver a feature are together from the start, a so called cross-functional team, the standup supports collaboration and communication towards that goal of feature delivery and the team can start to hunt features.
Feature and component matrix
Traditionally, most teams are organized by similar skills or technical components. My suggestion is not to throw this all up in the air and try to reorganize in feature teams. Instead it can be a method to move on step by step. Try to see the entire thing as a fluent matrix structure. This it how it goes: stick with the component teams und try to see them as some kind of profession frame with people who keep their architectural component intact and maintain their specific professional skills. Now, in addition, when you have a clear backlog with a straight line from your product strategy to the delivery order of your features, pick the first and most valuable feature and let the people select themselves by deciding who is needed to deliver it. Those people will be your first feature team. Then pick your next feature from the backlog and do the same again. You will be able to identify chunks of features that should go to one feature team or the other, but the important thing is, now you have two organizational dimensions - the established that is grouped by components and skills, and the new one, which will support you to hunt for features. This is a start. Maybe over time you identify patterns, see who often comes together to deliver a feature, what is working, what not, and then you adjust. My suggestion here is only to make a first start.
You may have heard about the essential idea pointed out by Melvin Conway, that you replicate the structure of your organization inside of your products [Conway 1968]. Simply, if you have a bloated, unfocused organization with unclear goals and responsibilities, your products will look the same. Instead, if you have a lean, focused organization with clear goals and responsibilities, again, this will be recognized in your products. For example, if two departments are responsible for developing a specific product, chances are, that the product will be made up by two components. If the two department heads can not bear with each other, the interfaces of the two components will not function well. In this case you will find duplicated or missing attributes, performance issues, long durations to identify failures and so on. All that said, this doesn´t give you a concrete advice how to structure your organization, but when people are getting aligned to develop a thing, keep Conway´s law in mind!
There is no precise recipe to follow. But you can use some guiding principles that will surely support you on your journey to let an agile organization grow. I´m really convinced that the ScALeD Principles point into the right direction. Believe in yourself and your organization, follow the principles instead of checklists. A checklist is good for well defined procedures that can be analyzed upfront (I´m using the term checklist as a drop in for “scaled agile framework”). When you reinvent your organization, a checklist will not help. Likely it will let you switch off your mind and let you repeat things other people have thought of. In any way, embrace self-organization. This force of life will give your organization the power to survive in complex environments. In an enterprise context, self-organization needs to get a direction by setting constraints. These constraints have to address two preconditions for fruitful self-organization: competency and clarity [Marquet 2013].
Competency means the technical skills to do things on top of a craft. These skills need to be maintained and nurtured. You know, skills are bound to people.
Clarity means clarity in organizational goals and intent. Understand what brings value and follow the value.
Scaling agile is about emancipating people. Strive for clarity in goals and intent, let people grow their competencies and give them control to decide. Then agile is self-scaling. Focus on being agile at team level. From there on you only need to move barriers out of the way and growth will be self-carrying into the organization.
[Beedle and Schwaber 2002] K. Schwaber, M. Beedle, “Agile Software Development with Scrum”, Pearson Prentice Hall, 2002
[Cohn 2014] M. Cohn, “Introducing the LAFABLE Process for Scaling Agile”, 2014, http://www.mountaingoatsoftware.com/blog/introducing-the-lafable-process-for-scaling-agile
[Conway 1968] M. E. Conway, “How Do Committees Invent?”, 1968, http://www.melconway.com/Home/Conways_Law.html
[Jeffries 2015] R. Jeffries, “Do we really need another method?”, 2015, http://ronjeffries.com/articles/2015-07-07-yet-another-method/
[L.A.F.A.B.L.E] M. Cohn, “Large Agile Framework for Big, Lumbering Enterprises”, 2014, http://www.lafable.com
[Marquet 2013] L. D. Marquet, “Turn the Ship Around! A true story of turning followers into leaders.”, Penguin, 2013
[Mayer 2013] T. Mayer, “The People´s Scrum, Agile Ideas for Revolutionary Transformation”, Dymaxicon, 2013
[Wohland and Wiemeyer 2007] G. Wohland, M. Wiemeyer, “Denkwerkzeuge der Höchstleister, Wie dynamikrobuste Unternehmen Marktdruck erzeugen”, Murmann Verlag, 2007
[Schwaber 2007] K. Schwaber, “The Enterprise and Scrum”, Microsoft Press, 2007