​I was at a small gathering with friends recently when the conversation took a turn into wheelchairs. Someone brought up how many people “abuse” wheelchair assistance at airports.

“Half of them are faking it,” one person said.
“Just charge them a big fee and see how many still need help.”
Heads nodded. A few more creative punishments were suggested.

Then the topic widened. From airport wheelchairs, we jumped to bribing at government offices in India and tricks people use for H-1B visas in the US. Finally, someone shrugged and said: “Come on, desis do this all the time. Our people will always find a shortcut.”

That line stayed with me.
It sounds like common sense. If you’ve dealt with a village office or tried to get something done at an RTO, it feels true. The file doesn’t move. The clerk is “very busy.” Until an “agent” appears, and things suddenly move faster. After a few rounds of this, it’s easy to conclude: this is just how our people are.

But that sounds like too simple of an explanation.

The same “our people” who pay bribes in one setting stand quietly in line at the US DMV. The same person who needs an agent for a driving license test in India follows every boring instruction on a government website in the US. They show up with the right documents. They wait two hours. No envelope under the counter.

Did their character change on the flight?
Did their DNA reset at immigration?
Or did something else change?

What changed was the system.

Imagine a simple experiment. Take one honest, rule-following American and drop him into the worst local office you know in India. Long lines. No clear instructions. The official can always find one more missing form. If he follows the “proper” process, he may lose days of work and still not get the thing done.

Then quietly offer him a shortcut.
“Sir, if you pay this much, you can finish today.”
How long before this very honest person starts to think about it?

Now reverse it. Take a “typical corrupt desi” and drop them into a system where the rules are clear, the website actually works, and the officer could lose their job for taking a bribe. In that world, they simply follow the process. There is no other path. They becomes the person who posts online about how “the system works so well here.”

This doesn’t mean people are angels. But it does suggest something uncomfortable: much of what we label as “Indian corruption” is people trying to survive bad systems.

Consider a small licensing office where one clerk controls dozens of approvals. His pay barely covers living costs. Even where pay has improved over time, discretion remains high and accountability weak. The rules are vague enough that he can always delay a file “legitimately.” There’s no real audit trail, and almost no risk of punishment. In that setup, refusing a bribe is costly. Taking one is rewarded. That’s not a moral question. It’s how the system is set up.

If a system is slow, confusing, and full of small officials with big discretionary power, bribes become the oil that makes the machine move. If the system is digital, trackable, and risky for the person taking the bribe, the same human being behaves very differently. This doesn’t make bribery okay. And it doesn’t make the pain of the honest person standing in that line any less real. 

But it changes the question we ask.
Instead of:
“What is wrong with desis?”
we can ask:
“What is wrong with the way this system is built and run?”

Many parts of our bureaucracy were never designed to serve citizens in the first place. They were built to control and extract. After independence, the flag changed, the leaders changed, and many laws changed. But much of the structure remained: centralized authority, endless permissions, and layers of signatures at every step. Later governments piled more rules on top, often with good intentions.

Low pay. High discretion. Weak accountability. Put those together, and corruption is not surprising. It’s predictable. When we say “desis are corrupt,” we skip over all of that. We take history, bad design, and political choices and collapse them into a story about moral character. About us. It feels like brutal honesty. But it does something else too: it makes us numb to people’s struggles.

The shop owner who pays to get a license faster because a delay will kill his business.
The student who pays an agent because everyone tells her nothing moves without one.

This is not to excuse it. It’s to understand it. If we want less corruption, shouting “we are bad people” is not a strategy.

So the next time we’re tempted to say, “Desis are corrupt,”.  Corrupt compared to whom? Inside which system?  Are we even willing to let go of the easy story (desis are corrupt) we tell about ourselves? 
​
Teaser for Part 2
At that same get-together, the conversation didn’t stop with corruption. Someone asked, half-joking and half-serious:
“Okay, fine, maybe it’s systems. But how long are we going to blame the British? In the last hundred years, who made all the big inventions?” That question pulls us much further back—into farms, ships, empires, and who got to build the first big labs. That’s where I’ll go next.

​Back to all posts

From the 2020 Scrum Guide, we know that “Sprints are the heartbeat of Scrum, where ideas are turned into value.”

Sprint Duration:
The length of the Sprint is fixed and less than 30 days – most commonly used duration is 2 weeks. Once chosen, the duration remains the same.  Extending the Sprint is discouraged as it will affect the consistency, predictability, and commitment. The Sprint ends when the Time-box ends like a clock. The consideration of extending the Sprint usually comes up when a team find that they cannot complete the work they planned for the Sprint. By not extending, the team tend to learn to plan better the next time. Take this as an opportunity to learn why they are not able to complete the work they selected? Reasons could be overcommitment, pressure from the organization to pick up more work, etc.

Determining the amount of Work:
The Scrum Team collaboratively decides how much work goes into a Sprint. Developers have the final say, considering, size of the product Backlog items considered to be included, their past performance, upcoming capacity, and the Definition of Done. Input about what needs to be included, primarily comes from the Product Owner.

Tracking Work During the Sprint:
One common question is, "Who keeps track of the Sprint Burndown Chart?" The Sprint Burndown Chart serves as a progress tracking tool for the Sprint. Developers collectively track their work to meet the Sprint Goal, with the Scrum Master offering support. Therefore, the primary responsibility is on the developers. If they are using a tool like Sprint Burn Down chart, It is developers who are primarily responsible. The Scrum Master can provide assistance, but the crucial question is whether the developers are dedicated enough to ensure they are on track for the work they selected. It's essential to remember that the Scrum Master is not a taskmaster but rather a helper and guide.
As a Scrum Master if you see that you are more concerned about the progress made in the Sprint than the developers, then your job as a Scrum master is to inquire why the developers are not concerned. Is there an organization structure that is affecting the commitment of the developers individually and collectively as team? Is the team not familiar with self-management? This is something to be discussed at the retrospective. Scrum Master has the responsibility to help the team become a self-managing team.Ultimately, it is the developers who are accountable, and if they are not, the Scrum Master's role is to investigate why and help them become a self-managing, focused, and committed team.
Adding Items to the Sprint:
Developers can add work to the sprint backlog if it aligns with the Sprint goal. Others will be requested to wait until the current Sprint ends and asked to request the Product Owner for prioritization. Unexpected events (like a high impact production issue) can lead to the team being redeployed. It is a good idea to discuss this event in the retrospective meeting to decide how a situation like this can be handled in the future. 

Back to all posts

Further Reading:
 The Scrum Guide 2020

Is Scrum Appropriate for your work?

According to the 2020 Scrum Guide where Scrum is defined, “Scrum is a lightweight framework that helps people, teams and organizations generate value through adaptive solutions for complex problems”. Scrum is most suitable for product development that lack clear definition or comprehension with the definition of product and the work involved in making the product. We call this type of work complex product development. In these cases, new information can emerge at any time. Scrum enables the flexibility to change direction without wasting effort. While it's possible to use Scrum for routine repetitive, and predictable work, its benefits and costs in such cases may be questionable. We call this type of work simple product development. For simple product development, upfront detailed planning is possible and following the plan will be adequate to reach the goal.

In order to asses the complexity, one needs to look how much of the product is know/unknown and how much of the skills to create the work is known/unknown. We also need to look at the environment the product belongs to that can change the need or the product itself. The unknowns in all these areas will affect how much of the work can be predicted upfront. If the work you are undertaking in unpredictable, crating a detailed plan upfront and sticking to it will be both waste of time and possibly end up creating a product that is unsuitable for the changed environment. In a complex product development, the issue at hand has never been previously resolved, and a solution has never been devised, which means there's no established formula to rely on. In these cases, an empirical process control will be better suited. Scrum provides a simple and adaptable framework based on empiricism. It’s iterative incremental way of working help to produce small incremental value, inspect it and adapt as needed.

Scrum or an adaptive process is NOT necessary if simple or complicated product development. In Simple product development, most of the elements are known and an upfront plan can be made. In a complicated product development, about 70% about the product and the work very well defined.  In the case of Complicated product development, with some amount of work upfront, a good plan be created and then be followed to build the product.
Example of simple product development: The table I am using right now was bough on Amazon. It was 5K positive reviews which might means that about 5K people built it successfully by following the instructions just as it is on leaflet that came with it in the box. I don’t really need an iterative incremental process for building that table. And example of a complex product development: The work of building a mobile App such as Uber in 2007-2010 was a complex product development for many reasons including 1) the customers were new to this way of service. 2) The technology was new.

There are a few models available to asses the complexity. Two of them are Dr. Ralph Stacey’s work (Stacy Matrix) on complexity and Dave Snowden’s work know as Cynefin framework.

Scrum operates as an adaptive process primarily suited for handling complex product development. However, its effectiveness hinges on the organization's willingness to embrace changes in plans. Several factors may influence this stance. For instance, some organizations may resist change because they perceive no immediate need for it. An organization's core objective is to efficiently complete its tasks, and if it firmly believes that traditional processes are vital for its operations, Scrum may not offer discernible benefits to anyone involved.
​
Scrum practices are rooted in the principles of empirical process control, relying on adaptation for both product and process improvements. The crucial elements of inspection and transparency are essential for facilitating adaptation. If an organization lacks transparency due to various reasons or if the organizational culture and environment do not foster a safe space for transparency, the empirical process control, and consequently, the framework will not be useful.

​Back to all posts

Further Reading:
Cynefin framework by  David Snowden
Dr. Ralph Stacey’s work (Stacy Matrix) -  Ralph Stacey's Agreement & Certainty Matrix

What is the difference between Agile and Scrum? Is Agile a Methodology? Is Scrum a Methodology? 

Here is a quick answer:
No, Agile is NOT a Methodology. Scrum is NOT a Methodology either.
Scrum is a framework with a set of events, accountabilities, and a structure that facilitates the creation of value through adaptive solutions for complex problems, employing empiricism and lean thinking. Scrum has been in use since the early 1990s. On the other hand, 'Agile' is a set of four values and twelve principles documented in the 'Manifesto for Agile Software Development,' established in 2001. These values and principles were distilled from 'light-weight methods,' such as XP and Scrum. As a result, you will find the values and principles outlined in the 'Agile' manifesto reflected in the Scrum Framework.

Scrum: The Lightweight Framework for Product Development (not a methodology)
History of Scrum: 
The Scrum framework was originally co-presented by Ken Schwaber and Jeff Sutherland at the OOPSLA Conference in 1995. This framework was born from their accumulated knowledge and experiences, crystallizing the first formal definition of Scrum.

At its core, Scrum is a lightweight framework designed to facilitate value generation through adaptive solutions for intricate challenges. Guided by empiricism and lean thinking, Scrum acknowledges that knowledge stems from experience and decisions founded on observations. Lean thinking, a cornerstone of Scrum, revolves around minimizing waste and concentrating on essentials.
The Scrum framework uses an iterative and incremental approach for complex product development.

Agile: Values and Principles for Modern Development

The term "Agile" stands and references the set of values and principles formulated and documented on on February 11-13, 2001 as the Manifesto for Agile Software Development.

The 17 individuals who were part of larger set of people around the world who were using XP, Scrum etc, which was collectively called “light-weight methods. These innovators were “uncovering a better ways to develop software” at a time when the norm was the use of cumbersome, time-consuming heavy-weight methodologies. These inflexible approaches often hindered adaptability and made the process of changing or adjusting the product challenging.

In a rapidly evolving world, attempting to construct a complex product using rigid methodologies, which mandated exhaustive upfront planning and strict adherence to that plan, proved illogical. The dynamic nature of the environment called for flexible 'light-weight' methods that could accommodate change. Such adaptable methods embraced evolving requirements and simplified responses to changes, contrasting with the predetermined rigidity of established plans.
Furthermore, these methodologies shifted the paradigm by recognizing individuals as unique entities, as opposed to interchangeable 'resources' within a hierarchical and bureaucratic system."

The manifesto's roots extend from Scrum and various other processes recognized as "lightweight methods," including XP (eXtreme Programming), DSDM, Adaptive Software Development, Crystal, Feature-Driven Development, and Pragmatic Programming.

The Manifesto for Agile Software Development distills the core ideals of agility from these ‘light-weight methods’. Martin Fowler's poignant words—"We decide to use the term agile to describe this new breed of agile methods"—underscore the novelty and significance of this movement. You may find more of Martin Fowler’s account on his article titled “Writing The Agile Manifesto”

Jim Highsmith's account of the events leading to the manifesto's creation paints a vivid picture. You may find his account on his article titled “History of AgileManifesto”
​
​Back to all posts

Further Reading:
History of AgileManifesto by Jim Highsmith

Writing The Agile Manifesto by Martin Fowler

What does the Scrum Master do all day.

One of the questions that is often asked is how a Scrum Master is going to keep themselves busy all day or what they actually do.

In line with the 2020 Scrum Guide version, the Scrum Master has three key areas of focus: the Scrum Team, Product Owner, and the organization. For the Scrum Team, they coach self-management, guide Increment creation, and ensure effective Scrum events. With the Product Owner, they refine techniques for Product Goal and Backlog management, supporting clear and concise items and collaborative planning. For the organization, the Scrum Master leads Scrum adoption, advises implementations, and facilitates an empirical approach while removing barriers between stakeholders and teams.

The Scrum Master do not do their work, but the Scrum Master guides the Scrum Team to proficiency. Through coaching and the introduction of innovative techniques, they enhance efficiency and effectiveness, assisting the team in producing high-value Increments that align with the Definition of Done. This guidance includes helping the team "reflect in the mirror" for continuous improvement. By addressing impediments and dismantling barriers, they create an environment conducive to growth and value delivery.

Additionally, observing the team in action stands as a vital aspect of the Scrum Master's coaching role. Much like a football coach intently observing players on the field to provide guidance, the Scrum Master actively engages and observes the Scrum Team's activities. This hands-on approach allows the Scrum Master to glean valuable insights into team dynamics, interactions, and workflow processes.

Please look at the Scrum Master Section of the Scrum Guide for more details of how the Scrum Master serve the Scrum Team and the larger organization.

Another excellent resource is “An Example Checklist for Scrum Masters by Michael James available at  https://scrummasterchecklist.org

Is Scrum Master a Full Time Position?

Another common question that arises is whether one person can serve as the Scrum Master for multiple teams or if multiple teams can share a Scrum Master. The answer is: it depends.

If you ask Michale James, he will tell you that “An adequate Scrum Master can handle two or three teams at a time…. And a great Scrum Master can handle one team at a time.”  He recommends “one dedicated Scrum Master per team of about six when starting out.”

The Scrum Master has three key areas of focus: the Scrum Team, Product Owner, and the organization.

In situations where a Scrum Team is new to Scrum practices  or during an organization's transition to the Scrum framework, the presence of a dedicated, full-time Scrum Master becomes crucial. This ensures the availability of consistent coaching, guidance, and support necessary for establishing effective Scrum practices and aiding the team in overcoming challenges. Additionally, observing the team in action stands as a vital aspect of the Scrum Master's coaching role. Much like a football coach intently observing players on the field to provide guidance, the Scrum Master actively engages and observes the Scrum Team's activities. This hands-on approach allows the Scrum Master to glean valuable insights into team dynamics, interactions, and workflow processes. In addition to this, we also need to consider if the team is a newly formed team. If the members are new, the Scrum Master will have more work in helping them to be a cohesive team.

Another factor to consider when allocating a Scrum Master to multiple teams is that whether these teams are working on different products, each with its own designated Product Owner. The the Scrum Master's role involves serving the Product Owner by aiding in the definition of effective Product Goals, managing the Product Backlog with clarity, enabling empirical product planning within intricate contexts, and fostering stakeholder collaboration as required. Given that these responsibilities are tightly intertwined with the unique objectives and requirements of individual products, organizations should assess the practicality of assigning a Scrum Master to multiple teams only when the teams share a product focus. Note that Scrum Master Job is not doing the Product owner’s work but to help the Product owner in becoming proficient in doing this work and possibly helping the Product Owner in doing the work.

As the Scrum team and the organization mature in Scrum adoption, a Scrum Master might potentially support multiple teams. This works well when teams are adept in Scrum, self-managing, and have cross-functional abilities. As experience grows, the Scrum Master's role can shift from hands-on guidance to facilitating shared challenges and maintaining Scrum values. The decision to share a Scrum Master among multiple teams requires considering multiple factors. Factors include team autonomy, cohesion, and self-management capability, the extent of support needed by Product Owners, the Scrum Master's capacity for meaningful guidance, and the organization's dedication to an empirical approach. Ultimately, the decision should align with organizational goals and the objective of sustaining high-performance Scrum Teams that consistently deliver value in accordance with Scrum principles.
​
​Back to all posts

​Further Reading:
 The Scrum Guide 2020
An Example Checklist for Scrum Masters, by Michael James

Navigating Changes During Sprint:
What do you do if your boss (or someone else) want to add new work to the current sprint?


A common scenario that arises in Scrum teams is a request for accommodating new items within an ongoing sprint. It may be the boss asking to include a new item/work/tasks or any other stakeholder making a similar request. The response to that request should consider the need for balancing the commitment to the Sprint Goal, maintaining focus, and upholding the principles of continuous improvement. In a general sense, it's important for the team to balance the need for flexibility with the need to maintain the integrity of the sprint.

According to the principles outlined in the Scrum Guide, if your boss comes to the team and asks to add a new item to the sprint, the team should consider the following:

• Can You Wait? Evaluating the Timing of New Requests: The first question to ask the requester is “can you wait?”. The Developers and Scrum Master can initiate an open dialogue, suggesting to the requester whether it would be possible to wait until the end of the sprint, or beyond. This approach allows the team to fully focus on the current sprint's commitment while showing consideration for the new request's timing and impact. Additionally, proposing that the requester directly engage with the Product Owner can help ensure that the potential impact and priority of the new item are thoroughly evaluated.

 

• Scope Clarification and Renegotiation: While changes that endanger the Sprint Goal should be avoided, the Scrum Guide acknowledges that the scope may be clarified and renegotiated with the Product Owner as more is learned. This means that if the new item aligns with the Sprint Goal and can be accommodated without compromising quality, the team can engage in a discussion with the Product Owner to assess the impact and make an informed decision.

 

• Sprint Goal Endangerment: The Scrum Guide states that during the sprint, no changes should be made that would endanger the Sprint Goal. The Sprint Goal is a crucial aspect of the sprint that provides focus and direction to the team's work. If adding the new item would compromise the achievement of the Sprint Goal, the team should be cautious about making the change. If the change deemed necessary and affects the Sprint goal, the Product Owner may cancel the Sprint. This happens only in rare occasions).

 

• Maintaining Quality: Quality should not decrease during the sprint. The team needs to ensure that the work they commit to in the sprint can be completed to the Definition of Done. It's important to consider how the additional work would affect the overall quality of the work.

 

• Addressing Significant Changes, Including Critical Production Issues: In such cases, the Scrum team must swiftly come together to deliberate on the optimal course of action. The Product Owner holds the authority to make a pivotal decision: the option to cancel the sprint. Although it may initially seem like a drastic measure, this step serves as a necessary safeguard to uphold both the team's  commitment to the Sprint Goal and the importance of delivering high-quality results, particularly in times of urgent need.

Deal with the change and don’t forget to talk about it at the retrospective meeting:
In the dynamic world of Product Development, the ability to navigate unexpected changes is important. As you face and conquer these challenges, remember the significance of the retrospective meeting. After the sprint concludes, take the time to collectively discuss the events that transpired. Was the introduction of the new item an exceptional occurrence? If so, explore how the team handled it and whether there are ways to manage similar situations more effectively in the future. On the other hand, if this situation isn't an exception and there's a likelihood of it occurring again, consider implementing a plan. Could your sprint planning process incorporate a contingency for such events? Should there be a dedicated triage team within the Scrum team for frequent production issues that demand immediate attention? By addressing these questions in the retrospective, the team can further refine their strategies, fostering an environment of continuous improvement.

Back to all posts
​
Further Reading:
 The Scrum Guide 2020
The Importance of Sprint Goal in Scrum: Commitment, Focus, and Continuous Improvement

What if a Scrum Team Finishes all the Work before the end of the Sprint?  

Or
What if the Scrum Team does not finish all the work within the sprint?


​Let's address the common scenario of NOT being able to complete all the work within the sprint. This situation presents a valuable learning opportunity. During the retrospective, the Scrum Team should delve into why they couldn't finish all the planned tasks during the sprint. This discussion should yield ideas to prevent similar issues in future sprints. The fate of the unfinished items must be determined. Consulting the Product Owner is crucial here. It's highly likely that these items will roll over to the next Sprint, but they must be evaluated against the entirety of the Product Backlog. The final decision on their inclusion in the next Sprint rests with the product owner and the Product Owner may decide to put them back into the Product Backlog and reprioritize.

While extending the Sprint by another week might seem tempting, it's important to acknowledge the potential consequences. Prolonging the Sprint can disrupt its consistency and predictability, impacting the overall productivity achievable in a Sprint. Furthermore, it could compromise the Scrum Team's accountability. This would create a mindset that completing everything isn't crucial as the timeframe can always be extended—an approach that's best avoided.
Now the other question: What do we do if our team finishes all our work before the end of the sprint?
Whenever I'm faced with the question,"What do we do if our team finishes all our work before the sprint ends?" I often counter with, "Has that really ever happened?" The usual answer is a resounding "no." But if by some stroke of luck it does, my suggestion would be to quietly enjoy a well-deserved break without drawing too much attention.
Before we explore other options, it's worth acknowledging the infrequent nature of this scenario. Much like stumbling upon a four-leaf clover, early work completion is a delightful surprise in the world of Scrum. More often than not, teams grapple with the opposite challenge – striving to accomplish tasks amidst tight timelines.

So, how can a Scrum team make the most of this fortunate circumstance in a manner that aligns with the  principles of Scrum framework? Here are some options to consider:

1.    Collaborate with the Product Owner: The initial step is to engage in a conversation with the Product Owner. Discuss the possibility of bringing forward high-priority items from the product backlog. Maybe the Scrum team could bring in more product backlog items that enhances the Sprint Goal that they already met.
2.    Enhance Quality: With additional time on hand, consider focusing on elevating the quality of the completed work. This can involve comprehensive testing, meticulous code reviews, and refining user experience elements.
3. Address Technical Debt: Utilize the extra time to work on technical debt – the accumulated compromises that might have been made during development. This could involve refactoring code, optimizing performance, and improving documentation.
4. Foster Innovation: Embrace the opportunity to explore innovative ideas or technologies that can contribute to the product's evolution. Experimentation can lead to breakthroughs that might not have been feasible during the standard sprint cycle.
5. Offer Cross-Team Support: If neighboring teams are facing challenges, extending a helping hand can foster a culture of collaboration. Assisting others not only promotes teamwork but also contributes to the overall project success.
6. Reflect and Refine: Dedicate time to introspection and process improvement. Evaluate the team's workflows, identify areas for enhancement, and devise strategies for more streamlined sprints.


Back to all posts

The Importance of Sprint Goal in Scrum: Commitment, Focus, and Continuous Improvement


 In Scrum, the Sprint Goal stands as a single objective of a Sprint, providing Scrum Team with a clear sense of direction, commitment, and focus during each Sprint. It aligns their efforts towards a common purpose. Let's explore the significance of the Sprint Goal, its role in the Scrum framework, and how it fosters a culture of continuous improvement.
 
Defining the Sprint Goal:
 
If you were to scour the Scrum Guide for references to the Sprint Goal, you would encounter 19 instances in those 13 pages. This abundance of mentions highlights its importance and prominence within the Scrum framework. According to the Scrum Guide, the Sprint Goal is the commitment for the artifact known as the Sprint Backlog. In essence, it serves as a pledge to ensure that the Sprint Backlog provides valuable information, enhancing transparency, and focus throughout the Sprint's duration. This clarity enables the developers to measure their progress against the Sprint Goal effectively.
 
The Sprint Goal and Commitment:
 
In Scrum, commitment is a core value, and the Sprint Goal is a prime example of it. The Developers commits to achieving the Sprint Goal during the Sprint Planning event. However, it allows for flexibility in terms of the exact approach and tasks required to achieve the objective. This ensures that the team has the autonomy to adapt and respond to changes, unforeseen challenges, and emerging insights during the Sprint.
 
As outlined in the Scrum Guide, "A Sprint could be cancelled if the Sprint Goal becomes obsolete." This singular instance is the sole condition under which the Scrum Guide addresses the potential cancellation of a sprint. This underscores the pivotal role of the Sprint Goal as the driving force behind sprint activities.
 
Creating Coherence and Focus:
 
The Sprint Goal goes beyond being a mere checkbox to tick off; it plays a vital role in creating coherence and focus within the Scrum Team. By having a shared Sprint Goal, all team members rally around a common purpose, collaborating and working together to achieve the defined objective. This fosters a sense of unity and avoids individual silos, promoting a collective effort toward success rather than isolated initiatives.
 
Crafting a Meaningful Sprint Goal (how to create a Sprint Goal?):
 
Formulating a Sprint Goal in Scrum encompasses a cooperative process that actively involves the Scrum Team. During this process, the Scrum Team collaboratively selects a Sprint Goal that holds significance for the current state of the product and is both achievable and realistic within the confines of the team's capabilities for the upcoming sprint.

According to the Scrum Guide, “The Product Owner proposes how the product could increase its value and utility in the current Sprint. The whole Scrum Team then collaborates to define a Sprint Goal that communicates why the Sprint is valuable to stakeholders. The Sprint Goal must be finalized prior to the end of Sprint Planning.”
 
It is during the Sprint Planning meeting, the entire Scrum Team, including the Product Owner, Developers, and Scrum Master, collaborates to create the Sprint Goal for that Sprint.
 
The Sprint Goal, the Product Backlog items selected for the Sprint, plus the plan for delivering them are together referred to as the Sprint Backlog.
 
Here's a step-by-step explanation of how a Sprint Goal is typically created:
 
•               Product Owner's Proposal:
The Product Owner starts by proposing how the product could increase its value and utility in the current Sprint. This proposal is based on the prioritized items from the Product Backlog.
•               Scrum Team Collaboration:
The Scrum Team collaborates to discuss the Product Owner's proposal. That discussion involves reviewing the prioritized list of features, enhancements, and bug fixes that are in the Refined Product Backlog.
•               Shared Understanding:
The Scrum Team collaborates to discuss the Product Owner's proposal.to ensure a shared understanding of the proposed work and its potential impact. This includes clarifying and discussing product backlog items.
•               Aligning with the Product Goal:
The Scrum Team ensures that the Sprint Goal is aligned with the broader vision and goals of the product.
 
By following these steps, the Scrum Team creates a Sprint Goal that encapsulates the purpose and value of the Sprint's work. This goal-setting process ensures alignment, transparency, and commitment to delivering meaningful outcomes within the Sprint.
 
After completing these steps, the Scrum Team proceeds to the next stages of the Sprint Planning meeting, which involve selecting specific items for the Sprint and planning how to achieve the Sprint Goal.
 

Maintaining the Sprint Goal:
Once the Sprint Goal is established, the Scrum Guide emphasizes the importance of maintaining its integrity throughout the Sprint. Several key factors are highlighted in this regard:
 
1. Endangering the Sprint Goal: During the Sprint, no changes should be made that would put the Sprint Goal at risk. This means that the team should be shielded from distractions or disruptions that might jeopardize the primary objective.
 
2. Ensuring Quality: The quality of the deliverables should not decrease during the Sprint. This ensures that the team maintains high standards and delivers valuable outcomes.
 
3. Refining the Product Backlog Items: As new insights and information emerge, the Product Backlog Items may require refinement. This process should be embraced to keep the development efforts aligned with the Sprint Goal.
 
4. Scope Clarification and Renegotiation: As the team learns and gains more understanding, the scope of the Sprint Backlog may be clarified and renegotiated with the Product Owner. This ensures that the most valuable work is being pursued to achieve the Sprint Goal effectively.
 
Shorter Sprints for Increased Learning and Reduced Risk:
 
The Scrum Guide acknowledges that if a Sprint's time horizon is too long, the Sprint Goal may become invalid, complexity may rise, and risk may increase. In response to this, shorter Sprints are recommended. By employing shorter Sprints, the team can generate more frequent learning cycles and limit the risks associated with longer timeframes, such as increased uncertainty and changing priorities.
 
Addressing Failure to Meet the Sprint Goal:
 
Despite the best efforts, there may be instances when a team fails to meet the Sprint Goal. However, Scrum encourages viewing these situations as learning opportunities rather than failures. It is important to address it during the Sprint Retrospective meeting. This creates a culture of continuous improvement, where the team openly discusses areas of weakness and identifies changes to address them. By adapting and refining their processes, the team enhances their chances of achieving future Sprint Goals successfully.
 
Here are some common reasons for team failing to meet the Sprint Goal:
 
Incomplete or Ambiguous Sprint Goal: If the Sprint Goal is not well-defined or lacks clarity, it can lead to confusion and misalignment within the team. A clear and specific Sprint Goal is essential for guiding the team's efforts. 

 
Overcommitment: Sometimes, Scrum Teams can be overenthusiastic during Sprint Planning and commit to more work than they can realistically accomplish within the sprint timeframe. This leads to an overloaded Sprint Backlog, making it challenging to achieve the Sprint Goal.

 
Lack of Collaboration: Scrum Team needs to work collaboratively and transparently. If there are communication gaps, lack of cooperation, or silos within the team, it can hinder progress towards the Sprint Goal.

Unforeseen Dependencies: External factors or dependencies on other teams or departments may cause delays or interruptions, impacting the team's ability to achieve the Sprint Goal.

 
Changing Priorities: If there are frequent changes in the Product Backlog or shifts in priorities during the sprint, the team may struggle to stay focused on the original Sprint Goal.

 
Ineffective Daily Stand-ups: The daily stand-up is an essential Scrum event for coordination and identifying problems that affects the Sprint Goal. If it becomes merely a status update, issues may go unnoticed, and progress may stagnate.

 
Inadequate Skills or Resources: If the team lacks the necessary skills, expertise, or resources to complete certain tasks within the sprint, it can hinder progress towards the Sprint Goal.

 
Quality Issues: Sacrificing quality to meet deadlines can lead to technical debt and rework, diverting the team's focus from the Sprint Goal.

 
Scope Creep: Additional work or changes introduced during the sprint without proper negotiation and consideration can affect the team's ability to accomplish the Sprint Goal.

 
External Disruptions: External factors like urgent production issues or organizational changes can disrupt the team's work, making it challenging to achieve the Sprint Goal.


Lack of Empowerment: If team members feel disempowered or are not involved in decision-making processes, they may lack motivation and commitment to achieving the Sprint Goal.

 
Ineffective Retrospective: The Sprint Review and Retrospective are critical for learning and improvement. If these events are not conducted effectively, valuable insights for meeting future Sprint Goals may be missed.

 
In conclusion, the Sprint Goal is a critical element of the Scrum framework. It serves as a commitment, aligns the team's efforts, and provides a clear sense of purpose throughout the Sprint. Embracing the Sprint Goal with dedication and learning from any challenges encountered not only enhances the team's performance but also reinforces a culture of continuous improvement, making Scrum an effective and dynamic Agile methodology.
 
Back to all posts 
 
 
Further Reading:
 
The Scrum Guide 2020
 
 
A Template for formulating great Sprint Goals.  Copyright © Pichler Consulting
 
The Sprint Goal: What is it and how can it help. by by Mike Cohn

Driving Value with Sprint Goals: Humble Plans, Exceptional Results. by Maarten Dalmijn (Addison-Wesley Signature Series (Cohn)) 1st Edition
​

Scrum Crimes and Misdemeanors: Reporting Violations with the Scrum Police

Are you a Scrum Master who practices Scrum religiously, with Scrum Guide as your bible? Do you feel like unleashing your inner detective when you see people committing crimes against Scrum? Well, then hold on to your hats, because I have some exciting news for you!

If you have been in one of my CSM classes, then you already know the importance of keeping Scrum sacred. You don't call it a methodology, and you don't write it in all caps like SCRUM. And you also know that breaking these rules is a crime against Scrum, punishable by law.

But what about when you see others committing these heinous acts? Do you let them get away with it? Not on your watch! That's where the Scrum Police comes in - the uniformed officers of Scrum Bureau of Investigations (SBI), led by the one and only Mike Cohn and his team at Mountain Goat Software.

And if you don't report these crimes, then you're committing a crime yourself! That's right; it's called "The Good Samaritan Law," and you don't want to end up in Scrum jail, do you?

So, what are you waiting for? Join the Scrum Police today! Head over to https://www.scrumpolice.com/ and report any Scrum Guide violations you witness. Don't let those criminals get away with it - let's make Scrum great again!

And I have a confession to make. The Scrum Police finally caught up with me, and I'm writing this from behind bars (check out my mug shot below). I've been found guilty of multiple Scrum violation, and I'm paying the price. But don't worry, once I'm out, I'll be a changed person. In fact, I'll be watching all of you like a hawk and reporting any Scrum violations I see. You better watch out - I'll be the newest member of the Scrum Police, and I won't rest until Scrum is safe and sound again! (No, No. Not that SAFe Ver 6.0!).  

Are there a lot of hard and fast rules in Scrum? 
On a serious note, if this has prompted you to ponder the necessity of hard and fast rules in Scrum, then you're headed in the right direction. Check out Mike's latest article to get more insight on that topic. 
​
References:
(1)Seinfeld: ‘The Good Samaritan' episode of Seinfeld (season 3, episode 20). Directed by Jason Alexander, written by Peter Mehlman, NBC, 1992. "Jerry and his friends struggle with whether or not to report a crime they witness in."


​Back to all posts
​

Did you know that Neanderthals might have been the world's first agilists? And yet, they went extinct. Could Agile suffer the same fate? Are there eerie parallels between the decline of Neanderthals and the challenges faced by Agile in today's world? This article explores these questions and more, inviting you to reconsider what we can learn from the past about the future of Agile.
 
In an article titled "What Neanderthals Got Right About the Agile Mindset"(1), ​Howard Sublett says that the Neanderthals might be among the world’s first agilists. The article goes on to discuss how one can develop an organizational design that is responsive to the needs of their customers. I highly recommend reading the full article - it was an extremely valuable read for me.

While I concur with all the points he raises regarding the characteristics of Agile, I find it intriguing to see the parallels between the Neanderthals and Agile. Such a perspective is indeed thought-provoking, particularly in light of some fascinating facts about the Neanderthals and their eventual extinction. The Neanderthals are an extinct species, which begs the question - is there a hint there? Could it be that Agile, as we know it, will go the same way as Neanderthals?
 
It is also worth noting that not all of the Neanderthal’s features disappeared - in fact, their DNA can still be found in modern humans(3), making up approximately 1-3% of it. This raises an intriguing possibility: could it be that while Agile as we know it may vanish, some of its defining characteristics will remain? Additionally, it's widely believed that Homo sapiens - us - played a role in the eventual extinction of the Neanderthals. This begs the question: who might be playing the role of Homo sapiens in the case of the disappearance of Agile?
 
The comparison of the Neanderthals to Agile, reminded of my previous research into their extinction. As I delved deeper into current scientific theories, I couldn't help but notice the similarities between their demise and the current state of Agile. Here are some of the parallels that stood out to me:

1. Coexistence with a more dominant group: Contradicting earlier assumptions, a 2014 paper(4) revealed evidence that Neanderthals and Homo sapiens coexisted for up to 5,000 years. This coexistence of dominant and subordinate groups parallels the current relationship between Agile and traditional plan-driven approaches. Plan-driven approaches typically follow a hierarchical and structured way of working, whereas Agile movements prioritize collaboration and flexibility. However, the widespread use of plan-driven approaches in many organizations has limited the adoption and success of Agile movements.
2. Interbreeding: A paper(5) published in 2022 showed that the Neanderthal DNA entered the Homo sapiens gene pool, but not the reverse. If fertile Neanderthals were regularly absorbed into Homo sapiens groups, they were effectively being removed from Neanderthal gene pools. We also know that about 2% of the DNA remains in the gene pool of Homo sapiens.  Like in the case of the Neanderthals and Homo sapiens, Agile movements often hybridize with plan-driven approaches, leading to the creation of hybrid and cumbersome processes. These processes tend to dilute the core principles of Agile and lead to confusion and complexity. In these cases of hybridization, we typically see two outcomes. One, more of the dominant group survives leaving only little traces of the other group remains. Two, the hybrid methods do not become successful leading to a blame game and of course all the blame will be assigned to the smaller group.  

In the same vein as Neanderthals, the hybridization of Agile with larger and more traditional organizations could trigger its decline. These organizations' significant size and power could create an unsupportive environment for Agile teams, which could impede their growth and development. In such an environment, Agile teams may be at a disadvantage, as they may not have access to the same level of resources, support, and opportunities for collaboration and knowledge sharing. The Prescott's Pickle Principle from the book Secrets of Consulting(6) by Gerald Weinberg aptly highlights this point, stating that "Cucumbers get more pickled than brine gets cucumbered". This means that the Agile teams' inherent agility and flexibility may be diluted, compromised, or even lost entirely in a more rigid and traditional organization, much like a cucumber being overwhelmed by the pickling process. Therefore, it is crucial to pay close attention to Agile's principles and values while adapting to the larger organization's needs to achieve success.
 
What are your thoughts?

PS: Please note that none of these possible parallels were hinted at in the original article by Howard. I had the opportunity to briefly speak with Howard this week. He stated that the idea of Agile going extinct was not in his mind when he wrote the article. It is entirely my own conjecture and speculation. All blame should be directed towards me alone.

​Back to all posts
​

References

1. What Neanderthals Got Right About the Agile Mindset. Published on March 3, 2023 on the Official PMI blog. (search for the title of the article and you will find it)
2. S. Gaudzinski-Windheuser, L. Kindler, K. MacDonald, W. Roebroeks, Hunting and processing of straight-tusked elephants, 125.000 years ago – implications for Neanderthal behavior. Sci. Adv. 9, eadd8186 (2023). https://www.science.org/doi/10.1126/sciadv.add8186
   
3. Vernot, B., & Akey, J. M. (2014). Resurrecting Surviving Neandertal Lineages from Modern Human Genomes. Science, 343(6174), 1017-1021. doi: 10.1126/science.1245938.  
   
4. Higham, T., Douka, K., Wood, R. et al. The timing and spatiotemporal patterning of Neanderthal disappearance. Nature 512, 306–309 (2014). https://doi.org/10.1038/nature13621  
5. Stringer, C., & Crété, L. (2022). Mapping Interactions of H. neanderthalensis and Homo sapiens from the Fossil and Genetic Records. PaleoAnthropology, 2022(2), 130. https://doi.org/10.48738/2022.iss2.130
   
6. Weinberg, G. M. (1985). The Secrets of Consulting: A Guide to Giving and Getting Advice Successfully. (1st ed.). New York, NY: Dorset House Publishing Co., Inc.