Full disclosure: I am an Agile Coach and an Enterprise Transformation Leader, and my knowledge of the work that surgeons do is based on my personal (very limited) experience. During coronavirus, I watched a few TV shows that I missed in my prior life and one of them, Grey’s Anatomy, resonated with me. I frequently found myself thinking that I’ve been in a similar situation with the organization that I am transforming, and decided to share some of my thoughts in this blog.
There is of course the obvious. As Agile coaches, we come into an organization to heal. Below is my attempt to “dissect” the concept.
1. Focus and relentless prioritization. Doctors start by addressing the direst problem first. This is exactly the same concept as a lean flow. In order to increase throughput, we need to address the bottleneck first. As the constraints theory teaches us, if we address anything rather than the bottleneck first, we will only slow down the process. This is why Derek Shepherd died in Grey’s Anatomy – the doctors worked extremely hard to save him but they failed to start with the most urgent problem - his brain bleed, hence the outcome.
2. Make decisions based on relevant data. When a surgical case is presented, the surgeons consider relevant data only. This is specific to each patient. Rather than measuring and listing everything they know about each patient, they start presenting the case by identifying each patient and then providing 3-5 factors that are relevant to the case. This reminds me of a question: which Agile metrics we should collect followed by a comprehensive analysis of all existing delivery data done every quarter. Instead, for each organization that we coach, we want to define a small relevant dataset and track this data to address the root cause until the next data point becomes a priority.
3. Identify and target the problem. There is no cookie-cutter solution to an Agile transformation, similar to no single cure for all patients. In each case, you make the assessment. It starts with the patient (organization) telling you where the symptoms are, and you as a professional, helping uncover the underlying root cause(s) and addressing them.
4. Set expectations from the start, be open upfront about risks, and don't fear failures. The healing process is not an easy one. It’s painful, it causes resistance, it impairs the patient, but it leads to a healthy long-lasting outcome. Similarly, in Agile transformation, it will get worse before the benefits become obvious. And sometimes both surgeons and Agile Coaches fail. Sometimes it’s their mistake, sometimes there is nothing they can do, but in either case, it’s learning, and they persevere and move forward – to the next patient to save, to the next organization to transform.
5. Identify meaningful OKRs. Objectives and Key Results that define success have to be meaningful, thinking otherwise leads to failures, sometimes irreparable. In Grey’s Anatomy, it was shown that when a company called Pegasus was buying the hospital with the only goal of making a profit, their decisions made a lot of damage – to people's morale and to the outcomes. A group of brilliant surgeons stopped being a team and turned against each other. This competition impaired teamwork and caused a patient’s death. Further, after Pegasus was gone, there was still the aftermath they had to deal with, sometimes not even being aware of the consequences.
A short-term gain of Pegasus cost-cutting caused a plane crash when their airline carrier was downgraded to a cheaper company. Moreover, it led to three patients dying because the surgical gloves were of low quality. This almost destroyed the new ownership who came after Pegasus and were not aware of these decisions. The long-lasting effect of the short-term cost-cutting was devastating, and the subsequent long-term investment by surgeons who were passionate about saving people led to rebuilding the hospital as the tier 1 trauma center.
6. People first. Whatever we do, it’s always about people. And it is not a general statement, it’s a fundamental concept of addressing any organizational transformation or any patient treatment process. I remember years ago when I was a software developer, we had a report distributed monthly: how many bugs did each developer produce during this month? The report would go to all developers in the department, and the ones who wrote clean code were celebrated. It did a lot of damage, and primarily, the damage of code quality. We got rid of this practice fast, but it taught me the fundamental concept that you get what you measure.
Measuring the right data leads to the right outcomes and vice versa. In Gery’s Anatomy, it was exactly the same situation. Once a poorly managed company with the wrong goals (profits vs. people) bought the hospital, they started measuring the death rate of each surgeon individually. Besides comparing apples to oranges (e.g. brain surgery has higher mortality rates than plastic surgery by default), it caused the opposite outcome. Do you think mortality went down? The wrong metric led to all types of wrong behaviors. The surgeons were not willing to take the risk, so there were more patients dying than before. This is the power of system thinking.
7. Focus on teamwork in a psychologically safe environment. As Agile coaches, we do not compare people or teams. We compare trends over time to understand where we can coach and improve the system rather than creating a psychologically unsafe environment of constant competition. Similarly, in Grey’s Anatomy, every surgery is teamwork – no matter how experienced the head surgeon is. There is work that nurses do day-to-day, and having the right team that a surgeon can trust is the fundamental constituent of success.
In Grey’s Anatomy, it was shown how Ben Warren as a nurse was able to solve major medical challenges that the surgeons couldn’t by observing and knowing his patients from an angle that was not known to them. An intern donated his blood and saved the patient when the blood bank was locked in a hacker attack. At the same time, there is always a lead doctor for each patient who has the ultimate responsibility for this patient’s health. This combination of empowerment and ownership in a psychologically safe environment is exactly what we as Agile Coaches are trying to build.
I am sure there are more things in common. We identify the problem, we work on a solution as a team, we support, and we cure. Are there any fundamental similarities (or differences) that I missed that resonate with you?
I wanted to give this article a different title, "What is good about COVID-19?" and changed my mind because I thought this would be too intense. I am very well aware that this is a global tragedy that kills people and poses a threat to the world economy. At the same time, my life’s motto is "Every challenge is an opportunity", and coronavirus is probably the biggest of all.
As a coach, I always tell people that we cannot change external events but we can change how we respond to them. There are things we can do about coronavirus (social distancing, supporting medical professionals, and influencing lawmakers) but as much as we want to stop it immediately, it will take time. Coronavirus is a huge challenge to humankind and a tragedy for many people around the world who lost their loved ones. Unfortunately, we cannot reverse that. There are also multiple opportunities that we can seize on a daily basis to help ourselves and people around us get through the challenge. There are many people who wrote so well about taking this challenge as an opportunity. Lyssa Adkins shared this beautiful poem with a powerful closing:
Promise this world your love–
for better or for worse,
in sickness and in health,
so long as we all shall live.
In difficult times like this, there are so many opportunities. I love the post by Rachel Ben Hamou on Medium on “Boosting Connection And Crushing Loneliness during epidemics”. As one of the ways to remain connected while being isolated, she suggested a check-out group exercise called Virtual Campfire. Check-outs are a quick way of polling people for reflections, which brings a sense of closure to the gathering and helps people mentally and emotionally transition out of the conversation.
In this exercise, each person in a remote location opens a campfire in a new window/tab on their computer. Then (one-by-one) they name something they are grateful for. Or something they observed. At the same time they symbolically throw an imaginary log onto the fire. Each person who completes a turn, names the next person until everyone has had the opportunity to contribute. As I am writing this blog, I have this campfire video on one of my four monitors - it brings me peace and quiet.
To contribute to all the goodness in this difficult time, I decided to use my profession of an Agile coach to find at least five opportunities that social distancing and self-isolation can bring us. I hope that you'll be able to add to those. Below is my list of five "opportunities" and related Agile tools and techniques:
1. Taking time to spend with our loved ones. Tool: Kanban board.
I work all the time. I have one full-time job and a part-time teaching job. I also have a husband and two kids that I wish I had a chance to spend more time with. Now I do. Instead of running to multiple activities - piano, swimming, social events, theater, movies, we are at home. We talk, we read, we beautify our house, and talk again. This is precious time. And - to maintain our rhythm - we use a Kanban board to manage our activities. Below is a picture - every team member (sorry -family member) is color coded. I am purple, my husband is yellow, kids are orange and green. We update it as we finish our activities and review daily together, right to left. We do it in Agile way - as a standup meeting which takes no more than 15 minutes for us to align on everything we've completed today and our plans for tomorrow.
2. Build relationships. Tool: Social Networks and communication software
It is very important to remember that these relationships are fueled by a sense of team, not physical proximity. I used these few days of continuously working from home to meet online with my friends from school in Moscow and my Stanford-era friends in California, which whom I rarely find time to connect anymore. I connected with Agile coaches around the world, learned a lot from Agile community in India and in Europe, and built meaningful online relationships - in forums, on LinkedIn, and professional associations' sites. In April and in May, I was scheduled to participate in two Agile and Lean conferences, and all presenters offered to present online to support the community and share knowledge. Look at this collaboration and the mutual support below related to cancellation of one of these conferences. I got to meet other presenters and connect with them in a way that is maybe closer than presenting in person.
3. Set long-term objectives Tool: OKRs
I believe in OKRs (Objectives and Key Results). I set my Objectives annually and review Key Results quarterly. This week, I had a chance to review my progress a few weeks earlier that the end of this quarter, and found out that I still have a chance to complete some of the first quarter Key Results and course correct on the future ones. Having a chance to stop and reminisce allowed time for long-term thinking and reflection. Below is the result:
4. Read and learn Tools: online learning, books, professional associations, MOOCs
This extra time saved from commute and in-person activities is a great time to learn online, update your certifications, or read a book. There are multiple other tools to learn from the community, For example, New York Scrum User Group is celebrating World Retrospective Day on March 26th with a Resilient Retrospective Experiment for World Retrospective Day. As one of the organizers, Dana Pylayeva puts it, "You've planned a perfect retro for your team, brought in creative props just to discover that most of your team members had to work from home on this day. You've pulled together best activities for your large scale in-person retro, yet COVID-19 arrived with all its travel bans. Don't be afraid to change!
Join us to participate in a NYC SUG large scale experiment and celebrate the World Retrospective Day. 100% virtual, 100% awesome. Learn how retrospective face-to-face activities can be adjusted to a new distributed reality. Discover together what works best and what fails spectacularly! Multiple facilitators, parallel discussions, one-on-one connections - you will experience it all and get inspired to re-create this level of engagement with your distributed groups."
If you need any suggestions, below are a few books I've read this week that I would recommend you:
5. Stay more connected. Tools: JIRA, Trello, Kahoot, Skype, Zoom
Many companies, universities, and schools switched to online education. Many employers had a hard time switching their employees to word from home and, surprisingly, after overcoming initial network-related hurdles, we found out that there are multiple tools to align and support each other while working from home. In the Agile world, we use JIRA, Trello, or similar tools to align on our work, we meet daily online for 15 minutes to align on our work, and show working work to our customers at a regular cadence - all of it works very well online.
I teach Agile Project Management class at NYU, and last week, we moved our classes online using Zoom. I was concerned because this is a highly interactive class, but I was able to use multiple interactive tools - kahoot, it, Poll Everywhere, whiteboarding, and chat. I have a large class (25 students) and the chat allowed everyone to communicate actively during the class in a synchronous way. I was pleasantly surprised when the students told me that they loved the class because I encouraged them to type their comments in the chat whenever they have anything to say and addressed each one of them throughout the class. For the next class, I plan to do a "Traffic Light check-in" before the class and an Agile Retrospective in the end.
From the global perspective, coronavirus allows us to stay connected in face of a major threat, support each other, and contribute to overcoming this challenge. And as we do it, I hope we stay grateful to those who fight the challenge and help people get through it - doctors, nurses, chemists and pharmacists, government officials, people like you and I - everyone who will stay strong and get through this together, while enjoying every day we got and every opportunity to make a difference.
I'd like to hear from you: what are the opportunities that you see and how are you utilizing them? Please share your ideas, suggestions, or invite others to share a virtual connection, learn, and collaborate.
"There are plenty of concurrent sessions going on here at Agile 2019 in Washington DC. About 20 options to choose from every 90 mins!
"Tuesday conference at hashtag#agile2019 was great. Heard the talk from Dominica DeGrandis on how to make better business decisions with flow metrics. We should align and focus on what key metrics that biz understands. Use other metrics such as velocity and committed to done for team retrospective for continuous improvement.
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 the "Agile did not work for us" category :-)
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 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.
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.