Many people entering the Agile world see the Agile Manifesto as the beginning of the world, where it was really the summing up of much previous work. Anchor the ideas of Agile development in earlier work, giving the learners continuity from the past to the present.

The 2001 Manifesto for Agile Software Development is still the anchor document for all forms of Agile development. Make clear that the Agile Manifesto is a set of values, not a prescription for a particular type of process. Also, learners should be introduced to the fact that the values on the left are preferable to those on the right.

Many people come to Agile looking for “the Agile process”. However, while some processes and methodologies may be more supportive or common in Agile organizations than others, the mindset must come first. Introduce Agile as a mindset and explain that agility is achieved through both “being” and “doing” Agile. The Agile mindset is characterized by things like valuing early failure for learning, collaboration, continuous improvement, continuous discovery, etc.

Experiencing the Agile mindset is the best way to establish it in a learner Allow the learner to experience situations in which the Agile mindset is likely to be different from their current way of working, so the learner can internalize the difference experientially, not just in concept.

One anchor of Agile development is incremental development. Introduce the concept and value of incremental development, and how it differs from effort-based or task-based management.

Many people, even understanding the idea of incremental development, can’t see how to break work into small, value-centered work items and track their progress. Develop and practice techniques for breaking problems into value-based parts and tracking progress against them.

It is easy to lose sight of the cost of rework in incremental-iterative development. Introduce and highlight why Agile developers need to keep an eye.

How is the Scrum theory implemented through time-boxes events, roles, rules and artefacts? How can these be used most effectively? We will experience why the Scrum framework is constructed as it is and how you as Scrum Master can effectively use Scrum to control risks and create maximum value.

Who is supposed to be a good product owner? What Product Owner does in Scrum? Do they write stories or maximize value? Why do we need a Scrum Master? Who decides Scrum Master for the team? What’s the meaning of a Self-Organized Development Team? Is a Self-organizing team good enough or we need a self- managed team? Developers are cross-function or Development Team is cross-functional?

Are you able to deliver a truly done product? What “DONE” means in Scrum and why it is important? Workshop focuses on differentiating DONE and UNDONE but also brings discussion about Technical Debts. Participants have to learn the meaning of DONE increment by defining definition in the workshop. Why not to have technical debt is critical to a growing organization? How Acceptance Criteria is different from Definition of DONE?

Why change is hard and what can be done to make it real? What organizational changes needed to see the real benefits of Scrum?

From concepts/ideas that may be vague, product owners are taken through the steps to turn this into a tangible and valuable artefact: a product vision statement. In a group exercise, the product vision statement is developed using proven techniques such as Elevator Pitch, Lean Canvas and Product Box. From the product vision statement, a story map is developed, breaking down the vision into a manageable number of steps or functional areas, depending upon what best suits the product. With this initial outline in place, high-level functional requirements are written, introducing the concept of user stories and epics.

The story map is populated by the group writing user stories to fulfil each of the product features, ensuring the stories remain aligned with the product vision and value drivers. Will have an understanding about how to split complex features into manageable stories.

The planning exercise is repeated a number of times using different criteria such as risk, value, complexity, size and marketability.

Identifying and responding to non-functional requirements to ensure they don’t get lost in the process of defining product success and lead to hidden risks.

Using key metrics and visualizing them with cumulative flow diagrams to help see where work is and how to improve the flow from concept to reality. Helping product owners to focus upon the right metrics and avoid those metrics that drive undesirable behaviors in development teams and by stakeholders.

Understand the role of the product in relation to the development team, how best to support them and what they need from a product owner to be effective in their role. Working with stakeholders, keeping them informed of progress and risks, influencing their decision making and managing expectations.

How to measure the success of an agile project in the ever-evolving requirement? Discussion around key metrics like business values, velocity chart, release burndown and sprint burndown. How to incorporate feedback in the forecast and how to forecast the project completion date.

Agile way of working has become buzzwords after the ING case study and recent adoption at ANZ. Let’s understand the pros and cons of the agile way of working. Will have a discussion around various models for organization agility and way to adopt. The focus will be on owning a roadmap for organization agility vs renting processes.