Piyush Rahate

Every Sprint starts with a Sprint Planning event. It is very crucial to ensure that the Scrum Team comes to a shared understanding of what and how are they going to deliver a “Done” increment that creates maximum business impact. Although, like other events Sprint Planning also is often marred with few dysfunctions. In this post I will bring forth 5 common dysfunctions that I have observed associated with this event. Unavailable Product Owner: Product Owners often tend to think that their job is to pass on the requirements to the Development Team and that is good enough to get the work done. They spend too much time with the end-customers, stakeholders or just writing detailed requirements for the team. On the other hand they spend too little time with the team and are mostly unavailable to the team when they are needed the most. This leads to the most common dysfunction – unavailable Product Owner which percolates to other dysfunctions. Lack of Refinement: Since Product Owner is often unavailable, the development team skips the Product Backlog Refinement sessions. As we are aware, Product Backlog Refinement is a collaborative session where the Product Backlog Items are refined and moved towards the ready state i.e. detailed enough, ordered and estimated. Ordering of Product Backlog Items is accountability of the Product Owner, as well as providing enough details around any Product Backlog Item is job of the PO. Now, since the PO is not available then the refinement doesn’t add any value. Ambiguous Requirements: As enough time is not spent in Product Backlog Refinement, the development team sees the requirements for the first time during the Sprint Planning. Since, refinement has not happened these requirements are often vague and ambiguous. The development often does not have clue how to move forward. They spend lot of time going over and over a single PBI and thus not making use of the Sprint Planning event to Inspect and Adapt for the Sprint. Erroneous Forecasts: Since the team sees the PBIs for the first time during the Sprint Planning, they often do not have any clarity of how to approach the requirement, or they often overlook scenarios/complexities that may arise as they start implementing the requirements. As a result, the estimates provided by the team are either overestimated or underestimated. This in-turn leads to erroneous forecasts of what can be done during the Sprint or thereafter. No Shared Commitment : All the above four dysfunctions lead to the final dysfunction which is No Shared Commitment within the Scrum team. As the requirements are vague, the forecasts over/under estimated and there is no shared commitment within the Scrum Team, a tiff starts between the business (Product Owner) and delivery (the Development Team). A game of pointing fingers and highlighting what other has not done or could have done begins. None of which is conducive for the team to work as a cohesive unit. Conclusion: There might be many more dysfunctions that might lead to not having a successful Sprint Planning event. These are few that I came across. As a Scrum Master it is always good to be vigilant about such dysfunctions, reveal them and help the team to overcome the dysfunctions.

The Daily Scrum is an important Inspect and Adapt event for a Scrum team. Yet the purpose is often ignored and swept under the carpet by a multitude of teams.

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect.

There has been so much written about Velocity and its impact on teams yet it is one metric that eludes everyone and keeps cropping up whenever there is discussion around productivity.

A few days back I did a Scrum Tapas Video explaining a few of the rules within Scrum. Besides these rules, there are also certain guidelines which help Scrum Teams to make the best possible use of Scrum framework to create maximum Business Impact.

Photography may sound simple but is actually a problem of complex domain. There are many variables - light, subject, motion, distance, composition, framing - that come into play while capturing an image. Although, with current range of cameras equipped with highly adaptable sensors (empiricism) many of these variables can be ignored to an extent and great images can be clicked with press of a button. I am passionate about Scrum as well as about photography and when I thought of writing my first blog, I thought of sharing important lessons that I found useful while supporting Scrum and taking photographs. Lesson 1: The Three Leg Rule. For creating awesome images, a photographer has to understand 3 important aspects which are key to capturing images. These aspects are - Shutter Speed, Aperture and ISO rating. Not paying attention to anyone of these impacts the quality of the image captured. For Scrum to create maximum business impact, empiricism is must which is upheld by 3 pillars of Transparency, Inspection and Adaptation. Every Scrum team should be paying attention to all the three aspects. Ignoring anyone of them is going to impact Scrum implementation adversely. Lesson 2: Perspective and Viewpoint. A simple photograph can have a dramatic effect if the perspective and viewpoint is changed while shooting the image. A shift in perspective or viewpoint brings out so many different details in the object that otherwise would not be visible. Scrum thrives on self-organizing, cross-functional teams. The perspectives and opinions that are brought by individuals to the team are valuable. Whether it is planning poker for estimating the work or Sprint Retrospective to look at the Sprint gone by; paying attention to everyone's perspective and taking them into account takes the Scrum team on its journey of high performance. Overshadowing the teams thoughts with the Hippo's opinion has devastating impact on other team members. Lesson 3: Light and Management Light is an important factor while capturing images. But it is out of the control of the photographer. In any given situation, we need to click images with the amount of light that we have, cannot ask for more or less. We need to tweak our settings to make the best use of available lighting conditions and create great images. Management, in any organization adopting Scrum, is like the light for photographer. One cannot ask for more or less. We need to work with what we have and make the best use of it to "promote and support Scrum, within the organization as defined in the Scrum guide". The best way to deal with Management that I have experienced, is to make them feel important and take their help in tackling organizational impediments. Lesson 4: Borrow all that which is good and helps you do better at what you do. A good camera is just the starting point. For capturing great images, in variety of situations, we might need much more than just a good camera. First and foremost, we need the skills of an able photographer to identify the right frame and composition. Then we might need a wide-angle/zoom lens, a flash gun, a tripod or may be a remote release. Using all the gear that we can make use of; we can create stunning imagery. This all would help only if we don't let go of the 3 legs of photography - Shutter Speed, Aperture and ISO rating. Scrum, does not create software by itself. It is a framework that provides certain ground rules which can help any team/organization to better its existing software development process. Within the Scrum framework, Scrum Teams may utilize practices, methods from different frameworks, processes that they find useful. Some common practices that I have seen teams use and benefit from are - test driven development, pair programming, user stories; story points etc. All these practices stand good as long as the key pillars of Transparency, Inspection and Adaptation are not compromised. Lesson 5: Finally, results can be verified only in hindsight. A moment is captured the instant the shutter is released. No matter how much planning goes into capturing a moment, one can only say the image is good, bad or ugly after looking at the image once it is clicked. That's when one learns what all aspects can be improved, to capture a better picture. With Scrum unless the Sprint is ended and an increment is created, we do not know whether it adds value to the product or not. We may do necessary planning, but given the complex nature of our problems, will we get the desired results at end of every sprint, every time; maybe not. Although, we can always look at the results and retrospect over the sprint about how to do better in upcoming sprints. Would love to hear your thoughts and learn; what were your experiences while supporting Scrum in your journey.