Agile Lean Transformation
  • Home
  • 100 Coaching Tips
  • Articles
  • OKRs
    • Agile DevOps
  • Blog
  • Books For You
  • Questions
  • About Me
  • Agile Metaphors
  • NYU Newsletter Feature

Agile and Lean Coaching Tips

Get your questions answered by a professional Agile Coach

Tip #3. Get the Teams Excited

2/3/2016

2 Comments

 
Picture
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.
2 Comments
Helen Kolesnikowa
2/20/2016 07:33:36 pm

I am a Scrum Master and a former Project Manager. It is easy to say that if we get team members excited and motivated, they will all become great team players and start collaborating. I have several skeptics on my team, and one of them hates Agile, does not like team environment, and makes everyone else feel negative about working this way. He is late to scrum meetings, does not participate in team discussions, and makes mean remarks. I escalated to his manager but she did nothing. What should I do?

Reply
Mariya Breyter
2/20/2016 07:47:45 pm

Thank you for sharing, Helen! It would be unfair to expect that everyone will be happy about Agile and will immediately buy into working in a new way. When I talk about Agile transformation, I use Lyssa Adkins' (a great Agile Coach) metaphor of "heads, hands, and hearts".

What this means is that we have to win "heads, hands, and hearts" of individuals who make this happen. Heads is their logic: we need to show from examples, industry research, and our own experience that Agile works and it successful in bringing results faster, better, and in a much more transparent way.

Second, we need to give them tools: define frameworks, provide templates, purchase and configure software to work in a new way to make execution seamless and enable delivery with quality. These are hands.

Most importantly, we need to win their hearts. If they do not feel excited and empowered in working in a new way, they won't support it.

It is obvious that Agile transformation did not win the heart of the team member in question. If he is not a strong team contributor in his subject matter area, talk to him first and if things do not improve, discuss his performance with his manager. Does he need training? Is he missing basic skills and experience?

However, if he is a strong contributor, then first, we want to find out what is happening. Depending on his specific concerns, there are many different ways to address those, such as:

1. Give him time. Maybe he had a negative experience with Agile before and needs to observe first success to change his attitude.
2. Talk to him. Maybe he is not aware of his negative impact on the team and will be open to adjusting his behavior. Maybe another team member would like to discuss this with him as a peer.
3. Find out what bothers him. Maybe he is afraid that he will lose his job. For example, he is a manual tester, and the team is planning to implement TDD, he may be concerned. Address his concerns through discussing training options, or via internal experience sharing.

In any case, there is no easy answer, but as most conflicts, this can be resolved via open communication and positive approach. Let me know how it goes and whether any additional advice on next steps would be helpful.

Reply



Leave a Reply.

    About the Site

    The goal of this web site is to provide free advice and support to Agile and Lean coaches and practitioners at enterprise or team level.

    Archives

    February 2016
    January 2016

    Categories

    All
    Helpful Tips

    RSS Feed

    Subscribe to the Newsletter

    * indicates required

Services

100 Coaching Tips
Blog
Agile Lean Library

Company

Free Professional Advice

Support

About me
© COPYRIGHT 2016. ALL RIGHTS RESERVED.
Website designed by Max Shustef
Photos from symphony of love, turbojams, Geoff Moore UK, Gabi Sakamoto (Gah'Be), HolgerLi, mayankumar, Simon Blackley, North Carolina National Guard
  • Home
  • 100 Coaching Tips
  • Articles
  • OKRs
    • Agile DevOps
  • Blog
  • Books For You
  • Questions
  • About Me
  • Agile Metaphors
  • NYU Newsletter Feature