How the Team Is Organized
Freedom and responsibility
This is one of our values. But simply having it on a poster does not help creating this feeling of freedom nor sharing responsibilities. So that’s why we chose to review the way the team is organized. The main change is to go from one- or two-week long sprints to six-week sprints. Projects will be shaped and prioritised in advance and product teams will be free to organize the way they want in order to meet chosen goals within given time and boundaries.
Six-week Sprint
Projects are designed and developed in cycles of 6 weeks. At the start of each cycle, teams of developers and designers will be formed, and each team will be assigned with one or more shaped projects.
The goal is to have shipped in production solutions to the given problems by the end of the cycle, meaning that review and testing must be accomplished in these 6 weeks. Teams will fully and only focus on the assigned projects. There will be no interruption during this period so to allow everyone to concentrate on their work.
We apply the rule of the circuit breaker, meaning that if the goal is not met, no additional time will be given. The development of the project will be stopped and it will go back to the definition table.
Six weeks is long enough to build something meaningful start-to-finish and short enough that everyone can feel the deadline looming from the start, so they use the time wisely.
Ryan Singer
Two-week Cool-down
Between each sprint, a cool-down of 2 weeks will take place. This is a period with no scheduled work, everyone is free to work on whatever they want. This time can be used to discuss issues, to fix bugs, to explore new technical stuffs, etc.
Maintenance Shift
During each sprint, a developer will be designated to take care of the maintenance and won't take part in any project.
This role is key since it will allow other members of the team to get uninterrupted time by:
investigating and fixing urgent and important bugs
maintaining the infrastructure
improving performances
taking care of security issues
onboarding new teammates
being available for code reviews and technical discussions
Shape up
Many concepts described here are taken from the book Shape Up. We can only but encourage you to read it!
Don’t think of this as a book. Think of it as a flashlight. You and your team have fumbled around in the dark long enough. Now you’ve got something bright and powerful to help you find a new way. Ryan Singer
Key Concepts
Shaped versus unshaped work
Setting appetites instead of estimates
Designing at the right level of abstraction
Concepting with breadboards and fat marker sketches
Making bets with a capped downside (the circuit breaker) and honoring them with uninterrupted time
Choosing the right cycle length (six weeks)
A cool-down period between cycles
Breaking projects apart into scopes
Downhill versus uphill work and communicating about unknowns
Scope hammering to separate must-haves from nice-to-haves
There are a few concepts that are explained hereafter more into details:
Shaped versus unshaped work
Shaping is making an abstract project idea more concrete by defining key elements of the solution before betting on it.
Breaking projects apart into scopes
Don't run into the project with no plan. Take a few days to think about the solutions to get to the finish line. Think about what should be achieved and what technology should be used. Think about each step, each task you will have to complete through the project. It doesn't mean that it won't be updated later in the work but better think ahead.
Start first by breaking the project apart into scope. What's a scope? It's a part of a project that can be built, integrated, and finished independently of the rest of the project. In Overloop, we will use the Story in Pivotal. Each scope contains a list of tasks to be done to complete that part of the project. The list of tasks can and will certainly evolve over time.
Once this has been done, decide where to start. The best way is to jump straight into the middle. It should be core and it should be small. The point is to finish something meaningful in a few days and build momentum—to have something real to click on that shows the team is on the right track.
Final criteria, prefer the thing you've never done before. Why? This part of the project might take more time than you think and might put you in a bad position if the project is getting to the end of its cycle. Better eliminate the uncertainty right away.
Each scope should be accomplished one by one. Don't work on multiple scopes at the same time. By finishing a part of the project at a time, you will have a project evolving at each step.
No waiting
Developers don't need to wait for designers to be done. Since the project is already shaped, there is many info already available to start working.
Designers don't need to create a perfect design in the first place, they can quickly decide where each button goes but leave it raw. Visual styling can come later in the process. There should be just enough design to quickly wire the scope up and test it.
Downhill versus uphill work and communicating about unknowns
Feel the work you must accomplish through the cycle like a hill.
In the uphill, this is the phase where you still need to figure out how to solve the problem, how you will get to the solution. Each task, scope, and project goes through this hill. This is where you think about the whole issue. You might go up, and then realize the solution will not be possible and go down again.
Once at the top, this is where you know what's coming next. You can then start the downhill which is the execution phase.
Placing your tasks on this hill helps to communicate your progress without having to share info or losing time in a meeting.
It also helps to highlight the tasks that are stuck and where you might require a bit of help or extra information.
Scope hammering to separate must-haves from nice-to-haves
You might want to get the perfect solution, the one you will be sure will cover every possibility but also with the cleanest code possible. The deeper you get into the solution, the more tasks you might find. But at some point, you need to think about what should be done and what would be nice to be done based on the time you have and on the solution you want to get.
Do the difference between must-haves and nice-to-haves:
Must-haves: Tasks that must be completed for a scope to be considered done.
Nice-to-haves: Task left for the end of the cycle. If there isn’t time to do them, they get cut. Marked with a ‘~’ at the beginning.
Last updated
