Hiren Doshi

The organizations must truly practice patience while applying Scrum. Scrum does not solve the problems, but it reveals all the problems that deter you from achieving your goals by making it radically transparent. Patiently work on the problems one at a time and very soon you will achieve the Business Agility you desire.

The Scrum values help build the foundation of Trust. Transparency, Inspection, and Adaptation, the three pillars to embrace empiricism flourish on the foundation of Trust.

*Covid is a fictional character based on my imagination that represents the strain of CoronaVirus that is causing the disease Covid-19. This is just a very simple and sincere attempt to put my knowledge and understanding about Covid-19 to test in this article and I tried making the connection with Scrum. I hope you enjoy it.

We all understand, every field has a skill quotient that you need to achieve to be able to qualify and deliver. It’s a Doctor of Medicine for someone who wants to practice medicine, be a Doctor, and save lives.

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 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 re-plan 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 discussion 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: 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?

Fifteen crucial responsibilities of an entrepreneurial Product owner. Maximize value & Optimizer, The Product Vision, Value, and Validation, Return of Investment, Reducing the Total Cost of Ownership, Stakeholder Engagement and Collaboration, Business Agility.

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