First cycle with Shape Up, a new take on agile delivery
We appreciate the changes that Scrum brought, but over time teams started to struggle with some of its artifacts; mainly estimations, sprints, and too much time spent on meetings. Recently one of our teams came across a new methodology, one that focuses on shipping work that matters and increases collaboration and engagement within the team. And we set off to give it a try.
Who are we and what has led us to this experiment?
We are the Delta team and our main mission is to help teams in Jamf Security Cloud to be as effective as possible during the whole development lifecycle: from development environments to release pipelines.
Here are a few issues that we have been facing:
1. Too many tools and a long lead time
Sometimes we worked on software that we didn’t lay our hands on for a few months, so we had to spend plenty of time to re-learn it.
We tried to limit the number of epics we would take on a given sprint, but with a large set of responsibilities, this wasn’t always possible. The more epics we worked on at the same time, the longer the lead time got.
2. Many questions/requests from other teams
One of our engineers is fully dedicated each sprint for Slack comms and queries from other teams. This way we were able to provide support, however, every couple of days we had to coordinate who could cover this.
3. Too much time spent on meetings and missing focus time
Because of all the Scrum ceremonies, we’ve not only spent many hours per sprint on meetings, but as we know, context switching is a costly thing. We have tried to have some “deep focus“ time slots in our calendars, but it gets interrupted more often than one would think due to various reasons (priority, ad-hoc calls, helping others with their problems, etc).
4. Bureaucracy
Often, it was easier and quicker to just fix a bug instead of going through the whole process of creating a ticket with enough details, waiting for refinement to estimate it, and planning it to a sprint where we can finally fix it.
Let’s shape up!
Shape Up is a methodology created at Basecamp. Shape Up has at its core a goal of reducing the risk of a shipment not arriving on time. Teams work in three to six weeks long cycles. Six weeks is long enough to deliver something meaningful and valuable. The goal can be either a new product or an upgrade to an existing one.
The first step is having the team split into a Shaping and a Build team. The Shaping team is working on projects that might be built in the next cycle. The build team is working on the projects that were shaped in the previous cycle. In our case, the Shaping team had three developers and the Build team had four developers.
The first cycle of this experiment was done in the summer, so there were situations, where only one person was present in the Shaping team. There were situations where only Team Lead was present in the Shaping team, so he had to neglect his Team Lead duties. This was the first thing we decided to change — Team Lead won’t be part of any team full-time, he will be a backup in case of need.
Shaping team
Shaping team prepares a few pitches and each of them should clearly describe:
· Problem — Description of the need we want to tackle. What problem do we want to solve?
· Appetite — How much time should the team spend on the problem
· Solution — Description of the high-level solution, e.g. rough sketch
· Risks/Rabbit Holes — Edge cases or risks that would endanger the delivery (What must happen for the project to be at risk?)
· No-Gos — Define what is out of scope
The pitch then goes to the betting table. This meeting serves as a place where the team decides what projects will be worked on in the next cycle.
Each pitch was presented separately in a short meeting with our key stakeholder, where we went over the main points and had a short Q&A. After the meeting, the stakeholder thought it over and posted his thoughts on slack, which were taken into consideration. Every pitch is moved then to the betting table.
We had three developers on this team — A Team Lead, a Senior Developer, and a part-time developer. Since we are a support team, one person is usually full-time supporting other teams in our company (reacting on slack channels, monitoring, etc.).
The main benefit was having free hands to do whatever was important at that particular moment. If any team needed help, we didn’t need to create a bug ticket in Jira, prepare it for Backlog Refinement, or wait for the Refinement to take place so we can estimate the work. NO. Instead of all that, we just fixed the issue.
After everything was cleared out, we agreed on having one 3-week cycle for one project.
Build team
The Build team had four developers — two senior developers, one developer, and one part-time developer.
One of the most important things is having the whole build phase for uninterrupted work. Personal Time Off (PTO) is a form of interruption, so take it into account when creating the build team.
Team members don’t need to handle many different fronts, attend meetings, or help other teams, they can 100% focus on that one goal — delivery.
One of the main principles is “Fixed time, variable scope”. From the start, we knew we would need to learn a new skill called “fat trimming” (ie de-scoping) instead of doing the project with all the bells and whistles. The team needs to watch closely where it is in the cycle and how much time it has while using this information to work with the scope on the fly. Not focusing on “fat trimming” together with underestimated PTO were the main reasons why the first cycle lasted nine weeks instead of the planned six.
Trust is the key
One of the most important things in Shape Up is self-organization. All you have is a goal. One goal, that needs to be finished in a specific time frame with your colleagues. How to organise the work and how to keep progress depends solely on the team.
If you take away the trust either between colleagues or stakeholders, Shape Up won’t work properly. The team needs the freedom to work how they see fit, on the other hand, the team needs to be responsible and reliable, and the stakeholders need to know that team is doing their absolute best. Clear communication and transparency are therefore crucial.
Keeping track of progress
Compared to our Scrum way of working, where we had Scrum board, Shape Up needs something more lightweight.
For visualization, Basecamp uses its own feature called Hill Chart. We liked the concept and so we tried to simulate it on Miro.
At first, we thought about using the Hill Chart we created in Miro, but after a while we totally ignored it. We have created a simple Kanban board in Miro with all our tasks and used the simplest workflow — To Do, In Progress, Done. Since we communicated daily and collaborated on that one particular project, everyone in the build team was up to date with what was going on. Unfortunately, we didn’t keep the chart or Kanban board up to date and as it turned out, this wasn´t the best approach. When someone came back from PTO, they didn’t know what is happening in the build team. To find out the progress or blockers, they had to ask directly and interrupt the build phase.
Lessons learned and main points from retrospective
Pros:
· The team enjoyed the Shape Up experiment and we are looking forward to the next cycle
· The team delivered a Jenkins migration project, which would take probably a few quarters with the previous ways of working.
· We saved plenty of time due to the absence of meetings
· It was efficient; we had full focus on the delivery with no context switching or interruptions
· We didn’t have to wait for refinement, planning, or sprints for trivial changes to happen… we just did it
· Freedom and a sense of ownership, which improves motivation
Cons:
· Since this was our first cycle, we had a couple of details to figure out on the fly
· Improve visualisation/transparency so others can see how the team is doing without asking them — focus more on keeping the Hill Chart up to date
· We skipped the betting phase and went right to the Build/Shaping phases, which resulted in working on not shaped projects
· 9 weeks was too long, people were losing drive and focus
· We didn’t properly count people’s absences, especially since it was summer
Q&A
Q: How are you handling bugs and when are they being fixed?
A: This can be done in a few ways. Either you can use cool down period for this or if you are swamped with bugs, you can plan a whole cycle for “Bug smash”
Q: Where are you putting all the requests or initiatives from stakeholders?
A: Shape up doesn’t have a central backlog. If an idea doesn’t make it to the shaping phase, the team doesn’t store it anywhere, it is “forgotten”. Anyhow, no one can stop you from tracking your requests independently. If it’s something important or a good idea, it will eventually come back.
Q: What happens if you don’t deliver the project on time?
A: This depends on whether the extra invested time is justifiable. Are we at the end phase and we just need a few days to finish it? Will it bring the necessary value to the customer? If the answers are “yes”, then we can dedicate couple more days to it.
It is still important to look at the project and validate/decide, whether the project still makes sense and brings the value we counted on at the beginning of the project. Sometimes it is better to scratch the idea and cut the losses.
Q: How do you align with the rest of the company, that uses other methodologies, eg SAFE?
A: Shape Up is focused on delivery during a relatively short iteration, while SAFe is focused on delivery for a longer period of time whilst facilitating cooperation between teams. Shape Up actually gives us more tools to accommodate either ad-hoc work or just prepare (ie shape) new projects ready for the next iteration.
Conclusion:
Even though the first cycle was longer than planned, we were happy with the new way of working. It was refreshing to try a new way of organising ourselves and working on one project uninterruptedly and with the sight of light at the end of the tunnel.
The main struggles from the first cycle were identified and we will see the results after the second cycle, which was better prepared compared to the first one.
We’d love to hear from you: what works for you, and what doesn’t? Did we leave anything out or do you have any unanswered questions?
