I recently said goodbye to one of my organization’s Agile Coaches and I felt that I needed to take a pause and reflect to consider my next move. The engagement had gone well, in fact one of the best we’ve had, but not without its share of successes and failures. But the successes had clearly outpaced any failures, and so there was a lot of good I wanted to build on.
The departing coach was part of a 3rd generation of Agile Coaches that I had worked with in the 3 years since we had begun our company’s transformation to Agile. And while he was a great coach, so were his predecessors and yet they had had fewer successes.
On reflection, what had really happened is that we had changed as a company; we had learned how to better execute our engagements with an Agile Coach.
Deciding to hire an Agile Coach can be a big step. A couple of things need to have happened, you’ve recognized that you need some help or at least another perspective. And given that Agile Coaches are typically not very cheap, you have decided to invest in your Agile transformation, however big or small. You’re clearly taking it seriously.
However, through my experiences I noticed that things can get a little tricky once that decision has been made. Many organizations can fall into a trap of externalizing transformation responsibilities to the Agile Coach.
In essence thinking along the lines of “as long as I hire a good coach, they should be able to make our teams Agile” can take you into an engagement model that is not very Agile in the first place.
Much like how Scrum and other Agile Practices connect customers with teams and establishes shared risk, an organization’s relationship with their Agile Coaches need to be a working partnership.
So it’s important for you to setup the right engagement approach to get value out of your Agile Coach and this goes beyond the hard costs of their services, but also the high cost of failure with not having the right coaching in the right areas.
Here are 5 positive patterns for coaching engagements that I’ve observed:
Usually it is management who will hire a coach, and they may do so to help one or more teams with their Agile adoption needs. So in this scenario who is the customer? Is it the person that hired the coach or the teams (the coachees) who will be receiving the services? In some cases, the coachees aren’t clear why the coach is there, they haven’t asked for their services and in some cases may even feel threatened by their presence.
For this reason, if management is hiring coaches you need to recognize that there is a 3-pronged relationship that needs to be clearly established and maintained.
With the customer in this case being someone in management, i.e. the person who hired the coach in the first place. The customer’s responsibility will be to not only identify the coachee but then work with the coach to establish and support that relationship.
Agile Coaches typically tend to be more effective when they have one or two specific mandates tied to an organization’s goals. Not only is the mandate important to establish why the coach is there, too many goals can significantly dilute the coach’s effectiveness. Put another way, Agile Coaches are not immune to exceeding their own Work in Progress limits.
The mandate establishes why the coach is there, and should be tied to some sort of organizational need. A good way of developing this is to articulate what is currently happening and the desired future state you want the coach to help with.
The teams on our new program are great at consistently delivering their features at the end of each sprint. However, we still experience significant delays merging and testing between teams in order for the program to ship a new release. We’d like to reduce that time significantly, hopefully by at least half.
Once the engagement is well underway you may find that the coach, through serendipity alone, is exposed to and gets involved with a wide variety of other areas. This is fine, but it’s best to just consider this to be a side show and not the main event. If other activities start to take on a life of their own, it’s probably a good time to go back to inspect and potentially adjust the mandate.
If you’re not sure how to establish or identify your Agile goals, this could be the first goal of any Agile coach you hire. In this scenario, the customer is also the coachee and the mandate is to get help establishing a mandate.
Agile coaches are not a homogeneous group, with many degrees of specialty, perspective and experiences. Resist the desire to find a jack-of-all-trades, you’re as likely to find them as a unicorn.
Your now established mandate will be your biggest guide to what kind of coach you should be looking for. Is the need tied to technical practices, process engineering, team collaboration, executive buy-in, transforming your culture, etc?
The other part is connected with the identified coachee. Are the coachees team members, middle management or someone with a “C” in at the start of their title? Will mentoring be required or are you just here to teach something specific?
Using something like ACI’s Agile Coaching Competency Framework, would be a good model to match the competencies required of the perspective coach.
In my example earlier, in order for your team to get help with their merging & testing needs, you may have to look for a coach with the right skills within the Technical Mastery competence. And if you have technical leaders who are championing the change, potentially the ability to Mentor.
With the coach, customer and mandate clearly identified, you now need to be ready to devote your time to regularly connect and work with the coach. Formalizing some sort of cadence is necessary, if you leave it to ad hoc meetings you will typically not meet regularly enough and usually after some sort of failure has occurred.
The objective of these feedback loops is to tie together the communication lines between the 3 prongs established: the customer, the coach and the coachees. They should be framed in terms of reviewing progress against the goals established with the mandate. If the coachees ran any experiments or made any changes that were intended to get closer to the goals, this would be the time to reflect on them. If the coachees need something from the customer, this would be a good forum to review that need.
Along with maintaining a cadence of communication, feedback loops if done regularly and consistently, could be used to replace deadlines, which in many cases are set simply a pressure mechanism to maintain urgency. So statements like “Merge & test time is to be reduced by half by Q2” now become “We need to reduce merge and test time by half and we will review our progress and adjust every 2 weeks.”
Resist the temptation to set the coach’s hours as a full-time embedded part of the organization or team. While you may want to have the coach spend a significant amount of time with you and your coachees when the engagement is starting, after this period you will likely get a lot more value from regular check-ins.
This could look like establishing some sort of rhythm with a coachee: reviewing challenges, then agreeing on changes and then coming back to review the results after sufficient time has passed.
This approach is more likely to keep the coach as a coach, and prevents the coach from becoming entangled in the delivery chain of the organization. The coach is there to help the coachees solve the problems, and not to become an active participant in their delivery.
Bringing in an Agile Coach is an excellent and likely necessary part of unlocking your Agile transformation. However, a successful engagement with a coach will have you more connected and active with your transformation, not less. So consider these 5 positive coaching engagement patterns as I consider them moving into my 4th generation of Agile coaches. I expect it will be a lot of work, along with a steady stream of great results.
After a recent large organizational change that resulted in a number of new teams formed, a product owner (PO) approached me looking for some help. He said, “I don’t think my new Scrum Master is doing their job and I’m now carrying the entire team, do we have a job description we can look at?”
I can already imagine how a version of me from a previous life would have responded, “yes of course let’s look at the job description and see where the SM is falling short of their roles and responsibilities”. But as I considered my response, my first thought was that focusing our attention on roles and job descriptions was a doomed route to failure. Pouring our energy there would likely just extend the pain the PO, and likely SM, were going through.
Sure we have an SM job description in our organization, and it clearly documents how the SM provides service to the organization, team and PO. But reviewing this with the seasoned SM didn’t really make sense to me; they were very well aware of the content of the job description and what was expected of them.
At the same time that this was happening, another newly paired Scrum Master asked for my help regarding their PO. From their perspective the PO was “suffocating” the team. The PO was directing the team in many aspects of the sprint that they felt was stepping beyond their role. “I don’t think the PO knows their role, maybe you can help me get them some training?” was the SMs concluding comment.
Over the course of the next few weeks this scenario played out again through more POs and SMs sharing similar challenges. Surely this was not a sudden epidemic of previously performing individuals who now needed to be reminded of what their job was?
A common pattern was emerging from all of this, change was occurring and each individual was relying on, and to some degree expecting, old patterns to continue to work with their new situation. Their old way of working in Scrum seemed to work very well; so it was everyone else around them that was not meeting expectations.
The core issue however was that change was not being fully confronted: the product was different, the team competencies were different, the stakeholders were different, the expectations were different and finally the team dynamic was different all the way down to the relationship between the SM and PO.
I looked for the solution from Scrum itself, at its heart a method for teams to use to adapt to and thrive with change. Was there enough transparency, inspection and adaptation going on between the SMs and POs in these situations? I would argue, not enough.
A pattern was becoming clear: nobody was fully disclosing their challenges to the other, they hadn’t fully confronted and understood their new situation and hadn’t come up with new approaches that would improve things. Said another way, they hadn’t inspected their new circumstances sufficiently and transparently enough so that they could adapt their role to fit the new need.
One thing that many successful SMs and POs recognize is that they are both leaders dependent on each other, and for their teams to be successful they need to figure out how they will work together in partnership. It doesn’t matter whether the terms of that partnership gets hashed out over a few chats over coffee or through a facilitated chartering workshop. What matters is clarity around how you agree to work together as partners meeting some shared goal.
As an SM or PO, here are some sample questions whose answers you may wish to understand and align on:
So if you are an SM or PO, and it’s unclear to you on the answers to some of these questions, you may just want to tap your leadership partner on the shoulder and say “let’s talk”.
The other day a technology leader was asking questions as if he didn’t agree that things like pair programming and code review should be part of the Definition of “Done” because they are activities that don’t show up in a tangible way in the end product. But if these things are part of your quality standards, they should be included in the definition of “Done” because they inform the “right way” of getting things done. In other words, the Definition of “Done” is not merely a description of the “Done” state but also the way(s) of getting to “Done” – the “how” in terms of quality standards. In fact, if you look at most of any team’s definition of “Done”, a lot of it is QA activity, carried out either as a practice or as an operation that is automated. Every agile engineering practice is essentially a quality standard and as they become part of a team’s practice, should be included as part of the definition of “Done”. The leader’s question was “if we’re done and we didn’t do pair programming and pair programming is part of our definition of “Done”, then does that mean we’re not done?” Which is sort of a backwards question because if you are saying you’re done and you haven’t done pair programming, then by definition pair programming isn’t part of your definition of done. But there are teams out there who would never imagine themselves to be done without pair programming because pair programming is a standard that they see as being essential to delivering quality product.
Everything that a Scrum Development Team does to ensure quality should be part of their definition of “Done”. The definition of “Done” isn’t just a description of the final “Done” state of an increment of product. In fact, If that were true, then we should be asking why anything is part of the definition of “Done”. This is the whole problem that this artifact solves. If this were the case, the team could just say that they are done whenever they say they are done and never actually identify better ways of getting to done and establishing better standards. We could just say (and we did and still do), “there’s the software, it’s done,” the software itself being its own definition of “Done”.
On the contrary the definition of “Done” is what it means for something to be done properly. In other words, it is the artifact that captures the “better ways of developing software” that the team has uncovered and established as practice because their practices reflect their belief that “Continuous attention to technical excellence and good design enhances agility” (Manifesto for Agile Software Development). The definition of “Done” is essentially about integrity—what is done every Sprint in order to be Agile and get things done better. When we say that testing is part of our definition of “Done”, that is our way of saying that as a team we have a shared understanding that it is better to test something before we say that it is done than to say that it’s done without testing it because without testing it we are not confident that it is done to our standards of quality. Otherwise, we would be content in just writing a bunch of code, seeing that it “works” on a workstation or in the development environment and pushing it into production as a “Done” feature with a high chance that there are a bunch of bugs or that it may even break the build.
This is similar to saying a building is “Done” without an inspection (activity/practice) that it meets certain safety standards or for a surgeon to say that he or she has done a good enough job of performing a surgical operation without monitoring the vital signs of the patient (partly automated, partly a human activity). Of course, this is false. The same logic holds true when we add other activities (automated or otherwise) that reflect more stringent quality standards around our products. The definition of “Done”,therefore, is partly made up of a set of activities that make up the standard quality practices of a team.
Professions have standards. For example, it is a standard practice for a surgeon to wash his or her hands between performing surgical operations. At one time it wasn’t. Much like TDD or pair programming, it was discovered as a better way to get a job done. In this day and age, we would not say that a surgeon had done a good job if he or she failed to carry out this standard practice. It would be considered preposterous for someone to say that they don’t care whether or not surgeons wash their hands between operations as long as the results are good. If a dying patient said to a surgeon, “don’t waste time washing your hands just cut me open and get right to it,” of course this would be dismissed as an untenable request. Regardless of whether or not the results of the surgery were satisfactory to the patient, we would consider it preposterous that a surgeon would not wash his or her hands because we know that this is statistically extremely risky, even criminal behaviour. We just know better. Hand washing was discovered, recognized as a better way of working, formalized as a standard and is now understood by even the least knowledgable members of society as an obvious part of the definition of “Done” of surgery. Similarly, there are some teams that would not push anything to production without TDD and automated tests. This is a quality standard and is therefore part of their definition of “Done”, because they understand that manual testing alone is extremely risky. And then there are some teams with standards that would make it unthinkable for them to push a feature that has not been developed with pair programming. For these teams, pair programming is a quality standard practice and therefore part of their definition of “Done”.
“As Scrum Teams mature,” reads the Scrum Guide, “it is expected that their definitions of “Done” will expand to include more stringent criteria for higher quality.” What else is pair programming, or any other agile engineering practice, if it is not a part of a team’s criteria for higher quality? Is pair programming not a more stringent criteria than, say, traditional code review? Therefore, any standard, be it a practice or an automated operation, that exists as part of the criteria for higher quality should be included as part of the definition of “Done”. If it’s not part of what it means for an increment of product to be “Done”—that is “done right”—then why are you doing it?
From the full article “5 Things Agile Leaders Must Do“:
Consider enrolling in our Scrum and Enterprise Agile for Executives ½ day seminar in Toronto.
The Real Agility Program is an Enterprise Agile change program to help organizations develop high-performance teams, deliver amazing products, dramatically improve time to market and quality, and create work environments that are awesome for employees.
This article is a written summary of the Executive Briefing presentation available upon request from the Real Agility Program web site. If you obtain the executive briefing, you can follow along with the article below and use it to present Real Agility to your enterprise stakeholders.
At Berteig Consulting we have been working for 10 years to learn how to help organizations transform people, process and culture. The problem is simple to state: there is a huge amount of opportunity waste and process waste in most normal enterprise-scale organizations. If you have more than a couple hundred people in your organization, this almost certainly affects you.
We like to call this problem “the Bureaucratic Beast”. The Bureaucratic Beast is a self-serving monster that seems to grow and grow and grow. As it grows, this Beast makes it progressively more difficult for business leaders to innovate, respond to changes in the market, satisfy existing customers, and retain great employees.
Real Agility, a system to tame the Bureaucratic Beast, comes from our experience working with numerous enterprise Agile adoptions. This experience, in turn, rests on the shoulders of giants like John Kotter (“Leading Change”), Edgar Schein (“The Corporate Culture Survival Guide”), Jim Collins (“Good to Great” and “Built to Last”), Mary Poppendieck (“Lean Software Development”) Jon Katzenbach (“The Wisdom of Teams”) and Frederick Brooks (“The Mythical Man-Month”). Real Agility is designed to tame all the behaviours of the Bureaucratic Beast: inefficiency, dis-engaged staff, poor quality and slow time-to-market.
Studies have proven that Agile methods work in IT. In 2012, the Standish Group observed that 42% of Agile projects succeed vs. just 14% of projects done with traditional “Bureaucratic Beast” methods. Agile and associated techniques aren’t just for IT. There is growing use of these same techniques in non-technoogy environments such as marketing, operations, sales, education, healthcare, and even heavy industry like mining.
Real Agility Basics: Agile + Lean
Real Agility is a combination of Agile and Lean; both systems used harmoniously throughout an enterprise. Real Agility affects delivery processes by taking long-term goals and dividing them into short cycles of work that deliver valuable results rapidly while providing fast feedback on scope, quality and most importantly value. Real Agility affects management processes by finding and eliminating wasteful activities with a system view. And Real Agility affects human resources (people!) by creating “Delivery Teams” which have clear goals, are composed of multi-skilled people who self-organize, and are stable in membership over long periods of time.
There are lots of radical differences between Real Agility and traditional management (that led to the Bureaucratic Beast in the first place). Real Agility prioritizes work by value instead of critical path, encourages self-organizing instead of command-and-control management, a team focus instead of project focus, evolving requirements instead of frozen requirements, skills-based interactions instead of roles-based interaction, continuous learning instead of crisis management, and many others.
Real Agility is built on a rich Agile and Lean ecosystem of values, principles and tools. Examples include the Agile Manifesto, the “Stop the Line” practice, various retrospective techniques, methods and frameworks such as Scrum and OpenAgile, and various thinking tools compatible with the Agile – Lean ecosystem such as those developed by Edward de Bono (“Lateral Thinking”) and Genrich Altshuller (“TRIZ”).
Real Agility acknowledges that there are various approaches to Agile adoption at the enterprise level: Ad Hoc (not usually successful – Nortel tried this), Grassroots (e.g. Yahoo!), Pragmatic (SAFe and DAD fall into this category), Transformative (the best balance of speed of change and risk reduction – this is where the Real Agility Program falls), and Big-Bang (only used in situations of true desperation).
Why Choose Transformative?
One way to think about these five approaches to Agile adoption is to compare the magnitude of actual business results. This is certainly the all-important bottom line. But most businesses also consider risk (or certainty of results). Ad-Hoc approaches to Agile adoption have poor business results and a very high level of risk. Big-Bang approaches (changing a whole enterprise to Agile literally over night) often have truly stunning business results, but are also extremely high risk. Grassroots, where leaders give staff a great deal of choice about how and when to adopt Agile, is a bit better in that the risk is lower, but the business results often take quite a while to manifest themselves. Pragmatic approaches tend to be very low risk because they often accommodate the Bureaucratic Beast, but that also limits their business results to merely “good” and not great. Transformative approaches which systematically address organizational culture are just a bit riskier than Pragmatic approaches, but the business results are generally outstanding.
More specifically, Pragmatic approaches such as SAFe (Scaled Agile Framework) are popular because they are designed to fit in with existing middle management structures (where the Bureaucratic Beast is most often found). As a result, there is slow incremental change that typically has to be driven top-down from leadership. Initial results are good, but modest. And the long term? These techniques haven’t been around long enough to know, but in theory it will take a long time to get to full organizational Agility. Bottom line is that Pragmatic approaches are low risk but the results are modest.
Transformative approaches such as the Real Agility Program (there are others too) are less popular because there is significantly more disruption: the Bureaucratic Beast has to be completely tamed to serve a new master: business leadership! Transformative approaches require top-to-bottom organizational and structural change. They include a change in power relationships to allow for grassroots-driven change that is empowered by servant leaders. Transformative approaches are moderate in some ways: they are systematic and they don’t require all change to be done overnight. Nevertheless, often great business results are obtained relatively quickly. There is a moderate risk that the change won’t deliver the great results, but that moderate risk is usually worth taking.
Regardless of adoption strategy (Transformative or otherwise) there are a few critical success factors. Truthfulness is the foundation because without it, it is impossible to see the whole picture including organizational culture. And love is the strongest driver of change because cultural and behavioural change requires emotional commitment on the part of everyone.
Culture change is often challenging. There are unexpected problems. Two steps forward are often followed by one step back. Some roadblocks to culture change will be surprisingly persistent. Leaders need patience and persistence… and a systematic change program.
The Real Agility Program
The Real Agility Program has four tracks or lines of action (links take you to the Real Agility Program web site):
Structurally an enterprise using Real Agility is organized into Delivery Groups. A Delivery Group is composed of one or more Delivery Teams (up to 150 people) who work together to produce business results. Key roles include a Business leader, a People leader and a Technology leader all of whom become Real Agility Coaches and take the place of traditional functional management. As well, coordination across multiple Delivery Teams within a Delivery Group is done using an organized list of “Value Drivers” maintained by the Business leader and a supporting Business Leadership Group. Cross-team support is handled by a People and Technology Support Group co-led by the People and Technology leaders. Depending on need there may also be a number of communities of practice for Delivery Team members to help spread learning.
At an organizational or enterprise level, the Leadership Team includes top executives from business, finance, technology, HR, operations and any other critical parts of the organization. This Leadership Team communicates the importance of the changes that the Delivery Groups are going through. They lead by example using techniques from Real Agility to execute organizational changes. And, of course, they manage the accountability of the various Delivery Groups throughout the enterprise.
The results of using the Real Agility Program are usually exceptional. Typical results include:
Of course, these results depend on baseline measures and that key risk factors are properly managed by the Leadership Team.
Not every organization needs (or is ready for) the Real Agility Program. Your organization is likely a good candidate if three or more of the following problems are true for your organization:
Consider that list carefully and if you feel like you have enough of the above problems, please contact us at firstname.lastname@example.org. or read more about the Real Agility Program for Enterprise Agility on the website.
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?
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:
TEAM CREATION EVENT AGENDA
Have you experienced an event like this? Did it work? What was different from what I described?
This looks like a great conference – to be held on Thursday, April 23rd, 2015. From the description:
An event for the whole organization, Spark brings together leaders from across the business to explore how they can work together to create lasting and total change. Talks and workshops offer inspiring examples and practical advice on taking action and overcoming obstacles. – See more at: http://2015.sparkthechange.ca/what-is-spark-2/#sthash.WI3bDFBA.dpuf
Leaders of Agile Transformations for the Enterprise need to have good sources of information, concepts and techniques that will guide and assist them. This short list of twelve books (yes, books) is what I consider critical reading for any executive, leader or enterprise change agent. Of course, there are many books that might also belong on this list, so if you have suggestions, please make them in the comments.
I want to be clear about the focus of this list: it is for leaders that need to do a deep and complete change of culture throughout their entire organization. It is not a list for people who want to do Agile pilot projects and maybe eventually lots of people will use Agile. It is about urgency and need, and about a recognition that Agile is better than not-Agile. If you aren’t in that situation, this is not the book list for you.
These books all help you to understand and work with the deeper aspects of corporate behaviour which are rooted in culture. Becoming aware of culture and learning to work with it is probably the most difficult part of any deep transformation in an organization.
This set of books gets a bit more specific: it is the “how” of managing and leading in high-change environments. These books all touch on culture in various ways, and build on the ideas in the books about culture. For leaders of an organization, there are dozens of critical, specific, management concepts that often challenge deeply held beliefs and behaviours about the role of management.
Agile at Scale
These books discuss how to get large numbers of people working together effectively. They also start to get a bit technical and definitely assume that you are working in technology or IT. However, they are focused on management, organization and process rather than the technical details of software development. I highly recommend these books even if you have a non-technical background. There will be parts where it may be a bit more difficult to follow along with some examples, but the core concepts will be easily translated into almost any type of work that requires problem-solving and creativity.
These books (including some free online books) are related to some of the key supporting ideas that are part of any good enterprise Agile transformation.
The Scrum Guide – Ken Schwaber, Jeff Sutherland, et. al.
The OpenAgile Primer – Mishkin Berteig, et. al.
Priming Kanban – Jesper Boeg
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:
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:
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.
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.
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!
I was observing a workshop last week that had been put together to create greater cohesiveness in a large organizational team who needed to create a unified vision about their department.
Initially they were broken up into smaller groups to discuss some of the ideas, issues, and challenges they had encountered. It was obvious how stressed everyone was. People were speaking animatedly with louder than usual volume, there was a great deal of tension, and everyone seemed agitated and uneasy.
Then came the LEGO. Mountains of it. Not just some mismatched pieces either. The kind of LEGO that would have made any child squeal with joy.
Each person was asked to create a model of what they thought their department was like at that moment, using the LEGO. Then another model of what they each envisioned their department could be. They were then asked to combine the ones they thought were best into a grand model for the department.
I immediately recognized this approach of play therapy used in child psychology, and I was curious to see how it would translate to adults in the workplace.
The effects were wonderful. The room that was once filled with heated arguments and loads of stress, had transformed into complete calm. Everyone was so engaged with building their models, they were quiet and relaxed, and whenever there were bursts of noise it was joyful laughter.
Then came the moment of truth, they had to present the large departmental model that they had all collaborated and contributed to making.
They spoke of their vision clearly without argument or dissent. They shared the space freely encouraging others to speak on parts of the model they didn’t know in detail. And when they finished their presentation, there was a long pause of silence where everyone was looking at the model, and in each person’s eyes, I saw pride for what they had accomplished together, and a deep sense of hope for the future where it was absent before.
I guess those colourful blocks really do have some magic in them.
In a recent post, Mishkin outlined the Leadership Team component of the Real Agility Program. While the Leadership Team track focuses on developing leadership capacity for sustained transformation, The Execution track focuses on launching and developing high-performance project, product and operational teams. This track is the one that most of our clients use when they run Agile pilot programs and is a critical component of getting quick wins for the organization.
Groundbreaking works such as The Wisdom of Teams (Katzenbach & Smith), The Five Dysfunctions of a Team (Lencioni) and Drive (Pink) have served well to distill the essential requirements of high-performance teams. Scrum, Kanban, and OpenAgile are proven frameworks that optimize the value of teams and create the necessary working agreements to help teams reach that high-performance state.
The Delivery Team track of the Real Agility Program creates new, cross-functional, multi-skilled, staff-level teams of willing individuals. These teams are responsible for delivering value—business results and quality. Individuals are committed to the performance of the team and the organization. Teams develop the capacity to self-organize and focus on continuous improvement and learning. A team is usually composed of people from various roles at the delivery level. For example, and IT project team might be composed of people whose previous* roles were:
* These roles do not get carried into the new delivery team other than as a set of skills.
The track begins with establishing pre-conditions for success including executive sponsorship, availability of team members and management support. Team launch involves a series of on-the-job team development workshops designed to enable the teams to create their own set of values, working agreements and high-performance goals. Teams are guided in the creation of their initial work backlogs, defining “done”, estimation and planning and self-awareness through the use of a collaborative skills matrix. The teams are also assisted in setting up collocated team rooms and other tools to optimize communication and productivity.
Qualified coaches assist the teams to overcome common issues such as personal commitment, initial discomfort with physical colocation, communication challenges of working with new people in a new way, management interference and disruptions and appropriate allocation of authority. This assistance is delivered on a regular schedule as the team progresses through a series of steps in the Execution track process. Usually, these steps take one or two weeks each, but sometimes they take longer. A team that needs to get to a high-performance state quickly might go through the entire program in 10 or 12 weeks. In an organization where there is not the same urgency, it can take up to a year to get through the steps of the track.
The coaches for this Execution track also help management to resist and overcome the strong urge to manage the problems of the teams for them. In order to develop through the stages of team development, teams need to be effectively guided and encouraged to solve their own problems and chart their own courses towards high-performance.
The goal of the Execution track of the Real Agility Program is to help the team go through the stages of forming-storming-norming and set them up to succeed in becoming a high-performance team. Of course, to do this requires some investment of time. Although the Execution track is meant to be done as on-the-job coaching, there is a 5% to 20% level of overhead related to the Real Agility Program materials themselves.
See also the article on the Recommendations component of the Real Agility Program.
One of the main components of our Real Agility Program for enterprise Agile transformations is the Leadership Development track. This track is a series of monthly leadership meetings with one of our consultants to help them establish their Leadership Transformation Team. This team is based in part on the concept of a guiding coalition from John Kotter’s work (see “Leading Change“), and in part on Edgar Schein’s work on corporate culture (see “The Corporate Culture Survival Guide“) as well as our own specific experience on successful Agile transformations in organizations.
The very first thing, of course, is to establish who should be on the Leadership Transformation Team. There are six major categories from which the team must find representatives:
In total, the number of people on this team should be no more than 12, but smaller is better.
Once established, this Leadership Transformation Team must execute on three core responsibilities in perpetuity:
This leadership support is a critical success factor for an Agile Transformation. One of the first steps in our program for this team is to help with the creation of the team’s plan for the transformation. This plan can be derived from an number of sources including assessment work, but includes a number of standard items that must eventually be addressed for a successful transformation. At a high level, these include:
Many of these items are multi-year change efforts that need to be closely guided and encouraged by the Leadership Transformation Team.
One final point about the Leadership Transformation Team needs to be made: the work they do must not be delegated to subordinates. If something is part of their three core responsibilities, it must be handled directly by the members of this team. Therefore, the team members need to allocate a significant percentage of their time to the effort. Usually 20% is sufficient to get started. The proportion may wax and wane slightly over time, but if it gets too low, the Leadership Transformation Team will lose touch with the transformation and the risk of it going bad increases substantially.
See also our article about the Recommendations component of the Real Agility Program.
From push system to pull system thinking
One of the disconnects holding teams back the most in an organization embarking on an Agile transformation is the lack of will and perhaps understanding of vision on the part of the business. The required shift in thinking is from a “push system” to a “pull system”. Historically and still culturally, most organizations, even those claiming to be ‘Agile’ are very much push systems. The business folks in client services – VPs, Directors, sales people, etc. seem to make time (deadline) commitments to clients on behalf of teams and then the teams are given the deadlines to finish the work. Sometimes, the deadlines are decided on in consultation with particular individuals on the teams and very rarely, if ever, with the actual teams themselves. In any case, the fact that the business is almost entirely deadline-driven is the centre of the push system. Deadlines push or drive everything else. Deadlines are fixed and often considered non-negotiable. Deadlines are a taboo subject – it is considered a waste of time to even discuss them because they just don’t and won’t ever move. The general attitude is that if we try to move deadlines, we put the entire business at risk because our clients will drop us and turn to one of our competitors who claim to be able to promise and keep deadlines. If we lose our clients, we lose business, we lose money and it potentially puts us all out of jobs. What this exposes is not only a push system driven by deadlines, but a culture that is actually driven by fear. The not-so-implicit message is that if you miss a deadline, you might lose your job, so you had better do whatever it takes to not miss the deadline. Or else. Push and pull systems and mentalities are like oil and water – they don’t mix. In Agile, there is no place for fear of failure. Rather, teams must be allowed to fail (miss deadlines) and learn from their failures (plan better).
Why quality, not time/cost or scope is non-negotiable
The “make the deadline or else message” is couched and clouded by other talk. The main excuse is to blame the client, as noted above. “That’s just the way our clients work, the way the market works”. Of course, such an excuse contains a kernel of truth. Without a true understanding and embrace of Agile, the idea of not meeting deadlines and the perceived consequences can be truly scary. Generally, there is an understanding from the business that the productivity of teams may drop somewhat as they progress through the storming stage. What this translates into is a difficult discussion with clients around delayed delivery. It is tolerable in that it is temporary. “Once the teams get up and running, we can go back to meeting our deadlines, and even be able to deliver early because Agile is supposed to be faster.” But the benefits of truly adopting Agile are much more powerful than this.
Understanding the true business value of Agile
What needs to be understood is the true business value for investing in Agile processes and practices – how it may add cost and time to the initial development Cycle, but how it saves both the business and the client tremendously on technical debt and support long-term. This needs to be understood and championed by the business in order for the organization to become liberated from its enslavement to the push system mentality. At the heart of such a mental liberation is the wholehearted adoption and commitment to the Agile/Lean principle that quality is non-negotiable. The investment in Agile processes and practices is essentially an investment not only in quality, but in continuous quality improvements towards the goal of being able to frequently deliver products of increasing relevance and quality (value). The ability to ship frequently allows for sustainable growth. All of this is made impossible by the deadline-driven push system mentality/culture of fear.
The urgent need for slack
One of the first things that a team needs in order to focus on continuous quality improvements is slack so that it can learn to learn. The first goal of the business leadership should be to facilitate scope and deadline slack for the team. This goal should also be fully and visibly championed by the business leadership. In order to develop the capability to facilitate slack, the business needs to gain knowledge around the purpose and importance of Agile processes and practices and be able to articulate a strong business case for them. The business leadership needs to develop the skill of educating the team, management and business leadership on the long-term benefits of an Agile transformation – the transformation from a push system to a pull system. The key stakeholders and business leaderships need to possess the courage to engage in difficult conversations with management and clients who may be upset by the short-term pain of delays and missed deadlines and protect the team from continued attempts to push work into the team. Perhaps above all, the business leadership needs to develop an attitude of learning – a humble learning posture that allows for the setting aside of preconceived notions, fears and prejudices around what it means to be a good business leader. A leader possessed of this posture demonstrates a learning attitude by stressing first and foremost the importance of creating slack for the team to learn to learn. It is a common pitfall for inexperienced business leaderships and stakeholders to expect Agile to provide solutions for their push system woes, woes that include the broken trust of clients from consistently broken (unrealistic, dreamt-up) deadline promises and the crippling effects of technical debt (the fallout of the former – when scope, time and cost are fixed, quality is compromised).
If the business leadership, with the support of the Process Facilitators and the Transformation Team, is able to foster the organizational will to create slack for the teams, then the teams will have the space they need to truly focus on continuous quality improvements. This is a critical milestone on the path to realizing the true, measurable benefits of Agile. Although the support of others is needed, the business leadership is in a unique position benefitting from an intimate relationship with both the needs of the business as well as the daily life of the team.
Why the business leadership needs to own the process
The first way that the business leadership creates slack for the teams is by championing the process. In OpenAgile, like all other Agile methodologies, there are key features of the process the purpose of which are to give space for new teams to begin to make the often seemingly inconsequential, yet ultimately critical first steps towards continuous quality improvements. One of the most obvious of these features is the Agile team meetings. In the early stages of team development, organizational understanding and will, the OpenAgile meetings (particularly the Reflection and Learning aspects of the Engagement Meetings in OpenAgile) can easily be discounted as an obstacle preventing the team from getting the “real work” done. What is often forgotten under the pressure of deadlines is the fact that in order for a team to be able to learn to make continuous quality improvements, it needs to develop the capability of systematic (frequent & regular) inspection and adaptation of the way that it works. It is easy to save on the short term pain of perceived non-negotiable deadlines (meeting deadlines at all cost = success) by compromising on investing in the process, especially when the team is still learning to learn and the effectiveness of the meetings is not yet apparent. When the team and the organization have an expectation of Agile as something that fits into the push system and allows for a team to function better within such a system, it can be hard to understand how spending time in a kind of meeting that the team doesn’t seem good at yet can be of any value. This is where the business leadership needs to stand firmly behind the process. The team needs the meetings – the space to reflect, learn and plan – in order to learn to become more effective at making continuous quality improvements – a critical feature of an effective pull system. Without the meetings, the team will never develop this critical capability and as a result, will never become an Agile team. Instead, the team will revert back to getting the “real work” done with all of the quality problems crippling the organization and which led to the decision to adopt an Agile framework in the first place.
Why the business leadership should care about burn-down
Another key feature of the process for the business leadership to understand and champion is the concept of burn-down as represented by the burn-down chart of an Agile team. Agile doesn’t care about how much work the team gets done. It assumes that the team is doing valuable work and getting things done – in other words, that the team is managing itself and working towards its goals and commitments. There are no tools in Agile for an individual, least of all the business leadership, to measure and manage how much work the team is getting done. Agile acknowledges the reality that real (sustainable) productivity cannot be forced on any team. Instead, a team grows its productivity at a sustainable pace when it is given enough slack to do so. The team makes a plan at the beginning of the Cycle based on what it understands about its capacity, works towards that goal throughout the Cycle and hopefully delivers valuable results at the end of the Cycle. By learning to apply the process of continuous improvement, quality and productivity go up hand in hand. That is the essence of the pull model. Through all of this, the team manages “how” it gets work done. The productivity of a team can be measured, but the burn-down chart is neither an appropriate nor effective tool for measuring the productivity of a team. Instead, burn-down provides one specific measurement and ONLY this one measurement: WORK REMAINING (in order to achieve the goal/commitment of the current Cycle). It does not and cannot tell you how much the team got done and even less so the whys and hows of the output and productivity of the team during the Cycle.
So what is the purpose of burn-down and why should the business leadership even care? If it can’t be used as a tool to measure the productivity of the team (in other words, if it can’t be used to manage the team) then what importance can it possibly have? These are typical questions of teams and individuals that are coming from a traditional project management, i.e. command & control, i.e. “push” system mentality. Understanding the purpose of burn-down depends on the ability to make the shift from the push system paradigm to the pull system paradigm. In a push system, burn-down is nice but somewhat irrelevant. For an organization committed to an Agile transformation (towards a pull system of self-managed teams) it is an invaluable launch pad for powerful conversations that live at the heart of continuous quality improvements.
Commitment to the business requirements come from the Agile teams
When a team decides on a plan for a Cycle of work, the plan is a commitment. This is a critical step in the Agile process. It is only after a unanimous commitment from the whole team that the team begins to work on the plan. If any individual team member feels hesitant about the work in the plan, tasks and potentially even Value Drivers should be removed until everyone is comfortable making a commitment. When the business leadership is telling a team what the plan is, then it is not the team’s plan and therefore it cannot be a team commitment. This is not only an inappropriate use of authority, it is also breaking the Agile process. Moreover, when a plan and therefore a commitment is forced onto a team, the team cannot be held accountable for failure. Worse yet, the team will never learn to plan. If a team is not able to plan, then it is not able to make commitments. If the team is overwhelmed by an overly-ambitious, management-forced plan, it will not learn to evaluate its capacity and apply that knowledge to long-term planning and project estimates. It will not learn to make meaningful quality improvements and reflect on its progress. It will not learn to self-manage or self-organize. The purpose of burn-down is to establish commitment velocity. In other words, the amount of work that the team can truthfully expect to complete during the Cycle when it is making the Plan. The difference between the number of tasks in the Cycle Plan and the number of tasks remaining at the end of the Cycle gives the team its commitment velocity. Commitment velocity is always based on minimum historical velocity. The team uses commitment velocity to make a Cycle Plan containing no more than the number of tasks represented by its commitment velocity. This allows the team to spend just the right amount of effort and time on planning and allows the team slack to focus on the truly Agile work of learning and continuous quality and process improvements. Over-planning, especially when it is wedded to over-committing or even worse, non-committing (a common push system mentality pitfall forced onto teams by the business leadership) leaves the team in a state of dependent on daily micro-management and can completely halt the progress of a team. Not to mention that this is a flagrant violation of Agile values (truthfulness, responding to change over following a plan) and principles (sustainable development). Such compromises to foundational Agile values, principles and processes may produce desired results in the very short-term, but the long-term costs can be crippling to teams and organizations. The wasteful activity associated with team dependency on micro-management is what often leads organizations to the accumulation of technical debt that places them in dire competitive disadvantage and desperate need for Agile transformation in the first place. If an organization misses out on this golden opportunity, teams can become demoralized and innocuous to the Agile practices and the promise of an Agile transformation can quickly erode.
Michael Badali, a good friend of mine, has asked a great question on LinkedIn: What is your Backlog for Agile Transformation?. From his question:
While I think that Band-Aid off quick is more likely to be successful than Band-Aid off slow, often Agile Coaches & Leaders are put in the position of Kaizen instead of Kaikaku. When asked for a detailed waterfall plan and schedule on how to become Agile… I generally refuse and create an Agile Transformation Backlog – a prioritized list of things that need to be done to become Agile. Please share your prioritized list of things that need to be done to be Agile.