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 for 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 to 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 one. 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 ideas 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 on 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 by 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 for 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 wasn’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 the 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 handoff 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 with 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 of 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 involved with the teams on a daily basis, but unfortunately, they weren’t ready to break down 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 team players, 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.
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, and 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 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 was 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 among 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 in 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 that 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.
Like Susan Evans, I want to change jobs so that I enjoy working again. Job Satisfaction Acceptance Criteria:
- To make a difference and help people and organizations be happier and more productive and therefore proud of my
- 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.
- Work for an agile organization (I can NOT go back to the “dark side”)
- Work for an established and stable medium-‐size company where I can work with and get exposure into many
- 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.
- I want to be challenged and provided the opportunity to learn and grow my skills.
- 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 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 afterward. 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, 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 building 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 my 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.
- 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.
- 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.
- Work for an established and stable medium-‐size company where I can work with and get exposure to 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
- 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 also experienced firsthand the Product team engaging with customers to get feedback.
- 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
- 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 the advantage to have interacted with many executives on a variety of occasions to see them as they truly were.
- 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 criterion 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 have 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 processes 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 where 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 grow 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 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 a 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 were 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
