Tip #3. Get the Teams Excited

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.