On this page, we will provide answers to your questions as well as helpful Agile Coaching tips, based on our experience.

​The list of the first 10 topics includes:

1. Plan your Agile transformation as an organizational change management effort
2. Getting executive buy in
3. Getting teams excited
4. Scale your Agile implementation
5. Lean mindset and 2-second lean approach
6. Roles and Responsibilities in Scrum
7. Moving to cross-functional team structure
8. Define portfolio management and prioritization in Agile
9. Acceptance Test Driven Delivery and technical excellence
​10. Celebrating Successes

You know what the number 1 reason for failed Agile transformations is? It is not the skillset of Agile Coaches and Agile teams' members, it is not the budget or executive support. The most frequent reason for failed Agile transformations is inability to manage organizational change. If we as coaches do not approach Agile rollout strategically, if we do not view it as a change management activity, we do not leave ourselves any chance to succeed.

What does it mean? When we come to an organization to roll out Agile, we start with multiple activities. We create template, produce playbooks, organize training sessions, work with the delivery teams, refine backlogs, create roadmaps, implement technical practices, and get outseves busy with important activities that help those organizations succeed. Six months or a year after, we find out that senior executives do not perceive our transformation as success, that there are concern from a product organization, from former PMO, from engineering managers, sales, marketing, and a whole ton of passive observers throughout the company. Are they blind? we wonder. Don't they see how high performing our teams are? how frequently they deliver? how innovative our new products are? have they missed our last demo? failed to stop by our hackaton and open space? what is happening. And before we know it, status quo is slowly restored, our Agile teams are lost because they cannot imagine themselves working the way they did before, and the whole effort is now in jeopardy.

How do we avoid this situation? Very simply. Rather than starting with multiple activities, we need to be strategic in how we orchestrate the transformation and make the change happen. By saying "strategic", I mean "relating to the identification of long-term or overall aims and interests and the means of achieving them." In creating my strategic vision of Agile transformation, I use two theories, traditional coaching and multiple organizational change approaches. Below are things you have to consider when implementing Agile transformation.

1. Close 3 gaps
In his book "The 3 Gaps: Are you Making a Difference", Hyrum W. Smith describes 3 gaps. Closing these gaps "enables people to live a better, more fulfilling life and have a positive impact on everyone around them." I applied those gaps to the organization change and specifically, Agile rollout, and have been using them as pre-requisites for the Agile transformations that I lead:
 - The Beliefs Gap - the difference between what we assume is correct and what is in fact true. For example, if we as an organization believe that product and process are independent, this is a fundamental gaps that we need to close, otherwise we won't be able to co-create beautiful products across the organization.
- The Values Gap - the difference between our long-term objectives and where we actually spend our effort. As an organization, we need to be clear on our values and long-term objectives. Do we want to create a product that will be available to anyone at a low cost? do we want to make the use of it super easy and intuitive? or are we targeting a small market niche with something sophisticated and new? Based on our values as an organizations and the objectives we set up (many organizations nowadays use OKRs ​ - objectives and key results to build and align those cascading goals throughout organization. For example, if we want to create a very basic minimum viable product (MVP) and make it readily available at a low cost, we would make our decisions differently from being able to create a sophisticated product providing elaborate functionality to a small market niche.
- The Time Gap - this is the gap between the values we have set up and where we are actually investing our time. Investing our time in the values we discovered is closing the time gap. It involves expectation setting at all levels and being very honest about where our time as coaches and transformation leaders is being invested. It requires courage and transparency, but also flexibility and emotional intelligence in dealing with unforeseen priority changes and unexpected circumstances.

2. Agree on organization-specific non-negotiables
Once we closed three gaps, we need to all agree on fundamentals, or Agile non-negotiables. These non-negotiables are different for different organizations and depend on scope, organization type, objectives, and level of openness to change, but they need to be stated, discussed and agreed upon. Some examples from various organizations include:
- budget constraints;
- retaining existing employees;
- continued support of legacy products;
- real-time dashboard for executives;
- complete visibility into deliverables and the budget for senior management.

3. Create emotional support of the change
An important aspect to remember is widely discussed in an organizational change bestseller, The Happiness Hypothesis. 

The author, University of Virginia psychologist Jonathan Haidt, compares our emotional side with an Elephant and our rational side is with a Rider. Perched atop the Elephant, the Rider holds the reins and seems to be the leader. But the Rider’s control is precarious because the Rider is so small relative to the Elephant. Anytime the six-ton Elephant and the Rider disagree about which direction to go, the Rider is going to lose. Similarly, the desire for the organization to change has to be emotional as much if not even more than it is rational. Prior to your Agile rollout, create presentations, set up Lunch and Learn sessions, talk one-on-one with division leaders and executives, start running our transformation team in kanban on scrumban mode and place your information radiators in a highly visible place in the office. Ensure that people understand reasons for change, that they see their pain points and are aware of benefits of Agile. Create organizational-level support before you start any activities, and 50% of success is accomplished. In their outstanding book "Switch", brothers Heath speak about building the emotional case for change as a pre-requisite for the change success.

This approach is relevant to every steps of the way, from hiring Agile Coaches (pay attention to empathy as much as their knowledge of Agile and Lean practices) to coming up with prescriptive requirements which take best practices into consideration but do not leave teams enough space to innovate and to grow.

4. 15 Rules of Agile transformation 

As in any organization, John Kotter's 8-step process for leading change is highly applicable to Agile transformation. The 8 steps of leading change listed by Dr. Kotter include: generating a sense of urgency, establishing a powerful guiding coalition, developing a vision, communicating the vision clearly and often, removing obstacles, planning for and creating short-term wins, avoiding premature declarations of victory, and embedding changes in the corporate culture.

Dr. Kotter's books are powerful and the examples given there are thought provoking. All of these steps equally apply to Agile transformation and have to be addressed before playbooks are being created and competency-based organization is being re-organized in product-based delivery teams with business stakeholders aligned to a specific team or multiple teams.

Based on these criteria and my own experience leading multiple Agile transformation, I formulated the following Rules for Agile transformation success:
- Create case for change.
- Build coalitions.
- Be inclusive. See yourself as part of a team.
- State goals and expected measurable results before introducing change.
- Co-create new reality.
- You can never overcommunicate.
- Build it, and they will come.
- Be genuine, transparent and positive.
- Question the status quo. Innovate and  experiment.
- Be assertive and courageous but not controlling.
- Serve but don't follow.
- Lead without authority.
- Walk the talk.
- Celebrate success (but not too early).
- Iterate. Never stop!

In the next posting, we will review these rules one by one and suggest some specific actions and artifacts to implement them.

In the previous posting, we introduced 15 rules of the Agile transformation change management. We also mentioned that each of those rules needs to be implemented before you move to the practical aspects of Agile implementation: selecting and introducing the framework, creating practices, processes, identifying tools, and forming Agile teams.

These topics are written from Agile coaching perspective, but each of them applies to every stakeholders of your Agile transformation, from senior stakeholders to internal and external customers.

We listed the following 15 Breyter Rules for Agile transformation success:
- Create case for change.
- Build coalitions.
- Be inclusive.
- State goals before introducing change.
- Co-create new reality.
- You can never overcommunicate.
- Build it, and they will come.
- Be genuine, transparent and positive.
- Question the status quo.
- Be assertive and courageous but not controlling.
- Serve but don't follow.
- Lead without authority.
- Walk the talk.
- Celebrate success (but not too early).
- Never stop!

Let's review these rules one by one:
- Create case for change. Status quo state is most stable. If you want to change status quo, you need to shake it, and the only way to shake it is to expose its inefficiencies. For each organization, those would be different. Is quality a concern? speed of delivery? flexibility? are customer unhappy? why? Talk to people, observe, ask five why's the lean way to understand root causes, review artifacts. If you are fortunate, hire an external vendor to perform organizational assessment. This exercise will help you come up with the baseline for the success metrics for your Agile transformation and will pre-define your dashboard or your organizational survey - whichever combination of tools you will choose to use to measure progress on a regular basis.

- Build coalitions. Relationship building is important in personal life, in career success, in your happiness and sense of accomplishment at work. However, in Agile transformation it is not something that is just important, it will make or break your Agile transformation. What do I mean  by that? Let's imagine you arrive to an organization as a newly hired internal Agile Coach or as an external consultant supporting Agile transformation. The person who leads the product team has been in the organization for more that 10 years. You can clearly see that this person has not bought into Agile. Besides skepticism that you observe, you hear from other about multiple comments that this person questions your and your team's mission at every meeting he/she attends at every level. You make a decision to talk to this person.

There are two choices: inform this person that you won't tolerate this type of backstabbing and share with the Agile transformation sponsor that the product organization leader is a closed minded individual stuck in the mindset from 1980's. The second choice is to put yourself in this person's shoes. He/she has been with the organization for many years and feels proud about multiple products and services that have been created. The company is making profits by selling those products and services, and the feedback from customers has been largely positive. Now you join the organization, question the products, want to change how they are being envisioned and built, and confuse people without having sufficient understanding of the organizational culture or the products being offered. Which choice would you make?

The easiest choice is to escalate and sometimes you cannot avoid that, but this should never be your first choice. If this person is genuinely interested in the organizational success, you share the same goal. Spend time with this person, share data, invite to Agile ceremonies, expose your dashboards, suggest help in specific areas of his/her concern.

- Be inclusive. Follow the same approach as discussed above with your key stakeholders, invest time in meeting with them individually prior to the meetings where the future of Agile transformation is decided, get their buy-in by genuinely and openly share your beliefs, values, and priorities. Besides targeting specific groups and decision-making individuals, create venues such as Lunch and Learns, Book Clubs or Open Spaces where anyone who is interested in the topic would feed welcome and listened to.

In one of the organizations I supported, we started an Agile Lean Practitioners Meetup - which was a great marketing and talent attraction opportunity for the company as well as a great venue for company employees at all levels to come, learn, share their experience, and meet interesting people involved in Agile. For us as a group of Agile coaches, these meetings were a great opportunity to identify internal change agents who later became formal and informal leaders of Agile transformation within the company.

- State goals before introducing change. This rule is super important. You want people to follow you for the right reasons. You want them to be as excited about the changes you are bringing, about empowering teams and individuals, about building the software that will delight your customers, about collaborative environment you are going to build. You do not want them to join you based on assumptions that are wrong or irrelevant. You do not want "yes" people around you who won't question ideas and challenge you. You do not want people who join you because "Agile" or "Lean" is a buzz word and they feel that being part of a new team will allow them to move fast on the career ladder. However, if you do not set expectations right, how would you expect them to join you for the right reasons? So what do you do?

First, you need to define your values and the success criteria for your transformation. This is based on the analysis you did in Rule #1.  here's an example:

"We as an organization lack transparency so Agile transformation will help people share and be aware of others' successes and challenges. No one will be punished. Actually, we want to fair early and often, and we want to experiment and take risks. No one is punished for their mistakes done as part of these experiments. Actually, these failures will be celebrated as nothing else gives us a better learning experience. Each month, we will have a company-wide demo to show our latest development and showcase new products. We are also going to publish our continuous improvement newsletter and implement 2-second lean practice across the organization. Making transparency and experience sharing an integral part of our company's culture is one of primary goals of Agile transformation. We will measure it by capturing process changes implemented based on lessons learned and by calculating time saved by re-using functionality across departments, based on open communication. We expect those parameters to grow 50% within the first 6 months of Agile rollout."

If you heard this from an Agile Coach who leads Agile and Lean implementation for your company, how would you not be excited and willing to take part of the effort?

- Question the status quo. We mentioned that status quo is a stable state. This is a psychological axiom widely used in the negotiations theory. Read or watch Margaret Heffernan  for a brilliant explanation of this fact and the joy of challenging it. Nothing is fixed. No opinion is sacred. Whether it is inertia or the organization is not prone to challenging authority, find a tactful and empathetic way to question current practices, whether this is active listening or asking thought provoking questions, or trying small things that produce big impact, one at a time, and showing successes. In one of the organizations that I coached, Agile terms were a taboo. They experienced a painful Agile transformation a year ago which miserably failed and cost jobs to many loyal and smart people. Agile was considered disruptive and irrelevant for that organization based on compliance requirements, lack of urgency to reduce time to market, and overall relaxed delivery culture. Besides, everyone was fairly happy with status quo, except for customers, executives, and a few software developers with prior Agile experience who were labeled as "troublemakers".

What did we do as Agile coaches? One on the team suggested to run as fast as we can, so that we do not ruin our reputation. His argument that if the organization is not ready for Agile transformation, if they do not see that the change is necessary, the best we can do for them is to let them fail big time, so that they realize that the change is a matter of survival for them and not luxury. We did consider this as our last resort, but we made a decision to give it a try. This included our agreement to avoid Agile and Lean terminology completely. We did not use the word "Scrum ceremonies", we said "meetings". Instead of "scrum masters", we continued saying "project managers". Within a few month, we were running Scrum full speed and no one even noticed, and of course, everyone loved it. This "sneaky" approach helped us avoid resistance and introduce change without openly disrupting the status quo.

- Co-create new reality. In the previous Rule, we discussed disruption. However, once the change is implemented, it has to be anchored. John Kotter's eights principle is about anchoring change in the culture for sustainable change. For me, it is more than culture. The change has to become the new reality, the norm for the organization, and it is up to us as Agile and Lean Coaches and change agents to make this shift possible. Let's review an example.

As an Agile Coach leading change, you addressed a challenge this organization had, which was paying zero attention to metrics as a measure of their progress. They did have organizational goals before but those were vague and not in a SMART format. When you started the Agile transformation, you assessed their processes and products, supported them in articulating their vision and stating SMART goals, and defining metrics around those. All of those are annual goals. Do you need to wait until the end of the year to check whether those have been achieved? Obviously not.

In order to anchor this new thinking, you introduce interim metrics in all possible forms: large screens serve as information radiators around the office, there are real-time dashboards in your Agile tools (both JIRA and Rally provide great capabilities to do so), you present results weekly to your CIO, COO, or even CEO (or divisional leader for larger organizations), these data is shared at Townhalls and in the company blog, someone even started a competition who will forecast next month results more closely - and eventually becomes part of the culture, something that everyone follows and is interested in. This example is a great segue to the next rule.

- You can never overcommunicate. Do not be afraid to overcommunicate. I've heard a lot from Agile coaches: let's not share this information yet. There are multiple excuses: it has not been approved or adopted, or we want to know first if this is going to be a success, or we shared it already in the blog, why would we share again in company's Townhall? We don't want to be repetitive, boring, controlling, or irrelevant. Here's the news: you cannot overcommunicate organizational change. Where there is change, there is always anxiety, and anxiety needs information to calm down.

However, one thing you can do is miscommunicate. During organizational change, any equilibrium is fragile. If something needs buy-in or there is a formal approval chain, respect it. If the information is sensitive, collaborate with the peer to target the message and ensure that it produces the impression you want to make. But none of it should be an excuse for withholding information or waiting with sharing something that is relevant.

- Build it, and they will come. Many Agile Coaches give up early. And in some instances, early means months, sometimes it means years. Agile transformations take time to catch on. It depends on how flexible the organization is and on their prior experiences (for example, if an organization is going through periodic layoffs, people will fear change and need to be reassured and empowered, or if they had a prior negative experience with Agile and Lean, people will resist change most actively).

The only advice is to continue trying, and try new forms, new types of communication, new pilots. Make yourself helpful and build your reputation, even if these are only marginal process optimization initiatives. Use this time to build relationships, meet with key decision makers on a regular basis to discuss their pain points and how you can support them. Create book clubs to discuss Agile and Lean books and conduct them only if one person shows up.  You will be surprized that this will pick up. 

- Be genuine, transparent and positive. This rule is about you, my fellow Agile Coach. For all of us Agile Coaches, there are good days and bad days, Days when you feel victorious. Proud. Full of energy and able to move mountains. There will be days when things will go wrong. Terribly wrong. Your sponsor will tell you that you drain resources and bring no value. When you will be ordered to do things that you do not believe in. Days when your teams fail. When a major deployment has to be rolled back. You will doubt yourself as a leader, as a coach, as a human being. Both victorious days and the days of defeat (seaming, temporary, and sometimes even imaginary) have great learnings and big threat.

Let's start with victorious days. On those days, when your powers seem limitless and your influence has no limits, emerge in the power of gratitude. Think of those people who believe in you, who followed you, who became better than you are. Thank them, share the victory with them, transfer it to them. 

On your tough days, do not question yourself, your skills or abilities. This of your failure as a learning experience, assess it and build on it. Once you assess it, you may find out that your sponsor is also human and needs support and re-assurance, that the teams bounced after the rollback and the product is online again, or you may find out that you have to re-think the whole transformation effort, which will be a great new learning for you. Remember and cherish those days and the experience that comes with them. 

Sorry to sound too sentimental or preachy, but I have seem many Coaches who became victims of either one of those situations. Some became self-absorbed and some gave up. Neither one is the answer, and I have no doubt you all know that. However, there will be the days that will challenge you, so I want you to be prepared. Staying genuine, transparent, and positive will let you avoid any of the risks listed above.

- Be assertive but not controlling. There is a fine line between being being assertive and controlling. Today, I was interviewing a highly skilled candidate for an Agile Coaching position. I asked him to share his values and his beliefs with me, and he told me that he never questions authority.

"What do you mean? - I asked.
"I am always loyal to my boss."
"I also highly value loyalty, - said I. - Can you give me an example of it?"
"Sure,-  said the candidate.-  When my boss wanted me to create a roadmap for my program, I created one and he told me I should do you different. So I changed everything I had and did what you wanted."
"Why did you decide to do it? Was his idea better?"
"No, I did not question it. He is my manager, so I did as he told me."

For me, this is not what I expect from an Agile Coach. I expect Agile Coach to have values, to have opinions based on experience, to question, and to disagree. The other type of an Agile Coach is my recent colleague, super smart and experienced Agile delivery professional. In leading a Scaled Agile implementation, he had everything defined to the minor level of detail. His favorite word was "compliance". His advice was stellar and the playbook covered all intricate details of a successful Agile implementation at scale. Everyone expected his program to do miracles, and everyone was shocked when it failed miserably. 

So what is the optimal solution? Empower the teams, organizations, individuals, guide them, advise them, listen to them, but don't try to control and prescribe. Use your emotional intelligence and well informed judgement to draw the line. For example, if your organization decided on OKRs (Objectives and Key Results) which have metrics associated with those, you need all teams to provide input into this data. If they do not see value, talk to them, explain the reasoning, show the data, explain impact on alignment and training efforts, make sense out of this effort and be as assertive and fact-based as you can. Listen to them. If they are concerned about the time to collect data, help them with the tools. If they are concerned about transparency, ensure there will be no negative outcome from the management. Do whatever you need to alleviate their concerns and show them metrics. But don't come to them and tell them that if they do not produce data next month, they won't receive full year's bonus payment. Handle this topic with passion and integrity which defined you as a coach.

- Serve but don't follow. This is another one that is not trivial. In a number of organizations where I led Agile transformations, the concept of a Scrum Master as a servant leader was challenged. What does this oxymoron mean in practice? For me, it means a lot. Be humble but have your values and goals clear and don't give up your integrity to be helpful, even if empathy is your number one trait.

I've seen Agile Coaches who tried to be helpful to the extent that they became implementors of senior management orders and seemed to forget why they were in the organization. If senior managers had a hands-on experience in implementing Agile transformation, they won't hire you. I've seen brilliant Scrum Masters who turned into excellent facilitators and note takers. Be mindful when you start turning into one of those and course correct immediately. It takes months for an Agile Coach to gain reputation and it sometime takes on instance to lose it.

- Lead without authority. The previous rule is in a way similar to this one, but this one provide a new view on this role. As an Agile Coach, you most likely have limited or no authority over people who define success of the Agile transformation. How can you lead them then? I recall an Agile Coach who resigned because she was very upset about not having Scrum Masters as her direct reports. Her complaint was that "they were not listening to her". What is expected then? Who is a real influencer?

Early in my professional career, I heard from an executive in the company I worked for: "You are too nice to be an influencer." This caused me to think a lot about this topic. Are influencers always mean? controlling? prescriptive? non-caring? self-absorbed? Over the years, my answer is that it's in fact the opposite. No wonder this company has major leadership issues. 

There is a lot of great advice on how to lead without authority. The authors talk about quiet confidence, ability to become an active listener, to make good choices, to provide mentorship, create the environment (rather than adjust to it), and show respect to others. Harvard Business review uses the term that I like, lateral leadership. My point about it that some people are born with it, and some people can develop it. To do so, they have to be willing, open minded, and build their learning on the culture of ongoing feedback. But without this skill, there is no successful Agile Coach.

- Walk the talk. No matter what circumstances occur, always walk the talk. For you as an Agile Coach, Agile is about being Agile rather than doing Agile. Best coaches approach Agile transformations in a similar way. If we do not live Agile values, we are giving them gym clothes but they will not to the gym if we do not help them believe in the power of health life and in exercising regularly. One of the Agile Coaches I respect, said "beware Agile Coaches who take people to church vs. helping them believe in God." I find this statement very true.

- Celebrate success (but not too early). So you've accomplished a lot, followed all the rules above, and your Agile transformation is a success. Invest time in celebrating successes of your teams. Share in information radiators, come up with internal prizes, establish surveys to nominate people and teams who deserve them. Make is super visible and prestigious. However, balance these celebrations with anchoring the changes in the culture and sustaining those practices in their day-to-day implementation.

- Never stop! And finally, remember that Agile and Lean transformation never ends. Challenge. Innovate. Disrupt. Set new, more challenging objectives. And once these teams, programs, organizations, practices become sustainable, identify new challenges and overcome them. And if you get stuck or discouraged, re-read the 14 Agile transformation rules above.

And of course, feel free to comment or to add your rules in the comments below.

Almost every Agile transformation effort starts from this concept. Actually, one of the variations of it, frequently contradicting each other:

- Get executive support!
- Start from the teams, and once they show success, you will get support in your transformation!
- No bottom up initiatives survive!
- The only recepy to Agile transformation success is top down. Otherwise, teams will get demotivated and say what we've heard so many times: "Agile does not work for us."

Scaled Agile Framework (SAFe) suggests that top management should become the driving force behind Agile/Lean transformation. "If you cannot come, send nobody" - a famous and very profound example of engaging executives in transformation effort cited by Edwards Deming. 

This example refers to a quote from William Conway, then CEO of the Nashua Corporation, related by Dr. Deming in his 1986 book. Mr. Conway was writing in response to the Vice President's request for an invitation to visit the Nashua Corporation. Dr. Deming elaborated for clarity: "If you don’t have time to do your job, there is nothing I can do for you." His point, driven home with typical Deming wit, was that there is no real substitute for leadership, for the top management support and involvement.

How do you ensure that you receive support from the top? Let me give you two examples:

1. In this Fortune 500 organization, all C-level executives were pro-Agile. They used words "Agile" and "Lean" in each of their presentations no less than three times. Their CEO said: "We need to be Agile by the end of this year. Tell me what you need and I will give it to you."

2. In a midsize educational organization, a CEO said: "We do not have unlimited budget. I want to learn everything I can about Agile, I want you to tell me how Agile transformation will affect our business, and I want to have a dashboard into our progress with metrics that resonates with me and our business stakeholders. I want to hear from you what is working and what is not, and how you pivot and improve your practices as we move forward."

Which company you think succeeded and which failed? Large powerful organization with unlimited budget and commitment towards Agile, or a midsize organization with limited budget and CEO who wanted to understand value and be involved in the progress?

Surprisingly, it was the first one. Despite unlimited budget in the first organization, the management wanted to see the results. They did not take time to understands what Agile and Lean actually mean and how their organization will be changing over time. They supported transition to product teams and expected these teams to start delivering value within months. Instead, some long-time employees left, some who did not fit into the new team-based culture were let go, productivity went down, old project management office was dismantled, and all the visibility into project status was lost, so the executives eventually decided that "agile did not work for them."

For the second company, transition was not easy either, but from C-suite to mid-level management, everyone felt their leadership role in Agile transformation. They came to the demos, asked many hard questions, each of them looked at their dashboards in Jira on a regular basis and questioned everything they did not understand or anything that they had doubts about. They were truly hands-on throughout many changes in company culture: their CEO served ice-cream to late evening hackathon participants, and sponsored external educational startup lab over the weekend. It was not an easy journey, but it was successful because the leaders wanted to be part of the transformation, wanted to understand its benefits and challenges, and be involved (but not micromanaging) every step along the way. Their expectations were properly managed (to say it correctly, they took active role in managing their own expectations) and this Agile implementation succeeded and brought results after the first six months. 

When you are starting Agile transformation, start with senior managers. Find out their pain points, design your communication specifically for them explaining how Agile and Lean will address current challenges, target this communication to company culture (workshops, presentations, informal conversations, one-on-one interactions - do it the way consistent with the company culture, but never neglect this step). Don't proceed further until you gain the right level of understanding and support from your executives, and definitely, do not rush it.

Why moving fast is an issue?  Let me give you just one example, and there are hundreds of similar ones with different inventions. This one is from an article that I read recently. It was about Josef Ganz, inventor of Volkswagen Beetle who invented the affordable family car in 1930 when Europe was dominated by motorcycles. No manufacturer was interested in producing this car. The world was just not ready for it yet. Motorcycles were cheaper, easy to start and to navigate, and there was no interest in Beetles. For many years, Adolf Hitler was considered an inventor of Beetle because when he saw the car at a car show in 1933, he used this model of a cheap family car later in his campaign of "motorizing Germany" and winning hearts of the middle class who were able to afford a car for their family. By 1939, the Nazis began their occupation of Europe. One of their tools was a nifty commando vehicle - a spruced-up version of the Beetle. After the end of World War II and the collapse of the Nazi regime, Germany's economy recovered with international help. The car industry, and Volkswagen with its Beetle in particular, became a huge success, but Josef Ganz was never able to reclaim his intellectual property which was introduced only 10 years before the world was ready for it.

Why did I share this seemingly unrelated story? Even 10 years play a huge difference in history. A month, a sprint, or a meeting with your key stakeholder may plan a huge difference in the success of your Agile transformation. Time your sequence right. Do not proceed with changing org structures, delivery cadences, and product mixes until the management has good understanding and realistic expectations of the next steps - short- and long-term. 

Those differ in each specific situation. Feel free to share yours, and we will brainstorm together.

Tip #2 above covered executive support and buy-in. This one speaks about your Agile teams being excited about working in a new way. There is a reason both are on the top of success criteria list.

Have you seen a picture with a bridge which was constructed simultaneously from both sides of the river and failed to meet in the middle? Similarly, your Agile transformation. We cannot go completely "top down" because your management will develop expectations and won't have patience for you to wait with the next steps until you get buy-in from the hands-on participants: team members. Similarly, we cannot go "bottom up" (which is an ever worse scenario) when teams will become Agile but won't receive support on the top. We've seen multiple organizations where software delivery was done in a structured and planned waterfall or waterfall-like way, but there were multiple Agile teams within it.

Imagine this situation. Within one program, there are several teams. One is a waterfall team (still a dedicated team) which has its releases planned quarterly with pre-defined scope until the end of the year. Another is an Agile team sprinting well and delivering production-ready software every sprint, which is two weeks for them. They share the same codebase. Before each quarterly release that their waterfall team is doing, there is a 3-week code freeze. Prior to that, there are 2 iterations of 2-week QA and 3 weeks of UAT. During all this time frame, no one can check code into the trunk, unless approved via waterfall team's release management process. What does the Agile team do during these two month out of every quarter? Still generates production-ready code and deploys it to their dedicated instance without integrating. Once quarterly release goes to production and all emergency defects are fixed, the Agile team checks their code to the trunk, and guess what? Nothing is working! Then, they spend 3-4 sprints just to catch up on latest code changes and re-write the code they wrote during the last two month.

Fairly soon, the team members of the Agile team get frustrated because they spend most of their time doing rework and leave the organization. The management sees the waterfall team producing successful quarterly releases, so they are not even concerned about Agile team members leaving at this point. They do not bring much value anyway. Another organization where Agile "did not work for them".

What is the recipe then? Well, Agile is not a silver bullet, and we all know it too well. It is a silver mirror which exposes areas that need our involvement and support as Agile and Lean coaches. What can we do in this case?

Well, first our bridge needs to meet. There is no top down or bottom up in Agile and Lean transformation. The change is too massive to support either one of the options. Once we recommend to start from senior management's education, expectations management, buy in, and support, we need to start building teams and involving team members almost immediately. There are several ways of doing it:

1. Training and education. Team members including those who had previous Agile experience, need to be on the same page in answering the question: what does Agile mean for us? This involves standard training, which is internal or external variation of CSM or CSPO training plus team specific brainstorming, review of their technical practices including introduction of ATDD/BDD, brainstorming on their challenges, and addressing their individual questions. Certification is irrelevant, although some organizations use it as a marketing tool internally and externally. Training has to be concentrated on values rather than specifics of execution in Agile environment.

2. Clarity on roles and responsibilities. Team members all want to know: what does it mean for me? The change will seem threatening to some of them, especially those who have been with the organization for a long time. Another category that needs special focus and extra thinking is your middle management. What now happens to them? They can become your biggest supporters or greatest enemies. They will "resist Agile to death" - their or Agile transformation's. Once a fellow Agile Coach told me that he usually starts by either letting go middle managers (if they no longer can do hands-on work) or making them equal members of an Agile team.

I do not let them go because there was a reason they were promoted into management position so we know they were good developers/testers/DevOps specialists, but I always spend a lot of time with IT managers to ensure their support and clear understanding of their role in an Agile environment. Do not underestimate them.

In my second enterprise-level Agile transformation, I underestimated the power of mid-level IT managers who have control over all the delivery organization. They can make or break the fragile change we are introducing. Let's ensure there is a strong partnership there. I will write more about the role of middle management (and specifically, IT middle management in Agile ) in a separate tip, but for now, let's agree that this group is paramount for our success. They can lead Communities of Practice, introduce new tools, techniques, process optimization ideas, if you partner well, or resist your Agile transformation and kills it fast, if you fail to establish partnership.

3. Expectations management. Team members have to be very clear how their role is changing, what their new team-level objectives are and how they support them individually, and how they are now interfacing with the business. They have to be clear on their career progression and recognition in Agile environment, and the increased value of collaboration. If they do not see themselves working in a team environment, help them with transitioning out, but do not try to make things work if they are not open to collaboration or not comfortable being transparent. The culture will have to change, and this is the most difficult and long-changing aspect of your Agile transformation.

4. Business involvement. While the role of Product Owner is well defined in Agile, involvement of business stakeholders is not as clear. I've seen business stakeholders (non-IT business analysts, product managers and analysts, researchers) storming into Agile environment and disrupting it to the extent that it became absolutely dysfunctional. For one of the programs under our umbrella, business stakeholders (four analysts and three product managers) requested directly from a Scrum Master (who did not have courage to object because he was a contractor and all seven business stakeholders were Directors and full-time employees of a Fortune 50 company) to add them to daily standups for all 5 teams within the program. As you can guess, the program became dysfunctional within one sprint. How to avoid that? Train business stakeholders, set expectations correctly, discuss their roles and level of involvement, invite to team demo's, maintain constant contact, build partnership, and avoid disruption at all costs.

5. Motivation and inspiration. Even though it is my last item, this is the most important one. Your team members will be delivering successfully, staying with the employer, and collaborating efficiently if they are motivated and excited about the work that they do, if they are growing, if their products delight customers, and they receive their feedback. Hackathons, open space events, participation in industry conferences will make them excited, but most importantly, they are looking for the respectful environment where they will innovate, fail without being afraid of repercussions, and bring value. More on that in Daniel Pink's book or this RSA Animate video.

What is the conclusion? Agile transformation can be initiated from the top (management) or the bottom (teams) - even though the terms "top" and "bottom" are not really applicable in this case - but there is no "top-down" or "bottom-up" Agile and Lean transformation: both sides of your bridge have to meet, and you as a Coach or transformation leader will have to pivot and adjust to ensure that this connection happens.

Please share your experience and ask questions: no situation is the same and it is always great to review practical examples.

Agile as a framework does not define any scaling mechanisms. Agile values apply equally to one team or one organization, however, the mechanics of enterprise-level Agile has not been well defined yet. Success at team level is not being questioned anymore, it has been achieved million times by teams around the world. Enterprises are frequently struggling. Scrum of Scrums as a scaling mechanism for thousand people IT organizations is not efficient. Meanwhile scaling Agile is not a rocket science. I've done it successfully with a number of organizations and saw others doing it even better. So what is the secret source? There are only 3 components from my perspective. You follow them, and your Agile will scale:

1. Scale your Agile implementation based on your company's culture and tolerance to change. Agile Coaching is all about "building on what is happening". Scaling Agile is nothing different. The question is not whether SAFe or LeSS is better, the question is which framework is right for you. Let me give you an example. In one of organizations with thousand-people IT department, we selected prescriptive approach. Organization was corporate and structured and responding well to management initiatives. With support from the top, we created an Agile playbook where we defined everything: ceremonies, their frequency. standard cadence, normalized story points, trained everyone in SAFe, and rolled it out. 

There was still autonomy at the team level. The teams defined their internal practices, but all checkpoints were synchronized. Tooling was also synchronized. Everyone had access to role-based dashboard in Rally for their program and could see team-level productivity for each team and their commitment met per sprint. No one was punished and there was no finger pointing because teams are different and velocity-based comparisons are meaningless, but commitment was public and the teams who had less that 80% commitment met were getting additional coaching. There was a lot of collaboration and IP (innovation and planning) sprint was sacred with hackatons, fix-a-thons, open space collaboration, unconferences, and a lot of education, self-education, and cross-team experience sharing. The overall implementation was at the same time very structured.

Metrics was also standardized, with 12 parameters (based on our OKRs) every team was moving into, including the 80%+ commitment rate, ATDD implementation, continuous integration up to staging, and a number of other process and technology goals. This implementation was a success because the organizational culture was receptive to the structure, because executives fully supported it, and the teams were ready and excited. 

2. Manage expectations at every level. The "big bang" approach we selected was a marginal risk because a well-defined structure with high level of standardization is easily scalable. It was disruptive but we managed expectations well with executives, product managers, and Agile teams, so there were no major surprises to anyone. However, this is frequently not the case.

In one of the organizations I worked at, I felt very fortunate when my arrival was warm and everyone was very welcoming. Very soon, I noticed that expectations seemed to be unrealistic. "You came and now our life will be different. We'll be more nimble, more efficient, and more aligned." So I started asking coaching questions: what prevents you from being aligned right now? (we had layoffs and people are concerned; we are used to be operating in silo's; people stay here of years and hold on to the way they used to work before; we are consultant-heavy; tolerance to failure is low) Immediately, I started thinking where we will anchor our transformation (is it support from executives? is it bringing more internal employees? is it bringing in an external coaching team? ) It was obvious that "big bang" approach wouldn't work here so the goal was to find out the right scope and approach.

Once the approach was defined, there was training put in place for every pilot followed by a discovery session. The discovery session helped define the scope, success criteria, and implementation timelines for each team. Once done, we made our expectations clear to the executives, teams involved, and all relevant stakeholders, and then were able to proceed. Most of the pilots were very successful, but one was not, and we spent a lot of time analyzing it and learning from failure. Tolerance to failure is one of the secret sauces of a successful transformation. But it cannot be unlimited. Be thoughtful in defining the strategy and socialize the approach and the support you will need by getting all key stakeholders aligned on this approach.

3. Scale continuously and establish build-measure-learn loops. If you have not selected a "big bang" approach (which has more risk to fail in the beginning but higher chance of success as a scaling approach), you will most likely start with early pilots. Once you implement these pilots and celebrate early successes, you will be expected to scale. If your scaling mechanism is not built in to your pilots, you will stumble at this point. So what needs to be built in? The following as a minimum:
A. Communities of practice. A community of change agents who support the change, who continuously think about supporting and implementing change, who can serve as informal coaches and inspiration to new teams. A community that scales itself organically and is excited about continuously thinking of becoming better and more successful.
B. The foundation. This includes training materials, trainers, ongoing education (such as Lunch and Learns) targeted at all stakeholders, not just immediate participants. Value proposition statements for business stakeholders and implementation sponsors, templates for the execution teams, playbooks with detailed instructions and helpful advice - everything they need to be successful. Scaling has to be a foundation of these practices and experience sharing sessions: how do we work together? what are the touch points? how we define impact and agree on timing and effort? how do we respect each other by working collaboratively and establish transparency? - from culture to process, the foundation has to cover all aspects.
C. Continuous improvement. Ability to analyze, implement, and then learn from our mistakes ("build-measure-learn" loop) is the foundation of success. It goes hand in hand with zero tolerance for blame and fingerpointing, with promoting the culture of transparency and feedback, with tolerance to failure if it comes with thoughtful analysis and commitment to success. Whether you have company-wide retrospectives, or themed open space sessions in the areas of difficulty, or open continuous feedback, you won't succeed without a desire for continuous improvement and a fear-free collaborative environment. Those two are pre-requisites for any organizational success but especially the one that involved scaling across the organization.

​What are your scaling secret sauces?

There has been a lot written about the difference between Agile and Lean. Yes, Agile frameworks utilize Lean principles. But there are also Lean methodologies, such as six sigma. Kanban comes from lean, kanban board from agile. Elimination of waste or removal of bottlenecks in a workflow comes from lean but increased velocity is an agile concept. Continuous improvement is built into both. So what is the difference then?

My colleague told me recently that the distinction is simple: lean is about cost and agile is about time. Sounds nice but it is not that simple. Yes, there are timeboxed iterations in Scrum but cost reduction and effectiveness are as important as in lean. Yes, we want to eliminate waste in lean, but continuous improvement via retrospective is built into Scrum as well. So what is the difference (if it exists)?

I think that the difference is in the way of thinking, not the rules themselves. While Agile follows a lot of similar practices, Lean emphasizes personal responsibility of every person to exhibit the new way of thinking. The 2-second lean video became famous. What can be less appealing than a trash can? It turns out that a trash can motivated and energized thousands of people around the globe. At a small plant, employees come to work every morning and spend 15 minutes brainstorming and coming up with improvement ideas in any area of their choice. A redesigned trash can cover saves employees hundreds of hours monthly, and it was such a simple fix outside of the person's area of responsibility.

What does it mean to you? No matter what you do, employ lean thinking and ask yourself the questions: why are we doing what we are doing? what is the value? can we realize value elsewhere? how we can improve? where is the bottleneck(s)? how we can pivot and continuously improve?

I conducted Lean-Agile Training for internal participants recently. I showed them the "2-second lean" video, and as they moved through the presentation, I was looking at their faces. They all seemed to like the concept but were bored towards the end. When the short movie ended, I asked a question: "Who thought about your own improvement?" and the best answer I got was: "Since you did not instruct us to read past Chapter 5 and did not give us instruction to think of own ideas,  we were sitting here doing nothing and waiting for others to finish." This is the scenario where lean thinking, which promotes ownership and initiativeness, does not apply.

Another interesting example: next, I asked a 15-people training team to come up with lean improvements after watching this video. Since there was a garbage bin improvement in the video, everyone came up with facilities-related improvement ideas (bathrooms, light bulbs, elevator buttons) but the interesting part was that this was a software development team. While clearly seeing inefficiencies in the facilities area, they did not prioritize any items in their immediate sphere of ownership. While they could clearly see inefficiencies in other areas, they were not able to see them in their own domain or prioritize them high enough to resolve. When I raised this topic and the team suggested several inefficiencies to resolve in IT area (e.g. PPM form has too many fields, deployment process is necessarily complex), they did not assume ownership over those and rather, suggested that an Agile Coach (!) takes this ownership. Lean thinking is not easy, neither gets acquired fast.

What does it mean to you? If you want to succeed in a modern fast paced world, become a lean thinker. See inefficiencies, identify them, quantify, suggest solutions, and own implementation. These are qualities of a true leader. Neither identifying issues nor owning resolution is easy, but it will give you visibility and the respect you deserve. As I mentioned in a previous post, every constraint is your best opportunity.

A lot has been written about roles and responsibilities in Scrum but the topic is still ambiguous. The Scrum Guide is saying that there is Product Owner, Scrum Master, and The Team. But what is The Team? Developers and testers only? What about business analysts? What about Product Managers on the business side who make prioritization decisions? What about Development Managers? QA Managers? Dev Leads? Operations? There is no stated role for them in Scrum.

This ambiguity is sometimes a reason for people in the roles listed above to fear and resists Agile. However, they are the ones who should embrace it because they will benefit significantly and will get seats at the table with Agile transformation, just not at the implementation team level.

Let's address the three primary roles first. According to the Scrum Guide, "The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Scrum Teams are self-organizing and cross-functional. Self-organizing teams choose how best to accomplish their work, rather than being directed by others outside the team. Cross-functional teams have all competencies needed to accomplish the work without depending on others not part of the team. The team model in Scrum is designed to optimize flexibility, creativity, and productivity." This does not mean that everyone on the team should be fully cross-functional, but it does mean that team as a whole should be able to provide end-to-end functionality, i.e. if you have web services team and UI team separately, they are not cross-functional.

"The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. " Check out this brilliant video by Henrik Kniberg on the Product Owner role.

"The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules. The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team." Check out this article on the details of the Scrum Master role.

What about Product Managers? All of them are definitely stakeholders so Product Owner will take their opinion into account while prioritizing, and will communicate back to them. According to a well-known Scrum metaphor, they are "chickens" but not "pigs".

What about Business Analysts? Many of those are very successful in their transition to Product Owner, but for the time being they are working as Product Owner proxies collecting information and populating the product backlog.

Now, dev leads are a tricky situation. Make an effort to remove them from a planning session where they estimate for everyone and start discussion from their own opinion. Dev leads are a great asset to a team as a team member not a manager or a decision maker for others. They will take over technical user stories or be a stakeholder in those and become a crucial team member with the same decision power as anyone else on the team.

Managers sometimes want to control their employees, so we have to be mindful about any signs of command and control. In Scrum managers have a distinct role to support roll out of best practices in  their area of expertise across the organization, whether it is testing or development. In many organizations though I saw successful managers becoming members of their cross-functional Agile teams and doing hands on work along with everyone else on the team. Either way, there is always a role for those who want to contribute and who are interested in bringing value in their area of expertise.

But most importantly, Scrum team members irrespective of their role on the team are decision makers on topics within their domains and active participants in any analysis and brainstorming session on their Agile implementation. No Agile Coach or Scrum professional can decide it for them. Bring them to the table, and you will be positively surprised by their thoughtfulness, creativity, and subject matter expertise!

 
​When a team is formed, each team member has a specific area of expertise. In software teams, we have developers, testers, analysts. In meta-teams, we have a group of specialists, each of them being a subject matter expert in their respective area. This is normal for a team as their stepping stone to starting collaborating and delivering products. However, no team can achieve hyper-productivity until it is cross-functional. 

Cross-functionality is part of the Scrum definition and is listed as a pre-requisite for Scrum success in Jeff Sutherland book "Scrum: The Art of Doing Twice the Work in Half the Time".  Why is it so important? Imagine a software team where all coding for the sprint is complete but the testers are just getting busy with the test cases while thousands of tests are run as part of  their regression test. You need developers to be ready to write test cases, automate regression testing suite, and run those cases. You need testers who understanding basic development work, and analysts who understanding both competencies and speak their language.

So how do you turn your team of narrow specialists into a truly cross-functional team? Let us first review the definition: "... interdisciplinary Teams are also referred to as „cross-functional teams. Each team member brings different skills to the table, all of which complement the skills of the others, making it possible to cope with a variety of tasks and find innovative solutions." This definition is fully applicable. In this case, team members "swarm" in supporting each other in accomplishing their sprint objectives so that user stories move through the workflow without obstacles. This approach increases productivity, supports innovation, and creates truly collaborative environment. 

As always, the best answer is in identifying the right balance between team members having deep knowledge in each of their areas while having working understanding on adding tasks to other team members' stories. How do you identify the best way to accomplish this? As always, by experimenting, by trying the best ways to increase cross-functionality and collaboration on your teams, and thoughtfully learning from your mistakes. You can try pairing, cross-training, creating mini-teams, and other ways to build Communities of Practice while promoting collaboration and team support. This is a pre-requisite for a healthy Agile environment.

While Agile works well at team level, it is portfolio level and higher where things get difficult. There are multiple things that get in the way:

• External dependencies: frequently, there are agile and waterfall projects within the same company. If Agile does not provide the level of advance planning that waterfall project stakeholders are looking for, there is immediate frustration with agile teams' planning process.
• Business stakeholders: if agile is rolled out for technology teams, your business stakeholders will be puzzled when you tell them that the team commits to what they can deliver within iteration and they won't accept scope/milestone directives from the business. This may seem a huge disadvantage to the business because your business stakeholders have to commit to specific dates of delivery; they have to initiative marketing efforts well in advance, and predict their product financials.
• Managers: they are used to receiving your weekly reports, which you will send them at a regular basis  ("push" method in lean) rather than being invited to your demo's ("pull", according to lean terminology). It means now it is their initiative, and there is no external trigger that will help them keep in touch.
• Priorities: if your team or your group of teams works well when you deal with one product and your system dependencies are minimal, things get confusing when you scale. Now you have multiple business stakeholders (product managers, marketing specialists) that you deal with, multiple code bases you are touching with many more integration points and technical dependencies, and in addition, the visibility for your product is huge, so the number of stakeholders at your demo's is going up. This is a great problem to have, but how to deal with it?

How do you address these challenges? The best way is to build a solid portfolio of your features and expose a roadmap based on your release planning. What are the primary milestones you are planning to deliver at high level? What are the timelines associated with key functionality delivered? There are multiple templates available but my preference is either portfolio template if we are delivering a product line within one program, or a feature roadmap if the team is delivering against specific product objectives. Good samples of these templates are available here. Many agile management tools such as Jira and Rally provide portfolio functionality based on the epics and user stories planned within your product backlog and generate roadmaps automatically or using plugins.

Once you create such a draft, the next step us to get input from the stakeholders based on shared priorities. Let them have focused conversations so that everyone understands dependencies and priority of one feature over another. Once the decision is made by the Product Owner based on this input, there is time to socialize your portfolio roadmap and the product features that are going to be delivered. It is important to build shared understanding that the roadmap is aspirational and changes will happen, which will be immediately communicated to the stakeholders.

Core stakeholders and anyone who is interested (dependent or contributing) in the outcome are invited (and expected) to visit demo's every sprint. It is advisable to send summaries (what was delivered, which stories were missed, major impediments and how they are going to be addressed, summary of questions and suggestions from the stakeholders, etc.) to all key stakeholders after each demo because some of them may not be able to join. Normally these summaries are send by the Product Owner or uber Product Owner within the portfolio, but sometimes Scrum Masters are better positioned to send it out every sprint as a summary.

In sum, there are two secrets to a successful portfolio management:
- involved the right group of portfolio stakeholders in providing input into prioritization decisions;
- once the roadmaps are created by the Product Owner and the team based on this input and the team's release planning, they need to be broadly communicated with the understanding that these goals and milestones are aspirational in nature and will be changing as delivery is progressing (progressive elaboration).

It is important to promote this atmosphere of co-creation with your key stakeholders in building portfolio and feature roadmaps for your products and to ensure that the roadmaps are updated as soon as there is a change. This is one of the reasons to keep these artifacts high-level so that a printed version fits one page, and to keep these files in a shared repository or on the Intranet, so that the changes are immediately available to all stakeholders.

Your roadmaps are both your strategy and execution tools that you use for communication and alignment, which makes them important artefacts relevant for product owners and agile teams as well as a broad group of stakeholders. You cannot overcommunicate these artefacts.

The essence of my advice is: do not treat your portfolio prioritization and release planning as a responsibility, treat these efforts and related artefacts as a vehicle to communicate your product vision and strategy, and align on dependencies and  expectations with other teams and business groups.