Day 1 – Overview, Vision, Scope and Accountability

So day one is down and it was a day of setting the vision and starting the definition of the scope (the Dev team were off sick, so it was only a 1/2 a day)

The Process

The day started with a quick whiteboard overview of the entire Agile Scrum Framework and this diagram kinda replicates what Gavin the BoostAgile Scrum Master drew for me:

As this was a 1 week Sprint the next step was a two hour Experience Mapping workshop, where we worked through some personas and the ideas on what outcomes the final product will enable people to achieve.

Then into mapping out the steps or activities we currently undertake to achieve the same outcome today (we are focussing on building a product that automates some stuff we do manually at the moment, or don’t even do at all).  Followed by grouping them into themes.

Then under each theme defining the functions we need to to achieve the theme, and then prioritisation of the functions.

Last thing was to write user stories for each of the must have features, that included how we would evaluate they are delivered successfully.

The important thing with features was to focus on what the outcome was not what the solution would be, which was a struggle for me given I spend so much time defining solutions!

User stories were defined in the format of:

As a <type of user>, I want <some goal> so that <some reason>

So again identified who would do what to achieve what outcome.

The Insight

I can see how the Experience Mapping through to User Stories can be used as a way of replacing the traditional Requirements Gathering phase of a Waterfall process.  But with a lot more focus on what the outcome would be and how we would validate it was delivered

And importantly I now have one of my major concerns negated, which was if we do lots of little developments (sprints) how do we ensure we come to an outcome.  This is achieved in a few ways:

• The Experience Mapping process and the feature definition means you define the total product (albiet at a very high level)
• The Sprint process followed by the review and retro means you can adapt over the project timeframe to make sure you deliver the required outcome vs delivering to the requirements that were defined months ago
• If the project gets canned at anytime then you can always go live with everything upto the end of the last sprint, try doing that in the middle of a waterfall project.

The other insight was that I think the Agile Scrum process results in a much higher level of accountability. This is because the Scrum Master is the sole person who manages the dev team and the Product Owner is the sole person who manages the stakeholders (steering committee etc).  So there are single points of accountability where it really counts.

So no different to a tech lead and a project manager you would think, but for me there are a couple of differences in that the roles are kinda of reversed from the norm:

• The Scrum Master who is responsible for making sure the tasks are complete (well the scrum team are self organising another difference but you know what I mean) does not report to the stakeholders, just the Product Owner (very different to a normal project manager role)
• The Product Owner is responsible for defining what is delivered (the product vision, features etc) and is accountable to the stakeholders, which ensures accountability with no where to hide (but very different to the tech lead role)

There seem to be a whole raft of other things that will make the development go faster but thats the excitement for tomorrow, looking forward to it!