You want to do what?
‘There’s no time.’ That’s what I always hear. ‘There’s a date to hit.’ That’s another good one. When I raise an eyebrow and say ‘there’s always a date to hit’ it’s not just a consultancy mantra. I know a secret about project dates. They move. Slippery little blighters they are. Reality storms in and changes the game. I don’t know anyone who hasn’t experienced this, yet it remains a secret. So, there’s no time to think, let’s build.
Now that we’ve established there is no time for a Sprint
Zero, I’ll start by communicating what I believe is a reasonable explanation of
what a Timebox or Sprint Zero actually is. I generally go with ‘a protected
time for the team decide how to work together, find out why the product needs
to exist and a basic idea of what needs to be done in the near future’. If I’m
not feeling particularly verbose then I’ll just call it ‘a team based starting
point.’
The order in which I say these statements is important (to
me) as the success of your endeavour has its basis in first the how (communicate
and iteration), the why (the real business value) and finally the what (how do
we go forward initially). Note the word ‘initially’, this can, will and
probably should change. Funny how when someone says risk they actually mean fear
of change and vice versa, that, is probably a whole other topic.
Its all about the community....
The foundation of a Sprint Zero for me is the challenge of
beginning to build a team. Some organisations are finally having the hallelujah
moment where soft and hard skills are equally valued so I’d like to stick with
that happy thought. So you have a team of multi-skilled ‘developers’ (used in
the holistic fashion), they are going to be together for a while so they need
to rub along in an efficient manner which promotes business value driven,
robust development.
The first thing to consider is buy in. How can we convince
the sceptical among us that two weeks of ‘team building’ (as they may see it)
is a worthwhile exercise? On an experienced based note the ‘sell’ will be
infinitely harder in organisations which are currently transforming to agile
methodologies. This is always juxtaposed with previous behaviour, where an
organisation will spend months preparing for a waterfall project but two weeks
for a Sprint Zero is too much to ask.
Understanding who needs to buy in is the key. You will need
to consider both the team and other stakeholders. Primarily if the team doesn’t
understand why it wants to embark on a two journey of practical and conceptual
discovery then it will be difficult to explain it to anyone else.
The team should need a Sprint Zero and demand it of their
organisation. It is their chance to understand, explore, ask big questions and
implement before the project begins in earnest.
Some teams will want the practical benefits of a Sprint
Zero. For example the team do not want to implement their Backlog storage tool
during the first/second/third Sprint. The team should not find out that they
don’t have database permissions when they begin Sprint One and wait two days
for Service Desk to sort it out. Some teams will be sold on the conceptual
benefits. How do we interact? What are expectations/promises to each other? How
do we define our relationship with the business?
Every team is different, its a blending thing......
Each team is usually somewhere in the middle and desire a
mix of the practical and conceptual. I would recommend a 50/50 split, too
practical and the team will struggle to engage with each other and the wider
stakeholders once the project begins. Too conceptual and the basic building blocks
are not there to begin with, leading to a stuttering first Sprint.
Other stakeholders bring their own layer of complexity plus
their own agendas. Business or project management stakeholders might see agile
development as a means of getting a project started quickly and seek to
circumvent the Sprint Zero process. This can be as a result of an agenda or
just a fundamental misunderstanding of the methodology in use, either way if
your team is bought in to the idea then you have a much better and (more
united) case to take forwards.
Don't fool yourselves........
The main selling point is that, eventually we will need to do most of these things along the way anyway. You will need to invest this time, whether you like it or not. As with most project and/or team based decisions, you can either choose to do this in a controlled fashion when it gives the most value, or in a piecemeal fashion over the course of many Sprints, directly impacting your velocity.
The main selling point is that, eventually we will need to do most of these things along the way anyway. You will need to invest this time, whether you like it or not. As with most project and/or team based decisions, you can either choose to do this in a controlled fashion when it gives the most value, or in a piecemeal fashion over the course of many Sprints, directly impacting your velocity.
How long?
In conjunction with the buy in will be the decision on how
long you will spend on your Sprint Zero. I would recommend no longer than the
length of a normal build Sprint. Teams can wallow in a Sprint Zero, especially
those whose organisation who is in agile transformation, the desire to know
more and more before beginning can be overwhelming. I have seen recent examples
of teams in this state for 6 weeks, iterating over their Backlog again and
again and again. Iterating while not moving forward is tantamount to
procrastination, as no new information exists to change your train of thought.
We should ask ourselves as a team, what, to us, is the most valuable content
for a Sprint Zero in the context of this project?
There are three main threads to consider when determining
your Sprint Zero content, let’s stick with our How, Why and What theme:
How?
I further split the How into four areas, to be noted that
this is not an exhaustive list:
Roles
Experience tells me that when a team faced with a certain type of situation displays hesitant behaviour, they are unsure of their role, its boundaries and where primary responsibility lies. Primary responsibility is often neglected, statements like ‘we all own the Product Backlog’ generally translate as ‘no one owns the Product Backlog’. Avoid this trap. Spend time exploring, educating and setting expectations.
Experience tells me that when a team faced with a certain type of situation displays hesitant behaviour, they are unsure of their role, its boundaries and where primary responsibility lies. Primary responsibility is often neglected, statements like ‘we all own the Product Backlog’ generally translate as ‘no one owns the Product Backlog’. Avoid this trap. Spend time exploring, educating and setting expectations.
Communication
Whether you are embarking on a software project or working on a fishing boat (as a random example) communication will always be the greatest challenge you will face. In this context consider how your team will manage the ten percent of the Sprint dedicated to the Product Backlog and its refinement and understanding. An effective strategy here will serve as an enabler for the team to collaborate with each other and the wider business.
Whether you are embarking on a software project or working on a fishing boat (as a random example) communication will always be the greatest challenge you will face. In this context consider how your team will manage the ten percent of the Sprint dedicated to the Product Backlog and its refinement and understanding. An effective strategy here will serve as an enabler for the team to collaborate with each other and the wider business.
Iteration
The team should consider how it iterates through the work it will commit to. What are the daily, Sprint and release cycles? How does work flow between analysis, programming, testing and release and back again. Considering how you size and estimate will affect how you iterate. There is no right or wrong here. I choose story points as I consider ideal day’s too literal, therefore lacking subtlety and flexibility.
The team should consider how it iterates through the work it will commit to. What are the daily, Sprint and release cycles? How does work flow between analysis, programming, testing and release and back again. Considering how you size and estimate will affect how you iterate. There is no right or wrong here. I choose story points as I consider ideal day’s too literal, therefore lacking subtlety and flexibility.
Artefacts
Different methodologies demand different artefacts. Scrum allows you to scale up the number and range of artefacts that you use whereas other methodologies demand more. Prior to embarking on the journey decide which artefacts you desire and who has primary responsibility for them. A Product and a Sprint Backlog are a given but you may include a Risk Register, Impediments Log and so on.
Different methodologies demand different artefacts. Scrum allows you to scale up the number and range of artefacts that you use whereas other methodologies demand more. Prior to embarking on the journey decide which artefacts you desire and who has primary responsibility for them. A Product and a Sprint Backlog are a given but you may include a Risk Register, Impediments Log and so on.
Why?
Engagement
Without an understanding of why a product needs to exist a team will struggle to engage over a significant period of time. The main reason for building may well be that the organisation is being paid to do so. Is this enough to instil a sense of belief in the team that what they are doing is valuable? Ask the question. Once you have had a high level project briefing with the team and stakeholders ask if they know why and what value the product will provide. Mere money may not be enough.
Without an understanding of why a product needs to exist a team will struggle to engage over a significant period of time. The main reason for building may well be that the organisation is being paid to do so. Is this enough to instil a sense of belief in the team that what they are doing is valuable? Ask the question. Once you have had a high level project briefing with the team and stakeholders ask if they know why and what value the product will provide. Mere money may not be enough.
Trust the team with the commercial value
Along the same lines is letting the team into the inner
sanctum of the project. What are the terms under which they will be working?
What is the Time vs. Cost vs. Functionality vs. Quality model? Many projects
are conceived based on a flawed model to be utilised in an agile project where time,
cost and functionality are fixed and quality is the variable. Knowing these
terms and being trusted with them is enlightening and empowering for a team.
What?
As with the How, I again split the What into 4 areas:
Prototyping
Building a simple prototype can drive out an early spiky area of development. Have tricky architecture you’ve never worked with before that you need to push data through? Build something that pushes a random number through. Have a User Interface you aren’t too sure about and need feedback on? Brainstorm, mock up and demonstrate to your users.
Building a simple prototype can drive out an early spiky area of development. Have tricky architecture you’ve never worked with before that you need to push data through? Build something that pushes a random number through. Have a User Interface you aren’t too sure about and need feedback on? Brainstorm, mock up and demonstrate to your users.
Approaches
This is as much commitment based as methodology based. If you want to use Test Driven Development, backed by automated builds, with exploratory User Interface testing and automated API testing, now is the time to consider. This commitment will also feed into your sizing and strategy for iterating over slices of the product. It can and should change over time.
This is as much commitment based as methodology based. If you want to use Test Driven Development, backed by automated builds, with exploratory User Interface testing and automated API testing, now is the time to consider. This commitment will also feed into your sizing and strategy for iterating over slices of the product. It can and should change over time.
Environments
This is one of my true favourites as the simplicity of it makes me smile. A project (that had no Sprint Zero) I worked on decided to use a particular environment which suited our needs. However after launching headfirst into the build phase we actually found out that it didn’t work. 10 days of heartache and a failed Sprint later, we had to abandon it. A simple Sprint Zero smoke test would have found the fundamental problem and saved an entire Sprint of development.
This is one of my true favourites as the simplicity of it makes me smile. A project (that had no Sprint Zero) I worked on decided to use a particular environment which suited our needs. However after launching headfirst into the build phase we actually found out that it didn’t work. 10 days of heartache and a failed Sprint later, we had to abandon it. A simple Sprint Zero smoke test would have found the fundamental problem and saved an entire Sprint of development.
Product Direction
This aspect is entirely project and context dependent. However, let’s aim for a few things in terms of direction. Firstly let’s have a starting point, a first Story to tackle which displays real business value. Secondly have the first set of stories and features prioritised and the first release nominally planned, primed and ready for change when the real velocity comes out during build. Thirdly, have the bigger future epics in the Backlog and sized, even if it is hundreds of points. Once they are in they become real to the team.
This aspect is entirely project and context dependent. However, let’s aim for a few things in terms of direction. Firstly let’s have a starting point, a first Story to tackle which displays real business value. Secondly have the first set of stories and features prioritised and the first release nominally planned, primed and ready for change when the real velocity comes out during build. Thirdly, have the bigger future epics in the Backlog and sized, even if it is hundreds of points. Once they are in they become real to the team.
You might need to battle for it....
As with most truly valuable project and team activities a Sprint Zero is worth fighting for and it is a belief that I carry with me to the organisations with which I work. That is not to say my advice is always heeded, sometimes the urge and pressure to build is too much for the team and project to bear.
As with most truly valuable project and team activities a Sprint Zero is worth fighting for and it is a belief that I carry with me to the organisations with which I work. That is not to say my advice is always heeded, sometimes the urge and pressure to build is too much for the team and project to bear.
Truly successful agile teams and organisations see that a
Sprint Zero is not a nice to have but essential to the success of the project.
Those who receive this time in a protected state and make good use of it give
themselves a firm foundation to evolve and change from.
Comments
Post a Comment