Based on a true story! - The work of Woody Zuill, and his team at Hunter Industries as they uncovered this practice together after the experience of collaboratively learning.

As agile matures, new development and collaboration techniques are being uncovered. In this 40 minute presentation, we dive into Mobbing, what it is, the benefits, and how to get started with your own mob experiment.

the good old Survey. Long standing bastion of quantitative data collection... but painfully flawed. Surveys are inherently biased in the collection of data simply because of the person writing it framing questions in order to get a response. This in turn shuts down a whole swath of potential insights that could be understood about your customer, your app, or your service.

So how to turn this on it's head, have fun, and get good quality information to drive your strategic decisions?

With Serious Games! Collaboration at scale, asynchronous, and proven effective.

Please contact me if you'd like to re-use this deck! Happy to share and support you in using this cool technique :)

At it's heart; Flow Mapping is a communication tool. It can be used as a method to create Living documentation of system architecture

The technique allows architects, developers and business people to be on the same page with their understanding of progress through the development of a feature or service, as well as making a fundamentally complex, intangible system idea intellectually graspable at any level of the business.

Readiness is something which has been, and will be hotly debated in the agile community. Personally, I love the concept... But Then I was a Business Analyst for years. Consider this scenario; Your development team is plagued with unexpected work, high bug counts and seemly never ending technical debt.. and very little traction on actually moving through the product backlog.

A Nightmare situation.

The morale impacts of constant problems on a team and no progress through the "interesting" work are brutal. The fastest way to drive productivity into the ground. So how did we get here, and where is a good place to start looking to solve these problems? In my opinion: start at the start. Look at the quality contained within the cards entering the sprint or iteration.

To excel at Just enough and Just in Time requires a level of pre-work before the sprint starts, and honing this pre-work is what a "The Definition of Readiness" is all about.

Quality in; Quality out.

Please contact me if you'd like to re-use this deck! Happy to share and support you in using this cool technique :)

At it's heart; Story Mapping is a system view, and an MVP plan, and enhancement plan... and a release plan.. and and and; the list goes on.

Originally designed in 2005 by Jeff Patton; this recognised and widely used method will help teams at any stage of development visualise their complete project and then develop milestones or releases to suit the cadence of their sprints or iterations. The technique also allows architects, developers and business people to be on the same page with their understanding of progress through the development of a feature or service.

As a tool to create a clear overview of the stages of development, including what's finished and what's not; it's incomparable, easy to set up and fast to update - No Electronics Required!

Flow. Every team wants to get there, but many working with iterative development can't quite make it.

Project managers, product owners and most people who are NOT developers struggle with defining a heavily technical solution... And business analysts of the traditional nature have this technical nous, but struggle to make the transition to using agile frameworks because of the lingering hangover of BDUF/BRUF. If your product owner is out of their depth in a technical sense, then the whole project/area of development and system architecture is placed greatly at risk from creeping bugs, unknown dependencies, and missing stories. Simply adding a BA to your team will likely create more problems than solutions without re-engineering the need to know all the facts into something that fits "just enough and Just in time".

But it doesn't have to be this way.

In this case study based presentation I explore exact the exact methods we used to upskill a Business analyst or requirements engineer, and massage their skillset into a key role that can insure that quality, detail rich stories go into any agile process, while bridging the communication gap and bringing a wealth of "Big Picture" thinking to the bite sized chunks of Scrum development.