Hiren Doshi

The Scrum Team consists of 3 distinct Scrum roles that promote Self-organization: the Scrum Master, the Product Owner, and the Development Team. The accountability of each role complements the accountability of the other roles. Hence, collaboration between these roles is the key to success: The Scrum Master, through servant-leadership, coaches, facilitates, educates, and guides the team to solve its own problems by using the three pillars of empiricism. The Scrum Master understands that constructive disagreements are necessary to build high performing teams. The Scrum Master allows the team to learn from the cycle of failing, trying, and failing again. The Scrum Master also helps self-organization by proactively and uncompromisingly removing impediments that are beyond the team’s self-organization capability. The Product Owner closely interacts with stakeholders and product management to identify the most valuable work. The [caption id="attachment_22649" align="alignright" width="300"] The 3 Scrum Roles promoting Self-organization[/caption] Product Owner relies on the Development Team for the actual delivery of a potentially shippable software increment in every Sprint. At every Sprint Review, the stakeholders help the team in shaping the future product. The Development Team members collaboratively select their own work from the Product Backlog ordered by the Product Owner. They collaboratively create actionable activities to realize their forecast as reflected in the Sprint Backlog. They replan their work on a daily basis within the time-boxed Sprint to optimize the team’s output. They deliver a potentially releasable increment (integrated with increments of other teams, if multiple teams are involved) of software at the end of each Sprint. This self-directedness, the ability for people to direct their own work, motivates them and reinforces self-organization. One of the best examples of self-organization comes straight from Ken Schwaber’s blog post “Self-Organization and Our Belief That We Are in Charge.” I pose the following question to Scrum Masters: What is the best way to organize 100 developers into Scrum Teams? According to Ken, he would let the developers self-organize themselves into Development Teams as per the recommendation in The Scrum Guide that has all the cross-functional skills to build an integrated done Increment every Sprint. The Scrum Master may remind them that all one hundred people must be engaged meaningfully and that mentoring is expected. The Scrum Master may have the lead developers lead a discus- sion about the software and architecture to be worked on, with the underlying dependencies. The Scrum Master may have the Product Owner discuss the intricacies of the Product Backlog. And, if they organize sub-optimally, they can correct and continually adjust team membership as they find out more. Promote a learning organization with Bottom-up intelligence. So the one-hundred-people group self-organizes and divides itself into teams. This is one of the topics from my book – “Scrum Insights For Practitioners: The Scrum Guide Companion“. Happy reading! I look forward to hearing your thoughts on how the Scrum roles can further promote Self-organization.

What Is Self-Organization? “Knowledge workers have to manage themselves. They have to have autonomy,” says Peter Drucker. Scrum Promotes Self-Organization By specifying a lightweight framework: three roles, five events, and three artifacts. By removing titles for the Development Team members. Everyone is equal, and there is no hierarchy within the Development Team. By empowering the Development Team and determining the best way to accomplish its work. Self-organization enables creativity within the Scrum Teams, accountability in the Scrum Team, and people’s personal commitments to achieving the goals of the Scrum Team. Self-organization is something that cannot be imposed on the team. Self-organization does not mean a free run where Development Team members can do whatever they desire. Self-organization happens by setting clear boundaries within which the empowered team members can organize their own work. Some factors that promote self-organization in Scrum are the following: Trust: People in the team must be able to trust each other, communicate freely, achieve insights, and collaborate. Anything that is a barrier to achieving these should be removed. Time-boxing: This Scrum rule helps focus and manage risks. Fixed Sprint length: This factor helps with the consistent delivery of business value in every time-boxed Sprint. Optimal Development Team size: A cross functional Development Team of three to nine members, as recommended in The Scrum Guide, helps remove unnecessary complexity and communication overhead. Definition of “Done”: Creating transparency regarding the work inspected during the Sprint Review, it also en- ables everyone in the Scrum Team to have common shared understanding. Scrum Values: The Scrum values of courage, focus, commitment, respect, and openness are embodied and lived by everyone. This is one of the topics from my book - "Scrum Insights For Practitioners: The Scrum Guide Companion". Happy reading! I look forward to hearing your thoughts on Self-organization.

Empiricism means working in a fact-based, experience-based, and evidence-based manner. Scrum implements an empirical process where progress is based on observations of reality, not fictitious plans. Scrum also places great emphasis on mind-set and cultural shift to achieve business and organizational Agility. The three pillars of empiricism are as follows: [caption id="attachment_22444" align="alignleft" width="220"] Three Pillars of Empiricism (Scrum)[/caption] Transparency: This means presenting the facts as is. All people involved—the customer, the CEO, individual contributors—are transparent in their day-to-day dealings with others. They all trust each other, and they have the courage to keep each other abreast of good news as well as bad news. Everyone strives and collectively collaborates for the common organizational objective, and no one has any hidden agenda. Inspection: Inspection in this context is not an inspection by an inspector or an auditor but an inspection by every- one on the Scrum Team. The inspection can be done for the product, processes, people aspects, practices, and continuous improvements. For example, the team openly and transparently shows the product at the end of each Sprint to the customer in order to gather valuable feedback. If the customer changes the requirements during inspection, the team does not complain but rather adapts by using this as an opportunity to collaborate with the customer to clarify the requirements and test out the new hypothesis. Adaptation: Adaptation in this context is about continuous improvement, the ability to adapt based on the results of the inspection. Everyone in the organization must ask this question regularly: Are we better off than yesterday? For profit-based organizations, the value is represented in terms of profit. The adaptation should eventually relay back to one of the reasons for adapting Agile—for example, faster time to market, increased return on investment through value- based delivery, reduced total cost of ownership through enhanced software quality, and improved customer and employee satisfaction. Scrum works not because it has three roles, five events, and three artifacts but because it adheres to the underlying Agile principles of iterative, value-based incremental delivery by frequently gathering customer feedback and embracing change. This results in faster time to market, better delivery predictability, increased customer responsiveness, ability to change direction by managing changing priorities, enhanced software quality, and improved risk management. This is one of the topics I covered in my book - "Scrum Insights For Practitioners: The Scrum Guide Companion". Happy reading!

I am listing out some commonly observed Scrum Myths, Mysteries, and Misconceptions from my experience. Scrum Teams are assigned to several projects or features. This results in context switching (i.e., multitasking), and the outcome is increased cycle time and delayed value delivery to business. The software is not released to market frequently, thereby missing the opportunity to gather customer feedback. When Scrum Teams say “Done,” they are not really “Done.” They need additional regression test cycles, or they need additional cycles to integrate their work with the work of other teams. There is more than one Product Owner for one product with no clear accountability. Proxy Product Owners are assigned to the Scrum Team with no empowerment to make business decisions, resulting in unnecessary delays. The role of the Scrum Master is undermined by assigning a part-time Scrum Master or team members taking turns to play the role of a Scrum Master in every Sprint. There is a certain myth that burn-down charts, burn-up charts, and cumulative-flow diagrams must be used by the Scrum Teams as metrics. The Scrum framework does not prescribe any of these metrics. Depending on the value these metrics drive, you can choose to use them or drop them altogether. It is a myth that success of the team can be measured by an increase in the team’s velocity. Velocity is neither good nor bad. It is just a metric that can be handy for planning. It is a metric to measure capacity, not productivity. There are Sprints called Sprint 0, Design Sprint, Architectural Sprint, Hardening Sprint, Stabilization Sprint, and Testing Sprint. The only true Sprint is a time-box of one month or less during which a “Done,” usable, and potentially releasable Product Increment is created. There are Sprints after Sprints just to build the overall architecture with no real business functionality at the end of each Sprint. Instead of recruiting someone with experience in working with Scrum, organizations recruit someone with no prior Scrum experience or send their in-house project managers to a two-day Scrum class, hoping they can play the role of an effective Scrum Master. .... The above excerpt is from book "Scrum Insights For Practitioners: The Scrum Guide Companion" What is your list of commonly observed Scrum Myths, Mysteries, and Misconceptions?

The Professional Scrum Product Owner (PSPO) is an Entrepreneur - a value Maximizer & Optimizer The PSPO sets a solid vision to help the Scrum Team keep laser sharped focus and direction that helps with incremental progress at the end of each sprint 1 Product == 1 Product Backlog == 1 Product Owner. Having one PSPO for the product helps with the clarity & focus, ensures quick decision making, and single person accountability for the success of the product. To validate the idea the PSPO frequently releases the increment of software to market to gain real customer insights The PSPO has the final say on the order of the Product Backlog. The PSPO orders the PBIs in the product backlog by keeping the Value of the PBI, the dependencies between PBIs and the dependencies on the other products in mind. The PSPO ensures that most valuable functionality is generated all times by the Development Team. The PSPO accounts for the Return on Investment and Total Cost of Ownership before a feature is built. The PSPO ensures that all work done by the Development Team originate from the single Product Backlog - a single source of truth. To determine the value of the product being delivered the PSPO might use metrics like time to market (cycle time / lead time), percentage of the functionality in the released product used by the customers & the overall customer satisfaction The PSPO is accountable for Interacting and engaging with the Stakeholders. The PSPO comes to the Sprint planning with a clear business objective in mind and works with the Development Team to craft a sprint goal based upon the forecast During the actual Sprint the PSPO is accountable for the Product Backlog Refinement, but may delegate the work to the Development Team. The PSPO  is the only one who can abnormally terminate the Sprint in case the Sprint goal becomes obsolete. The PSPO Is just one person and not a committee The PSPO builds trust by closely working with Development Teams. He is not hesitant to delegate the work of writing user stories / Product Backlog items to the Development Team.

The 3 Scrum Roles are: The Product Owner The Scrum Master The Development team The various levels of services in the Scrum roles are: Scrum Master serves the Development Team Development Team serves the Product Owner Product Owner serves the stakeholders. The accountability of the the various roles are: Product Owner is accountable for the value being delivered. Scrum Master is accountable for building High performing Scrum Teams by ruthlessly removing impediments and facilitating Development Team decisions. And the best way a Scrum Master can remove impediments is to empower/teach/coach the Development Team to remove them themselves. Only if the team is stuck the Scrum Master removes the impediments himself. Development Team manages itself and is accountable to build a releasable increment of software that adheres to their agreed 'Done' at the end of every sprint

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. [embed]https://youtu.be/nQ5sr6gu-sM[/embed]

This blog is the feedback on Scaled Professional Scrum using Nexus Framework and over 50 practices from the participants who attended my SPS workshop in India. [embed]https://youtu.be/hC6H5MtsClY[/embed]

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 story / feature estimate generating considerable waste; 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 product backlog refinement the development team members arrives at a high-level estimate for each story in the product backlog normally in story points (Fibonacci series) 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. 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”, be empirical, learn by 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 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. Through the journey they identify the uncertainty, complexity and effort required to finish the story. 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 better with lean approach of estimation and are equipped at deriving an almost accurate story point during product backlog refinement, thereby aiding in better agility and transparency.

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 automated enough test scenarios in that sprint. The “Team of Teams” had accomplished their mission of writing sufficient automated test scenarios to reduce the manual in-sprint test effort. 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.