
Hiren Doshi
www.practiceagile.com
Languages
- English
- Hindi
- Gujarati
- Marathi
Country
IndiaReviews
What students say about HirenAbout Hiren
Hiren, CEO of Practice Agile Solutions and a Professional Scrum Trainer with Scrum.org has 26 years of Product Development experience working as a Product Owner, Scrum Master. Hiren is passionate about building high-performing teams and enabling Business Agility for organizations. Hiren, as a PST has trained over 5000 people on Scrum across all continents.
Hiren's Book
Hiren's Clients
Free Udemy Course on Scrum Foundations
Hiren has contributed to the following books:
"97 Things Every Scrum Practitioner Should Know", Collective wisdom from the experts. Published by O'Reilly: Hiren's article - Five Sublime Aspects for Being a More Humane Scrum Master, page 172
Reviewer of the Book: "The Professional Product Owner", by Don Mcgreal and Ralph Jocham, The Professional Scrum Series by Scrum dot org
What students say about Hiren
Courses taught by Hiren
Other Services by Hiren
- Coaching/Consulting
- Immersion Classes
- Private Courses
Latest Blogs by Hiren
See all blogs
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.
May 18, 2020
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.
May 9, 2020
*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.
May 3, 2020
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.
Jun 27, 2018
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.
Jan 23, 2017
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.
Dec 12, 2016
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!
Dec 4, 2016
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?
Nov 28, 2016
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.
May 5, 2016
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
May 3, 2016
Hiren's Certifications
Professional Scrum Trainer
Professional Scrum Master I
Professional Scrum Master II
Professional Scrum Master III
Professional Scrum Product Owner I
Professional Scrum Product Owner II
Professional Scrum Product Owner III
Professional Scrum Developer I
Scaled Professional Scrum
Professional Agile Leadership I
Professional Agile Leadership - Evidence-Based Management
Professional Scrum with Kanban I
Professional Scrum Facilitation Skills
Professional Scrum Product Backlog Management Skills
Classes Attended by Hiren
Applying Professional Scrum for Software Development
Trainer:
Richard Hundhausen
Date:
Jun 25-26, 2015
Professional Scrum Master II
Trainer:
Stephanie Ockerman
Partner:
Practice Agile Solutions
Date:
Sep 1-2, 2018
Professional Agile Leadership - Essentials
Trainer:
Punit Doshi
Partner:
Practice Agile Solutions
Date:
Jan 16-17, 2020
Professional Scrum Product Owner - Advanced
Trainer:
Robbin Schuurman
Partner:
Xebia
Date:
Jan 27-28, 2020
Professional Scrum with Kanban
Trainers:
Venkatesh Rajamani, Daniel Vacanti
Partner:
tryScrum
Date:
Aug 7-9, 2020
Professional Agile Leadership - Evidence Based Management
Trainers:
Mark Wavle, Chris Conlin
Date:
Jul 20-21, 2021
Professional Scrum Facilitation Skills
Trainers:
Todd Miller, Ryan Ripley
Partner:
Agile for Humans
Date:
Sep 23, 2022
Professional Scrum Product Backlog Management Skills
Trainers:
Todd Miller, Ryan Ripley
Partner:
Agile for Humans
Date:
Sep 28, 2023
By using this site you are agreeing to the Privacy Policy and Terms of Service