Looking At An Impediment From A Value Perspective

#SridharPeddisetty #Agile #Scrum #Strategy #Organizational Strategy #Impediment #AgileBestPractices

The old Master instructed the unhappy young man to put a handful of salt in a glass of water and then asked him to drink it. "How does it taste?" the Master asked. "Awful," spat the apprentice. The Master chuckled and then asked the young man to take another handful of salt and put it in the lake. The two walked in silence to the nearby lake and when the apprentice swirled his handful of salt into the lake, the old man said, "Now drink from the lake." As the water dripped down the young man's chin, the Master asked, "How does it taste?" "Good!" remarked the apprentice. "Do you taste the salt?" asked the Master. "No," said the young man. The Master sat beside this troubled young man, took his hands, and said, "The pain of life is pure salt; no more, no less. The amount of pain in life remains the same, exactly the same. But the amount we taste the 'pain' depends on the container we put it into. So when you are in pain, the only thing you can do is to enlarge your sense of things..... Stop being a glass. Become a lake!"

By definition an impediment is a hindrance or obstruction in doing something. From an Agile perspective, an impediment is anything that keeps a team from being productive or reduces the progress of a well functioning team to achieve its goals. Some root causes of an impediment include

1. Lack of team cohesiveness 
2. Lack of domain knowledge 
3. Lack of technical skills
4. Limitations to environment 
5. Lack of tools  
6. Lack of well defined processes or
7. Lack of managerial or organizational buy-in  

More often, an Agile team spends a lot of time in trying to categorize the impediment, be it trying to classify it as a feature, epic, user story, user task, bug or technical debt. Not undermining the importance of classifying an impediment but while looking at an impediment, its important to view the impediment in the context of delivering value rather than spending too much of an effort in categorizing it. Just to reiterate, categorization of an impediment sometimes helps to discover new impediments so its important but remember that it is in the solutions to those impediments where you find innovative ideas for your team to provide more value. In other words, remind yourself that impediments could be viewed as the tasks that need to be completed for user stories and then the tasks could be prioritized for the value. If needed, impediments can be managed in an impediment register where they can be prioritized as needed. 

Summary

To summarize, focus more effort on solutions rather than categorization of impediments. So when faced with an impediment, enlarge your vision of looking at the impediment from the perspective of delivering value. 

Previous posts you might be interested in

• Everyone's Perspective Is Key In Retrospectives
• Active Listening Is Key For A Successful Delivery
• Minimum Marketable Features: An Agile Essential

Case Study: Scrum Followed Properly Versus Not

Note: My following article Case Study: Scrum Followed Properly Versus Not is originally published in Scrum Alliance 

Case Study: Scrum Followed Properly Versus Not

It is not the methodology or the tool that fails to deliver quality software but it is the people involved. I strongly believe in the opening statement and here am sharing a case study of when Scrum was followed properly versus when it was not followed properly. Before that let me share the essence of Scrum as documented in the 'Do Better Scrum', which is

Majority of the teams have a common knowledge on Scrum including the basics such as

but more often than not the essence of Scrum is overlooked by the teams, which fail to follow Scrum properly.

This case study is about two Engineering teams,  ‘Team A’ and ‘Team B’, both following Scrum but one team missing practicing the very essence of Scrum while the other team practicing it to the core. 

‘Team A’ believed it was delivering software using Scrum by having The Team, Scrum Master and a Product Owner. Team was having Scrum Artifacts including Product Backlog, Sprint Backlog and Scrum Ceremonies including Sprint Planning, Daily Scrum and a Sprint Cycle of 4 weeks. But still the team was struggling to deliver software incrementally, which was shippable and could be rolled out to production. To its advantage, ‘Team A’ was also collocated including having an onsite Product Owner and most of its stakeholders. But still results were not there in the form of regular delivery of most valuable features in production and more importantly, not very happy stakeholders. 

Project was then handed out to a virtual team, ‘Team B’. ‘Team B’ not only practices core Scrum principles but also believes in the essence of Scrum. ‘Team B’ being virtual could not have Daily Scrums because of time constraints but using collaboration tools, was able to effectively and efficiently share what they worked on previous working day, what was their plan for next working day and if there are any impediments. Team was able to communicate robustly with the Product Owner through collaboration tools on user stories, acceptance criteria, design of the new features and agree upon definition of done. ‘Team B’ did have weekly calls with stakeholders to sync up on the status of the sprint. Team was disciplined in defining their Sprint Release Cycle including defining the milestones like Sprint Planning Meeting, Code Freeze, Functional Testing, Integration Testing, Sprint Reviews, Stakeholder Sign off and Sprint Retrospectives, associated with their respective dates.

By sharing a transparent sprint release plan with dates & milestones and following the same meticulously, ‘Team B’ demonstrated following the essence of Scrum. As a result, ‘Team B’ not only delivered the project on schedule and with quality but also was able to refactor the code written by ‘Team A’, getting rid of most of the technical debt. 

So lets analyze a little more on what was the difference between both the teams. ‘Team A’ was less disciplined in ensuring visibility into the team’s progress and honestly communicating about progress and risks. Team struggled to organize itself around the work and failed in delivering the most valuable features regularly. As a result, ‘Team A’ was not able to receive valuable feedback from stakeholders and with no way to retrospect on its work, the team set itself up for failure. It was not a case of team not working hard enough but more a case of failure on its part to properly plan, set expectations and delivery frequently. As the team was committing itself for a 4 weeks sprint cycle, development team allowed itself some short term code wins by providing the features without paying attention to long term goals of insuring scalability, reliability, availability and maintainability of the feature. The QA team was brought in late into the sprint cycles and thus losing the advantage of having second opinion on the requirements early to find any gaps. By the time QA team found any requirements gap, development team would have moved ahead into middle of next sprint cycle.  Team also missed setting expectations with stakeholders on the timelines of signing off on the sprint items, thus not allowing them to provide timely feedbacks and missing the opportunity to improve on the delivered features.

In contrast, ‘Team B’ though virtual, was disciplined in planning well, setting expectations by being transparent & robustly communicating using collaboration tools and finally able to deliver most business valued features frequently.

I look forward to read your feedback on how properly your team follows the essence of Scrum.

References:

•  Do Better Scrum