Feedback on Scrum.org Professional Scrum Foundations workshop

Dear Hiren,

Classrooms can survive without iPads, phones or even without any power point based training presentation for that matter, but never without inspirational teacher like you.

vwOne of the way to look at it, this was just 2 days of training event just like other events those keep coming in our journey, but the way it was executed by you, I am sure these memories will last forever.

Instead of leading us by holding our hands, you asked us to walk ahead while you caringly observed from behind.

On behalf of VW team I would like to say big Thank you!

 

Thanks & Regards,

Milind Nanal

Chief Information Security Officer (CISO)

Myths, Misconceptions & Mysteries Of Product Ownership

Here’s what the Scrum Guide says about the Product Owner Role:
“The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. How this is done may vary widely across organizations, Scrum Teams, and individuals.”

Who is an effective Product Owner in Scrum? Is (S)He a requirements typist, user story writer, business analyst, domain expert, maybe all of the above? What are some effective practices of Product Ownership? What are the biggest myths and misconceptions around Product Ownership?

Five of the most respected Scrum.org PSPO Trainers – Ralph Jocham, Mark Noneman, Erik Weber, Hiren Doshi, and Simon Reindl talk and answer questions on Product Ownership myths, misconceptions and mysteries of Product Ownership.

Feedback on the Professional Scrum Foundations workshop

This video captures the feedback from the students on the Professional Scrum Foundation workshop facilitated in India. The students share their learnings on how writing granular user stories, story splitting, defining clear Scrum roles helps with agility. They talk about values and principles like self-organization, empowerment, Courage and Respect needed to embrace Agility. They also talk about the interactive and intensive, hands-on and powerpoint free facilitation of this PSF workshop.

My 10 Days of Agile| Scrum Adoption at LULU

The Agile Adoption Strategy used at LULU included Agile Readiness Assessment, The Scrum | Agile Training,  Story writing workshops, Distributed team Alignment, Re-structuring, Facilitating a Sprint, Team Building Activities, and open workshop.

Scaled Professional Scrum & Nexus – Feedback

The feedback is for the Scaled Professional Scrum workshop from Scrum.org that  I facilitated in Mumbai on January 9th and January 10th.

The feedback is given by Parag Barve, Ajay Solanki, Prasad Kamath and Syed Ali.





Culture Change – An important ingredient for organizational Agility

To imbibe Agility in an organization which is a state of high responsiveness, speed, and adaptiveness organizations should promote a new organizational culture of openness, transparency, respect for people, constant learning, improving, and constant adaptation. Even with so much of awareness, cultural change seems to be one of the major hurdles impeding organization’s success.

Culture is more about “The ideas, customs, and social behavior of a particular people or society.” When an individual behaves in a particular way, we associate that to be his nature, but when a team or an organization responds, we relate to its culture. As this is associated with people and their entrenched culture it is very difficult to change!! While it is also a very common observation that the culture within the same organization varies across various geographies. It’s not uncommon to hear statements like that’s the UK Culture, or the US Culture, or the Indian Culture, etc.

When a team/group of cross-functional individuals work together (co-exist and collaborate) for a long period of time in the same organization by respecting and following certain organizational values; they display a unique identity of that group forming their culture. And when we address the culture exhibited by all the teams in an organization it is referred to as the organization culture. If you observe carefully, culture is not the characteristic of one individual but of the team/organization as a whole.

I recollect one of my consulting experiences where I was hired as a coach in one of the organizations that had been practicing Agile for a while, but their adoption was stalled. Although from the outset they seemed to follow all the Agile best practices, they were still struggling with the deliveries and their team motivation was at a all time low. One of the first things I did was to probe the teams by facilitating Anonymous Retrospectives to generate insights. It was quite revealing to find that the organization had a “Culture of Fear”; fear of getting penalized for a decision going wrong, fear failure to meet the commitments, fear of poor quality deliverable, fear to be completely honest and transparent, fear to challenge the status-quo, fear of lack of trust and respect among people, etc. This culture of fear in the organization did not allow Agile to penetrate beyond the surface. Once these insights were shared with the organization, they embraced and acknowledged the shortcomings and worked towards corrective practices to remove the fear thereby imbibing the “Culture of Agility” in the organization.

Organization culture contributes significantly towards successful Agile adoption and therefore understanding it is the key. Management, executives, and team members should support and embrace this change. Invest in a few prominent agility attributes like the healthy team dynamics of self-organization teams, continuous improvement, frequent delivery, effective communication, adapting to the changing environment, etc. that benefits an organization and its customers. To bring culture shift, organizations must examine its existing practices with a critical eye, try new way of doing things, create new opportunities, coupled with commitment and nurturing at all levels within an organization.

Organizations which have traversed through the Agile adoption culture change journey exhibit some of these characters:

  • Team members demonstrate values like Trust, Respect, Courage, Openness, Confidence, Synergy, Unity, Affiliation,and Commitment.
  • Creativity, Collaboration, Emergence, Rhythm, Empiricism, and Discovery are encouraged organization-wide.
  • Embracing Transparency, Inspection, and Adaptation as part of everyday routine.

Embedding cultural shift involves a lot of patience, a full top-down support, constant learning, and a bottom-up intelligence. While an organization may follow all the bookish guidelines and yet fail in this journey if they cannot identify this subtle/invisible ingredient of “culture” which plays a substantial role. Focusing on the correct culture, eventually leads an organization towards success in this transformation path!!

A scaled scrum tactic – Team of Teams, A real life example

A program team of over 40 people decided to move to Agile from their traditional development practices. The program was old and had been in existence for over 6 years. In these 6 years they had released multiple versions of their software product to their customers. In the rush to satisfy the customers they had ignored the basic hygiene of following the good engineering best practices. So, along with their move to Agile they had also inherited a considerably poorly maintained legacy code. There was tight coupling between the various software components in the entire system; The majority of  the code files had 10000+ lines of code with plenty of code duplication; there was poor technical documentation on how the overall system interacted; the entire testing effort was manual. There were certain components which when modified, in most instances, introduced regressions in the existing system.  Even though the teams spent significant time testing the entire end-to-end system, the overall confidence on the quality of the deliverable was considerably low.

The program formed 4 cross-functional Scrum Teams and started sprinting. The dysfunctions from the poorly maintained legacy code started surfacing and becoming more evident.The teams struggled to meet their planned sprint forecast. The development team’s time spent testing the new features was exponentially higher than it took to build those features. In addition, most of the times the development teams kept busy fixing unplanned production defects to maintain the business continuity. The deliveries of new business features were at an all time low which made the sponsors very anxious. The scrum teams collaborated, brainstormed and came to a common conclusion that to accelerate product delivery, one of the first steps was to reduce the manual test effort spent by the development teams. They decided to write end-to-end automated service level tests to cut down the time teams spent on manual testing as well as to gain enough confidence in their deliveries. The product owner helped by ordering the PBIs for the service level automated tests higher in the product backlog. The skill-sets required to develop the service level tests were spread across multiple scrum teams. Something different had to be thought of to overcome the above challenge without having a major impact on the business continuity. A new scaled scrum tactic of “Team of Teams” was introduced: “Team of Teams” is a concept where members with the right skill-set from the existing scrum teams participate to form a new Scrum team for a short duration of a sprint or 2 to solve a very focused problem. The 4 Scrum Teams self-organized and quickly identified 2 development engineers from each team with the correct skill-set to participate in the new “Team of Teams”.

One of the Scrum Masters from the existing teams volunteered to help with Scrum Master duties for the newly formed Scrum team. The new “Team of Teams” decided to operate in “Boot Camp” mode and they co-located themselves in a conference room to allow maximum collaboration. In the first few days of the sprint, the team carved out a homegrown test framework and added a couple of end-to-end tests to validate the framework. A quick review of the framework with the original 4 scrum teams and the Product owner validated their hypothesis. The newly formed team of teams worked through their sprint backlog and carved out 17 rich test scenarios in that sprint. The “Team of Teams” had accomplished their mission of writing sufficient automated test scenarios to reduce the manual testing effort thereby accelerating the product delivery. The team members from the newly formed team of teams then returned back to their original scrum team where they continued to build additional test scenarios. Having led many Agile adoptions across multiple organizations, I have found scaling tactic like “team of teams” to be very helpful when a very focused problem has to be addressed.  The “Team of Teams” tactic has also been explored for strategizing the product vision and the product backlog refinement with multiple scrum teams and overall the outcome has been quite rewarding. I would be happy to hear some scaling tactics you have used and learn from your experiences.

Is agility fueling organizations towards profitability?

Let me begin this blog by relating one of my travelogue experiences. A known taxi driver drives me in his car to the Mumbai airport every week from the last 4 years. The car is about 8 years old, poorly maintained, and has tugged a good more than 300000+ kilometers; has by all means attained end of life, good enough to be dumped, and reap benefits from its scrap. As an enduring passenger, I have been containing the noisy tractor-like ride in his car due to my acquaintance with him and also believing his long false promise of a new car on its way to replace this one!

Week-on-week he comes with the same car and asks me if I noticed any evident difference in terms of travel experience. He would spend good amount of money replacing the old parts (like the tires, cars’ engine, AC, etc.) with better ones, beautifying it by a coat of varnish, etc.; the expenditure now almost exceeding the price of purchasing a 3-year-old second hand car. I honestly said a big NO each time he asked me and also wondered why he was investing on this old car when a new car according to him was arriving in the next 3 months!! This fetish behavior of patching the old car in anticipation of some miracle resulted in the loss of many good loyal customers (as they were fed up of the continued bad bumpy ride with no respite in sight in the form of a new car).

During one of my recent rough ride in the taxi, I realized how well this experience was analogous to what many organizations undergo during their agile journey. They have every agile practice in place; right mindset, best practices, roles/ceremonies/artifacts well defined coupled with communication, motivation, and empowerment. Even with such a robust agile framework, the teams/organizations lack agility to adapt to the changing customer requirements and deliver in a fast paced manner. Although in reality, organizations want to go fast (like any new car) by adopting agile but unfortunately are stuck with poorly maintained legacy codebase (like the old taxi). Any amount of replacement, beautification, superficial modification, or adopting new methodology/technique without addressing the deep-rooted problems might temporarily mask the real problem thereby breaking ‘transparency’, one of the 3 legs of empiricism (for scrum to be effective, each of these 3 pillars – transparency, inspection, and adaptation must stand and be supported).

When such projects are assessed, in all probability the hidden truth is that the organizations carry a herculean technical debt in terms of complicated and poorly maintained legacy codebase (just like the old car) with little or no attention to the engineering best practices, poor feedback cycles, no automation of unit./integration/regression, poor re-factoring and code reviews, etc. Based on the assessment findings, organizations need to perform a cost-benefit analysis and decide whether it makes sense to fuel such projects and take appropriate corrective actions immediately rather than wait for some magic to happen overnight in an organization/product by just adopting agile. If not, (like the taxi driver) organizations will fail to deliver/meet customer expectations, not be profitable, and loose out longstanding clients.

Therefore, for organizations in their attempt to keep pace with the competitive world it is not just enough to adopt agile methodology but should imbibe agility in their DNA. Varnishing an old car may give it a new look but the driving experience will remain the same; the same applies to organizations as well. In most cases, change/expected results may not be visible by just refactoring in bits and pieces (replacing the defective parts) but it may call for a complete eradication of the existing system (significant remarkable/dramatic one which would be a winning selling pitch for the organization; in the car analogy it is like buying a new car) and re-designing/re-writing the software to bring in a new vibrant spectrum.

Upon this cleanup and novel thought it is now time to think how to drive this concept (new car) effectively and efficiently! Adopting the rich agile ethodology along with adhering to solid engineering practices at this juncture would act as a fuel to propel the team/project/product/organization, accelerate, and drive towards success!

With the legacy issues addressed and best engineering techniques embraced, agile adoption certainly triggers agility and benefits the organization by delivering fast-paced, feature-rich, competitive, and user-beneficial products of significant business value!

Evidence-based Estimation

An analogy I can think of is… I want my dart to hit the dart board, and not necessarily the bull’s eye…. as it calls for a lot of details which apparently is missing during estimation. However, if my dart doesn’t hit anywhere on the dart board… it’s almost like shooting in the dark; a very disappointing estimation scenario.

A vast chunk of new teams struggle in arriving at a correct project estimate; with most them failing due to a huge variation (with estimated Vs actual)! Very few succeed in this journey by coming closer to the actual in the initial cycles itself.

Project managers in traditional development focus on detailed scope, so that the cost, estimate, and time are accurate and frozen before kick starting a project. How far this is successful and precise is debatable! In agile projects, during release planning the development team arrives at a high-level estimate for each story in the product backlog normally in story point which aids in finer estimation during sprint planning. This helps the team to get started, rather than wait for all the project details to get finalized.

Story point is an arbitrary measurement of a feature’s size relative to other features and not the time needed to complete a feature. For example, by looking at the picture of the whales you cannot determine the exact age or weight of each whale but can compare the size of each with respect to each other. This is a very handy approach as detailed information to estimate the effort may not be available so early. Story points are used to calculate how many user stories a team can complete in a sprint which is termed velocity.

The story point size assumptions are interpreted using an estimation scale, the most common ones include numeric sizing (1 through 10), t-shirt sizes (XS, S, M, L, XL, XXL, XXXL), Fibonacci sequence (1, 2, 3, 5, 8, 13, 21, 34, etc.), etc.

A team to get started with story point estimating must be clear, synchronous, and agree upon the below aspects (I call it the ‘Five subtle rules’ as they are hidden and work at the back of our mind.).

Common reference – Each team member estimating should have a same reference. For example, the size L to measure a story point size should be the same criterion for everyone in the team. Any conflict with respect to the reference index results in huge variation and wrong estimation. Agreeing upon a common reference is very critical.

Collective wisdom – Estimation is a team activity and hence all should participate in this. Having one person do this will be a huge risk as the margin of error will be high! However, a collective decision helps in arriving at a common estimate which in all probability will be accurate.
In addition, during relative estimation the team should also take into account the effort, complexity, and uncertainty for every story before arriving at a number.

Effort – How much effort a story would take to complete, relative to the reference story.

Complexity – How complex is the story with respect to the reference story.

Uncertainty – How much risk/unknowns a story holds relative to the reference story

Even with this common agreement, it may still take a few iterations for the team before arriving at a common estimation value. With estimation being definitely hard, how do we get the best estimates of story size?

Why not take a closer look at “Evidence-based estimation”, learn from experience, become proficient with every calibration, and adopt during the initial project estimation phase to understand its true benefits!

Here is the approach a team should take to proceed with “Evidence-based Estimation”:

Let’s consider a scrum team of 7 members commence a 2-week sprint of 10 working days. With 6 hours as the effort per day, the capacity would approximately be 7 * 10 * 6 = 420 hours.

  • During the 1st sprint planning meeting, the team begins story estimation from scratch with no story points assigned to stories in the product backlog.
  • A story is picked from the product backlog followed by task and time breakdown for each. This step continues till the estimated capacity adds to about 400 hours/5 stories (considering the average team capacity is 420 hours).
  • Through the sprint, the team works towards completing all the planned stories.
  • Just before the retrospective meeting, the team assembles to story point the completed stories (definitely now with some experience/evidence).
  • Among the 5 stories, the team picks the one with medium effort, complexity, and uncertainty and assigns a story point (keeping the 5 subtle rules in mind). For example, when we take an estimation scale of 1, 2, 3, 5, 8, 13; this story is assigned a story point of 3 and it becomes the common reference story. A closer look at this exercise clearly indicates that the story point number is emerging out of working experience/evidence and not by mere guess work!
  • The team continues story point estimation for all the stories in Sprint 1 (per Step 5) and assigns a value lower, higher, or the same when compared to the reference story point.
  • As the team proceeds from one story to another, the comparative reference points become varied apart from being evident which helps them with better estimation. At this point if the team feels a need to refine the previous estimates, they can. The idea is to get better estimates with experience that are realistic.

The teams may decide to use this estimation during the initial few sprints till they are confident of the process. With experience, the team becomes an expert and are equipped at deriving an almost accurate story point during the release planning (rather than after the completion of a sprint), thereby aiding in better agility and transparency.

1 2 3 5
×
×