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.
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:
I further split the How into four areas, to be noted that this is not an exhaustive list:
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.
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.
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.
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.
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.
As with the How, I again split the What into 4 areas:
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.
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 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 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.
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.