 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.
0 Comments
 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.  No one needs to prove that Agile is a modern delivery framework. According to VersionOne’s State of Agile Survey for 2015, 94% of all organizations surveyed are practicing Agile. In addition, 45% of respondents worked in development organizations where the majority of their teams are Agile. Contrast this with the 2009 report: only 31% of the respondents worked in organizations with zero to two teams practicing agile. There are multiple successful Agile implementations with well documented case studies around them.
We cannot state the same about scaling Agile. There are several frameworks: Disciplined Agile Delivery by Scott Ambler, Scaled Agile Framework (SAFe) by Dean Leffingwell, and Large Scale Scrum (LeSS) by Craig Larman. Introduced by three different thought leaders, each framework generated communities of practice and a number of positive stories related to successful implementations. That being said, each of those frameworks requires deep analysis and experience in scaling Agile in order to be successful. Frameworks define the approach and the implementation paradigm, but in each case it is the methodology built on top of those frameworks and the company-specific execution that makes or breaks it. At InRhythm, we have been providing enterprise level Agile support for almost 10 years, and we have our own defined methodology. When SAFe was introduced, we felt that our experience and approach resonated with the crispness and the combination of Agile and Lean practices defined by SAFe. Our current approach to supporting large organizations in scaling their Agile delivery is based on three steps:
How did this collaboration happen? Our company's goal is to bring thought leadership to our clients and support change within their organizations. The clients who bring us in are the leaders within their organizations. We come in as change agents to support their commitment to continuous improvement. This is how this company, via a prior client referral, brought us in to support their commitment to scaling Agile. Initially, a team of Agile coaches came on site to meet with their executives, team members, as well as product and delivery managers. The team attended their Agile ceremonies, reviewed artifacts, and mapped their delivery processes. Their receptivity to change, open thinking, and positive attitude still resonate with me. I felt proud to have had a chance to collaborate with such a strong leadership team. We were able to identify their areas of strengths, which they could build upon, as well as provide practical advice on areas of opportunity that, if addressed, will expedite delivery and support quality at the portfolio level. Based on our findings, we created a customized training curriculum to provide specific implementation details to the teams within a large portfolio. Once this was shared and presented to the client, we were excited to head back on site and provide the training, which we certified with the Scaled Agile Academy. The training covered how a large software delivery structure should be organized, how to manage dependencies, how to identify priorities at release level, how to build program-level engineering practices, and several practical details of scaled Agile implementation. In addition, we discussed how each of those principles applied to their specific organization:
The next step includes coaching Agile implementation teams at the portfolio and program levels, co-create artifacts that reflect their unique objectives and organizational structure, and provide thought leadership in building repeatable processes that will stay with the organization after we leave. It is such a great responsibility, and so much fun, to help organizations build world-class practices and sustainable cultures of Agile delivery at scale!  This is my older blog post from 2012 when PMI-ACP exam was introduced. Being part of the pilot group, I enjoyed the opportunity to "test the test" and contribute to how this PMI examination shaped up. I'm hearing that it has not changed much, and many people who still read this blog post reach out to thank me for this information or share their experience. As a result, I decided to move this post to this new site, hoping that it may be helpful to some of our visitors.
In today's competitive job market, primary credentialing is an important way to identify industry professionals with a full understanding and practical experience. It also a way for employers to identify prospective employees with valuable industry experience which is confirmed and verified by the means of widely accredited and recognized certification. This is one of the reasons the new PMI-ACP examination (http://www.pmi.org/Certification/New-PMI-Agile-Certification.aspx) released in 2011 raised significant interest in Agile community world-wide. As of December 2011, the following numbers on PMI-ACP examination were available on PMI community blog page and some other sources (http://agile.vc.pmi.org/Public/Community/Discussions/tabid/170/aft/9709/Default.aspx,http://thecriticalpath.info/2011/12/13/pmi-acp-numbers/)
My pilot experience is not fully relevant anymore. But here it is: I took PMI-ACP exam in November 2011 and I feel it has been a rewarding experience, which I am happy to share with you. First, I want to share that I embraced the fact that PMI acknowledged Agile by instituting this certification and while I’ve heard a lot of contradictory opinions on this subject, I felt that this exam is a bridge which will fill the gap between Agile and what we call “traditional project management”. PMI-ACP certification exam was welcome by the Agile community. Overall, this exam is an remarkable step towards bridging traditional, waterfall project management and adoption of agile practices. Many organizations in multiple industries are adopting agile practices to align their development environment to changing market needs, and with this trend, the requirement for project managers trained in agile practices is going up. In January 2010, Forrester release a research which shows that 35 percent of 1,300 respondents stated that agile most closely reflects their development process and made a conclusion that agile software development processes, in which software is built in short iterations rather than mapped out fully in advance, have joined the mainstream of development approaches(http://www.forrester.com/rb/Research/agile_development_mainstream_adoption_has_changed_agility/q/id/56100/t/2). The new PMI Agile-Certified Practitioner certification, PMI-ACP, reflects this tendency and addresses the requirement from project management everyday reality. Being an established project manegement boady with high value for the certifications it awards, PMI made this step towards recognizing the value of Agile practices. PMI established its Agile Community of Practice in 2009 and PMBOK® Guide 3rd & 4th edition contain references to iterative development. According to PMI, For practitioners, PMI-ACPSM helps:
While I was excited about taking the exam, I was concerned with the fact that the questions and expected answers from PMI should not violate Agile values and principles. The concerns were triggered by two facts: first, PMI was not involved as an organization (according to my knowledge) in building Agile repository of knowledge so it is acquired methology rather than conceived and lived through; and second, since there is no AgileBoK (at least no single repository of knowledge on Agile), I was concerned about the level of consistency between 11 books suggested by PMI for preparation to this test. Based on my exam experience, neither concern is in fact a concern for Agile community. I think questions adequately reflect Agile values (I am not aware who exactly was involved in creating the questions, but I certainly feel that exam preparers are Agile practitioners who share Agile values). And while there is certain degree of inconsistency (most obvious one is “Agile project manager”, “project leader”, and “scrum master”; or “team” refers to both “scrum master” vs. “team” and “scrum master and development team” in different questions – you would have to guess what is applicable) but overall, I did not come across significant inconsistency or ambiguity. Overall, the exam experience was pleasant. I completed the questions in 1.5 hours and took another 30 minutes to go through those 20 questions out of 200 that I was not sure about. But let this not misguide you. This does not mean that exam is easy, though about 60% of the questions were quite straightforward, if you have significant Agile experience and have read the books from the list. You may not need all this time because there are no complex formulas or tricky confusing questions, but the level of knowledge required is adequate. It was not as difficult as PMP exam for me, which required a lot of preparation, but luckily, I’ve read most books on PMO list before PMI-ACP exam was introduced, so my preparation was reasonable. Again, it is hard for me to judge because I do not know the result yet – the results will be made available in early January (originally, it was reported to be Q4, 2011). While everyone would love to see results immediately after taking the test, I understand the reason why this is delayed and the fact that baseline has to be established before providing assessment. I find it thoughtful and support this decision by PMI, though I’ve read a lot from the disappointed test takers who were unhappy that they did not see the results right away. Pilot is a pilot though, and it will establish baseline for future test-takers. Please note that PMI-ACP is not the only exam in the field of Agile knowledge. Scrum Alliance transformed the Certified Scrum Professional (CSP) program starting January 2012 by offering a 150-question exam, which is available at proctored test sites around the world and has a three-hour time limit (http://www.scrumalliance.org/pages/certified_scrum_professional). The intent behind the CSP certification program is to offer a clearly defined and well-respected credential in the Agile community, recognized as the primary credential for Scrum Professionals and sought by the employers who hire them. The beta test that was conducted in October 2011 to assure that the CSP examination met accreditation requirements and is theoretically and technically sound, and as of January 1, 2012, Scrum Alliance will be offering CSP as a credential that implies, regardless of the Scrum role in which an individual works, those holding it have a full understanding of Scrum and its implementation. This being said, CSP certification deserves to be a subject of a separate review, and back to PMI-ACP exam. For those of you who are planning to take the exam, below is my summary from the test I took in November 2011. While it would be unethical to list specific questions, I will list the areas and my not-so-accurate and definitely subjective estimation of the exam topics and what to pay attention to while preparing for the exam: 1. Risk Management in Agile – around 10% of questions. This was not an unexpected topic (I read on linkedin that this area will be significantly covered but I was not prepared for the depth of questions asked). Make sure you understand risk burndown chart, have an idea on how Pareto principle applies to risk analysis, and how risks are managed in Agile vs. waterfall. 2. How Agile delivers business value – around 10%. There were multiple well versed questions on the topic, many related to Lean but some to scrum (hopefully you understand the term “empirical process control” described by Ken Schwaber in “Agile project management with Scrum”). However, in some questions, the concept of business value (or “customer value” – these terms seemed to be used interchangeably) was hidden. Overall, there were multiple concepts tested, such as incremental delivery, time to market, and minimal marketable feature. Separate topic – EVM and measurements around customer value. If you read “The Software Project Manager’s Bridge to Agility”, you got this covered. 3. Agile values and principles - around 10%, according to my estimation, but these are difficult to estimate because all test questions relate to them and most were tested indirectly, e.g. the concept of sustainable pace or self-organizing team, however, there were direct questions on literal verbiage of those. 4. Estimation and planning – largest group of questions, around 15%. Techniques – be prepared for terms like “Dephi technique” or “Monte Carlo analysis” – but if you passed PMP exam, you are most likely very comfortable with this terminology. Other questions were well thought-through questions related to who estimates and what unit of measurement is used with 2 or 3 specific examples where you will be asked to do iteration breakdown. Be familiar with the concept of progressive estimation. Overall, if you are practicing Agile and understand abstract nature of story points and the concept of velocity – and if you read Mike Cohn - you should have no problem with this large group of questions. 5. Agile methodologies and relationship between them – another 15% or so. I had 5 or 6 questions related to Lean, one related to WIP in Kanban (very basic), and quite a few XP questions – on roles, principles, concepts. Interestingly, there were questions about relationships between those (scrum and XP or waterfall as opposed to Agile). Questions were not overly deep or difficult, but some were quite specific to the term or the concept. 6. Roles in Agile – 10%. Multiple questions on roles – roles in Agile in general, in Scrum, in XP – roles related to specific ceremonies or artifacts, such as the “Definition of Done”. About 6 or 7 situational questions asking who is responsible for a specific artifact or who should take action in a specific situation. You should understand well when self-organizing team takes lead, and when scrum master is supposed to interfere to preserve process health – some questions seemed to be tricky – or maybe just deep and thoughtful. Pay special attention to roles in XP – there was a question about those which would be tricky, if you expected a scrum master to be one of XP roles. 7. Behaviors and cultures – no less than 10%. I want to applaud PMI for having those questions. They relate to culture of transformation from waterfall to Agile, conflict resolution, proper behaviors in unwanted situations. I have to confess that I haven’t read Lissa Adkins’ book “Coaching Agile Teams” as part of my previous Agile life, but I read it in preparation for the exam and found it very helpful and informative. Highly suggest that you cover this material in preparation for the exam. 8. Agile/scrum artifacts and ceremonies – another 10%. Multiple questions on burndown chart (including a practical question with a sample), two questions on information radiators, and – surprisingly – no single question on story (task) board – maybe I was just unlucky and did not get one picked. Multiple questions related to all Agile ceremonies – what questions are being answered, what’s the purpose and structure/duration, who participates, how is process enforced. If you read Ken Schwaber’s “Agile Project Management with Scrum” and if you are a Scrum practitioner – no need to worry, they are mostly intuitive. 9. Resources – about 5% – multiple resourcing concepts related to team composition, dynamics, colocation. Good questions provoking thinking – just one advice: be familiar with the concept of fractional assignments. I personally find it useful and was pleasantly surprised to see it on the exam. 10. Communications – also around 5% - questions related to importance of face-to-face communication in Agile and techniques of working with distributed teams. You would have to understand the concept of “osmotic communication” – almost everyone who writes about the exam indicates surprise that this not-so-widely-used term appeared on the exam – however, I agree with the choice of exam preparers because it is an important concept and one of success factors for Agile implementations. My advice on books: All the books listed by PMI is a cerefully made selection of the highly informative sources on Agile and it is important to read the all. Here are some sections to pay particular attention to: · From James Shore book, read about "fractional assignment", what they are, and whether it is advisable to have those in Agile. · Read Mike Cohn (both) and Alistair Cockburn - cover to cover on estimating and planning. · Michele Sliger - on risk management and EVM. · Lyssa Adkins and Ken Schwaber - make sure to remember specific examples because there are similar behavioral/situational questions on the exam. · Alan Shalloway et al. - on value stream management. I read all books in my preparation for the exam, and as challenging as it was, it was a great experience to read and re-read them, and each one of them is a great book - informative and interesting. And finally, if you are interested in expanding your Agile horizons, I want to add several books to PMI list that you will no doubt enjoy as much as I did (but most likely you’ve read them already): · “Scaling Software with Agility: Best Practices for Large Enterprises” by Dean Leffingwell · “Scrum from the Trenches” by Henrik Kniberg · “Management 3.0. Leading Agile Development. Leading Agile Developers, Developing Leaders” by Jurgen Apello · “Agile Portfolio Management” by Jochen Krebs · “A Practical Guide to Distributed Scrum” by Elizabeth Woodward, Steffan Surdek, Matthew Ganis · “Practices for Scaling Lean & Agile Development: Large Multisite and Offshore Product Development with Large-Scale Scrum” by Craig Larman, Bas Vodde Everything you’ve read above are my personal impressions from one instance of PMI-ACP test-taking based on my personal experience and perceptions. While I hope this will help future PMI-ACP test takers, please be aware that you will get a different set of questions/topics on your exam. Also, our level of experience may be different, so the items that seems either basic or complex to me, may be something different for you. My opinion is based on 6+ years of experience as an Agile practitioner in a scrum master as well as agile coach and transofrmation specialist role, prior PMP certified project management experience, as well as the books I read from the PMI list and beyond on the topic. As I mentioned, I am a member of PMI as well as Scrum Alliance and hold both PMP and CSM certifications. This review is independent and has not been reviewed or entitled either by any of those organizations, or by my employer. I wish you all a successful exam taking experience.  There is an interesting discussion in my linkedin group. The topic is: when you hire a scrum master, do you look for technical skills and leadership skills? Would team members respect a scrum master who is not a good subject matter expert or who is technically challenged? (in case of a software scrum team)
I have seen so many team members who write great code and develop great applications, but fail in scrum master role when they choose to try it out. Similarly, I've see several effective managers totally failing this role because they did not have control over the team any more. So - while I prefer both - I vote for personal skills, leadership, honesty, desire to help, respect, unselfishness. In terms of hiring, there are situational questions that I find most efficient. Here are some examples: 1. An executive walks into your team's retrospective because he wants to know how things are going. Do you ask him out, and how? 2. At a demo, a business stakeholder not directly involved with your product, starts making suggestions like "why don't you change a label of that button" and "I do not like the color of this screen", and does this for each feature your team demo's. The team members look demoralized. How do you protect your team? 3. You are a scrum master for a new team that has no prior scrum experience. At a standup, two team members engage in a 5-minute long conversation on a specific topic. Do you interrupt them at the standup, right after, or wait until the retro? 4. At a retro, your team members do not speak up, while you know that there are communication issues on the team. How do you make them talk? 5. The team committed to 5 stories for this sprint at a sprint planning, but you know for sure they won't be able to complete all of them. How do you tell them about it so that they don't overcommit, and do you have to? There are more complex questions on managing cross-team dependencies, dealing with the business requests to deliver the product by a specific timeline, getting buy-in from the management, dealing with fractional assignments, etc. Any other ideas?  I decided to move this 2013 blog posting to this site because the concept of Lean Startup which was emerging at that time became mainstream in less than two years, but this Lean Startup Machine experience remains a unique opportunity to test your skills and desire to continuously innovate and learn.
The concept of Lean Startup introduced by Erik Ries is an amazing collection of common sense and innovative ideas. If you have not seen his Google talk or read his book on Lean Startup, my advice for you is to stop reading this blog and watch this video instead. My Agile team at work has our own Book Club, and the last three sprints, we are reading Erik Ries' book, and each time we find a lot there to admire, and about as much to disagree with. Some ideas resonate with me (validated learning, minimally viable product, pivoting once your assumptions are invalidated - all makes perfect sense) while selecting a small group of customers to validate your product and make decisions based on this restricted subgroup does not. I value contradictions. Primarily, I do so because I do not believe that they exist. I treat them as puzzles for us to solve. So when I got a qiestion whether I would want to go toLean Startup Machine Training in New York, I said "yes" without hesitation, even though I had no clue what the training is going to be. And once I did, I found that it is all-weekend training which starts on Friday evening and ends of a Sunday evening, and goes almost non-stop for all three days. It is a hackathon-like experience for entrepreneurs and for anyone who wants to learn how to start building your product right. The concept of working through the whole week-end slightly scared me but not enough to pass on this exciting opportunity, so I rolled my sleeves, checked into a hotel in New York and started the 3-day marathon. Now that the second day is over, I want to share my thoughts with you while the experience is still fresh. First, it is worth doing! Learning about lean startup is nothing compared with going through it. Powered by a simple yet powerful product envisioning tool called validation board, my team started with building a fee-free tool for business professionals who need to find company after work hours while on travel (at that time, we were thinking of social activities or just a friendly chat) and after 5 pivots and a lot of interviews of potential customers, we have designed a VIP Travelers Club with a $5K/year membership fees. Interesting that our first idea had a very low conversion rate while the final one brought us an advisor who wants to introduce us to an investor. You never know your customers until you ask them directly! This is my learning experience #1. And the second one is similar: "go out"," "talk to the people". My two teammates - Hao and David - and I spoke a lot to the strangers and learned that the first product that we loved and voted for has limited business value while the final one has a significant business potential. Why am I telling your this? - To encourage you to get out of the building, meet your end user, validate your assumptions and pivot as many times as you need until you find a perfect combination for your Minimally Viable Product (MVP). And once you did, validate and build over again. This is how all successful product owners create their winning products.  Feedback is important for human beings and it is one of the most important means of development. I agree that performance reviews are not the most effective way of obtaining feedback especially in Agile environment where there are a built-in mechanism for feedback, which is a retrospective. Effective retrospectives enforce Agile values and come from your peers. However, I still support all types of thoughtful and one-on-one feedback in a corporate environment because it contributes to the atmosphere of transparency and continuous inspection and adaption, which are important Agile values. There are several drawbacks but they can be mitigated: 1. People do not like to be judged. - Be non-judgmental in your feedback and prepare to take feedback from others constructively and continuously. It feels good once you get into the habit. 2. People are sensitive to feedback. - It is important to create tolerance for risk. If people are comfortable to try, make mistakes, and try again, they need feedback to succeed. Once this understanding becomes your organizational culture, feedback is welcomed rather than causes frustration from the recipient. 3. People get feedback but don't act on it. - Help your colleagues define professional goals that work for them and create such an environment where they will have an opportunity to share their success with others. So my solution to ineffective performance reviews is: decouple performance appraisals from career development and more importantly, from compensation evaluation. Establish continuous feedback flow and a consistent and fair compensation system which does not depend on annual review. Whether it is Google's elaborate promotion system or Valve's "select a peer" system, do not base it on performance reviews. How does it work in Agile? First, we support each other in aligning on our goals. As Netflix refers to it, we are creating a tightly aligned loosely coupled organization. In one of my coaching assignments, we decided to use goal setting process in such a way that scrum masters align in supporting company's business objectives by establishing common goals with their teams. We did brainstorming jointly (of course, we used stickies, silent grouping, and voting) and came up with the following high-level goals: improve accuracy of planning, increase reliability of commit (there were KPIs associated with this to make this goal measurable, differing between teams), building self-organizing teams (this translated into different specific goals for each scrum master), and maturing product backlog quality. Each scrum master has a set of specific measurable (S.M.A.R.T.) goals associated with one of those, and will seek continuous feedback from the team, adjust accordingly, inspect and adapt. How does it all translate to performance appraisals? First, those should not happen once a year, there should be continuous feedback, and all parties should be open to it. Second, it does not have to come from your manager, I think it is important to welcome any feedback you can get and not feel hurt or upset, kind of grow thick skin and take any feedback constructively. Third, think of it as of a way to help you become better, or help your peers become better, not as an input for your salary increase. To sum it up, I agree with Mary Poppendieck that it is important to create an environment where you have a coach, presented with a challenge (Mihaly Csikszentmihalyi's flow), provide and are open to feedback, and foster dedication. How you do it is up to you, but if you find an effective way to incorporate performance reviews in this process, go ahead. Just remember not to be judgmental, rather, use it as a feedback mechanism and as an input to creating goals for your colleagues that will help them become better professionals, better leaders, and better team contributors.  The Scrum Guide defines team roles very clearly. We all know that the product owner envisions products that deliver value and team members write and validate code, but what does a ScrumMaster do? According to theScrum Guide, a ScrumMaster ensures that Scrum is enacted. But, isn't this what every team member does on a self-organizing team? What does “servant leadership” mean to a Scrum team, and why does the team even need a designated “servant” or a proclaimed “leader?”
The ScrumMaster is the most controversial role in agile. Is a ScrumMaster a natural leader within the team or is the role a profession in itself? Is it the basis for a career or a simply a stepping stone? This is not a simple question to ask, and I believe that this is a question every ScrumMaster asked him- or herself at a specific point of time as their teams became more self-organized and mature in their agile implementation. Am I still bringing value? Am I expendable? As one of my colleagues presented it in a ScrumMaster paradox, “if I am a good ScrumMaster, I will become obsolete soon.” Does it mean that the better a ScrumMaster is, the more likely this ScrumMaster is to no longer be needed by his or her own team? Let’s attempt to answer this question in three logical steps:
What does it mean to ensure that Scrum is enacted? I am sure you’ve seen this role being interpreted as a combination of facilitating meetings, managing the Scrum process, and removing impediments. A more detailed description of a ScrumMaster role is provided by the Scrum Alliance in which a ScrumMaster is perceived as being a “facilitative team leader who ensures that the team adheres to its chosen process and removes blocking issues.” According to Mike Cohn, “The ScrumMaster is responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules. The ScrumMaster helps the Scrum team and the organization adopt Scrum. The ScrumMaster teaches the Scrum team by coaching and by leading it to be more productive and produce higher quality products. The ScrumMaster helps team members understand and use self-organization and cross-functionality, and also helps them do their best in an organizational environment that may not yet be optimized for complex product development. When the ScrumMaster helps make these changes, this is called “removing impediments.” The ScrumMaster’s role is one of a servant-leader for the Scrum team. For me, most importantly, the ScrumMaster role is about orchestrating a team’s work. The ScrumMaster’s responsibility should not fall on facilitating ceremonies (I encourage ScrumMasters to delegate this responsibility to the team members), removing impediments (regarding self-organizing teams, team members do a marvelous job removing all sorts of obstacles and coordinating cross-team dependencies), and minimizing distractions to the team members (for empowered co-located teams, this stops being an issue once your agile implementation matures to a state in which there is shared process understanding, focus, and common goals). So, why do teams need a ScrumMaster then? My team of internal agile coaches runs our agile implementation as Scrum. Our product owner defines a roadmap, and every sprint we work on is a subset of user stories aligned with the roadmap and prioritized by the product owner. Recently, my colleague was working on a story involving a “ScrumMaster elevator pitch.” If someone within the company who is new to agile asks you “What does it mean to be a ScrumMaster?” during a three-minute elevator ride, what would you tell this person? We brainstormed on this topic as a team and found out that describing tasks or positioning the ScrumMaster as someone being responsible for the process did not resonate with people. We then moved to using analogies, with the one we chose relating to the idea of a race-car mechanic; someone who ensures that the race car operates smoothly and efficiently so that the team performs at its best. This person is someone in the background, yet highly reliable, knowledgeable, and respected by the team and stakeholders. Another analogy that I like is the idea of an orchestra conductor, but this analogy is more suitable to a less mature team that needs someone to suggest direction and set up rhythm, while the race-car mechanic is the one in the background giving the team all of its pre-requisites for success. If there is no mechanic, the race car will start experiencing issues and will eventually halt to a stop. This provides an answer to the question whether a great team still needs a ScrumMaster. It does, the same way as a great race car still needs a mechanic to keep it going. Is a ScrumMaster a Title or a Role? This question is the most controversial one and the one that I personally do not have a good answer to, yet. As a hiring manager, I asked the following question repeatedly to myself and to recruitment professionals: What is the most important factor when you hire a ScrumMaster? Is it the people skills, the ability to lead by example, or one’s previous experience or technical skills? What I found out is that similar to agile, values come first and the rest (experience, technical knowledge, familiarity with specific agile tools) come next. The values that I find important for ScrumMasters are being honest, fair, open, never finger pointing, always analyzing and suggesting ideas, listening well, being respectful to team members, and having open communication targeting the right group of stakeholders—not too large, which leads to unnecessary escalations, and not too small, which can lead to team members feeling excluded; it has to be just right. A ScrumMaster makes judgment calls in case of uncertainty, and has a quiet and confident demeanor. All of these values that are hard to quantify make someone a good ScrumMaster. Of course, having knowledge of agile principles and techniques, exposure to successful agile implementations, prior coaching and mentorship experience, and possessing technical knowledge are all important, but they can be acquired. Values and instincts cannot. So, my answer to hiring managers is straightforward. In my perception, the ScrumMaster is not a role that any stakeholder can play. At work, we have a standard job description for a ScrumMaster that lists pre-requisites for knowledge, skills, and experience, but the most important part during the ScrumMaster interview process are the scenarios or situational questions that I ask. I do so to learn if these potential ScrumMasters are able to better understand how they make decisions, respond to difficult situations, resolve conflicts, and motivate and inspire their teams. I have also witnessed multiple examples of successful teams that did not have a separate title for a ScrumMaster. In those cases, one of the team members would become a designated part-time ScrumMaster. I’ve seen a business analyst, development lead, or one of the cross-functional team members being labeled a ScrumMaster on a team. In these cases, the team perceives the ScrumMaster as one of the cross-functional team members, and the other team members eagerly relate with this person. In all successful cases, the ScrumMaster is a natural leader on the team, an effective communicator, and is respected by the team members for being knowledgeable and fair. Is the ScrumMaster a Stepping Stone in One’s Career or a Career in Itself? This question, so seemingly simple, raised a lot of concerns from the ScrumMasters I have dealt with throughout my coaching experience. If you work for a startup, you may be less concerned with your career progression. If you are a successful ScrumMaster working in a corporate environment and your colleagues are progressing up a corporate ladder, you may ask yourself some questions like the following: What is my next step? If I have been a ScrumMaster for three or five years, does that mean I am not making a good career decision? What should be my next career move? Many practitioners think that the ScrumMaster is a role, so prefixes such as “junior” or “senior” are not applicable. There is no such thing as a “senior leader” or a “junior leader.” While this logic may sound appealing, I disagree. If you are a permanent company employee in a corporate setting, titles matter. Titles reflect the level of experience, complexity of the job, and perceived employee contribution to a company’s success. Companies differ in the way they define ScrumMaster career progression. Some companies use titles to designate levels of ScrumMaster maturity (e.g. labels like junior ScrumMaster, senior ScrumMaster, or agile coach) or complement titles by departmental levels (labels like manager, lead, director, etc.), but in each case, it is important to have a known and communicated career path within organization. In this case, the career path should have a set of clearly defined and well-documented requirements associated with each title based on experience, skills, certifications, role, the number of teams, coaching and mentorship responsibilities, and a number of other criteria that fit company’s existing structure, title designations, and staff hierarchy. Once there is transparency and a shared understanding of the levels, ScrumMasters can see their title as a career and not as a stepping stone to their next, more exciting assignment. Having a defined career path for a ScrumMaster does not mean that a ScrumMaster is expected to move in this pre-defined direction. Nowadays, most advanced companies support their employees in so-called “lattice” career advancement versus “ladder” career advancement, as defined in The Corporate Lattice: Achieving High Performance in the Changing World of Work by Cathleen Benko and Molly Anderson. According to this book, the word “ladder” refers to a traditional (vertical) career progression, which relies on titles and hierarchies; however, the career landscape is changing. As organizations become flatter, work becomes increasingly virtual, collaborative, and dispersed. Careers zig and zag. As a result, a “lattice” (horizontal) career model is better suited for today’s global business in which employees do not need a vertical progression to be defined anymore. This includes moving to different roles within the same organization, learning new skills, and mastering adjacent (and in some cases, totally new) areas of responsibility. Many of the ScrumMasters I know moved into product ownership, product development, and even into executive roles within their companies. Why, you will ask? Because the qualities I described in this article as being important for a ScrumMaster are the ones that define a successful business professional, from a C-level executive to a successful entrepreneur or an agile team member. A ScrumMaster is more than a role or a title, it is a state of mind based on a strong commitment to agile values and dedication to the team and its success.  There are multiple descriptions of a ScrumMaster role, my personal favorite being Ken Schwaber's. When I assumed my responsibility of an Agile Coach, I was asked to draft a role description for a ScrumMaster. I used my own experience, multiple scrum sources including The Scrum Guide, and numerous job descriptions I found on the internet. Below (in blue) is the result:
Summary of role: A ScrumMaster is a team leader focused on bringing continuous improvement to the Agile Team and the Agile Community of Knowledge. The ScrumMaster helps the Scrum team and the organization adopt Scrum. The ScrumMaster is accountable for the ability of the team to deliver the sprint goal / deliverables. The ScrumMaster is responsible for ensuring that the Scrum team adheres to Scrum values, practices, and rules. Responsibilities: A ScrumMaster: 1. Creates a motivational, transparent, collaborative, fun, open, and trustful environment where a Scrum team can work efficiently and the business can deliver high-quality products quickly; 2. Prevents team distractions, identifies and leads the impediments-solving process, and escalates risks and issues if necessary; 3. Organizes and facilitates (or works with a designated team member to conduct) effective product backlog grooming, sprint and release planning sessions, daily stand-ups, sprint reviews (demos), and retrospectives; 4. Creates and maintains an electronic repository for the team’s historic information and collaboration space on ongoing topics including but not limited to sprint summaries (demo decks), links to document repositories, impediment log, and the list of retrospective action items and their status; 5. Garners respect from the team and leads the team towards hyper-productivity; promotes self-management and self-improvement to grow team efficiency and velocity; monitors team’s velocity and suggests corrective actions at a Retrospective, if relevant; 6. Maintains metrics related to velocity and other metrics as agreed with the product owner and advised by the Agile Coach; 7. Promotes self-organization and cross-functionality within the team; relinquishes command and control style to involve the team in decision making ; promotes effective conflict resolution on the team and outside of the team; 8. Regularly attends and actively contributes to Scrum of Scrums and to the Agile community; 9. Reports non-resolved impediments to the Impediment Removal Team (IRT) and participates in resolution; 10. Assists the team in making appropriate commitments and supports the team in standing up for their estimates; responsible for working with the team to ensure that their team is realistic in their commitments; 11. Creates, updates, and leverages quality information radiators including but not limited to release and sprint burndown charts, task board, working agreement, and other relevant artifacts to create transparency around the team's velocity and progress against its current sprint or release; 12. Enables the team to focus on high-priority items and increases team accountability for the deliverables by removing impediments, scheduling all ceremonies and facilitating them effectively (or partnering with other team members to ensure effective facilitation), and following up on the action items agreed upon by the team; 13. Coaches the team on how to be more productive and produce higher quality products by ensuring the health of the process and adhering to Scrum principles; 14. Facilitates the involvement of shared, fractional, and cross-team resources with the Scrum team; reports cross-team dependencies in a cross-team dependency list and updates the status regularly at Scrum of Scrums and in the appropriate repository; respects other teams and successfully collaborates on shared goals; 15. Promotes open and transparent communication and alignment with other functional areas, including Finance and Operations; acts as a liaison with other departments within the organization; 16. Ensures that all deployment activities are in compliance with the established process; and coordinates deployment activities and resources with other teams as applicable; 17. Helps surface whether the product backlog is not "execution ready" for release planning or sprint planning; 18. Assists the Product Owner with product backlog maintenance and Roadmap creation; ensures that there is a Roadmap and release plan available to every team member. 19. Leads the Scrum team and its adoption of Scrum by communicating Agile principles and sharing team success in efficient sprint review meetings. 20. Understands the values, practices, and rules of Scrum and other methodologies and proactively seeks out opportunities to grow this understanding by attending internal and external trainings, reading relevant materials, or achieving professional certifications; educates others on the team and throughout the company; Skills: A ScrumMaster:
As you can see, this role description is a combination of ScrumMaster role expectations in Scrum and organization-specific policies and rules, such as information repositories, mandate for having Product Roadmaps, and operational procedures. There are also pain points that are obvious from here, such as Product Backlog quality and residual command-and control management style. Let me ask you a question: what do you think is the level of Agile maturity of an organization where this role description has been created? |
AuthorTransformation 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. Archives
October 2020
Categories
All
|
RSS Feed