Scrum, as the predominant agile approach, is maddeningly simple – have a single team deliver a potentially shippable increment every couple of weeks. It says nothing about how to get this promised land! So, how do we get there from a standing start? The transition to regular value delivery can be split into three phases:
- Prior to forming the team (Inception)
- Team formed but not yet sprinting (Sprint 0)
- Team sprinting
Prior to forming the team (Inception)
What kind of team do I want? Does it make commercial sense? How will this fit in with all the other stuff going on round here? Are business stakeholders aligned that we should do this? These are all good questions to ask up front so many companies have a process for this – often very PRINCE2 Project oriented.
Where can we get agile inspiration for this? The portfolio level in the Scaled Agile Framework(SAFe) provides some guidance (Lightweight Business Cases, Epics etc.). It separates the flow of work from the creation of capacity to do the work (motto “move the work to the people, not the people to the work”). SAFe almost kills off the project notion entirely in the interest of have stable (and therefore high performing) teams. This is a good direction to look in. If this is a step to far for you, Discipline Agile Development (DaD) has a specific name for this early phase: Inception. In the DaD Inception Phase:
- Form Initial Team
- Develop Common Vision
- Align with Enterprise Direction
- Explore Initial Scope
- Identify Initial Technical Strategy
- Develop Initial Release Plan
- Secure Funding
- Form Work Environment
- Identify Risks
Sounds like the right kind of things, doesn’t it? The challenge is that these are all unbound activities – how do we prevent endless polishing that ultimately delays finding out whether we have something of value or not (by building a bit and getting it out there).
I’ve had reasonable experience with setting a target time for these Inception activities but anything that involves a gateway (e.g. typically Secure Funding) can not be fully time-boxed because, if the funding committee say “No! Not good enough” then the proposal is bounced back to be further refined. (By the way it’s a good principle of process design that you should not have a stage gate without a way of limiting work-in-progress upstream.)
Team formed but not yet sprinting (Sprint 0)
The team are now here (incidentally, recruitment of team members can typically take 3+ months so Inception can be quite long). Should they start sprinting immediately? Most practitioners use a Sprint 0 whereby the team prepares itself to be delivering value. What should be in sprint 0? Here are some suggestions:
- Architectural goals/approach identified and made visible.
- High level architectural milestones understood
- Dependencies and risks have been identified and made visible.
- High-level conceptual design has been completed.
- Network requirements arranged
- Minimum environments ready (Development/test)
- Development machines ready (Local development environments)
- Logistic requirements in place (phone, desk, etc.)
- Tools for testing, coding, integrating, and building have been selected and installed
- The team has received required training
- Roles and responsibility have been defined
- Team board is set up
- Stakeholder map created
- Definition of done agreed.
When is sprint 0 done? Is it a fixed scope (all these things must be done) or fixed time (do as much as you can in 2 weeks). My encouragement is that it should be primarily on a fixed-time basis (as much as possible in 2 weeks) except for one item. This one:
AS A: Scrum team
I WANT TO: Create a Definition-of-Done and a tiny bit of working software (“hello world”) that fully meets this Definiton-of-Done
IN ORDER TO: Ensure the development pipeline works end-to-end
- Demonstrated/Reviewed by Product Owner
The Definition-of-Done should include releasing software into a production-like environment (or even better, to production itself). The reason I like this a lot is that it drives out all the problems around environments, documentation, version control, testing, security, release management, etc.
If you are not able to demonstrated in Sprint 0 that you can release to a production-like environment, you’re simply not ready to sprint.
Once the team is sprinting, then the sprint retrospective within Scrum is the mechanism whereby the team takes time to check whether they are (still?) in the promised land of regular value delivery and make changes to how they work as necessary.