It is always the same. What is the typical pattern you imagine when someone says they are in an agile transformation? The usual scenario is the following: Depending on the amount of money an organisation has, it hires either one of the Big 3 or a “Boutique Agile” or not-so-popular consultancy company. They come, spend one to three months, and create a 200-page PowerPoint. The document is filled with eye-catching graphics, diagrams, scenarios, and key advantages of new approaches. It may also contain some suggestions on which tools to use, how to configure the first Jira board, which calendar cadence to adapt, and what the difference is between horizontal and vertical backlog slicing. It will most likely also include some sort of SAFe implementation somewhere between those slides—the organisation's senior management doesn’t want to lose control, does it? Then, the consultancy company departs. Project Managers are renamed into Scrum Master/Agile Coach/Product Owner, depending on the assessment of the level of maturity senior leaders decide their organisation have during the workshop on maturity level assessment and, maybe, personal preference of specific individual (even the sentence that describes it doesn’t make sense). Then, teams host Team Charter exercises, create Scrum Kanban Boards, refine two work sprints, and start their work. By this time, everyone is irritated already because: As consultants, during their initial assessment, didn’t have a chance/time/money (or all together) to understand that some teams are not working in the same environment and just can’t use a similar workflow to others; Some teams have never had exposure to what Agile truly means, although they have been working in “new ways of working” for five years already; Engineers now spend more time refining work than coding; everyone knows they hate it; … Familiar, isn’t it? But is it the right approach? Back to school When children are first introduced to geometry in secondary school, it all starts with basics: What is a dot, line, and surface; Why parallel lines never cross each other; Why right angle is equal to 90 degrees; With this basic, it is easier to move forward. It's the same thing with Scrum. When you open Scrum Guide, it starts with the theory. It gently explains the idea of empiricism to the reader and introduces three Pillars - transparency, inspection, and adaptation. Whatever comes next - rules, events, artefacts, etc.- are all implementations of the basics and are impossible without following them. Same as geometry, isn’t it? If you open tasks for high-school students, you won’t be able to solve them without the basic knowledge provided to you in 5th grade. Try different Try to focus on these basics. You can’t touch or see them, and they are hard to measure and visualise on the dashboard. However, they are your values that truly uncover the beauty of Scrum and help to uncover “better ways of building software.” How can you promote and follow transparency? How can you ensure that you are actually taking some uncovered facts into account to improve your processes? Do you actually see all the unnecessary waste and explore ways of eliminating it? These questions are the quintessence of the Scrum Guide—“Easy to follow but hard to master.” Focus on understanding what potential you uncover through specific actions. If you know what's behind change/practice, you will find it easier for your team to understand and follow it. You will start supporting every action with the question, “Does it help us deliver better results? Do we support our actions by three fundamental pillars?” To make sure you are not making the same mistakes that many organisations who are stepping into the Agile Transformation territory have encountered before, try reading the Agile Manifesto and Scrum Guide again. While reading, think about how each item is presented in these documents, how they support each other, and how they build a common structure that makes sense. Use your imagination The transformation will only provide value when you think about the fundamental values every time the decision has to be made. If you have made a mistake, one of the key elements may need to be included. It is insanity to expect a different result without changing your actions. You need to change something to try again anyway - so why not try returning to school? Try to understand which exact element is missing. Find it, incorporate it into your process, and you will most likely succeed. Our main goal is to eliminate the habit that has been dominant on the market for the past twenty years—the habit of implementing tools and techniques without considering their value or how exactly they work. I highly recommend looking into Zombie Scrum — it's an amazing read and also the biggest library of problems that your team may encounter if they do not consider the purpose of every single item they implement from the framework. What is your secret to following what matters? Share in the comments. It is always the same. What is the typical pattern you imagine when someone says they are in an agile transformation? The usual scenario is the following: Depending on the amount of money an organisation has, it hires either one of the Big 3 or a “Boutique Agile” or not-so-popular consultancy company. They come, spend one to three months, and create a 200-page PowerPoint. The document is filled with eye-catching graphics, diagrams, scenarios, and key advantages of new approaches. It may also contain some suggestions on which tools to use, how to configure the first Jira board, which calendar cadence to adapt, and what the difference is between horizontal and vertical backlog slicing. It will most likely also include some sort of SAFe implementation somewhere between those slides—the organisation's senior management doesn’t want to lose control, does it? Then, the consultancy company departs. Project Managers are renamed into Scrum Master/Agile Coach/Product Owner, depending on the assessment of the level of maturity senior leaders decide their organisation have during the workshop on maturity level assessment and, maybe, personal preference of specific individual (even the sentence that describes it doesn’t make sense). Then, teams host Team Charter exercises, create Scrum Kanban Boards, refine two work sprints, and start their work. By this time, everyone is irritated already because: As consultants, during their initial assessment, didn’t have a chance/time/money (or all together) to understand that some teams are not working in the same environment and just can’t use a similar workflow to others; Some teams have never had exposure to what Agile truly means, although they have been working in “new ways of working” for five years already; Engineers now spend more time refining work than coding; everyone knows they hate it; … As consultants, during their initial assessment, didn’t have a chance/time/money (or all together) to understand that some teams are not working in the same environment and just can’t use a similar workflow to others; Some teams have never had exposure to what Agile truly means, although they have been working in “new ways of working” for five years already; Engineers now spend more time refining work than coding; everyone knows they hate it; … Familiar, isn’t it? But is it the right approach? Back to school When children are first introduced to geometry in secondary school, it all starts with basics: What is a dot, line, and surface; Why parallel lines never cross each other; Why right angle is equal to 90 degrees; What is a dot, line, and surface; Why parallel lines never cross each other; Why right angle is equal to 90 degrees; With this basic, it is easier to move forward. It's the same thing with Scrum. When you open Scrum Guide, it starts with the theory. It gently explains the idea of empiricism to the reader and introduces three Pillars - transparency, inspection, and adaptation. Whatever comes next - rules, events, artefacts, etc.- are all implementations of the basics and are impossible without following them. Same as geometry, isn’t it? If you open tasks for high-school students, you won’t be able to solve them without the basic knowledge provided to you in 5th grade. Try different Try to focus on these basics. You can’t touch or see them, and they are hard to measure and visualise on the dashboard. However, they are your values that truly uncover the beauty of Scrum and help to uncover “better ways of building software.” How can you promote and follow transparency? How can you ensure that you are actually taking some uncovered facts into account to improve your processes? Do you actually see all the unnecessary waste and explore ways of eliminating it? These questions are the quintessence of the Scrum Guide—“Easy to follow but hard to master.” Focus on understanding what potential you uncover through specific actions. If you know what's behind change/practice, you will find it easier for your team to understand and follow it. You will start supporting every action with the question, “Does it help us deliver better results? Do we support our actions by three fundamental pillars?” To make sure you are not making the same mistakes that many organisations who are stepping into the Agile Transformation territory have encountered before, try reading the Agile Manifesto and Scrum Guide again. While reading, think about how each item is presented in these documents, how they support each other, and how they build a common structure that makes sense. Use your imagination The transformation will only provide value when you think about the fundamental values every time the decision has to be made. If you have made a mistake, one of the key elements may need to be included. It is insanity to expect a different result without changing your actions. You need to change something to try again anyway - so why not try returning to school? Try to understand which exact element is missing. Find it, incorporate it into your process, and you will most likely succeed. Our main goal is to eliminate the habit that has been dominant on the market for the past twenty years—the habit of implementing tools and techniques without considering their value or how exactly they work. I highly recommend looking into Zombie Scrum — it's an amazing read and also the biggest library of problems that your team may encounter if they do not consider the purpose of every single item they implement from the framework. Zombie Scrum What is your secret to following what matters? Share in the comments.
