Start with Why Agile community is well known for transparency, supportiveness, and generous knowledge sharing – after all, this is what Agile is about. This is one of the reasons I volunteered for the Coaching Clinic. Having previously coached at BASD as well as the Lean Startup Conference, I expected to meet new people, support them in their exciting challenges and opportunities, and share my experience of nine enterprise-level transformations I was part of - and all of this happened, and much more. Gene Gendel who runs BASD coaching clinic since the first conference four years ago, made every coach and coachee (I am told there is no such word so I made it up 😊) feel welcome and comfortable. Anyone could sign up for any slot for anyone or for a specific coach, and there were always coaches available in the clinic area to answer any questions or to have a friendly chat with participants. It was a great opportunity to meet other coaches who are all great professionals well known in the field, and many of them are good friends since the first BASD. Everyone who came over for coaching was super nice, generous and grateful – thank you all for making this Clinic a success! Now about the specifics.
Who came for coaching? Among those who came over for coaching, there were accomplished and successful professionals in all areas of the enterprise, from large and small companies. Each of them is knowledgeable in their area of expertise and wants to get to the new level of their career, scale their agile adoption, drive continuous improvement in their enterprise, define roles and responsibilities, or hear about how others overcome challenges that they have. There were coachees who are in management roles driving change at the company level and those who are leaders even though they are just starting their career and work at a team level – as a software engineer, ScrumMaster or Product Owner. There were Agile Coaches and people who are completely new to Agile and want to know what it means. There were coachees who works in the entertainment industry, education, government, and transportation. There was one thing in common with everyone I spoke with – they were eager to learn and grow, and this is the reason each conversation was unique and inspirational.
What were the topics? There was no single topic – this is the beauty of coaching. You never know what are the questions you get or the topics you will be discussing but it always turns out to be inspirational for both coach and coachee, with great findings, sharing of ideas, and an opportunity learn from each other. Some of the topics that came up in my coaching sessions were related to scaling agile – how to adjust team-level agile practices to a growing agile practice with all the dependencies, program-level alignment and prioritization of value streams at the portfolio level. There were also topics about agile certification, career progression, and roles and responsibilities. We discussed the difference between a product owner and a product manager, as well as prioritization challenges at the backlog level and at the enterprise level. We spoke about professional challenges and difficult situations – the most important part of the Coaching Clinic is that each conversation is unique and fully targeted to the topics and experience of the coachees.
Conclusion. How different was 2018 Coaching Clinic from prior years? In my prior experience at BASD from the first year of its existence, the sharing and learning spirit is always present. There was a good structure in the organization, there were many coaches so we were able to help everyone, and the coaches knew each other well and had many meaningful conversations as we stayed in the area to be available to anyone who’s looking for us. Also, at times where we had more coaches than coachees, we did not wait for someone to come over, but rather, we engaged in meaningful conversations with conference participants and shared our experience without any specific structure. It was a great vibe, great people, and great conversations. Thank you to my fellow coaches, organizers, and everyone who came to the Coaching Clinic! Thank you to the Coachees for your kind feedback (pictures attached) - your generosity and partnership is the key to the success of our Agile Coaching Clinic.
There are many Agile myths which create unrealistic expectations that teams will switch to Agile and all their problems will be solved. Well, this is not the case, and when you here from teams "Agile did not work for us", you are dealing with a case of unrealistic expectations. To avoid this, I put together most common myths I'm used to. Please add yours to the list - I'm sure all of you had a fair share of those.
Myth 1: Agile is a project management framework.
Reality: Agile is a way of thinking. It is a set of values starting with our customer being the end goal and including team collaboration, commitment to quality, focus on people, empowerment and self-organization listed in Agile Manifesto.
Myth 2: Agile is all about processes.
Reality: Agile is about people, their collaboration, and orchestration of value delivery. Processes are a means to this delivery, not a goal.
Myth 3: If we are doing daily standups, we are Agile.
Reality: Agile is a mindset and doing any of Agiel ceremonies, does not mean that a team is Agile.
I took Agile training and got certified. Now I am an Agile professional.Agile (or Scrum) 2-day training and certification does not make you an Agile professional yet. It takes 2 days to get certified and a lifetime to master.
Myth 4: Agile means “no planning”.
Reality: Agile establishes a pre-defined cadence and makes the delivery transparent. Planning is performed continuously: from release to product to sprint planning to daily scrum. In Kanban, cycle time allows to predict delivery with accuracy. Every Agile framework has planning built into it.
Myth 5: Agile is equal to Scrum.
Reality: There are multiple Agile frameworks, and Scrum is most popular. However, there are many other ones: kanban, XP, and many hybrid approaches.
Myth 6: Agile works with software teams only.
Reality: Agile works for any team - software or business. It is important though to implement Agile thinking and build Agile mindset at enterprise level, otherwise teams will face multiple challenges coming from the waterfall mentality.
Myth 7: Agile teams have to be co-located.
Reality: Today's reality is that most software delivery teams are distributed. There are multiple tools for online collaboration and delivery, which are successfully utilized by Agile teams.
Myth 8: Agile works at team-level only and with small-scope projects.
Reality: Agile scales at the program, value stream, and enterprise level. There are multiple Agile scaling frameworks, depending on the organization, culture, and the type of business.
Myth 9: Agile means “no documentation”.
Reality: Documentation is very important. It has to be relevant and sufficient.
Myth 10: Agile work is hard to predict.
Reality: Agile work is highly predictable. In Agile, you know real-time how the team or program is tracking against objectives.
Myth 11: Managers are not needed in Agile.
Reality: Managers have a special role in an Agile enterprise. They build and support teams, remove impediments, provide coaching, support career progression of team members.
Myth 12: You can't pick and choose your Agile practices.
Reality: Agile is a toolbox - there are multiple tools and techniques to build the right combination for each implementation. At the same time, there are Agile non-negotiables, otherwise you will end up with “scrumbut”, such as "we are doing Scrum, but we are not doing retrospective. Continuous improvement is a pre-requisite for being Agile, so it is important to recognize and avoid "scumbuts".
Myth 13: In 2-4 Sprints, we can master Agile.
Reality: Agile is a journey and there is always an opportunity to improve. The most important value of self-sustainable teams is continuous improvement.
Myth 14: The goal of Agile is to increase velocity.
Reality: Agile optimizes value delivery and customer satisfaction, not just productivity.
Myth 15: Agile means "ad hoc".
Reality: Agile is highly structured and disciplined. It's oriented towards value delivery and driven by metrics on a daily basis.
The biggest myth: Agile is a silver bullet.
Reality: Agile is not a sillver bullet, it's a silver mirror. If won't fix the problems, but it will expose them to you so that you become aware of those and fix them. Prepare to work hard on your agile journey, otherwise you will end up in "Agile did not work for us" category :-)
There is a reason educators love playing games. Games promote learning. One-way information sharing is passive and does not stick. According to Michael Schrage, a leading expert on the relationship between technology and work, "the "serious play" that leads to breakthrough innovations is increasingly linked to experiments with models, prototypes, and simulations. As digital technology makes prototyping more cost-effective, serious play will soon lie at the heart of all innovation strategies, influencing how businesses define themselves and their markets."
No surprise that Agile is linked to playing. The creative nature of Agile environment demands active learning and innovation. This is one of the reasons why agilists from around US and many other countries gather annually for the Agile Games conference in Boston, MA. This year I had a privilege speaking at a conference. Actually, not speaking (surprisingly to those of you who are frequent conference attendees, PowerPoint decks and one-way training sessions are not welcome guests at this event) but rather, leading a 1.5 hour-long innovation workshop creating shared learning and ability to take a new look at well-known Agile challenges and resolve them. However, I will write about my presentation separately while this blog is dedicated to my "aha" moments from the conference, which I hope you can apply to your organizations and Agile teams.
I decided to select my ten favorite "aha" moments from the conference:
1. In his outstanding keynote, Thiagi shared many ideas about learning and playing. Check out his web site for a ton of games and organizational change cards. One of his thoughts was that we frequently rush to complete presentation or cover all materials within the time allocated. Don't do it! People remember unfinished business best. Just stop where you are and leave your audience craving for more. This will promote their learning experience.
2. Move around the room as you present. Do not create intense learning vibe in the front of the room where there are no participants. Go around the room and make everyone feel that they are in the front seat.
3. Thiagi taught us many games ideas, and there are even more on his site. Check out this goal setting game or the "35" prioritization game (which was introduced at the conference by Yuval Yeret). My favorite one was writing a topic on cards (one statement per each) and having people walk around the room introducing this topic to each other, and then selecting a winning card. I would use "creative plagiarism", as Thiagi called it, and have participants exchange cards with each iteration.
4. Another great game introduced by Thiagi was to have an SME recite a topic for 3 minutes, and then have teams ask each other 3 closed-ended questions (if the chosen team member answers correctly, the team receive 2 points, another team member - 1 point, otherwise 0) and then 3 open-ended questions (competition between the teams is resolved with voting).
5. Another highlight was the session by Yuval Yeret where he introduced two question/answer tools that can be used for decision-making, knowledge assessment, consensus building, or prioritization. The tools are kahoot.it and socrative.com. Check them out!
6. There were several lego sessions. My favorite was the retrospective session with Ellen Grove and Mike Bowler. We were supposed to build a lego composition that represents our feedback about the conference and share it around the table. There was colorful and creative compositions involved to share many helpful ideas. I am planning to use it at work.
7. The podcast which closed the conference was funny, smart, and thoughtful. It was improvised right in front of us. By the way, there was a great Improv session at a conference led by Todd Charron - I did not have a chance to attend but I heard a lot of laughter from the room that was neighboring with the one where I attended the lego workshop. And it was a great challenge: there were so many interesting choices that selecting a session to attend was super hard.
8. At the second day keynote by Rich Kasperowski, we learned about "modern Agile" which includes open space, besides other items. Open and informal nature of Agile is the heard of success. Rich also taught us how to do a "check in" exercise - we all enjoyed the experience, and even used it in the following session, FeatureBan.
9. FeatureBan lead by Andrea Chiou was fun. We simulated kanban and established experiential WIP limits. Our team, WIPless, increased throughput from 4 to 9 cards in three 10-day games. I also heard a lot about Laura Powers' session about Agile brain and her "Scrum. Or Not?" game from other participants and about David Graver's excellent session. Too bad I was not able to visit all concurrent sessions in parallel!. Meanwhile check Laura's site, http://poweredbyteams.com/. Based on the matchmaking game "Hot or Not" - the game "Scrum or Not" is designed to conclude an introductory scrum training workshop. It gives the group an opportunity to test their knowledge in a fast-paced game where everything is not scrum, but it certainly sounds like it could be.
10. There were many great sessions and learnings at a conference. One of the themes was storytelling. Let me tell you my own "wow" story from the conference. On the first day, I wanted to buy a new book on open space. The books were sold for cash so I decided to withdraw cash from an ATM later and of course, day 2 was so full with great events that I totally forgot. When I realized that I need to buy the book towards the closing session, the book table was already dismantled. I told my neighbor at the table, Mark, that I am so upset that I missed the book, and - what a surprise - I found out that Mark was one of the authors, and he kindly promised to send me the book by mail. What a coincidence! But wait: this is not the end of the story. In the end of the conference, there was a book drawing for five different books, and I won. Can you imagine my feelings when it turned out that I got exactly the Open Space Agility Handbook that I wanted!
Tomorrow is the Open Space which marks the last day of Agile Games 2016. This was a great experience, and I am going back home to start preparing for Agile Games 2017!
It is not news that Agile community is highly inclusive. Agile thinking is formed on collaboration, sharing, and transparency. So no surprise that Agilists love sharing: forums, user groups, meetups, conferences - you name it! I started with answering questions at LinkedIn Forums, then joined a number of meetups and user groups where I met great people who became my friends, mentors, and peers, and then discovered Agile conferences and gatherings. First, I joined as a listener, then was invited to present at one (it was Agile Day NYC in 2012 and then a follow up Agile NYC Presentation- an amazing experience), and then was invited again, then started applying for larger conferences and was invited to speak at some of them (rejected by others), and finally, decided to support one of those where I had a excellent experience as a presenter. Below are my findings and my advice for others who may be in the beginning of this journey.
1. Online Agile presence. As I mentioned, Agile community is super inclusive. Whether you are a starting Agilist or an experienced Enterprise Agile Coach, online communities are a great place for you to gain or share knowledge. I am part of multiple LinkedIn Forums such as this and event post myself.
2. The next steps for me was to attend Agile events. I started with local eventsl: from New York Scrum User Group, Agile NYC meetups, PMI Agile events, other Agile/Scrum meetups in New York and New Jersey. There, I met great people and dedicated Agilists who became my friends and peers over the years. Most of those events are free and highly informative. It is an opportunity to bounce off ideas, get professional advice, meet people who share your professional interests, and share what you have to offer. It energized me because I could support others in the community and learn a lot myself.
3. The natural next step was to host some of those events. It was a great experience. I hosted NY SPIN and PMI Agile Panel at Kaplan Test Prep where I worked at that time, and it allowed Kaplan employees and many people outside of the company to collaborate and shared their experience. I did not mention yet that all of those were free events (some of those may charge $5-$6 for pizza and drinks provided there because people come after work day and it is an opportunity to share professional interests in a warm home-like atmosphere). They are run by community enthusiasts who do not get paid or rewarded anyhow else but by communication and collaboration. Up until recently, I have not heard of a presenter (even well-known) ever paid for presenting at a meetup. I was sad to hear of a first instance recently and I truly hope it's an outlier. The one below is free of charge and open to everyone - feel free to join!
4. After these first successful hosting experiences, my colleagues and I co-organized our own Agile/Lean Practitioners Meetup at Kaplan Test Prep which is now in its fifth year of existence and unites 1,259 practitioners as of today. Recently, Jeff Sutherland presented at our meetup - my posting on this is is on my blog. But most importantly, over a few years it became an important destination for the tri-state Agile community and a great venue for sharing Agile and Lean experiences. This is where I presented on Agile topics for the first time for the external audience, and it was a professionally rewarding and encouraging experience.
5. The next step was organic: my colleague and I were invited to present at Agile Day NYC 2012, and the experience was overwhelming. The feedback from the audience and from several well-known agilists who were at the event was energizing and though provoking. This is where I realized that sharing your thoughts with a large audience gives you an opportunity to organize your thinking, to meet amazing people, and get the feedback that you cannot compare with individual learning. This is how my speaking journey has begun.
6. Last year, I presented at Big Apple Scrum Day (BASD). The topic was "Agile Coaching is Dead. Long Live Agile Practicing." I was concerned about the provocative nature of my title and wanted to hear from the audience how they feel about my take on Agile Coaching changing as a profession over the last few years. The audience was amazing. Despite the large number of participants, we had a dialog, and it was positive (despite the difference of opinions) and I learned a lot from the conversation (and so did the participants). I came home energized and excited. When I came to Agile Day NYC in the fall, it was great to see many BASD participants and exchange our latest news and get their advice and encouragement.
7. Then, a friend of mine, Dana Pylayeva (who I met through an introduction in her role as a BASD Conference Chair) suggested that I apply to speak at larger conferences, and I submitted my topics to the Agile Games, Global Scrum Gathering, and Agile Conference 2016. I was selected by Agile Games, and I am excited to present in Boston in April 2016. Will share this experience with you in my upcoming blog postings. Thank you for your encouragement, Dana! I don't think I would have courage if Shilpa did not introduce us and you shared your passion as an engaging and thoughtful conference speaker. But things happen for a reason, and I was ready for the next step.
8. Excited by the community and the experience, I volunteered to support Dana and the New York Scrum User Group community for BASD-2016, a non-profit Agile community conference. Until you participate in organizing one of those events, it is hard to see the amount of work that goes into those. Just some of the activities include finding and booking a venue that can hold 300 people (talk to me if you think it's an easy task in New York), setting up an engine to collect submissions, then forming and running a team of expert Agilists who will be selecting out of hundreds of great applications, tying it all into a cohesive agenda with parallel sessions, organizing the space and food so that every participant feels comfortable, enjoys the food and the experience, and then make everyone feel welcome while providing an encouraging venue for ideas sharing and making it both interactive and a deep learning experience for everyone.
All the people who participate in organizing those events do it in their "free" time after work and do not get any remuneration, except for the opportunity to contribute to this community. When I asked Dana why she is doing this, she shared that she felt as a long-time conference presenter that she wanted to give back to the community, and this is why she organized BASD, which is a huge success in its second year of existence (all tickets are sold out 5 weeks before the May 16th event). By the way, it's not too late to be a volunteer.
The reason I am sharing my journey from being an observer to participant to host to organizer is to encourage you to think where you are in this journey and where you want to be, and if you are looking for encouragement and advice in this journey, feel free to reach out - I'll walk it with you.
Today, Jeff Sutherland presented at Agile/Lean Practitioners meetup at Kaplan. It was a big event with over 100 participants from multiple meetups and a lot of practitioners and agile coaches. The conversation was about benefits of Scrum, and while it addressed a well known topic, it was a great refresher of Scrum non-negotiables and a reminder to the audience, as Jeff described it. The primary focus of the conversation was productivity, both sides of it: what increases productivity and what kills it.
I was not taking any notes but as I was listening to the presentation which included well known facts presented in a metrics-driven way with a good sense of humor, I was thinking through my current and previous experiences and trying to figure out whether we are following those practices or deviating without realizing it. Below are the ones that caught my attention:
1. Multitasking. Everyone knows that multitasking results in loss of productivity. I knew the context switching results in 20% productivity loss. What I did not know was that this metrics is related to context switching between 2 items. Once you get to 5, your productivity loss is 75%. This is a powerful proof of WIP, limiting work in process.
2. Happiness. When Jeff was talking about the concept of company success, he started with employee success, which provides immediately impact on company performance. According to Jeff, there is proven direct correlation. Happy employees - happy company. There is a direct dependency between RoI and level of happiness. His advice is: measure your employee happiness every sprint and pivot if needed.
3. Cross-functional teams. If we want to succeed, we form a cross-functional team. There may be specialists on it, but no one is exclusive and everyone can do job(s) of others. According to Jeff, a lean implementation will not be successful without a cross-functional or cross-trained team.
4. Swarming. Interestingly, the scrum framework has been patented under the word "swarming". Swarming is the heart of Agile. By swarming, Agile teams achieve shared objectives. Jeff sees swarming as the core concept in Scrum.
5. Kill impediments - Jeff's advice is to use "no prisoners" rule and kill impediments as they arise, no matter how complex or easy they are. Impediments should not be ever kept in the backlog for over 24 hours.
6. According to Jeff, all these rules similarly apply to software or non-software teams, this distinction is purely semantical from methodology perspective. Non-software team's agile is as basic and as important as a software team's.
These are the ones that resonated with me. Overall, there was a lot of helpful metrics and insights on productivity increase, lean principles, and kaizen thinking. A helpful concept that came up was the discipline within Scrum. As we know Scrum does not mean ad hoc, it brings transparency and cadence of execution. The example that Jeff provided was a CMMI5 company in Europe which increased productivity 5 times and reduced waste from 64% to 9% by moving to Scrum. Very impressive!
In sum, great points by Jeff. We all know them but frequently overlook, myself included. Let's stick to those because we know they work!
On November 3rd, The Agile Group of Project Management Institute’s New York City Chapter, invited me to speak to their members about Agile implementation at scale. It was an interesting opportunity to learn what the major challenges of Agile implementations from a project management perspective are and to share the patterns that make an Agile transformation at scale a success.
Leo Tolstoy’s book Anna Karenina begins:
"Happy families are all alike; every unhappy family is unhappy in its own way."
We can refer to it as the "Anna Karenina Principle" which is fully applicable to implementing Agile at scale. Imagine, you rolled out Agile in your organization successfully and your energized teams are delivering high quality software on cadence. What does management say next? Let’s scale! You coach more, establish repeatable practices, coach the teams, but all of a sudden, it all falls apart. Unmanaged dependencies, overlapping product backlogs, conflicting roadmaps which bring quality issues, delays in delivery, frustrated teams, and unhappy stakeholders.
Scaling Agile is still a hot topic years after the first failed attempts of Agile implementation at an enterprise level. There are many successful examples of scaling Agile at a significant scale. Between multiple scaling models (SAFe, DAD, LeSS) there is something in common that makes or breaks it. Remember the Anna Karenina Principle? "All happy Agile implementations at scale are alike; all unhappy implementations are different." The goal of my presentation was to offer practical advice for organizations that want to follow the pattern of "happy" implementations of Agile at scale.
The audience asked a ton of questions about each of the patterns presented. Project and program managers and directors of Project Management organizations wanted to know about Acceptance Test Driven Development (ATDD), program management in Agile, culture and resistance, the role of middle management in Agile, and multiple other practical topics of Agile implementations. It was a great sharing opportunity and a way to contribute to community knowledge.
You can find my deck from the presentation on slideshare.
Have you ever dealt with a skeptic in your organization who does not think that scrum masters bring value to the team? Who thinks that all that scrum masters should do is schedule and facilitate ceremonies, and everything else that scrum masters do - removing impediments, protecting the team from distractions, improving the process - the members of cross-functional teams would do without any problem. He views scrum masters as creating more work for team members in order to justify their own existence.
I know this is not the case. Without the scrum masters, team members will have to spend hours removing impediments, fighting with external distractions, and implementing improved processes on their teams. However, this is hard to quantify, unless we remove a scrum master from a team and measure their productivity before and after. But if we don't want to be that radical, what can we do?
The more I have been thinking about it and trying to quantify Scrum Master value, the more I realized that the best scrum masters are not those who are highly visible and vocal but those who are most supportive of their teams, who encourage continuous improvement, and make their contribution to the team almost seamless. This is similar to the race car mechanic who's not visible during the race but plays crucial role in the team success.
This thought did not help me with coming up with the proof of the Scrum Master value and an explanation that it won't be right to have team members protect themselves or remove impediments, such as coordination of development and deployment activities with other teams, changing priorities, and changes in team composition. So I posted the question onlinkedin forum for certified scrum masters (got several great ideas and a lot of encouragement) and did some research. What I found is fascinating! I truly believe that this is what defines a great Scrum Master:
Tao Te Ching Written by Lao-tzu Ch 17
When the Master governs, the people are hardly aware that he exists.
Next best is a leader who is loved. Next, one who is feared. The worst is one who is despised.
If you don't trust the people, you make them untrustworthy. The Master doesn't talk, he acts.
When his work is done, the people say, "Amazing: we did it, all by ourselves!"
Credit goes to Jeff O.
While this is so true, it is hard to prove the value of something that is not always visible and never is obvious. To understand the value that scrum master brings to the team, a good starting point is the checklist of things the ScrumMaster can look at and work on. Michael James from Danube has an excellent Scrum Master Checklist available for download. Another great Scrum Master checklist was put together by Bernd Schiffer who citesScrum Master manifesto in response to a common misconception that Scrum Master is not a full-time job: "We believe the Scrum Master is a full-time position for one person on one Scrum team ."
I would argue that the team won't achieve hyperproductivity without a scrum masters described in this checklist whose value is well defined by Bob Hartman. Both Bob Hartman and Michael James speak of intangible things - influence, sense of purpose, commitment - which translate into tangible outcomes which can be measured. Similarly, Len Lagestee speaks of "transformational leadership" - the role that scrum masters play on their teams supporting their path to greatness and about a leadership code of a Scrum Master.
This type of value is not easy to quantify. I like comparison of a scrum master with a football coach standing on the side-lines during the game. A football coach doesn’t play a position but they are constantly looking at how the team are interacting with each other. They know if the defensive line is being held too high and how the team aren’t working together to achieve a common vision. After the game the coach helps the team look at their performance for strengths and weaknesses, they’ll identify actions for potential changes and implement them incrementally. Although a football team may be able to play one or two games without a coach, other teams will eventually overtake them in ability and effectiveness.
This is not a question that has an easy answer. Working with multiple clients, I got multiple requests to hire Scrum Masters who can code in Java or to explain Agile to a Tech Lead in one day so that he add responsibilities of a Scrum Master to his technical and managerial duties. This will keep happening and Scrum Master responsibilities will continue to be questioned, but this situation will also produce amazing leaders who do not concentrate on titles and who are organic leaders - and servants - on their teams and organizations.
An exciting experience presenting at Big Apple Scrum Day 2015 and a great discussion about the future of Agile coaching as a profession. The full deck is posted here.
Moving from a consulting job to a permanent role in a new organization is never easy. From a consulting role with an airline industry client to an Agile delivery role with a major health insurance company - comparable size (160K+ employees), corporate culture, multimillion dollar projects, agile at significant scale and yet, everything was different and new for me there.
Multiple challenges, ultimate uncertainty, lack of buy in, significant resistance, lack of trust, strong waterfall mentality - everything that we are so well familiar with as change agents coming to an organization as agile coaches and leaving as part of the transformed and high performing work environment leaving high performing and self organizing teams behind. I did not come to my new job to leave though, the scope was unlimited and the amount of work would last long enough for a long professional life span and well beyond. I came to enlighten, transform, and execute.
I was excited. I had great conversations at multiple job interviews that resonated with me. Agile at significant scale, like minded agilists excited about building products that transform healthcare and delight customers. I did my research, asked a lot of questions, and felt that I was well prepared. I spent my two days before joining putting my 90-day plan together. It was a no brainer. Build relationships, create the team, hire as needed, put together a transformation roadmap, socialize, get buy in, come up with a training and coaching approach, position the team externally, empower them, get them the tools, identify continuous improvement opportunities, decide on metrics, start execution, compare the baseline with the first few sprints' data, and celebrate successes.
Pretty simple for a 90-day plan. I wanted to assess the environment and start whatever would take me to change the delivery culture and mindsets at scale. I was excited about my 90-day roadmap! It was following the SMART (specific, measurable, achievable, result-oriented, time-bound) format, so each milestone had specific acceptance criteria and the timelines. For example, I was committing to building relationships by introducing myself to 5 people per day within the first 10 days, 2 people for the following 20 days, and 1 person the remainder of the 90 days. There was a breakdown which areas of the organizations these relationships should come from because I wanted to cover software delivery, project management, product management, business side of things and other dedicated teams. All thought through in minor detail.
I started with a lot of enthusiasm of an Agile coach who came to an organization to stay, to transform it from waterfall to the collaborative culture of ongoing delivery. I was thinking hackathons, product workshops, innovation weeks, collaborative spaces, agile at scale, multi-day PI planning sessions, changing the way healthcare is administered and perceived. My 90-day plan was translated into color-coded stickies and attached to the wall in my office. I was all set and ready to sprint.
The following 90 days were a torture. My 90-day release planning for a new job was forgotten. It was an ongoing never ending set of challenges ranging from archaic engineering practices to the process challenges multiplied by the high distribution rate for team members, lack of trust with the business, and ton of inefficiencies. But the people were amazing and teams were willing, and the product team was a fountain of ideas and suggestions!
So I did my version of Agile maturity assessment, spent a lot of time with teams and stakeholders and while doing that, met like-minded people and created multiple task force teams to address prioritized action items for continuous improvement. We made it a rule that every day we want to accomplish something, even though it may feel small and insignificant. And each time a user story was completed, I moved a user story on our kanban board to the right column tagged as "Completed". I worked around the clock, worked directly with multiple teams, and somehow things started moving. The teams moved into a cadence, became higher-performing, were moving ahead fast, implemented ATDD, and were plowing ahead overall.
So one day I came to work, checked stickies on my 90-day board and was stunned to notice that all the stickies are gone from the left and the right column has them all as completed. All my tiredness was gone and I was more excited about my Agile delivery role than ever. The teams within my portfolio are not highly performing yet, but they are developing quality software at cadence, they are collaborative, innovative, empowered. Their technical maturity is growing. Team members work at sustainable pace. I looked at a calendar, and - surprise - it was exactly 90 days since I started my new employment. All of a sudden I realized that I've completed all my user stories - my 90-day sprint was not wasted. Just like Michael Watkins says in his book, "The First 90 Days", it is all about building momentum during a challenging transition.
So the momentum is built now. The transition roadmap is in place. This is where the power of the first 90 days is!
What can you use Agile and Lean for? Software delivery? Manufacturing? My answer: everything! Even running a company.
Let’s first consider the value. For me, as an Agile Coach and practitioner for many years, there are three things that make any Agile team successful:
As simple as it sounds, this is not easy to achieve: a team is going through multiple phases before it becomes high performing. A backlog is a product of multiple conflicting priorities and ambiguous features, and the cadence is frequently impacted by multiple emergencies and schedule changes. Yet, without all three components it is impossible to achieve an established velocity or high productivity.
In one of my engagements when I led an Operations team, I saw my role in leading and supporting the team in establishing our operational rhythm based on all three Agile components of success listed above, and this is how we do it:
1. Collaborative cross-functional team. Culture comes before everything else. It has been proven time and again that collaborative well balanced teams achieve success in every single area they choose, while a collection of brilliant misaligned individuals moving in opposite directions rarely is capable of accomplishing anything significant.
Everyone on the operations team was supportive and ready to swarm on high priority items no matter if they fall within their immediate area of accountability. How did we achieve that?
Step 1: We create a cross-functional epic to achieve any strategic goals, whether it is a new on boarding process for our consultants, or a company Meetup for our engineers - open to any technologists who would like to join us.
Step 2: For each cross-functional epic, everyone creates stories and tasks related to their functional area of contribution – for example, for the Meetup, our talent development team, CTO, marketing – everyone collaborates to make these workshops successful and informative for engineers.
2. Now the second component of Agile success: a healthy backlog. We have weekly sprints so our backlog is never stale. We do ongoing grooming during the sprint and we use persistent chat to discuss any questions related to priorities and time lines. When we need input from the team, we create tasks for our team members. Just-in-time tasking helps us stay current. The challenge of just-in-time tasking is to ensure there is a handshake and an agreed upon time line between the team members, so that the scope does not increase during the sprint. Our Agile tool, Jira, is a helpful mechanism of organizing our backlog and reflecting planning results in a prioritized and structured form.
3. The third component is the well-established cadence, or our operational rhythm. In order to stay in rhythm, we needed to define whether release planning applies to an operations team and whether sprint cadence works for us better than kanban, which is traditionally suitable for operations. We discussed our cadence at the latest retrospective, and decided to leave the rhythm of quarterly strategic planning, monthly release planning, and weekly sprint review and planning sessions, in addition to the daily stand up. We are still finalizing the format for each of these ceremonies.
What is my role on this team? Probably you’ve guessed already. As a team member responsible for running smooth operations, I act as a Scrum Master. No more status meetings or progress updates. Collaboration, alignment, open mindedness – these are all signs of a productive team. Our burndown chart and sprint commitment rate (the ratio of completed work to committed work within the sprint) are the best indicators of the predictability and quality of planning.
About lean: Continuous improvement is the heart of our Agile implementation. At every retrospective we come up with more ideas for how to optimize our processes, make them repeatable by creating checklists and templates, utilize modern tools such as online checklists or new Jira functionality – whatever it is, we are eager to try and learn. Once one of us comes up with an idea, the team discusses it and everyone is positive, open minded, and ready to try it out. If it works, we make it part of the process, if it does not, we pivot.
We do not wait for retrospectives to improve our processes. We try to come up with one improvement a day – whether it is installing chrome boxes in our conference rooms or turning one of the conference rooms into a cozy library full of technical and professional growth books. There are small ones, such as switching from a phone call to Google hangouts for our stand ups – but whatever they are, everyone feels ownership and support in introducing our “2-second improvements” every day.
There is a lot more I can tell you about how exciting Agile journey is for our team, but I do not want to give you impression that everything is perfect. We are on our journey to fine tune our rhythms and working towards commitment rate of 90%. Predictability of delivery is very important to us because our clients and consultants depend on how efficient and responsive we are on the operations side, so predictable and efficient operations are our utmost priority.
Transformation agent with experience in business transformation including transition to Agile (Scrum, kanban, lean) and building scaled Agile and Lean organizations. Passionate about motivating people and building great teams.