Ravi Verma

True story - happened in one of my recent Professional Scrum Master workshops. I think had just mentioned that there is no "Sprint Commitment" in Scrum, only a "Sprint Forecast".

Like many old, boring people, my favorite radio channel in the car is National Public Radio. Since I live in Dallas, TX, my local channel is KERA. Of all the shows in KERA, my favorite is a show called Think With Krys Boyd. Almost each show I listen to leaves an imprint on my mind and modifies the way I think.

The role of the Scrum Product Owner is probably the most misunderstood of the three Scrum Roles. As I look back at the different incarnations and interpretations I have seen of Product Ownership, I thought it was time to articulate the different stances I thought an Effective and Professional Scrum Product Owner might consider.

Many times, clients ask Agile Coaches like me to come in and share our "expertise" with them. But sometimes they really don't want our "Expertise". What they really want is someone with lots of TLA's to come and tell them that there pre-existing opinions are correct.

THE (MIXED) BLESSING OF NEXTGEN REWRITES About 10 years ago, I experienced the mixed blessing of being part of yet another nextgen rewrite project. I was guiding a team of about 25 really smart team members, part of a much larger team of about 150+ people. Our team was responsible for completely rewriting the UI, the database, the messaging hub, build and install. I was using Microsoft Project to manage and predict the work of about 25 team members over the next 12 months. It felt like an interesting exercise in futility. BLUDGEONED INTO SUBMISSION I was introduced to the joys of Resource Leveling a 400+ line Microsoft Project Plan. I was not very good at it. Moments after I got the dang thing leveled, one of my team members would walk into my office and tell me something had changed. Finally, after many many years, Microsoft Project was able to do what many wiser, smarter people had tried to do and failed - bludgeon me into acknowledging that there might be a better way to manage the delivery of complex software. I just did not know what it was. ANOTHER DOSE OF HUMILITY Fast forward a few years - my search for a better way led me to Scrum. I decided to become a Scrum.org Professional Scrum Trainer and passed the PSM-1. The next step was the PSM-II, and I was not ready for it. I failed. In those days, the PSM-II was hand graded by Ken Schwaber (the co-creator of Scrum) and the feedback gave me another dose of humility. There were gaps in my understanding of Scrum and I had much more to learn. It was time to go to to Scrum.org Headquarters in Boston to learn and fill in some of the gaps. PROFESSIONAL SCRUM MASTERY In October 2012, I spent 2 days with Ken & Gunther attending the Professional Scrum Master course and had 3 key takeaways burned into the firmware of my mind. Scrum was a framework that helped organizations accomplish 3 key outcomes... OUTCOME #1: INCREASE BUSINESS VALUE OUTCOME #2: DECREASE NON VALUE-ADDING WASTE OUTCOME #3: MANAGE BUSINESS RISK EXPOSURE This seemed to me to be the bread and butter of Technology Executives. I assumed that Scrum would resonate with them. Turns out that was not a valid assumption. SLEEPLESS IN CXO-LAND Many executives that I coach seemed to be perennially in survival mode - neck-deep in alligators. They seem to be lurching from one call to another, wrangling one escalation after another. Trying to placate an unhappy client one moment and then trying to say whatever is needed to close the deal with a prospect the next moment. Threatening teams that caused production failures or those that were running late in one call and then being threatened by their management for quality issues and project delays in the next call. These CXO's seem to be sleepless in CXO-Land, living on antacids and anxiety medication. Interestingly, when I offered Scrum as a way to break out of this vicious cycle, they usually responded with comments like "Out here, we need to keep it real and stay away from all that agile text-book BS. We are trying to do "real-work" and don't have time to remove these stupid impediments teams are whining about. We wish these so called Agile Teams would get it and understand what we are doing and why." SUFFERING IN SCRUM-TEAM LAND Speaking to members of the Scrum Teams gave me another perspective. They were tired of the whiplash from their executives. They felt like they were running fast in the direction of the most important project one day, only to be jerked in a completely different direction the next day. Scrum teams often struggled to get the context - to understand what they were doing, why they were doing it and if anything they had done in the past truly helped their customers and their company. THE CHASM In such organizations, it often feels like the efforts of Executives and Scrum Teams were disjointed and disconnected. Executives were trying to set the destination and choosing the strategy to get there. Teams were trying to execute the strategy and help the company get to the destination. But they were struggling to connect with each other, as if they were separated by a wide chasm. Ironically, this was exactly the kind of chasm Scrum was designed to help organizations bridge. Scrum was designed to help leaders clarify the destination and create an environment where cross-functional teams could self-organize and find the most effective way to help the company get there. Then why were these organizations struggling to cross this chasm? Could it be due to a ritualistic, tactical understanding and implementation of Scrum? What might help such organizations elevate their understanding and cross the chasm? STRATEGIC SCRUM So here is one possible approach that might help Sleepless CXO's use Strategic Scrum to beat stress and stay in sync with Scrum Teams... STEP #1 - BHAG The first step is to articulate a clear, compelling, inspiring vision that inspires Scrum Teams. One possible way to communicate this elevating goal is to create a BHAG - a Big Hairy Audacious Goal, as explained in the book - Built To Last, by Jim Collins and Jerry Poras... "A true BHAG is clear and compelling, serves as unifying focal point of effort, and acts as a clear catalyst for team spirit. It has a clear finish line so the organization can know when it has achieved the goal; people like to shoot for finish lines." Some possible examples of BHAG's, from the article on Big Hairy Audacious Goal in Wikipedia SolarAid: To eradicate the kerosene lamp from Africa by 2020 Gift of Life Marrow Registry: To cure blood cancer through marrow donation by ensuring a match for every patient in need, whenever they need one. Facebook: To make the world more open and connected. Amazon.com: To be Earth's most customer-centric company. SpaceX: Enable human exploration and settlement of Mars. STEP #2 - STRATEGIC PILLARS Once the BHAG has been clearly defined, leaders can clearly articulate the strategy that will help accomplish it. One possible way of articulating the strategy is to use Strategic Pillars. In his blog - "What Are The Strategic Pillars That Support The Vision", Greg Githens says... "Pillars provide strength and support for something. In the case of strategy formulation, strategic pillars hold up the vision. Remove a pillar, and the vision is in risk of collapse. (Strategic pillars are also called strategic planks.)" For instance, one possible way to think of Facebook Strategic Pillars might be... ACQUISITION: Get new members to sign up for Facebook accounts. ENGAGEMENT: Get Facebook members to keep logging in, posting content, sharing, commenting and engaging with each other. MINING: Mine user behavior and preferences to gain insights into what they like. MONETIZE: Monetize these insights by selling them to advertisers. One possible way to clarify and complement strategy in a way that can be easily understood by Scrum Teams is to describe the business model with a canvas like Roman Pichler's Extended Product Vision Canvas. STEP #3 - PORTFOLIO INVESTMENT Once the BHAG, Strategic Pillars and Business Models have been clarified, it is now time for leaders to create some guidelines for investing funds in the portfolio in a way that is aligned with the strategy. One technique I have used to help CXO's come up with these guidelines is to ask them to distribute 10 points of investment across the pillars. The only catch is that no two pillars can receive the same # of points. One possible resource to guide this thought process is Agile Portfolio Management by Jochen Krebs. Here is how we might distribute funds across the strategic pillars in our illustrative example... STEP #4 - WILDLY IMPORTANT GOALS To enable empirical measurement of our progress towards our strategic outcomes, the next step could be to design quantified goals. One possible format that has resonated well with organizations I have coached is called Wildly Important Goals, proposed by the Franklin Covey 4 Disciplines of Execution framework. The format of WIG's is... Increase / Decrease 'x' from 'y' to 'z' by Target Date To avoid setting tactical, misleading or sub-optimal WIG's, we can integrate the Franklin Covey framework with the Scrum.org Evidence Based Management EBMgt (TM) Framework Some possible examples of Strategic WIG's... Increase engaged customers from 1 million to 2 million by December 2017 Decrease defects detected in production from 5 per week to 1 per week by December 2017 Increase customer net promoter score from 20 to 40 by December 2017 Decrease cycle time of concept to cash from 6 months to 3 months by December 2017 STEP #5 - SCOREBOARD Now that we have quantified success, the Franklin Covey 4 Disciplines of Execution framework suggests that we create a "Player's Scoreboard" that clearly helps teams understand whether the company is winning or losing the game. Reviewing such a scoreboard can also enable empirical transparency, inspection and adaptation. You can see this approach in action by watching a free YouTube Scrum Pulse episode by PST Don McGreal - Agile Metrics STEP #6 - PORTFOLIO MAP Now that we have created the acceptance criteria or test for success in the form of a player's scoreboard, it is time to express how we can execute our strategy. One possible approach is to define high level backlog items for each strategic pillar by applying the User Story Mapping technique created by Jeff Patton. STEP #7 - PORTFOLIO BACKLOG Now we can apply the portfolio investment guidelines and backlog management techniques to flatten the two-dimensional portfolio map into a one-dimensional, rank-ordered portfolio backlog. This can provide clarity to teams about leader perspective on value. STEP #8 - PORTFOLIO ROADMAP We could now start working with Scrum teams to apply ideas like Minimum Viable Product to forecast a cohesive and coherent roadmap that factors in business value, technical feasibility, complexity, dependencies and risk. STEP #9 - PORTFOLIO EXECUTION Create the artifacts suggested in previous steps incrementally. Don't use a big-bang, phase-gate waterfall approach or a sprint 0. Review and refine ideas in time-boxed refinement activities on a cadence. We are now ready to start designing and executing experiments using Scrum. Depending on the size of the company, we could either use just the Scrum Framework or complement Scrum with a Scaling Framework like Nexus. STEP #10 - PORTFOLIO LEARNING We can now start delivering incremental value to the market, use the player's scoreboard to inspect market response and adapt the backlog of future experiments with validated learning. Repeating this approach on a fixed should help us sustainably increase value, decrease waste and manage risk exposure to match our company's risk tolerance. CALL TO EXPERIMENT My hypothesis is that this approach to Strategic Scrum might help Sleepless CXO's Beat Stress by Staying In Sync with Scrum Teams. I am inviting you to conduct some small experiments to test my hypothesis in your context. EXPERIMENT #1: MODIFIED PERFECTION GAME Review artifacts like the BHAG, Strategic Pillars, Portfolio Investment Guidelines and Portfolio Map with your Scrum Team members. Ask them to rate them on a scale of 1 to 5. For every point below 5, request reviewers to suggestion one improvement that would earn one extra point from them. EXPERIMENT #2: TEACH THE TEACHER Start Nexus / Scrum Sprint Planning & Sprint Review meetings by having members of Scrum Teams present their understanding of BHAG, Strategic Pillars, Portfolio Investment Guidelines and Portfolio Map to their colleagues. Listen closely as a way of getting empirical feedback to validate whether Executive Vision has been understood by Scrum Teams. Bridge gaps as needed by adapting the message and communication approach. EXPERIMENT #3: CADENCE OF INSPECTION Regularly inspect the player's scoreboards in Nexus / Scrum Team Sprint Reviews and tap into the wisdom of stakeholders to adapt future experiments. EXPERIMENT #4: EMPIRICAL FEEDBACK Use surveys to measure if this approach can create measurable improvement in alignment between CXO's and Scrum Teams. One possible survey question is... On a scale of 0 to 10 where 0 is strongly disagree and 10 is strongly agree, please rate your level of agreement with this statement... Our CXO's and Scrum Teams are completely in sync. You can also find the slides that summarize this blog on slideshare. Let me know what you think and until our next interaction - Keep Calm and Scrum On!

IMAGINE Imagine you have just been asked to build an Agility Enablement Organization for your company. Sounds like fun, but there are some constraints you need to work within or around… There are 100+ teams with varying levels of interest in Agile You only have a small team of enablers You would like to deliver incremental, measurable business value Where would you begin…? THE THREE TEACHERS I've been thinking about how I would answer this questions and consulted three wise teachers for their advice... TEACHER #1: SCHOOL OF HARD KNOCKS My first teacher was the Shool Of Hard Knocks. This teacher distilled the wisdom from my practical experience helping introduce, scale and optimize Agility in organizations of varying sizes - from 10 to 350 teams (150 to 4,500 team members). This teacher taught me 3 key lessons... Be prepared for a wide spectrum of agile hunger / aversion in the teams There will likely never be enough people to help nor enough time to accomplish what we would like to There might be a temptation to start thinking like B.B.Watts - and running a Big-Bang, Waterfall Agile Transformations. Read an earlier Blog to understand what this mindset looks like and how you might avoid it: Enterprise Agile Transformation – The Story of B.B. Watt’s Lawn Service TEACHER #2: THOUGHT LEADERS FROM SCRUM.ORG My second teacher was conversations with thought leaders from Scrum.org who help large organizations Scale Agility each day. They challenged me to think differently about Agile Enablement & Scaling... What if we de-scaled? This was a radical notion. Sometimes less might be more - could we potentially increase agility and delivery of business value with fewer teams? What if we were selective? What if we were super-selective and laser-focused about which teams we focused on? Could Agility be offered as a service? What if we offer Agile Enablement as a set of services, kind of like API's that interested consumers could invoke? TEACHER #3: INSPIRING CXO - MICHAEL DUNN My third teacher was Michael Dunn - a very inspiring CXO with whom I partnered to scale Agility in 2 organizations. Michael taught me 3 key lessons... Agility should be a choice for teams Agile Enablement Teams should introduce Agile Value, Principles, Practices & Tools and make them available to teams so that those interested can step-forward and explore them When interested Agile Teams request for help, the Enablement Teams should be ready to serve. He supported a "bottom-up pull" for agility and not a "top-down push" 5 LESSONS As I look at the wisdom from these 3 teachers, 5 key lessons stand out... LESSON #1 - SEGMENT: Agile Interest + Business Value It is important to segment teams based on their level of Agile Interest and the Business Value that might be created by coaching them. LESSON #2 - FOCUS:Intentional + Surgical Since there will likely never be enough people on the Agile Enablement organization nor enough time to do what we want to, we must apply the Scrum Value of Focus and be very intentional about which teams we help and how. LESSON #3 - BE AGILE:Measurable + Incremental We must practice what we preach. We must apply the same Agile Principles to Agile Enablement, that we preach teams to use for Agile Software Delivery. We must create targets for incremental, sustainable, measurable Agility, We must frame hypothese on how to accomplish these targets We must design & execute experiments to test these hypotheses We must measure results to validate / invalidate our hypotheses and create validated learning We must apply the learning to adapt our approach LESSON #4 - DIVERSIFY:Services + Packages We must have a diverse portfolio of services organized into simple packages that are easy to communicate and understand. LESSON #5 - BE SELECTABLE:Allow Choice Finally, we should allow teams to step forward and select how they want to engage and choose the package that makes most sense for their goals. SEGMENTATION We can segment teams along 2 dimensions... DIMENSION #1 - BUSINESS VALUE Some teams would be working on products that are strategic to business value, while others might be working on products that are tactical or that will soon be retired. DIMENSION #2 - AGILE INTEREST Some teams may love Agility and are ready to do whatever it takes to become more Agile. Others may hate Agile Value, Principles and Practices. 4 QUADRANTS Based on these 2 dimensions, teams can now be segmented into 4 quadrants as shown below... RANKING Now that we have segmented teams in 4 quadrants, how do we rank them to make sure we are laser focused on helping the teams that can deliver maximum increase in sustainable, measurable value for the business...? Here is one possible rank ordering... Focus maximum energy on the teams that are hungriest for Agility and are working on the most strategic products Support teams that are very hungry for Agility but may not be working on strategic products Get wins from teams in quadrants 1 and 2 that might shift teams in quadrant 3 towards quadrant 1 Ignore teams in quadrant 4 10 QUESTIONS Now that we have segmented and ranked our teams, here are 10 questions that might help you offer Agility-As-A-Service for choice-based Agile Enablement... QUESTION #1 - WHERE IS THE TEAM TODAY? Each team might be in a different state of Agile Maturity and Readiness. We can use Agile assessments to help teams clarify where they are in terms of ability to deliver business value and desire for getting better. QUESTION #2 - WHERE DOES THE TEAM WANT TO BE? Teams may be interested in different goals. Some may be interested in faster time to market. Others may want to improve quality, stability, flexibility, etc. What's most important is that the goals be important to the teams themselves. QUESTION #3 - WHEN DOES THE TEAM WANT TO GET THERE? The next question is by when does the team want to accomplish their goal. Like the target destination, the target date should be determined by the team. Both these ideas are captured really well in the concept called Wildly Important Goals or WIG's by the Franklin Covey 4 Disciplines of Execution Framework QUESTION #4 - WHAT IS THE TEAM WILLING TO INVEST? Sometimes, there might be a disconnect between what the teams are willing to invest, what they expect from the Agile Enablement Organization and what they expect to get in return. Some teams may be willing to commit to investing time on a regular cadence, while others might not. Some may be like to be challenged, while others may not. Some may want to be coached, others may want to be left alone. Some may want existing culture and processes to be improved while others may consider those to be untouchable. No matter where each team might be, is important to bring transparency into what the teams are willing to put in and what they expect from others, to manage mismatched expectations. QUESTION #5 - WHAT SERVICES CAN THE AGILE ENABLEMENT ORGANIZATION OFFER? The Agile Enablement organization should be equipped to provide key services... Business Outcomes & Measurement Services: How to quantify business outcomes in terms of business value and how to measure progress towards the target Strategy & Portfolio Management: How to define a strategy to help accomplish the business outcome and how to invest the portfolio of funds in a way that is aligned with the strategy and outcomes Delivery Frameworks: How to understand and implement Agile Frameworks like Scrum, Nexus, Evidence Based Management (tm) Craftsmanship: How to master engineering practices - emergent architecture, evolutionary design, pair programming, automated testing, build, deployment, etc. Culture & Enablement: How to design an organizational culture that supports sustained Agility at all levels QUESTION #6 - WHAT PACKAGES DOES THE AGILE ENABLEMENT ORGANIZATION OFFER? Can we create some bundles or packages that are easy for teams to understand? Kind of like the combo meals on a fast-food menu. Some possible packages... Measurement Only: For teams that may not care about Agile but may still care about delivering sustainable, measurable business value. Self-Help Only: For teams that want to on-demand resources like blogs, videos, books and the flexibility to choose what they want, if they want, when they want. Training Only: For teams that want training in select areas and then want to be left alone. Quick Launch Only: For teams that want training to be followed with a short intense "boot-camp" like engagement that helps them apply what they learned in training On Request: For teams that want to "buy" a bundle of coaching hours that they can request on a first come first serve basis as needed Embedded: For teams that want embedded coaches who will sit with them for a time-box, 40 hours a week. Transformation: For teams that are willing to do whatever it takes to accomplish sustainable agility and lasting transformation. Build Your Own Package: For teams that want to pick and choose and build a customized package QUESTION #7 - WHICH PACKAGE DOES THE TEAM WANT TO CHOOSE? Now that teams understand the different ways in which they might engage with the Agility Enablement Organization, they can pick and choose the package that works best for them or co-create a new package. If the Agility Enablement Organization feels that there is a disconnect between where the team is, where they want to be, by when they want to get there and what they are willing to invest, this would be the time to respectfully disengage or guide the team towards options that are more realistic. QUESTION #8 - HOW WILL THE TEAM MEASURE PROGRESS TOWARDS THEIR GOALS? To make sure that we eat our own dog-food, we must manage our Agile Enablement empirically. We must design and execute experiments in short sprints and measure leading and lagging indicators so teams can empirically inspect and adapt their progress towards their goals. QUESTION #9 - WHAT'S AVAILABLE FOR THE AGILE ENABLEMENT ORGANIZATION? The Agility Enablement Organization must scan the industry to identify any ore-existing, reusable resources that are available for their company. QUESTION #10 - HOW WILL THE AGILE ENABLEMENT ORGANIZATION USE WHAT'S AVAILABLE? Finally, the Agility Enablement Organization must be strategic in their Build or Buy decisions. Can they reuse any of the existing frameworks, assessments, trainings or workshops as is? Can they complement internal talent with external talent? When should they they complement / customize / replace industry resources? Why? You can also view the slides for this blog on my slideshare presentation. INVITATION How would you apply what we have explored? What experiment would you execute to test your hypothesis? Try something and let me know what you learn. Until our next conversation, keep calm and Scrum On!

NEW YEAR RESOLUTION So it's a new year. New Year, new start, yadda yadda yadda... Maybe you are considering some New Year Resolutions so I wanted to invite you to take our 2017 waste-loss challenge by decreasing your Sabotagile Quotient. This challenge builds upon my previous blog - "Agile or Sabotagile: Help Your Management Understand the Difference". So if you haven't read it yet, please do so and come back. Before we go further, let's start with some definitions to help clarify the difference between Agile, Sabotagile and to introduce the Sabotagile Quotient... DEFINITIONS agile adjective An organization that applies the Agile Manifesto & Principles to enable self-organizing, cross-functional teams that frequently release high quality, incremental business value as a means to getting market feedback which guides future decisions. sabotagile adjective An organization that applies the Sabotagile Manifesto & Principles to command and control teams into releasing feature-packed releases on unrealistic deadlines, usually sacrificing quality and sustainability and delaying feedback from the market. SABOTAGILE QUOTIENT noun A number based on empirical evidence, that has an inverse co-relation to an organization’s agility. Calculated as follows... SQ = { ∑(Evidence of Sabotagile Manifesto) + ∑(Evidence of Sabotagile Principles) } x 100 ---------------------------------------------------------------------------------------------------------------------------- 1 + {∑(Evidence of Agile Manifesto) + ∑(Evidence of Agile Principles)} Ranges from 0 (high likelihood of agility) to 1800 (low likelihood of agility). Now let's explore how to calculate the Sabotagile Quotient... CALCULATING YOUR COMPANY'S SABOTAGILE QUOTIENT So here's how you can calculate the Sabotagile Quotient for your company... 1. Sabotagile Quotient is calculated on a cadence, at least monthly 2. Members of Agile Teams reflect together. Management reflects with peers – ex. Groups of Managers, Directors, VP’s, SVP’s, CXO’s 3. Each participant has access to the Agile & Sabotagile Manifesto / Principles. Use my slideshare presentation as a reference 4. Each participant maintains 2 totals - Agile Total & Sabotagile Total 5. Reflect on the retrospective period & compare significant events and decisions to 18 pairs of statements in the Agile / Sabotagile Manifesto and Principle. 6. There are only 2 possible scores for each pair of statements: 0 or 1. For each pair of statements, assign a score as follows… •If there were significant Sabotagile events or decisions relevant to this category, increment the Sabotagile Total by 1 and move on to the next item. •If there were significant Agile events or decisions relevant to this category, increment the Agile total by 1 and move on to the next item •If there were no significant Sabotagile or Agile events or decisions relevant to this category leave the totals unchanged and move on to the next item. 7. Calculate the Sabotagile Quotient: (Sabotagile Total) x 100 ------------------------------------- 1 + (Agile Total) It should be a value between 0 and 1800 9.Average the score for the entire team INTENTIONAL IMPERFECTIONS This is an imperfect process and tool by intent. Reminds me of something I once read... “A tool can be a valuable servant but a terrible master.” - Forgot who said or wrote it and google is not helping much. There's plenty of ambiguity... What may be a significant event or decision for one team member may be insignificant for another. Awesome! What may be an Agile for one team member maybe SabotAgile for another. Great! Let’s use this as an opportunity to value interactions between these individuals over the process and tools EXPLORATION Some food for thought... What might the Sabotagile Quotient tell us about our company? How might we apply the Sabotagile Quotient to increase value, decrease waste and manage risk for our company? What might be some risks and unintended consequences? How might we manage them? INVITATIONS I am ending this blog with some invitations... Calculate your company's Sabotagile Quotient in your next team retrospective. Compare and contrast perspectives across team members. Disagree without being disagreeable What would you like your company's Sabotagile Quotient to be? Set a target for December 2017. If there was 1 experiment your team conducted in the next 30 days to help your Sabotagile Score trend in the desired direction, what would it be...? You can also view this blog as a presentation on slideshare here Let me know what you think and discover. Until the next blog, keep calm and Scrum On!

EMBARRASSING CONFESSION OK, so this will be awkward, and maybe cringe-inducing post. But we are approaching the new year. Plenty of people might be making new year resolutions. Many will be around fitness. So everyone needs to read this. I was once really impressed by 24 Hour Fitness. I used to see their ads on TV, watch super-fit, muscular people coated with sweat leave the neigbourhood location as I was ordering Jalapeno Poppers from Jack In The Box. I used to imagine the mind-boggling array of fitness machines inside the location. I used to think of being motivated by master of contradictions, oxy-moronic Mother Theresa drill-seargeant fitness intructors. So I finally, I did it! I got myself a gym membership. However, I was very disappointed with the results. At the risk of being sued by 24 Hour Fitness (I will create a Go Fund Me campaign to pay the legal bills) I will tell you the truth... TOTAL FRAUDS! After months of membership, there was no change in my physique. I did not have one new muscle or one new iota of fitness. None of the coaches or sophisticated machines helped me. I was just the same. 24 hour fitness had no trouble hitting my credit card every month, but there was no ROI. I was very disillusioned with the whole fitness industry. They were just con artists exploiting the vulnerabilities and desires of innocent hard working people like me. Oh, BTW, did I tell you that I never once went to the gym? I wanted to be like the cool kids and if anyone asked me if I work out, I wanted to tell them something evasive but not completely untruthful like - "I have a membership at 24 Hour Fitness. It's really close-by." "I really like the ambience at 24 Hour Fitness." "I will probably work out at 24 Hour Fitness this weekend." I just didn't want to feel left behind or sound uncool when I was hanging out with the cool kids. But it was too painful to actually get up and go to the gym, especially when I could have a nap or watch TV. However, I liked having the option so that some day, if I really wanted to, I could go to the gym. This reminds me of the relationship many CXO's have with Agile... AGILE MEMBERSHIPS They buy an expensive Agile membership by paying the monthly fees for Agile Tools (Rally, VersionOne, JIRA, etc.), by hiring Agile Coaches, sending people to Agile Training, re-naming Project Managers to Scrum Masters and Business Analysts to Product Owners. This way, they can still hang out with the cool kids and if anyone asked about Agile, they could say something evasive but not completely untruthful like - "We are Agile - we have <Rally/VersionOne/Jira/etc.>" "We are Agile - we have Agile Coaches, Scrum Masters, Product Owners." "We are Agile - we just sent a bunch of people to Agile Training." ... They wouldn't have to change the way they think or behave, just change the way they talk and add a monthly auto-payment to the company's credit card payment, so they could sound more "Agile." SABOTAGILE! The more time I spent with executives like this, the more commonalities I observed between them. I realized that their behavior was more likely to help their companies in Sabotaging Agile than in being Agile. I captured some of these ideas in a blog last week - SABOTAGILE! – PROVEN TECHNIQUES FROM INDUSTRY EXPERTS TO FAKE AGILE, DEFEND THE STATUS QUO & ADVANCE YOUR CAREER . The blog introduces the unifying guiding values and principles of this group of people, via the Sabotagile Manifesto & Sabotagile Principles. Let me paste them here for quick reference... SABOTAGILE! MANIFESTO Manifesto for SabotAgile Software Development We are uncovering better ways of faking Agile Software development, defending the status quo, and advancing our careers. Through this work we have come to value: Defining rigorous processes with Milestones, Phase Gates, and Audit Trails Tracking project and program progress with Gantt Charts, %-age completion reports and Red-Yellow-Green executive dashboards Holding resources accountable with baselined contracts with fixed-scope, fixed-dates, fixed-costs Preventing a descent into chaos with rigorous change control boards Integrating phrases from flavor of the decade fads into lingo without changing behavior This is how we have delivered software in the real world for decades. And this is how we are going to do it! © 2016, www.smoothapps.com this declaration may be freely copied in any form, but only in its entirety through this notice. SABOTAGILE! PRINCIPLES Principles behind the SabotAgile! Manifesto We follow these principles: Our highest priority is to have resources deliver on scope, on time, on budget. Rigorously control deviation from plan to prevent resources from wriggling out of commitments & to prevent business from moving the goal-posts. Increase efficiency from resources through economies of scale, phase gates and large batch sizes. Use proxies between business people and resources, enabling business people to be externally focused and do real work. Use management oversight, performance objectives and bell-curves to maximize output from resources. Use documents and e-mails with audit trails as primary means of communication with resources. Executive dashboards are the primary measure of progress made by resources. Resources work late nights, weekends and cancel vacations to meet deadlines. Resources meet commitments by delivering to production and then patching with agile fast-followers as needed. Leverage economies of scale by having resources deliver as many features as possible in each release. Hire smart technical leaders to come up with architecture and design that junior resources can implement. Provide a sense of freshness to resources by integrating buzz words from latest fashionable flavor(s) of the decade into process and procedures manuals, training and executive communication without changing our way of thinking and behaving. Conduct postmortems with resources at the end of projects if time allows, as long as it does not interfere with resources doing real work. Return to Sabotagile Manifesto © 2016, www.smoothapps.com this declaration may be freely copied in any form, but only in its entirety through this notice. If you would like to compare and contrast Agile & Sabotagile Manifesto & Principles, check out my Slides on Slideshare. TEST DRIVEN COACHING OK, so that was the easy part. Now for the hard part... How can we make Managers, Directors, VP's/SVP's & CXO's understand the difference between what they say (Agile) and what they do(Sabotagile)? Management is usually super-busy doing "real work" and has too short an attention span for conversations like this. Fear not - I have the perfect solution - the Sabotagile Quotient, which we will explore in the next blog. Until then, please discuss with your teams and management and let me know what you think. Keep calm and Scrum On!

UNFLATTERING WISDOM OF HIND SIGHT As I look back at my many years as an Agile Coach - helping organizations introduce, optimize and scale Scrum, I am amazed and disappointed by the number of contradictory things I have been asked to do as an Agile Coach. And in all humility, I am also disappointed by the things I have done and the person I have been as an Agile Coach. The term "Agile Coach" has become overloaded to mean many different things to different people. This overloading can create a lot of mismatched expectations and suffering for Hiring Managers, Agile Coaches and Agile Teams because each person may have a completely different interpretation of who an Agile Coach is, what they do and what one might expect from them. With the unflattering clarity of hind-sight, I wanted to jot down some of my thoughts in the hope that they will alert me when I start going down a path I will regret in the future. And also to help hiring managers, Agile Coaches and teams get on the same page when it comes to expectations of an Agile Coach. So here are the 6 kinds of Agile Coaches I have been asked to be. And sadly, there are times when I have allowed myself to play almost all of these roles ... #1-CTB AGILE COACH The CTB Agile Coach is a Check-The-Box Agile Coach. The Hiring Manager couldn't care less about what Agile is and is not. They just know that everybody seems to be "doing it" and they are tired of answering irritating questions from people (especially their powerful stakeholders - leaders, customers, prospects, investors...) about why they are not "doing Agile". The Hiring Manager often thinks Agile is the fad and flavor of the month and will soon pass. So they decide to hire someone, anyone to play this role so they can put this conversation to bed and focus on doing "real work". #2-TPST AGILE COACH The TPST Agile Coach is a Trophy, Parade & Sales Tool Agile Coach. The Hiring Manager wants to hire someone charismatic with lots of TLA's and industry certifications who will shut up and sit in a trophy display case. At the appropriate moments, this Trophy coach is brought out of the trophy display and paraded to placate unhappy customers or to impress key prospects about how Agile the organization truly is. #3-L AGILE COACH The Legitimizer Agile Coach is someone who is brought out to endorse, legitimize, and "Agilize" whatever ridiculous, unethical, ineffective behavior powerful leaders are engaging in. The target audience is often an unhappy customer who is frustrated with the outcomes and needs to be confused and convinced into thinking that they are completely un-Agile and the root cause of all misery in the failing relationship. Often combined with the role of TPST Agile Coach. #4-SE AGILE COACH The Selective Enforcer Agile Coach is brought out by the Hiring Manager to bludgeon and confuse anyone who dares to challenge the Hiring Manager's ideas about what Agility is, until they give up and align with the Hiring Manager. #5-R AGILE COACH The Ritualizer Agile Coach is used by the Hiring Manager to ensure that teams are blindly following the rituals of Agile like the "Daily Stand-Up" and "Demo". The Hiring Manager does not care about the underlying principles, values or intended outcomes of Agile Frameworks, they just want to be able to show some evidence that teams are "doing Agile". Often combined with CTB Agile Coach. #6-HUGeB AGILE COACH This is one of the rarest Agile Coaches - the Help Us Get Better Agile Coach hired by a rare Unicorn Hiring Manager who sincerely wants application of Agile Values, Principles and practices to enable sustainable, measurable business agility. This Agile Coach enables self-sustaining communities where self-organizing teams and servant leaders... Continuously gain a deeper understanding of Agile Frameworks, Values, Principles and Practices Continuously create a clear, shared understanding of what business value is in their context Continuously apply '1' to implement experiments that reveal actionable insights to generate sustainable business value as expressed through '2' TWO INVITATIONS So I would like to end with two invitations that might help us reduce needless suffering in the name of Agile Coaching For Agile Coach Hiring Managers: Can you be courageous, authentic, unambiguous and unapologetic and communicate exactly what kind of Agile Coach you are looking for? For Agile Coaches: Can you ask hiring managers and leaders which of these Agile Coaches they are looking for? Keep calm and Scrum On!

SCRUM IS NOT THE END. IT IS A MEANS TO THE END… The end goal of empirically building strong, self-organizing Scrum Teams to help your business… Increase Sustainable Value Sustainably Decrease Waste & Sustainably Manage Risk It seems quite straightforward, however, as you start traveling down this path, you may run into complex challenges with no clear, black and white answers. Just lot’s of grey. So how do you navigate this sea of grey in a way that does not deviate from the three core outcomes of increasing value, decreasing waste and managing risk? In this blog, we will explore some tips to help you and to test your new-found knowledge by completing the Scrum.org PSM-1 assessment. THE PSM-1 ASSESSMENT The PSM-1 assessment is a foundational assessment from Scrum.org to gauge basic knowledge of Scrum Fundamentals. Many recruiters, hiring managers and Scrum Team members use this assessment as a way to screen out candidates who want to join the team. ACCEPTANCE CRITERIA I consider the PSM-1 to be a risk assessment & management technique. Decision makers are looking at current or prospective Scrum Team member(s) and trying to figure out Do our Scrum Team members have a solid theoretical understanding of Scrum fundamentals…? Do our Scrum Team members understand the practical challenges they will encounter in the application of Scrum? Will our Scrum team members apply their theoretical knowledge to tackle challenges in implementation of Scrum in an ethical & effective way? SO THAT... We have strong, self-organizing Scrum Teams that help our business… Increase Sustainable Value Sustainably Decrease Waste & Sustainably Manage Risk CHALLENGES Unlike some other Scrum Assessments, which are HARD TO FAIL, the PSM-1 is VERY HARD TO PASS. There are 80 multiple choice questions that must be answered within a 60 minute time-box to get a passing score of 85% or higher. This means that you can only get 12 answers wrong. Now this might not seem to be too big of a deal, and depending on how strong you are in this area, perhaps, it isn't. However, some people severely underestimate the complexity and ambiguity in the questions. Many questions have 2 or more right answers. There are seldom any black or white answers. Just plenty of grey. It is possible that all 80 questions that you get in your assessment are in grey. 80 shades of grey. So here are 10 Tips to help you navigate the ambiguity, uncertainty and complexity of Scrum and the PSM-1 assessment... TIP #1 - EMPIRICISM Empiricism is the heart of Agile and Scrum. Before you take the PSM-1 assessment, I would recommend that you understand what empiricism is and how it might fit into Agile & Scrum. Here is a short summary adapted from the Wikipedia article - Empiricism... Empiricism in the philosophy of science emphasizes evidence, especially as discovered in experiments. …all hypotheses and theories must be tested against observations of the natural world rather than resting solely on a priori reasoning, intuition, or revelation. …"knowledge is based on experience." …"knowledge is tentative and probabilistic, subject to continued revision and falsification." TIP #2 - AGILE Understand what Agile Software Development is. A quick summary is available at the Agile 101 page on the Agile Alliance site... What is Agile? The ability to create and respond to change in order to succeed in an uncertain and turbulent environment. What is Agile Software Development? Agile Software Development is an umbrella term for a set of methods and practices based on the values and principles expressed in the Agile Manifesto. Solutions evolve through collaboration between self-organizing, cross-functional teams utilizing the appropriate practices for their context. TIP #3 - MANIFESTO Understand the Agile Manifesto and the 4 dimensions along which we must continuously make trade-off's in the field of complex software delivery. Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. As you evaluate possible answers in the PSM-1 assessment, you could come back to the Agile Manifesto and reflect on which option might help us best in staying true to the manifesto in service of increasing value, decreasing waste and managing risk exposure for a business. TIP #4 - PRINCIPLES Internalize the 12 Agile Principles that can help our teams make decisions in the midst of uncertainty, ambiguity and pressure in the high-stakes business of complex software delivery... Principles behind the Agile Manifesto We follow these principles: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Business people and developers must work together daily throughout the project. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. Working software is the primary measure of progress. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. Continuous attention to technical excellence and good design enhances agility. Simplicity--the art of maximizing the amount of work not done--is essential. The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. Start applying these 12 Agile Principles as you evaluate options in the PSM-1 assessment. Sometimes, you may have to choose the least desirable option from among many undesirable options. TIP #5 - THE NEW NEW PRODUCT DEVELOPMENT GAME Read the Harvard Business Review article by Takeuchi & Nonaka, that was a key inspiration for Scrum - The New, New Product Development Game. This white paper will teach you 6 common characteristics that helped 6 different teams successfully introduce new products before their competitors, in a fiercely competitive environment. This article might shed some new light on the roles, events, activities & artifacts of Scrum. TIP #6 - SCRUM! Read the Scrum Guide - the official definition of Scrum. Internalize the roles, events & activities & artifacts of Scrum. Pay special attention to differences between the Scrum Team & Development Team. Carefully distinguish between words like "must", "may", "should" and "could". The PSM-1 assessment may have questions that test your ability to distinguish between immutable rules of Scrum and the recommendations of Scrum. Watch the video in which Ken Schwaber & Jeff Sutherland - the co-creators of Scrum explain the reason for introducing Scrum Values in the 2016 Changes in the Scrum Guide. Apply the Scrum Values to eliminate invalid options in the PSM-1 assessment and get closer to the right answers. TIP #7 - PRACTICAL CHALLENGES Once you start implementing Scrum, you will likely run into some common practical challenges. As you review the Scrum Guide for guidance on how to navigate these challenges, it is possible that you may not get definitive answers. The Scrum Guide is intentionally descriptive and not prescriptive. It intentionally does not prescribe responses to every conceivable challenge Scrum Teams might face. So if you are new to implementing Scrum, how might you respond to these challenges? One possible way is to read the book Agile Project Management with Scrum by Ken Schwaber - the co-creator of Scrum. This book is a series of real world Scrum challenges with some suggested ways to respond that stay true to the rules Scrum. Reading this book might help you prepare for some tricky scenarios that are presented in the PSM-1 assessment. TIP #8 - BUSINESS VALUE Scrum is a means to the end goals of empirically increasing value, decreasing waste and managing risk exposure for your business. As you evaluate options in the PSM-1 assessment, you may have to decide which option best supports these goals. One possible way to understand how decisions could have a domino effect on business value is to look at the EBMgt (tm) framework - Evidence Based Management for Software Organizations. This framework suggests 3 KVA's (Key Value Areas) and 11 KPI's (Key Performance Indicators) that might indicate how effective an organization is in conceiving, delivering and sustaining business value. Although you won't get questions about the EBMgt (tm) framework in the PSM-1 assessment, being familiar with the thinking may help you choose the right option from the sea of grey. TIP #9 - MINDSET I once heard Agile Thought Leader, Author & PST - Gunther Verheyen say that there is a distinction between what the Scrum Guide says and what the Scrum Guide means. The Scrum Guide was intentionally and rigorously designed to be minimalist, it can become a strait jacket without the right mindset. Without the right mindset, you may mis-interpret what the Scrum Guide says and pick the wrong answer on the PSM-1 assessment. But mindset is such a cliche. How can you get the right mind-set? One possible way is to learn from the thinking of advanced practitioners. Here are three ways in which you could get the Scrum Mindset Read blogs from Ken Schwaber - the co-creator of Scrum - https://kenschwaber.wordpress.com/ Read blogs from Gunther Verheyen - Agile Thought Leader, Author & PST - https://guntherverheyen.com/ Watch the free webinar series - Scrum Pulse, where Agile Experts explore practical challenges and recommendations in implementation of Scrum - https://www.scrum.org/Resources/Scrum-and-Agile-Webcasts TIP #10 - PRACTICE! If we were to eat our own dog-food, we would use empiricism and evidence to test our readiness for navigating the ambiguities of Scrum and passing the PSM-1 assessment. One possible way to do this is to take the free Scrum Open Assessment. I tell my students that getting below 95% on the Scrum Open assessment indicates a high risk of failure in the PSM-1 assessment. But the converse may not be true - you may get 95%+ on the Scrum Open and still fail the PSM-1 assessment unless you apply the tips I have recommended. WHAT NEXT...? You now have a backlog of learning to prepare for navigating the ambiguities of Scrum and passing the PSM-1 assessment. If you want a quick reference version of this blog, check out my Presentation on SlideShare. Plan your sprint(s), start scrumming and don't wait too long to SHIP IT! Keep calm and Scrum On!