Agile Coaching - Agilonomics

Optimizing Workforce Efficiency: Employee Utilization with Agilonomics

Effective “Utilization” of Employees

January 19, 2023 No Comments

Have you heard the phrase? – “Watch the Baton, not the runners?” Translated to development work, it means: “Focus on Idle work, not Idle workers”! (Image 1) I still come across management finding ways to extract most out of their developers by assigning them to multiple projects The thinking is to get 100% utilization out of each worker So, Joe is made to work: 40% on project A, 30% on project B, and 30% on project C And, this way Joe is 100% utilized! Such a mindset is flawed Here are two different ideas to explain this: Theory#1: Queueing theory and utilization (Image 2) As you can see, when queue sizes are small(optimum), utilization looms around 70% – 85%. Work continues to flow optimally. A little surge here and there is absorbed easily With further increase in queue size, utilization shoots over to 100%. Things slow down considerably and bottlenecks are seen This means that if Joe is close to 100% utilized, then it will slow down the delivery or completion of all the items he is working on Furthermore, if Joe’s team mates Harry and Nancy are all (also) 100% utilized, then the team cannot handle critical items that suddenly pop up and need attention And, hence, Management needs to focus on idle work and not idle workers! Theory#2: Context switching 40% + 30% + 30% does not add up to 100% IT DOES NOT! Why? Because, Joe is a human being and not a “resource” There is context switching and we know that loss of time due to context switching is pure waste! Image 3 – is from research on multi-tasking done by Clark and Wheelwright (1992) which shows that when working on more than two projects, a person’s time spent on value-adding work drops rapidly Multitasking is an evil and really speaking, everyone is to be blamed and not only the management I once met a developer who was asked to divide his time between 4 different projects, and as a result, couldn’t deliver to his Scrum team commitments but was fine working on the 4 projects as it brought him importance and visibility at the cost of impacting all the projects – spread across 3 Scrum Teams It took several coaching sessions between us that helped him realize that this may negatively impact him in the long run as well and he voiced his new understanding to the management and they set him with just two projects which helped everyone! With these two well researched theories, management and leaders need to reflect on how they utilize their people and best ways to help them be effective! What has been your experience with over utilized workers and multi-tasking? How have you dealt with such a mindset and what have you done about it? (taken from Amit’s Linkedin post “January 12, 2023”)

Scrum Managers: Agile Leadership Roles With Agilonomics

Managers in Scrum

December 28, 2022 No Comments

We all know that the Scrum Team consists of the three main roles – Scrum Master, Product Owner and Developers (erstwhile Development Team) Where do Managers fit in then? Many think that Managers do not have a role in Agile and Scrum. Some even say that Managers are not necessary and teams can survive and even thrive without them Well, Agile being “agile”, is all inclusive and so Managers can live and actually help Agile grow and thrive in a number of ways Let us explore all different roles and places where Managers can fit in and how they can positively impact their Agile and Scrum teams and what do they need to avoid that would weaken agility in their environment and organization Manager and Scrum Team: The Manager role has been in place long before Agile and Scrum came into being. Managers were responsible for taking care of people, what they work on, how they accomplish the work and would help with tracking the work However, Agile encourages self organizing teams. Per the Agile manifesto: The best architecture, requirements and design come from self organizing teams (Principle#11), and Build projects around motivated individuals. Provide them with the environment and support they need and trust them to get the job done (Principle#5) Furthermore, the Scrum roles and responsibilities outline the Scrum Master as one who owns the process, team effectiveness and team happiness. This includes conflict resolution, making sure the impediments are resolved in a timely manner, mentoring, guiding, coaching, facilitating, … You may benefit from reviewing related blogs. What Does A Scrum Master Do? | Agilonomics and An Ideal Career Path for a Scrum Master | Agilonomics for in-depth understanding of the Scrum Master role Scrum Product Owner is the one who understands the market, the users and customers, brings in the requirements and prioritizes them. He/she creates the vision for the product and aligns it with the team and stakeholders. He/she works with the team to groom the backlog, is available to clarify requirements and accept the “done” work throughout the Sprint The Scrum Master coaches the developers and the Product Owner to work effectively keeping in mind the tenants of Agile, focused on value delivery and team effectiveness What is the role of a Manager in this setup then? And, where and how does a Manager fit in this whole picture? Well, there are a number of ways Managers show up with Agile teams. I discuss a number of scenarios I have come across with examples and suggestions that can make the role effective Manager as the team boss: Developers report to the Manager and Scrum Master is an independent role with reporting lines in another department (example – PMO) Manager’s micro-managing the team can conflict with the Scrum Master role and create an impediment to Scrum effectiveness. If Scrum Master wants to experiment with the process or coach the team for following Agile Principles but the Manager opposes it, it will weaken the SM role and team effectiveness can suffer It is important that the Manager, Scrum Master and Scrum Master’s boss have a working agreement so that the Scrum Master feels empowered and the role is supported In the case the Scrum Master role is played by one of the developers then the Scrum effectiveness can be weakened further as there is no one for the Scrum Master to intervene if needed. Such Scrum teams work towards only perfecting “doing” Agile Manager as the Product Owner: This is common in many companies where Manager transitions to the PO role since she has been working with the same team managing the what, how and tracking prior to transitioning to Agile Scrum Master belonging to an outside-the-team department such as PMO may find it hard to coach the Manager in Agile ways. Example: Manager failing to agree-upon/cooperate on how to address change and repeatedly brings scope (creeping) in the middle of Sprints and justifying her being the PO, can call the shots on scope. Such reasoning can hamper with correct and effective agility Here, too, having a working agreement with the Manager and PMO can help empower the Scrum Master Again, If the Scrum Master happens to be a developer, then coaching one’s own Manager-cum-PO can be even harder and challenging Manager as the Scrum Master: This is a tough one. There is a conflict of interest in the two roles. A servant leader Scrum Master coaches the team, adheres to the Agile values and principles but experiments with the process to see what works best for his team. He is open to the team challenging his assumptions and disagreeing and in fact uses such disagreements to foster powerful conversations and bond the team However, when this role is played by the team Manager, it is difficult for developers to oppose or challenge the choices the Manager makes. The subtle thought, “my performance review will be impacted if I oppose my Manager”, is always in the back of the mind of the developers Best is to avoid this anti pattern in the roles because however hard you may try, you will find it will never achieve the right balance between the two conflicting roles Manager as both the Scrum Master and the Product Owner: This is a double tough one. One for the reasons mentioned above and second for the two conflicting roles being played by the same person Scrum Master role is to protect the team from being overly and unreasonably pushed by the PO and stakeholders while the PO role is to push and drive the team to achieve business goals. A delicate tension between the two roles is healthy for effective Scrum Remember, when the same person plays both the Scrum Master and Product Owner roles, it is like being a 2 headed dragon. At any time, one head will end up eating the other. In other words, you cannot be a good Scrum Master and a good Product

Jobs To Be Done vs User Story Maps – 2

July 8, 2022 No Comments

scrum This is part 2 of the article on JTBD vs. USM For part 1 of the article, please refer to …… Jobs To Be Done vs User Story Maps In this article, we will fully dive deep into what Jobs To Be Done (JTBD) really is and how it differs from User Story Maps. I will also help show how to use them collaboratively in meeting your needs. JTBD first came out when Clayton Chirstiansen, a professor at Harvard Business School’s Product Management group, set out with his team to understand what ‘needs’ drive people to ‘hire’ a product. Needs are driven by “jobs that need to be done”. In short, Clayton and his team ended up interviewing a number of people buying Milkshakes at a fast food restaurant. They asked each Milkshake buyer, “What jobs do they need done that makes them hire a milkshake?” While many did not understand what the question really meant, Clayton’s team through observation and talking with customers figured out that people who had to commute long distances early AM needed to buy milkshakes to keep them full till lunch, to have something that takes quite a while to consume, to have something that is easily manageable while driving through the commute……. And that, they were not necessarily buying milkshakes because they were delicious. Here is the video where Clayton talks about Milkshakes! This and other experiments made Clayton and his team conclude that people hire a product because they have a certain job that needs to be done. This is quite revolutionary. “The secret to right innovation lies in understanding what causes customers to make choices that help them achieve progress on something they are struggling with in their lives. To get to the right answers, Christensen says, executives should be asking: “What job would consumers want to hire a product to do?” So, in summary, JTBD: Indicates what users want to get done Is independent of specific personas Provides insights into the deeper needs of the Customers. The deeper needs provide insights to a business on how to be innovative while creating products. A lot of people who love Apple phones still end up buying Samsung because their need is to have a better camera on their smartphones! User Story Maps (USM) on the other hand, is based on users and their experiences while using a product. USM focuses on specific personas and their story on how they (want to) use your product. A good user story map contains not only the journey but also the experience – challenges, pains, awards and joys the users feel or express while using your product. Although, the USM has no specific set of rules, it is recommended to understand the difference between the sea-level “user steps” (a step that a user takes in the journey of using your product with the intention of completing it once started) and the “backbone” – activity or higher level summary of a group of steps as shown in the image below Fig. xxx – User Story Map for an Air Travel App While both the sea level (user steps) and backbone (higher level summary) are in narrative flow, the backbone actually represents the jobs to be done and provides insights into the deeper needs of customers or users. The narrative flow of sea level user tasks goes like this: (As a user of this product) I will do this , and then I will do this, and then I will do this and then…. The narrative flow of backbone (user activity) goes like this: (As a user that wants to get this job done – air travel in this case) I need to do this , and then I need to do this , and then I need to do this and then … Please refer to the examples below illustrating the above: Looking at these images, one can easily see that jobs to be done are already embedded into the user story maps. Many do not know how to create story maps effectively. If you can build your maps wisely and mark out areas or steps where customers and users experience challenges, pains and have to work around to get through those step(s), you will be able to draw insights on what they want to get done and what needs are not being met for which they have workarounds. Clayton himself has said: “For me, this is a neat idea,” Christensen writes of the Theory of Jobs to Be Done. “When we buy a product, we essentially ‘hire’ something to get a job done. If it does the job well, when we are confronted with the same job, we hire that same product again. And if the product does a crummy job, we ‘fire’ it and look around for something else we might hire to solve the problem.” Many folks who have never experienced story maps and their effectiveness and usefulness in creating delightful products, but know about Jobs To Be Done, use this thinking framework to draw insights. However, they will still need to create some sort of visual alignment for conversations to build a shared understanding. ou cannot just use JTBD on its own to help others understand a product. Remember, JTBD is a motivation and not a product design! However, people who employ user story maps can easily draw out the jobs to be done Comparison between Jobs to be done vs. User Story Maps Conclusion: There’s quite a bit of debate out there on what is a better approach for building a great product, Jobs To Be Done Or User Story Maps. The reason for the debate is due to a lack of proper understanding of how these two approaches work. Looking deeply and objectively, one will find that they are not conflicting but are different ways to understand your customers and user’s real problems and goals, which is part of a good product thinking exercise. A user story map will ideally

Jobs To Be Done vs User Story Maps – 1

May 18, 2022 No Comments

This part – 1 of the article explains situations that arise due to lack of ownership for journey mapping exercises. Who should own them?, why should they be done? Etc. The part – 2 of the article discusses in depth the Jobs To Be Done vs. User Story Maps – 2 Part-1 While helping clients with Agile transformation, I focus on a few important aspects, which are outlined below: Engaging executives, senior management and leaders from the beginning Roles and Responsibilities, Events and Ceremonies, The Team, PO and Scrum Master roles Helping create happy, high performing, effective teams Product mindset and Value delivery – keeping the big picture context and desired outcomes in perspective from beginning to end It is with respect to this last point #4, I often introduce journey (aka user story) mapping concepts and workshops to the leadership. It is usually received with mixed response, and although, people love the workshop, they need some hand holding to get started onto this. We eventually get the product owners to own this and work with a small group of engineering and design leads to get the high level maps in place, which eventually results into exploring deeper area maps (remember: maps, contain maps, contain maps…) that are owned by individual teams as they try to build a shared understanding for the features or products they are responsible for. I also saw resistance from Product Owners to drive the creation of journey maps citing that they already created a PRD (Product Requirement Document) and since it’s all clear in their minds, they failed to understand why it is difficult for engineering and design teams to align with their thinking. The engineering team, on the other hand, complained that the product only provides a document or a one-liner explanation for critical items, and they have to interpret the details on their own. The design teams tended to side with engineering in not having a clear understanding of assumptions made by the product team. Moreover, the design team decided to start driving the creation of the JTBD list involving members from engineering and product through discussions. Let’s distil the issues hidden in the above paragraph: Firstly, written documents do not create a shared understanding. Writing such documents and making them the basis for alignment is the reason why so many of the products fail to delight the end users and customers, and as such, do not do well in the market. I wrote an article on this: The Problem with Requirement Specification Documents Secondly, Product Owners not wanting to own creating visual artifacts (JTBD, Journey Mapping, etc.) and being more in the role of a secondary observer/participant is quite puzzling. On inquiring a little, I found that the Product teams had bandwidth issues, were overwhelmed in learning a new concept and lacked belief in new ways of thinking to create a powerful version of their product that would highly differentiate them from their competitor’s offerings. This not only needs coaching to understand the value of such activities, but also a commitment from the product leadership to invest time in them. Thirdly, the product leadership failed to understand why their Product Owners should co-drive the journey maps? I asked a few questions: They realized that missing POs during such journey mapping activity might not give them the desired outcome they want to see while delivering the product! Once this was resolved, the product leadership had two asks: We really do not understand how to create user story or journey maps; can you help us get started with a hands-on exercise? And, We have the same big question again: How is the JTBD (Jobs To Be Done) list different from journey mapping and if they are different, how can we leverage them in journey map creation? In answer to the first question, I took them through a fun and hands on user story map session. It took around 90 minutes to facilitate this for a big group of 20 people. I have captured this into a 4-minute cartoon video that anyone can find handy. In answer to the second question: Please read the part 2 of this article Jobs To Be Done vs User Story Maps Amitabh (Amit) Sinha is a servant leader entrepreneur, visionary, mentor, trainer and coach. Amit is highly passionate about Agile, its principles, values, and the human side. Amit is a people champion and strives to bring out the best in his teams. Amit leverages his expertise in Agile, Scrum, Kanban and people skills to increase team effectiveness and happiness. See more

Why Sprint Reviews Are So Hard ?

March 18, 2022 No Comments

Why Effective Sprint Reviews Are So Hard To Achieve? As we know, there are four main Scrum ceremonies: Sprint Planning, Daily Stand up, Sprint Review and Sprint Retrospective. Additionally, we also groom or refine the backlog (Backlog Refinement) which happens throughout the Sprint. The Sprint Review is second to last ceremony in the Sprint. The purpose of the Sprint Review is for an Agile team to show their product increment to the Product Owner and business stakeholders. The idea is, for the team to demo their product increment, features or functionalities and engage the audience in conversation to understand how they feel about it, what they like or dislike about it, what they think is still lacking etc. In the course of this conversation, the team gets valuable feedback, which they use to improve the product in subsequent iterations. Among all the Scrum ceremonies, the one that appears to be the weakest or least effective is the Sprint Review. There are many reasons why Agile teams struggle organizing effective Sprint Reviews. 1. The most critical reason is the inability of Agile teams to create their product keeping the big picture in mind. If one looks at the Product Backlog Items (PBI) of most Agile teams, they will not be surprised to see that many of those items, called “Stories”, do not give any value to the end user or customer. Even combining a few of these stories does not give much value. Having finished these components, the team demonstrates those bits and pieces to the business stakeholders. Not only is this boring for the audience, they also do not see much value in it. Imagine somebody is designing and creating a beautiful table, but only shows one leg and half of the top to potential buyers at an agreed upon date. Would you be excited to buy such a product? Will you even be motivated to come back and look at it unless it’s completely done? I have often seen senior leaders and executives coming to a Sprint review for the first time when a new Agile team demonstrates their completed work. While these leaders praise the team for their accomplishments, you can see a confused look on their faces asking an unspoken question: The senior leaders and executives eventually stop coming to the Sprint Reviews, as they don’t find them meaningful. 2. The second most important reason for Sprint Reviews to be not attended by senior leaders or relevant stakeholders has to do with the language used during the demo. What I mean here is, that a lot of Agile teams do the demonstration of their product in technical language. They bring up a screen with a Linux prompt and open the code, showing pieces to confirm on how the goal of a Story is achieved. While this could be attractive to other technical team members or even engineering managers, the business folks really do not get much value from it. This is akin to an audience that understands only Japanese, but being invited to a review of a product that is to be given fully in English. Just imagine bringing up a screen with English letters and words being displayed, with the hosting team speaking only in English. Will the Japanese stakeholders come back to such a Sprint Review? – NO! It would be a good idea for the (Business) Product Owner to actually drive the demo. They can work with the team and also speak the language of business stakeholders. Enabling stakeholders to be able to directly interact with the functionality of a product rather than demoing technical code will also be appealing to them. 3. Sprint Reviews being held on the wrong day of the week. Ideally, the Sprint cadence should run from Wednesday to Tuesday or Thursday to Wednesday. The advantage with this cadence is that the starting and ending days do not fall on a Monday or a Friday – the days when people tend to be busy or not easily available. For example, a 2-week Sprint that starts on a Wednesday will end 2 weeks later on a Tuesday. However, many teams, especially new ones, without much experience, tend to start their Sprints on a Monday or a Tuesday. This results in Sprint Review falling on Fridays or Mondays (Ideally the last day of a Sprint) when senior leaders and relevant stakeholders are busy and unavailable, resulting in poor attendance. 4. I have also seen that there are certain scaling frameworks in Agile which tend to encourage many teams in organizing their reviews or demos together. I have seen such teams sitting in a big conference room for hours together doing their Sprint Reviews. This is a painful sight to see. Especially so, because most of these teams were component teams and did not have much understanding of how each other’s work contributed to the bigger product. It is difficult to visualize senior leaders and business stakeholders sitting in such reviews for half a day. It would be considered a big waste of their time, and for this reason, attendance for such Sprint Reviews are low. 5. Lack of proper engagement of key stakeholders also results in poor attendance. Most teams call their Sprint Reviews as Sprint Demos. In fact, Sprint Demo has become the more popular name for Sprint Reviews. The whole idea of this ceremony is about engaging your customers and users for a meaningful conversation and taking important feedback that can be critical for the product success. But more often than not, hardly any conversation takes place. How do we break this barrier? One thing that comes to mind is, that, instead of waiting for the entire Sprint Review to be over, teams should take feedback after every item is reviewed. This will not only keep the stakeholders engaged, but will encourage them to provide valuable feedback for each item at the current time. How often should we do Sprint Reviews? Ideally speaking, Sprint Reviews should be held every

A RAMBLE ABOUT METRICS – ZACH BONAKER

October 1, 2020 No Comments

MEASURING AGILE How will you show the progress of agile transformation? How will you measure improvement in teams and people? And how will you avoid the trap of shallow metrics like say:do ratios and velocity? Whether you’ve worked as a manager, coach, or consultant, you’ve likely experienced conflict and confusion over “agile metrics.” Traditional metrics which emphasize personal productivity drive negative behaviors, encouraging us to stay busy with tasks over working together to achieve goals. Meanwhile, leaders feel dissatisfied with popular “agile metrics,” such as velocity and burn-down charts, when they fail to provide the insights desired. This conflict between management and the information generated by metrics is further exacerbated when three common human desires for “measuring agile” inevitably occur: The need to prove “the new way of working” achieves more than “the old way of working.” This desire typically reveals itself through challenges like, “how will we know we’re more productive with agile?” or “how can you show me are teams are more efficient?” The desire for agile to deliver “more quality.” Often, we hold on to the premise that a new process (e.g., teams will work in sprints) is the key to unlocking quality. The scenario can be especially challenging in the absence of systemic knowledge about quality. “Our CEO is sending strong messages expecting quality to improve. Beyond defect counts and customers complaining, we’ve never had a good idea of what quality is. What do we do?” Sound familiar? The belief that process conformance is a good proxy for success. How we will respond when a senior leader challenges us with, “I want to know the maturity of teams and the adoption of process. How can you show me our agile transformation is successful?” Success Metrics and Improvement metrics While there are many reasons these scenarios may be challenging–and frustrating–to solve, one possible contributor is the failure to distinguish between “success” and “improvement.” By definition, “success metrics” are exactly that: the key measurement which reflects on the interaction (and collaboration) within the system to generate a successful outcome. By taking a measure-up approach to avoid focusing on individuals, we can see whether our system of work is delivering the result we need. Because we’re considering the success of the system, we likely only need one, possibly two, success metrics. Further, such metrics would be relatively long-term in persistence. On the other hand, “improvement metrics” are useful until they no longer are. They exist to help guide us towards reaching a desired state, whether it be behavior, process, or performance. By definition, “improvement metrics” should be relatively short-term in lifespan and may change based on new information gathered. It’s easy to test for an improvement metric: we can state what decision(s) we will make as a result of the metric, plus what conditions would exist for the metric to no longer be useful. An interesting thought which comes to mind: perhaps in the early stages of using agile (and assuming an absence of prior “success metrics”), our success metric might be the length of time before an improvement metric becomes obsolete. I believe this structure of categorizing “success” and “improvement” metrics creates an environment where two beneficial things can happen: We reduce the fear (i.e., gaming) of metrics through transparency of our intent to use metrics. Clear statements of intent, as well as conditions to make metrics “go away,” often create motivation to work with–rather than against–measurement. The defined difference between “success” and “improvement” metrics can catalyze a helpful mindset change in people. To illustrate the second point, consider a scenario which might be familiar: A company shifts from a matrix system of work to teams working in sprints. Once this happens, a manager feels the need to measure team productivity and/or performance. After all, this is a new “process” and the manager wants to make sure it’s effective. To do so, the manager asks teams for a “say:do” ratio: the number of items/points/features/etc predicted versus the total actually delivered. If not success metrics, it is an improvement metrics It’s likely the manager considers this measurement a “success metric.” Therefore, we ask her to explain how the metric represents the interaction of all the parts necessary for success. Assuming our goal is wildly successful software products which our customers love, we likely realize this metric ignores essential contributions of product management, customer support, the degree of disruption the team must manage, and other probable factors. So, if not a success metric, might it be an improvement metric? We explore further: What decisions will we make with this metric? If a “say:do” ratio is considered poor (the team doesn’t meet their forecast), what happens? If the ratio is very good, what then? Could decisions we make with this metric encourage people to “game” the metric or be less transparent? What conditions must exist to make this measurement no longer needed? If a team meets their forecast 100% of the time, we likely no longer need it. Is this condition an indicator we have achieved our goals? I suspect these conversations might guide the manager to reveal her assumptions about measuring teams aren’t serving her ultimate needs. We then have the opportunity to explore together a more systemic need for measurement, most likely focusing on gathering information to improve, rather than perform. In my experience with agile and “transformation”, whatever that might be sometimes, I’ve found results tend to improve when we move away from “metrics to manage behavior” and begin using “metrics to help us understand behavior.” This framework of success and improvement metrics can help us achieve exactly that outcome. About the Author Zach Bonaker Agile Coach Zach Bonaker is a “benevolent trouble-maker” based in San Diego, California, USA and has more than 10 years of experience assisting organizations with achieving their goals through improved working conditions and team-centric systems of work. With experience guiding Fortune 500 companies to multi-million dollar startups, Zach draws upon agile principles, relationships, and systems thinking to redesign structures into safe, collaborative

Agile SOW

July 1, 2020 No Comments

Software projects are becoming increasingly complex. This complexity demands Agility. Agility translates to faster product increments, shorter review cycles, end-to-end picture of the product which essentially means incremental and iterative delivery. Quality needs to be built in. End user and customer engagement (via the PO) is indispensable for both building the “right product” and the “product right”. While the IT operations are going through a paradigm shift towards Agile, has the documentations such as SOW changed to cater the needs of Agile world? What is an SOW ? Statement of Work (SOW) is a legal binding contract between an Organization and a contingent worker or a vendor that dictates the directions of how the work will be done. So, for Agile projects, the less you write, the better off you are. Remember, the mantra is: “Less is more”. Having said that, an SOW for an incrementally-delivered project should consider the following facts when drafting one. What system are you trying to build? What are the common objectives? Describe the system. Include lists of themes, (feature) areas and any other important descriptions that help both the parties to understand the system better. Declare – loud and clear – that our development strategy is incremental and iterative. In Agile, neither of the parties know up front 100% of features that will constitute the final system. We negotiate that with the product Owner (PO) on an ongoing basis Establish the fact that features will be delivered incrementally in an iterative fashion called sprints. Define the sprint. A Sprint may range anywhere from 1 to 4 weeks of iterative cycle. The PO, business stakeholders and customer can review what has been created and provide valuable feedback at the end of each sprint to refine and re-prioritize for upcoming iterations. The project sponsor has the power to cancel the project should he/she see no further value in building this product. There should be a working agreement on how much advance notice the sponsor needs to provide to the development teams and it should ideally apply at the end of an ongoing sprint The customer/PO can choose to change the pace of delivery by changing priorities of upcoming features based on the review of product increment. The customer/PO cannot change the pace of delivery by demanding to cut corners (quality). In other words cutting out features/MMF is fine but delivering everything at a tighter pace by cutting upon quality is not acceptable Elaborate on what to Expect from the team. Include an initial delivery plan of features that the customer can expect from the team in the first 2 to 3 sprints in the order of priority. If possible, It is good to provide the vision, product backlog (top 3-4 sprints prioritized with 70-80% accuracy. Including a Release plan in SOW The SOW can include a statement that as the teams start working, they will put together a release plan to provide an insight on how the timelines look at this time. A note in bold must indicate that this is how it looks at the very beginning and that this release plan will be updated after every sprint and the updates will be made available to all stakeholders. The release plan should try to cover the below facts: Top 3-4 sprints with updated items(from the initial plan) Next 8-10 sprints prioritized with 50%-60% accuracy. Then, next 6-8 sprints could be with even lower( 30-40%) accuracy and the remaining items prioritized with 20% or lower accuracy. The PBI (product backlog items) should map to the product roadmap. The product roadmap should also have releases marked with farther out releases having increasingly lower accuracy (confidence rating) Initially the big blocks of work lower in the backlog will be Tshirt sized and the teams may want to have a rough mapping of Tshirt sizes to get an arbitrary value of story point . Alternatively, affinity sizing can be used to quickly and roughly estimate a large initial backlog so the teams have some numbers to refer to as they take strides into sprints With time, as the product emerges and evolves, the PO and stakeholders get better sense of the timelines with updated release plan which has estimates with higher accuracy The team velocity is an important factor for creating the release plan. Prediction of team velocity is possible after first few sprints. A team’s velocity is not same as any other team’s due to various factors like experience, number of members in team, complexity of product, the technology they are working on, their style of estimation, etc. Velocity plays an important role in Agile release planning. Proper coaching by a servant leader Scrum Master is highly essential for a Scrum team to estimate consistently, plan and commit to correct capacity and then deliver to its commitment. This brings up a stable velocity and predictability which in turn provides confidence to the PO and stakeholders and they look forward to the updated release plan Agile at the end of every sprint. Servant leader Project managers and Scrum Masters must include only the details in SOW that are of Agile nature. There should be no pressure from the leadership to include details that SMs/PMs do not feel confident about. This way the Servant leader SMs won’t be held hostage by not accomplishing timelines and scope they did not think could realistically be included in an Agile SOW. The behavior of the leadership in such companies that want to really adopt a more Agile way of working should be transparent and oriented towards creating a culture where their actions are in sync with their desire to be Agile Final Notes Let your SOW be versioned and wait for the signatures till an agreed upon Agile SOW is in place. The first version of the SOW should be light. A small handful of sentences should suffice. If you do get push back, review your options, some of which could be: If it’s not win-win, educate and coach the client on why Agile