99 Problems but a Coach Ain’t One

This is a very personal story of my evolution from an internal coach fighting the culture to becoming a consultant and working with companies and individuals who want to improve.

1. INTRODUCTION

Life as an agile coach is never dull, with everything from  growing, shrinking, international, self-­‐managed and completely  brand-­‐new  teams,  to  backlog  management,  code  deployment,  production  support,  and  old  school executives who want one throat to choke. It can be overwhelming to check one issue off the list yet feel that   you have 99 more to address. It can feel like you are fighting a losing battle and no longer have the ability to influence anymore. In this report, I’ll cover how I had to coach myself to see that I was making a difference and accept that being a passionate agile coach was NOT one of the problems. I’ll also provide insight into how I handled some difficult and frustrating situations, and ultimately used the agile principle of “inspect and adapt” to inspect my job satisfaction and make adjustments for the better.

 

2. BACKGROUND

I started my career as a Business Analyst and Project Manager in a traditional waterfall world. I worked for a small company that was a reseller of document imaging hardware and software. I provided BA / PM work for a variety of companies in a variety of industries. It was an amazing experience where I gained a lot of knowledge not only for my position but also on business politics. Unfortunately, the company went out of business, so I moved  to  a  medium-­‐size  company  where  I  was  the  BA/PM  for  software  development  projects.  It  was  during this time that I realized traditional project management was just not conducive for software development. I knew my day as a traditional project manager had come to an end when I all but refused to create an elaborately detailed project plan and provide a baseline. “Why? Why bother? We know everything will change! This plan will be different two weeks into the project and even more different two months in! There’s got to be a better way.” And thankfully, that’s when we went through our agile transformation! We wanted to sunset a product, but we didn’t have enough people to keep the old system afloat while building the new. Therefore, we hired a consulting company to build the new product and a part of their contract was mentoring us during our agile transformation. I was so grateful to observe an experienced Scrum Master conduct the ceremonies with an  established  cross-­‐functional  team  for  6  months  before  I  became  a  Scrum  Master.    Since  I  had  been  a Business Analyst and Project Manager, I could have become a Product Owner, but I chose to take the Scrum Master route as it was a better fit for my personality. I was a dedicated Scrum Master for two teams for only 6 months when I was recruited by an acquaintance to work for a digital marketing company. They needed a Project Manager to continue leading the agile transformation they had just started. They were 5 sprints in when  I  started  and  had  5  co-­‐located  teams  that  on  occasion  had  cross-­‐dependencies.  I  was  the  only  Project Manager responsible for overseeing projects through the entire agile lifecycle from idea to beautiful working software in our customer’s hands.

 

3. MY STORY

3.1 When things got frustrating…

After the first 9 months of addressing the easy low-­‐hanging fruit, I decided it was time for a refresher for the organization. I contacted the company that conducted my Certified Scrum Master class and arranged an off-­‐site all-­‐day agile bootcamp. I was thrilled that the CTO and executives from Product, Development and Operations were in attendance as well as the delivery and support teams. After the first hour, our consultant, John Miller,  realized that we didn’t need a refresher of the basics; instead, we needed to dig into some deeper topics. He did an excellent job addressing the executives’ concerns and I felt we covered some tough topics that I had been struggling to convey. It took some time, but eventually we made big changes that were largely influenced from this one-­‐day session with a consultant.

We shifted from managing projects to managing products: we  aligned  teams  to  a  product  that  had  a  dedicated Product Owner. This allowed the Product Owners and Teams to establish expertise and depth in one product instead of just getting by on a wide variety of products. Excellent! We established that the Product Owner   meet   with   the   teams   weekly   to   refine   the   backlog   for   1-­‐2   sprints   ahead   of   the   current   sprint. Unfortunately,  these  weekly  meetings  didn’t  have  full  buy-­‐in  and  were  not  done  consistently.  I  was  fighting against  a  long  history  of  last-­‐minute  complete  changes  of  priority.  Our  product  relied  heavily  on  3rd  party integrations; if the connection went  down  for  10  minutes,  we  lost  thousands.  Therefore,  when  the  3rd  party  said “Jump!”   We had to say “How high?”  They were notorious about telling us, “this change in our product is going into effect in one month and you need to update your  connections  before  then”.  Needless to  say,  we  weren’t 100% in control of our backlog.   It didn’t matter how many times the Product Owner explained to the    teams why priorities were shifting; they lost trust that the Product Owner was leading us in  the  right direction. It was very discouraging for the teams to work hard on a project only  for  it  to  be  put  on  hold  and  never  revisited. Therefore, Product Owners and Team Members alike felt it was a  waste  of their time to refine  user  stories even one sprint ahead, since the odds  were  high  that  priorities  would  change  and  they  would  never  work on those user   stories.

Later that year, I attended the Agile Alliance conference and became energized with lots of new ideas. I was overwhelmed with things I wanted to do and areas to improve but I knew I couldn’t do it alone. I voiced this concern to an agile coach while at the conference and she suggested that I start an Agile Community of Practice. When I got back to the office, I posted all of the issues with our entire agile lifecycle process and asked each individual to dot-­‐vote on the ones they felt needed to be addressed first. From there, I created the backlog that the committee would work through to improve our agile process. Once a month, the committee would meet and we would plan which items we would work on for the month, with weekly stand-­‐ups along the way. There was a great turnout for the first planning session and a handful volunteered to help. Unfortunately, attendance at  the  stand-­‐ups  weren’t  as  well  attended  going  forward,  and  with  each  planning  session,  the  audience dwindled to just two who didn’t have the capacity to help. This was very discouraging and spoke volumes   about the culture. It was ok to complain about process and not help to do anything about it. It was someone else’s problem to fix.

And then, we added off-­‐shore teams. The initial plan was to have two off-­‐shore teams which could provide production support during our off-­‐hours and would create automated tests. Quickly, two teams turned into five and our problems were compounded. Not only did we have completely opposite time zones with no  overlapping business hours, but we had a HUGE communication issue. One manager and one architect in the off-­‐shore  office  knew  English;  after  several  small  miscommunications  (does  vs  doesn’t,  on  vs  off,  etc.)  a translator was hired to manage all communications, written as well as audio. It was extremely difficult for developers to provide feedback from code reviews. More often than not, the on-­‐shore teams had to work long hours  before  every  weekly  deployment,  correcting  code  that  was  checked  in  by  the  off-­‐shore  teams.  The  on-­‐ shore teams could only tolerate that pace for so long. With no improvement in sight, half of the individuals on the on-­‐shore teams left for other opportunities. The Product Owners gave it their best too by conducting Sprint Planning  sessions  during  off-­‐shore  business  hours.  They  would  use  a  web  meeting  tool  with  the  webcam hoping  for  better  communication  and  understanding  of  the  acceptance  criteria.  Unfortunately,  the  off-­‐shore teams lost the Product Owners’ trust quickly, which led to reverting from User Stories back to Requirements Documents. The VP of Product was adamant that due to the ‘hand off’ of information and the lack of daily interaction, the way requirements were given to the teams needed to go back to the way it used to be. I was getting worn out by fighting for Agile and always trying to put a positive spin on things.

On top of that, I was constantly trying to find a compromise that would provide the operations and database architects  a  solution  for  the  high-­‐level  design  that  they  required, with  just  enough  information  that  the  team needed.  The  architects,  who  had  a  lot  of  influence  and  executive  support, really  liked  the  big  up-­‐front  design approach and found it very difficult to support a design in our iterative approach  of defining just enough, just in  time. We asked a member from the operations team to  attend  Sprint  Planning  and  the  Sprint  Demo  so  they  could see what the team was going to work on and what was delivered. They said those ceremonies were not technically detailed enough and they wanted to know as soon as something changed instead of at the end of the sprint. Therefore, we tried having them attend the daily standup, so they would know the day something changed,  but  they  felt  that  to  be  too  time-­‐consuming  and  we  were  frustrated  because  they  weren’t  paying attention during the standup. Since none of the existing scrum events fit their need, the teams had to schedule design review meetings when a large effort was starting and every story that went towards it had a task to conduct a technical review with operations and database architects. I was trying to show the value of having a member of operations being involved with the teams on a daily basis, but unfortunately they weren’t ready to breakdown  that  silo.  That  would  have  been  a  great  step  towards  truly  cross-­‐functional  teams  having  all  the skillsets and permissions needed to take an idea and get it into production.

Our teams were cross-­‐functional with one database developer, 2-­‐3 middle tier and UI developers and one QA engineer. The Scrum Master role was shared by a member of the team and would rotate when the team felt it was time. The teams all sat together in an open space environment and eventually the Product Owner even moved to sit with the team full-­‐time. The annual appraisal evolved to include a rating on the individual’s ability to be a team member instead of a stand-­‐alone rock star. We also changed the interviewing process to include a meeting with me, where I would explain our agile environment and make sure they would be a good fit for the culture. It was important for candidates to know they would be expected to respond to changing priorities, be a team player, have flexible business hours with the opportunity to work from home and support remote teammates, and sit in an open environment. The company promoted a fun work environment that included serious competition play of ping pong and foosball and was alcohol friendly. In fact, the company provided 2 kegs on tap. As great as that sounds to some of us, to others it was a complete culture clash that they would struggle to be successful in.

With every issue we improved and checked off the list, it felt like there were 99 more to address, with the hard  executive  and  cultural issues at the  core. As a  coach, ‘keeper  of project management’, with a growing  list of issues to address, you feel like you have the weight of the world (well, the company) on your shoulders and it is up to you to champion improvements in the ‘broken’ process. I was able to get the right people together to talk through the issue and determine a solution. We even communicated the process change to all involved so the issue wouldn’t happen again. However, many of the decision-­‐makers and key leaders never changed their ways to follow the new process. I took this very personally -­‐-­‐ thinking that they did not respect me -­‐-­‐ and I felt like a failure. Executives still wanted ‘one throat to choke’ instead of understanding that a self-­‐managed team either succeeds or fails together, not due  to  a  command  and  control manager. As hard  as it was for me  to  admit, I found that as the internal coach, I was no longer being heard and therefore no longer making a difference. My confidence  was  shaken.

I drew the diagram below of all the areas that were still having issues. I’ve described a handful in this  report, but as you can see, there were many more issues still remaining and I didn’t have the strength to  continue fighting for improvement.

3.2 What I did

I started coaching myself. I read Lyssa Adkins’ book “Coaching Agile teams” for new ideas and reassurance  that I was doing what I was supposed to be doing. One suggestion that really resonated with me was to conduct a personal coach’s retrospective. Each team conducted retrospectives and always had things that went well, but I couldn’t always say it was because of my influence, therefore it was hard to see my worth. I started a list of accomplishments and called it my ‘Proud Mommy Moments’. Lyssa Adkin’s was right when she stated that “you may well discover the value you delivered but couldn’t see”.

When times were tough, I would reflect back on this list and occasionally would review it with my boss.

Some examples included:

• Product Owners started regularly attending daily standups, owned their projects and statuses and became a part of the team. Therefore, the weekly PMO meeting was no longer about scheduling projects but instead more about validating that we were following the process according to our success criteria
• During the Sprint Demos, originally I would review the team’s burndown chart and explain why they did or didn’t meet their commitment, and then the team would show their beautiful working software. We changed our approach so the teams started presenting what they had worked on and explained their situation. This put more ownership on the team to meet their commitment instead of using me as a crutch to buffer
• We conducted a ‘draft’ where individuals signed up to be on the team / product of their choice which followed by a smooth kickoff of new teams that picked names, chose scrum master, created mission statement and Definition of Done, moved desks and assigned work to new teams in VersionOne, an Agile Lifecycle Management tool that supported our agile
• We established a production support system where production bugs would be triaged by DevOps and if development was needed, then it was routed to the appropriate product team to resolve. There was a rotation between the developers on who would be production support during that sprint. The executives understood that the team’s velocity would go down but the management of support would be consistent and addressed faster. I also loved that it was a great way to hold the team accountable for quality work since their own bugs were going back to the team to
• A naysayer developer began supporting the use of story points and velocity and even showed a new hire how to use

 

I’ve always said that a good portion of my job as an agile coach is to be an occupational therapist. Thankfully, I had people that I turned to who returned the favor. Through several conversations, I came to accept that a passionate agile coach was NOT one of the problems. I stopped blaming myself for the failures. I can provide guidance, therapy sessions, suggestions and pros and cons around decisions but I couldn’t make them do anything. While it was my responsibility to set and communicate the process, it was not my responsibility nor did I have the authority to force individuals to follow it.

I strongly believe that if there’s anything in my life that I’m unhappy about, it is only up to ME to do something about it. So when I found myself considering a complete career change, I knew it was time to inspect the situation and see what needed to be changed. To make a difference again, I needed to be empowered to influence the culture, which meant I needed to be a peer with the executives as a Director of an Agile PMO. I  had just started reporting to the CTO and we had a long talk about his expectations for project management. Unfortunately he was not interested in an Agile PMO Director so this solution was not available to me. In fact, the environment that he described and would support was not one that I would thrive in, for example:

• More focus on capacity planning by individual / skill set instead of measuring velocity for a cross-­‐ functional team
• Stop automated test creation efforts and unit testing with no increase of QA members
• Decrease code deployments from weekly to every two weeks or longer
• Preference for functional requirements documents for projects instead of user stories in a product backlog

 

Therefore, it was my time to evolve and move on to a new opportunity. I told him that day that I no longer wanted to work there and he wouldn’t want me there unhappy. Thankfully we worked out an  agreement where I would finish out some initiatives that I had started while allowing me time to get on the job market. I was proud of myself for following my heart but was terrified that in five short weeks, I wouldn’t have a job.

I asked myself ‘What do I do now? What kind of company and industry do I want to work in? What will  make me happy?’ To help provide focus and know my priorities, I wrote a simple user story with acceptance criteria.

As Susan Evans, I want to change jobs so that I enjoy working again. Job Satisfaction Acceptance Criteria:

1. To make a difference and help people and organizations be happier and more productive and therefore proud of my
2. To respect the leaders of the company I work for in their ability to grow the company and do the right things for their customers. I want to work hard to make money for my executives.
3. Work for an agile organization (I can NOT go back to the “dark side”)
4. Work for an established and stable medium-­‐size company where I can work with and get exposure into many
5. The culture of the company must be casual with attire and work hours and strive to have happy employees with fun activities during and after hours. I want to feel a part of a hard-­‐working family.
6. I want to be challenged and provided the opportunity to learn and grow my skills.
7. I want a supportive manager who will trust me to do my job to the best of my ability and provide guidance when necessary.

 

As the administrator of VersionOne, I had formed relationships with a variety of individuals at VersionOne.

Since I was local, I invited them to attend a ‘how we use VersionOne’ session and enjoyed  a  fun  lunch  afterwards.   At the Agile Alliance conference, I attended the customer appreciation party and  would hang out at the booth chatting with a variety of executives, marketing, sales  and  agile  consultants.  I  appreciated  how  everyone was honest, down to earth and easy to talk to, fun and passionate about their job. I always felt at ease and enjoyed myself when interacting with them. I became a part of their VersionOne + 1 community where twice I went on-­‐site to perform user experience testing and provide my feedback to Product Management. The fun environment at their office reminded me so much  of  what  I  enjoyed  at  my  current  job;  pool  table,  ping  pong, darts, keg on tap and a full bar. Unlike my current job, it  was  obvious  that  the  VersionOne  employees enjoyed spending time together and built relationships as friends and  not  just  colleagues.  Therefore,  when  I  found myself on the job market, the first person I contacted was Robert Holler, the CEO of VersionOne.  I told him my situation and asked if he had any suggestions on what to do next. I was considering becoming an agile consultant and was curious about the day in the life as an external coach. Robert put me in contact with some fabulous agile consultants at VersionOne who graciously spent three hours over dinner discussing all of my  concerns. They  explained  how  they  recognize  each  consultant’s  experience,  strengths,  and  weaknesses  and  how they work together as a team to support each other and build their skills. Since I had never been a consultant before, I was excited to learn about the on-­‐boarding process and was assured that ‘we’d build you up so you can stand on your own’. They reviewed a typical workload for a consultant that included short engagements  for  3-­‐5  days,  not  3  months,  with  the  expectation  of  50%  with  clients  and  the  other  spent  on thought leadership in the industry  (blogs,  speaking,  conferences),  travel  time  and  administration  (booking  travel, expense reports, preparation for engagements etc.). I left that night knowing that my heart had led me to VersionOne and becoming a consultant for them would satisfy my acceptance criteria.

 

1. I want to be challenged and provided the opportunity to learn and grow my
   • The agile industry is always evolving. Being engaged in the agile community and staying up to date with the latest practices is a part of the job. I would never run out of ways to grow my skills.
2. The culture of the company must be casual with attire and work hours and strive to have happy employees with fun activities during and after hours. I want to feel a part of a hard-­‐working
   • I experienced the culture and camaraderie many times and it was exactly what I was looking for.
3. Work for an established and stable medium-­‐size company where I can work with and get exposure into many
   • I learned that the first instance of VersionOne was launched in June 2002 and the company had just over 100 employees with great potential for
4. Work for an agile organization (I can NOT go back to the “dark side”)
   • Not only was the VersionOne tool built to support agile teams but I learned that every employee became a Certified Scrum Master regardless of the department -­‐ even Accounting and HR. I had also experienced firsthand the Product team engaging with customers to get feedback.
5. To make a difference and help people and organizations be happier and more productive and therefore proud of my
   • I would be working with clients who hired us to help
6. To respect the leaders of the company I work for in their ability to grow the company and do the right things for their customers. I wanted to work hard to make money for my
   • As a customer, I had the utmost respect for the CEO Robert Holler who was an obvious servant leader and cared for his employees and customers, the Director of Product Management Mark Crowe who truly listened to me as a customer, and VP of Sales Richard Fuller, CTO Ian Culling, and VP of Alliances Paul Culling because of how welcoming, genuine and fun they were at the Agile Alliance conferences. I had such an advantage to have interacted with many executives on a variety of occasions to see them as they truly were.
7. I want a supportive manager who will trust me to do my job to the best of my ability and provide guidance when
   • Since I didn’t know the services manager well, this is the only criteria that I didn’t know for certain would be satisfied. The consultants that I talked to spoke highly of her and based on the other employees I did know, I trusted that she would be great to work

 I’m proud to report that I joined the VersionOne family one week after leaving my previous job. Everything happens for a reason!

3.3 Results

Working for VersionOne as a Product and Agile Consultant has been a dream come true. All of my job satisfaction Acceptance Criteria has been met and I couldn’t be happier. Being a consultant and traveling for my job was new to me so thankfully I had the opportunity to shadow some talented individuals to get my feet wet, show me the ropes, and build my confidence. I’ve experienced agile failing fast but I’ve also experienced lots of inspecting and adapting that leads to success. As a consultant, I have the chance to share my knowledge and experience with the goal of steering clients away from failure and closer to success. What I love is that I get to help clients in a variety of ways so I never get bored. No two engagements are the same with different clients and their unique cultures, different cities in different seasons, and all of the lively individuals that I meet. I’ve been fortunate to work with clients by learning their process and helping to configure and implement VersionOne to enhance their agile practices. It’s a great coaching opportunity and a chance to gain insight into how different companies operate. I also have engagements where I train people who are new to VersionOne or who want advanced training. Both are very satisfying by being able to help people be more proficient with VersionOne making their agile process that much smoother. I’ve also had the privilege to guide clients through their agile transformation. It’s so rewarding to have people repeat back your words to you and truly be excited to try something new.

I  thought  I  would  miss  being  embedded  with  teams  long-­‐term,  but  I  feel  I  have  the  best  of  both  worlds.  I have clients that I have the honor of working with on many different occasions but as a consultant, I’m not impeded by their politics. I also have fun quick engagements that I can provide some guidance and leave a hero. The tough part is remembering that I still can’t make them do anything. They can implement my advice or not, but I hold my head high knowing I had done my job as a consultant by providing options on ways to improve. My knowledge and passion for agile grows daily and I can’t help but love what I do. Several times I leave engagements on such a high thinking ‘I had so much fun that I can’t believe I got paid to do that!’ As my Dad used to say, ‘Just another day in paradise!’

 

4. WHAT I LEARNED

I used to think that asking for help from a consultant would mean that I had failed and I was not capable of doing my job as an internal coach.  I’ve learned that sometimes all it takes is for a respectable consultant to  take a fresh look at the situation and provide their guidance. On many occasions, I have had the agile coach, scrum master or agile evangelist come up to me after a consulting session and say, “you just said exactly what I’ve been saying for months but they acted like they were hearing it for the first time. Thank you for getting through to them.” Therefore, my advice for anyone feeling that they aren’t making a difference anymore, is to ask for help. At the digital marketing company where I had worked, we had made great strides with the agile refresher / consulting session provided by John Miller and I should have had him back again. If you can’t get approval to hire a consultant, then go to your local agile or scrum user group meetings and network with other agilists in your area to get their advice or fresh look at the situation.

I am a Certified Scrum Master, not a Certified Scrum Product Owner, so my product coaching at the time was minimal. Since then, I’ve recognized my weakness and spent as much time as possible shadowing a colleague who was a strong Product Owner coach. I learned techniques such as; Story Mapping and how it is a great tool to help identify gaps and the Minimum Marketable Features, Weighted Shortest Job First to prioritize a backlog, and Empathy Mapping to characterize personas. Also, my confidence and messaging was weak on why to use User Stories over traditional requirements. Therefore I read blogs, watched videos and would engage in conversation with other consultants to get stronger at conveying the importance behind User Stories. Maybe the most important lesson is to know what you want and do everything you can to get your personal acceptance criteria satisfied. Now as an Agile Consultant, I get the satisfaction of helping people with every engagement. Therefore, I no longer need to keep a list of Proud Mommy Moments as reassurance that I’m making a difference that I so lacked before. My confidence is back and I know that being a passionate agile coach is not a problem.

 

5. ACKNOWLEDGEMENTS

I wouldn’t have been able to pursue this career if it weren’t for my very supportive husband John Evans, who also works and does a great job of holding down the fort while I’m on the road. I’m thankful beyond measure.

Thanks, too, to Troy Larson, Scott Brown, Mike Simpson, Nogol Tardugno, Donella Cohen, John Miller and Luanne Willimon for listening, being a friend and coaching me through a very difficult time in my career.

Brian Watson and Matt Badgley for seeing my potential and helping to bring back my confidence. Sue Burk, my shepherd for keeping me focused and providing many edits while drafting this report and to VersionOne for allowing me to expand on my blogs and create this report.

 

REFERENCES

Adkins, Lisa. “Coaching Agile Teams: a companion for Scrum Masters, agile coaches, and project managers in transition” Pearson Education, Inc., 2010