Updates on Scrum Developer Training

23 Dec 2016

How Is Emergent Architecture Handled in Scrum?

Scrum embraces the Agile principle of emergent architecture and design. Architectural needs emerge due to functional and non- functional requirements. Certain nonfunctional requirements like security, deployment platforms, compliance, and scalability are often of very high value and ordered high in the Product Backlog. Usually some parts of each of those nonfunctional requirements are required for an initial release of a minimum viable product.Business-facing functionality (i.e., functional requirements) also drives architectural and design needs as well. In Scrum, each Sprint serves to build at least one piece of business-facing functionality that has at least some tiny amount of value. So as we evolve the system, we build only enough architecture and design to support the functional and nonfunctional requirements that we are focusing on for that Sprint.

Important: In every Sprint at a minimum we have to build at least one piece of that business-facing functionality, regardless of how many nonfunctional requirements and architecture we are also focusing on.

Then with every subsequent Sprint, more and more of the architecture and design emerges in response to more and more high-ordered requirements. The purpose of this is to build architecture and design only in response to the highest-valued requirements at the top of the Product Backlog.

An example of how Architecture is handled in Scrum.

Emergent Architecture

In the example shown in the chart, in Sprint 1 the majority of the work done by the Scrum Team is on architecture/infra- structure; however, enough business-facing valuable functionality is still released by the team to deliver value and validate the current architecture work. As the team progresses further Sprint over Sprint, the architectural needs decrease, and the value-driven business functionality delivered increases.

The Development Team also ensures good architecture by ensuring a set of guiding architectural principles that every Development Team member understands and follows while writing code. In addition, architecture is an ongoing discussion in the Development Team focusing on implementing current Sprint Backlog items.

This is one of the topics from my book – “Scrum Insights For Practitioners: The Scrum Guide Companion“. Happy reading!

You can read more about Emergent Architecture and Design here.

12 Dec 2016

How Does Scrum Promote Self-Organization?

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.

04 Dec 2016

The Three Pillars of Empiricism (Scrum)

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:

Three Pillars of Empiricism

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!

20 Nov 2016

Book: “Scrum Insights For Practitioners”

I am pleased to announce my new book — “Scrum Insights for Practitioners: The Scrum Guide Companion”. Thank you all for your support and help.

The Scrum Guide holds the bare and essential rules of Scrum. It provides sufficient information to understand Scrum but leaves much open for interpretation by readers and practitioners. When individuals and organizations follow The Scrum Guide blindly, without understanding the real, deep essence of Scrum—the principles and values underpinning the framework—they likely will fail to reap all the benefits Scrum has to offer.

Scrum Insights for Practitioners fills in some gaps in the understanding of Scrum for individuals or organizations practicing Scrum. This book can be thought of as a companion to The Scrum Guide. I encourage readers to first read The Scrum Guide if you are new to Scrum before reading this book, as this will help you reap the maximum benefits.

Scrum Insights for Practitioners is a perfect companion to The Scrum Guide that helps the practitioners master the Scrum framework by gaining in-depth practical insights and helps answer questions such as these:

What are some common myths, mysteries, and misconceptions of Scrum?
The Scrum Guide recommends three to nine members in a Development Team, but we have fifteen members. Is this Scrum?
Can you share some tactics to do effective Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospective, and Product Backlog Refinement?
My designation is development manager. Does this mean I have no role in Scrum?
How is Scrum Empirical?
Can Scrum Master and Product Owner be the same person?
We don’t have a Scrum Master. Are we still practicing Scrum?
What does Self-Organization really mean?
How does Scrum embrace the four values and twelve principles of the Agile Manifesto?
Please share a case study on Scrum based product development?

Recommendations for the book from the Scrum champions

Take advantage of Hiren’s vast experience and avoid making the common errors people make as they begin their journey. This book contains a wealth of practical information that will be useful to readers as they work to implement the basic theory found in The Scrum Guide—Steve Porter, team member, Scrum.org

In his book Scrum Insights for Practitioners, Hiren has extended the core rules of The Scrum Guide with practices he has found useful. Hiren answers questions regarding Scrum that potentially remain unanswered even after one reads The Scrum Guide. Hiren dismantles common misconceptions about Scrum, regardless of the source of such misconceptions. Hiren elaborates on basic information provided in The Scrum Guide, as well as on the principles underlying Scrum—Gunther Verheyen, Author of “Scrum — A Pocket Guide, a Smart Travel Companion”

Hiren Doshi has written a fine companion to The Scrum Guide, filling in some of the intentional gaps left in the Scrum framework. Using this companion along with The Scrum Guide will undoubtedly improve the outlook for those teams that internalize its teachings.”—Charles Bradley, ScrumCrazy.com

This book will help you understand the nuances of Scrum. It takes a very practical approach toward implementing Scrum without compromising on its values and principles. A useful and handy reference for Scrum practitioners!—Gopinath R, Agile coach and practitioner

Currently the book is available as a physical copy on Amazon. The Kindle version to follow shortly.

I sincerely hope you find great value in each and every page of the book.

Enjoy Reading. Happy Scrumming.

25 Aug 2016

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.

06 May 2016

15 things a Professional Scrum Product Owner (PSPO) actually does

The Product Owners – Steve Jobs and Jeff Bezos

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.

03 May 2016 - 1

The various levels of Services in the 3 Scrum Roles

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

27 Feb 2016

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.

20 Feb 2016

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.

Blog