Application of Scrum Values

The essence of Scrum are the 5 values. A Scrum-Agile project will not be successful unless these values are demonstrated in every event, while preparing every artefact and while performing any role.

In fact, these values can be demonstrated in any environment to reap benefits.

Here are 10 practical instances for each Scrum value that any team can demonstrate:

COMMITMENT

Team members dedicate themselves to achieving the team's goals and doing their best work. They commit to the sprint goals and support each other in meeting those commitments.

  1. Team commits to delivering specific user stories in the sprint backlog, even when facing technical challenges or scope creep requests from stakeholders.
  2. Team members commit to rotating on-call duties to ensure continuous support for critical production systems across different time zones.
  3. When a legacy system needs modernization, team members commit to learning new frameworks or cloud technologies required for the enhancement.
  4. Committing to code review processes, automated testing, and documentation standards even when under tight deadlines.
  5. Team members commit time to learn each other's specialized areas to reduce knowledge silos and improve team resilience.
  6. Following through on committed delivery dates for bug fixes and enhancements, communicating early if risks arise.
  7. Committing to implement retrospective action items and process improvements identified during sprint reviews.
  8. Honouring service level agreements (SLAs) and committed response times for support tickets and maintenance requests.
  9. Allocating committed time in each sprint to address technical debt alongside new feature development.
  10. When team members transition between projects, committing to thorough documentation and handover processes.

 

COURAGE

Team members have the bravery to do the right thing, tackle difficult problems, and speak up about issues or impediments. This includes courage to make necessary changes and face challenges head-on.

  1. Having the courage to escalate critical bugs or security vulnerabilities immediately, even if it means stopping a deployment.
  2. Questioning unclear or potentially problematic requirements from clients, suggesting better alternatives even when it might create initial friction.
  3. Taking the initiative to refactor poorly written legacy code, even when it's not explicitly requested but necessary for maintainability.
  4. Being honest about not knowing certain technologies and asking for help or training rather than struggling silently.
  5. Having difficult conversations with stakeholders about unrealistic deadlines and their impact on quality.
  6. Suggesting and implementing modern architectural patterns or tools to replace outdated systems, despite resistance to change.
  7. Junior team members voicing concerns or ideas during client calls or team meetings, despite hierarchical cultural norms.
  8. Addressing team conflicts, skill gaps, or process problems with management rather than letting them fester.
  9. Accepting responsibility for bugs or issues in production and working transparently to resolve them.
  10. Insisting on proper testing, security measures, and documentation even when clients want to skip these steps for faster delivery.

 

FOCUS

The team concentrates on the sprint work and goals, avoiding distractions that don't contribute to delivering value. Everyone stays focused on what needs to be accomplished during the current sprint.

  1. Resisting the temptation to work on interesting but non-committed tasks, staying dedicated to current sprint goals.
  2. Organizing work to handle support tickets in dedicated time blocks rather than constantly interrupting development work.
  3. Keeping client discussions focused on current iteration goals rather than getting sidetracked by future enhancement ideas.
  4. Concentrating on the specific changes being reviewed rather than starting major refactoring discussions during code reviews.
  5. Focusing on critical and high-priority bugs first, avoiding the distraction of fixing minor cosmetic issues.
  6. Creating targeted, useful documentation for the current release rather than over-documenting theoretical scenarios.
  7. Writing tests that directly support the current user stories rather than extensive testing for edge cases not relevant to current requirements.
  8. Learning specific technologies needed for current projects rather than pursuing general upskilling that doesn't immediately benefit the team.
  9. Resolving the specific issue reported rather than expanding scope to fix related but unreported problems.
  10. Keeping daily standups, sprint planning, and retrospectives focused on their intended purposes and time-boxed durations.

 

OPENNESS

Team members are transparent about their work, progress, challenges, and learning. They openly share information and are receptive to feedback and new ideas.

  1. Providing honest updates about development progress, including delays or blockers, during daily standups and client reports.
  2. Regularly conducting technical sessions where team members share learnings from recent implementations or problem-solving approaches.
  3. Welcoming feedback on code and actively participating in peer reviews to improve code quality and share knowledge.
  4. Speaking candidly about what went wrong in previous sprints and being receptive to process improvement suggestions.
  5. Being open about cultural differences and communication preferences when working with global teams and clients.
  6. Maintaining and sharing technical debt registers, making the impact of legacy code issues visible to stakeholders.
  7. Openly discussing individual and team skill gaps during planning sessions to ensure proper resource allocation.
  8. Actively seeking and gracefully receiving feedback from clients about deliverables and service quality.
  9. Being open to trying new development methodologies, tools, or practices suggested by team members.
  10. Conducting blameless post-mortems after production issues, openly discussing what happened and how to prevent recurrence.

 

RESPECT

Team members value each other's diverse skills, backgrounds, and opinions. They treat one another with dignity and create an environment where everyone feels valued and heard.

  1. Respecting different cultural backgrounds within the team and accommodating various festivals, holidays, and working preferences.
  2. Valuing contributions from both senior and junior team members, ensuring everyone's voice is heard in technical discussions.
  3. Scheduling meetings and deadlines that respect team members' work-life balance across different shifts and locations.
  4. Recognizing and leveraging the different technical strengths each team member brings, from database expertise to front-end skills.
  5. Treating client requirements and feedback with respect, even when they seem technically challenging or suboptimal.
  6. Respecting the original author's approach when modifying existing code, seeking understanding before making changes.
  7. Allowing team members time to learn new technologies without pressure, recognizing different learning speeds and styles.
  8. Respecting personal time and avoiding after-hours communications unless dealing with genuine emergencies.
  9. Respecting the Project Leader’s roles in decision-making, even when disagreeing with specific choices.
  10. Supporting team members' career aspirations and certification goals, sharing opportunities and providing mentorship when requested.
In addition to these 5 Scrum values, there is another value which I believe is significant
  1. Setting 90-minute uninterrupted blocks for complex development work with phone on silent and all notifications disabled, followed by a 15-minute break to maintain peak concentration and code quality.
  2. Checking and responding to emails only during three designated 20-minute windows per day (morning, post-lunch, end of day) rather than constantly monitoring the inbox throughout the workday.
  3. Dedicating exactly 30 minutes each day to learning new technologies or improving skills, using this consistent time investment to gradually build expertise without overwhelming the regular workload.
  4. When stuck on a technical issue, setting a strict 2-hour limit for independent troubleshooting before seeking help from colleagues, preventing excessive time waste while encouraging self-reliance.
  5. Allocating focused 45-minute sessions exclusively for writing technical documentation, treating it as a creative writing exercise with no interruptions allowed during this period.
  6. Establishing specific hours (e.g., 10-11 AM and 3-4 PM) for making client calls and responding to urgent requests, allowing for deeper focus during other hours while maintaining responsiveness.
  7. Setting aside exactly 1 hour every morning for reviewing team members' code, ensuring this critical activity gets dedicated attention rather than being squeezed between other tasks.
  8. Using 25-minute work blocks (Pomodoro technique) for administrative tasks like updating project trackers, filling timesheets, or organizing personal workspace, making mundane tasks more manageable.
  9. When exploring new solutions or technologies, limiting research time to 3 hours maximum before making a decision or seeking additional input, preventing analysis paralysis on technical choices.
  10. Designating specific 10-minute periods for checking team chat messages and responding to non-urgent queries, reducing constant context switching while staying connected with the team.

As a Project leader, you can facilitate 

- Create an environment where team members can demonstrate these values

- Coach your team on the meaning of and application of each value

- Be a role model for these values

- Call out team members who demonstrate these values and highlight the instances

- Reward team members who live these values 

- Consider the demonstration of values along with other performance metrics during performance appraisals 

Comments

Post a Comment

Popular

5 underrated Leadership skills

There are many skills identified as essential for Leaders.  For example, coaching is an essential leadership skill because it’s easy to measure the impact of coaching and the number one-on-ones. It’s easy to draw a connection between the number of difficult conversations and accountability. However, there are some leadership skills which are underrated maybe because the direct correlation to business results is often a gray area.  When you specifically ask individuals about the impact of these skills on their work, the response is likely to be very positive but it’s challenging to point to them as the exact reason a team is successful. So, what are these underrated leadership skills? 1. Culture eats strategy for breakfast Peter Drucker famously said, “Culture eats strategy for breakfast.”  Drucker’s point was that no matter how advanced a company’s strategy is, its success ultimately depends on the culture. You can think of it like a game of cricket.  The coach and c...
Read more

Definition of Done v/s Acceptance Criteria

One of the most common questions asked by Scrum-Agile practitioners and the the question which also receives the most varied set of answers is this: What’s the difference between acceptance criteria and the Definition of Done (DoD) ? The simple answer is this: Acceptance criteria are specific to a   particular   product backlog item. Something becomes an acceptance criteria if it is so vital that the Product Owner will reject the item if it does not fulfill any of the criteria.   The Definition of Done, on the other hand, is  universal . A Definition of Done includes things that nearly all product backlog items need to comply with.   An Example Here’s an example of how I'm using a Definition of Done and Acceptance Criteria if I were to create a podcast on this topic.   The acceptance criteria for the podcast would be:   Explanation of Acceptance Criteria Explanation of Definition of Done Explanation of the difference between the two But for the podcast...
Read more

Science of Influence

One of the traits that Project Managers or any Leader needs to develop is the ability to influence. Every project ecosystem consists of Stakeholders, internal and external. These include your own team members. The ability of a Project Manager to influence these Stakeholders will ensure that the project is in control. Dr. Robert Cialdini has developed 7 principles of influence which can be used by Leaders to influence others. 1.  Reciprocity :  When you do people a favour, they tend to respond in a manner you want them to. However, there are some points to note. - I t’s not about what is given, but HOW AND WHEN IT IS GIVEN . Be the first to give the favour. - Let it be personalized and unexpected. Tell them ‘ I am doing this only for you ’. Suppose, you have done a favour to a person and he/she says ‘Thank you’. What is your response? Many of us say, ‘Its okay’, ‘It was my duty’ etc. Some rare person may say ‘Now you also owe me a favour’.  Instead use this principle Respo...
Read more