In case there unfamiliar terms in blogs and e-mails, I provide the following definitions to ensure understanding for all.
Agile Leader
the Agile Leader posses a sense of urgency about transforming himself or herself and also transforming the organization where he or she works.The Agile Leader may or may not have a position of authority in an organization. In either case, the Agile Leader
The Agile Leader may or may not have a position of authority in an organization. In either case, the Agile Leader takes personal initiative to learn and apply practical agile strategies and conduct experiements that will enable teams to enhance effectiveness and efficiency of the organization.
The Agile Leader patiently coaches and educates others with empathy and firmness.
The AGile Leader might have a role of Scrum Master, Product Owner, Software Developer, Software Engineer, Software Architect, Solutions Architect, Team Lead, Software Development Manager, Engineering Manager, Software Engineering Manager, Engieering Senior Manager, Agile Project Manager, Project Manager, Software Development Project Manager, IT Manager, Director of Engineering, Director of IT, Chief Technology Officer, Chief Executive Officer, President or Founder.
It doesn’t matter what your title is. It matters what you do with your time and if you take positive initiative.
The Agile Leader does NOT complain about problems, but instead emphethizes with people and solves problems.
The Agile Leader does NOT dictate, but instead collaborates, brainstorms and seeks first to understand before seeking to be understood.
The Agile Leader does NOT talk negatively about other peoples, but instead tries to understand other peoples perperspectives and reaches out to bridge gaps of mis-understanding with face-to-face converstation.
The Agile Leader embraces the vision provided in the Agile Manifesto and the Principles behind the Agile Manifesto.
Product Owner or PO:
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.
The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:
- Clearly expressing Product Backlog items;
- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;
- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,
- Ensuring the Development Team understands items in the Product Backlog to the level needed.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
The Product Owner is one person, not a committee. The Product Owner may represent the desires of a committee in the Product Backlog, but those wanting to change a Product Backlog item’s priority must address the Product Owner.
For the Product Owner to succeed, the entire organization must respect his or her decisions. The Product Owner’s decisions are visible in the content and ordering of the Product Backlog. No one is allowed to tell the Development Team to work from a different set of requirements, and the Development Team isn’t allowed to act on what anyone else says.
– Copyright @ 2016, scrumguides.org
Scrum Master or SM:
The Scrum Master is responsible for ensuring Scrum is understood and enacted. Scrum Masters do this by ensuring that the Scrum Team adheres to Scrum theory, practices, and rules.
The Scrum Master is a servant-leader for the Scrum Team. The Scrum Master helps those outside the Scrum Team understand which of their interactions with the Scrum Team are helpful and which aren’t. The Scrum Master helps everyone change these interactions to maximize the value created by the Scrum Team.
Scrum Master Service to the Product Owner
The Scrum Master serves the Product Owner in several ways, including:
- Finding techniques for effective Product Backlog management;
- Helping the Scrum Team understand the need for clear and concise Product Backlog items;
- Understanding product planning in an empirical environment;
- Ensuring the Product Owner knows how to arrange the Product Backlog to maximize value;
- Understanding and practicing agility; and,
- Facilitating Scrum events as requested or needed.
Scrum Master Service to the Development Team
The Scrum Master serves the Development Team in several ways, including:
- Coaching the Development Team in self-organization and cross-functionality;
- Helping the Development Team to create high-value products;
- Removing impediments to the Development Team’s progress;
- Facilitating Scrum events as requested or needed; and,
- Coaching the Development Team in organizational environments in which Scrum is not yet fully adopted and understood.
Scrum Master Service to the Organization
The Scrum Master serves the organization in several ways, including:
- Leading and coaching the organization in its Scrum adoption
- Planning Scrum implementations within the organization
- Helping employees and stakeholders understand and enact Scrum and empirical product development
- Causing change that increases the productivity of the Scrum Team; and,
- Working with other Scrum Masters to increase the effectiveness of the application of Scrum in the organization
– Copyright @ 2016, scrumguides.org.
The Agile Manifesto
Manifesto for Agile Software Development
We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on
the right, we value the items on the left more
Principles behind the Agile Manifesto
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.
Continuous attention to technical excellence
and good design enhances agility.
Simplicity–the art of maximizing the amount
of work not done–is essential.
The best architectures, requirements, and designs
emerge from self-organizing teams.
At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.
Shu-Ha-Ri
Shu-Ha-Ri is a concept from Japanese martial arts describing the stages from ’learner’ to ‘master’.
- Shu (shoo) – learner – do everything in rote fashion without too much analysis.
- Ha (hah) – practitioner – understand the theory and tweak the systems based on reflections, analysis, and experience.
- Ri (ree) – master – innovate and create, potentially breaking with previous systems.
This mindset is important to understand when approaching a transformational effort or when training and mentoring people on your team. The construct is fairly simple. You crawl, then you walk and finally, you run.
The nuance of this mindset is that you as the leader are on the path from Shu to Ri. You cannot get stuck in the Shu-box, which is just following the methodical, repetitive plan of an agile process. You also cannot expect people who are starting as learners to suddenly become masters. It’s a two-pronged mindset.