We trialled a 6-week project cycle and here's what happened

At InsideOut we've been managing our workload in a Scrum-based environment where we have 2-week long sprints and 4-sprint long iterations, but we recently switched to a project-based workflow and we've found several benefits.

The old way: Scrum-diddly-umptious

Each developer has a pre-set number of tickets that they aim to complete by the end of each sprint. Each ticket has a number of points that indicates its complexity, not time required to complete. The theory here being that if each ticket were scored by time taken, this would change per developer, whereas a complexity score is immutable. If a non-urgent issue or bug pops up, we add a ticket to the 'backlog' which will be picked up in a future sprint. Equally, tickets that contribute to a larger project (like a new app feature, or a new app entirely) will be written up and added to the backlog. These tickets may be prioritised if the project has a deadline.

Sprint iterations are a collection of 4 sprints so we can assess our longer-term productivity, but also plan and work on longer-term projects. All sprints are managed via a Kanban board.

Ok, so what's the problem?

There wasn't anything inherently wrong with this approach. It worked for us in that we were getting a lot of work done, and the methodology was agile in as much as we were only ever a maximum of 2 weeks away from working on something new. For the wider business, this meant that if a non-critical bug was spotted, or if there was a small feature request that was provably important, we could work it into our next sprint.

There were, however, 4 main problems with this approach.

1. Bigger projects took longer.
Our sprints always comprised of several types of tickets ranging from support, bug fixes and data reports, alongside tickets that contributed to larger projects. This inherently meant we were unable to focus on any single project and our time and attention was always split.

2. Requests came in thick and fast.
Because we were only ever a short amount of time away from new tickets, the wider business was more than happy to add to our workload regularly. For every request that came in, we would have to assess a solution and potentially add a ticket to our backlog, thus splitting our attention even further. Also, if you've ever written up tickets, you'll know that to do it properly requires some thought and time. Hence, we would often end up doing 'quick things' there and then which ended up being unaccounted for and distracted us further still.

3. Meetings.
On top of our daily stand-ups, we had sprint planning meetings every Friday. This involved going through our backlog of tickets and work out what needed to be prioritised in the next sprint. It also involved discussing and pointing each and every ticket. We tried to keep these meetings down to an hour, but they naturally always overran and sometimes even took up a whole morning.

4. Under appreciation 🎻😭
As is often the case, the wider business doesn't see all the work we do. This is inevitable. But with this Scrum approach, our work felt even more obfuscated as the smaller, more technical things were being done but not necessarily understood, and the larger, more visible things appeared to take far longer than they 'should'.

The new way

We have trialed, and intend to continue using an 8-week work cycle that's comprised of a 6-week project and a 2-week 'wash up' period.

Project cycle

A select few members (the best suited to the project) will be put on The Project Team. It is up to The Project Team to start and finish a project within 6 weeks. This means that by the Friday of Week 6, the project has been released to production and is in the customers' hands. The project can be anything from an internal product (the most recent being a new dashboard built in React) or a new feature for our mobile app that will be released as part of our regular app-store updates for our clients to use.

The rest of the engineering team during this period will support the wider business with support requests and bug fixes etc - i.e. smaller tasks that do not belong to a larger project but still have to get done.

Wash Up cycle

The 2 week Wash Up period is where we debrief the project and look for ways to improve the next project cycle. We can also use the time to add things that may have been missed in the project cycle, whether because they were out of scope or we ran out of time and they didn't affect the core functionality of the product. These 2 weeks are also used as Kaizen time, as well as planning the next project. It's important the projects are planned properly as the condition of any project is that it gets delivered in 6 weeks. This means that we need to properly assess ths scope of each project and ensure that the Project Team is not overstretched or, indeed, slacking ;)

How does a project get chosen?

In the 2-week Wash Up period, any engineer can advocate for a new project. They don't necessarily have to take the lead on a project they advocate for, but it's often the case that they do. It means that the developers are actively encouraged to look for areas of the business that can be improved, but also advocate for things they may want to work on. Projects also get put forward by other areas of the business where they spot areas that need improvement in their department. Ultimately, the projects get given the green light by the CTO and CEO.

Disadvantages

I'll get the downsides of this approach out of the way first, as I'm a big fan of this new approach and I'm honestly struggling to find many downsides.

1. Less agile.

It takes longer for requests and business support issues to get done as we are now dealing with an 8-week block of time, instead of 2. However, there are still engineers on hand to deal with these requests, so it's not like nothing can be done in these 8-weeks.

2. Not everyone has a project!

It is the case that developers not on a project, arguably, have less fulfilling work to complete as they're working through tickets just like before. Having said that, people might prefer grinding through tickets and might hate projects, so it's all swings and roundabouts!

3. Smaller things may get skipped... maybe.

I can foresee a situation where smaller issues do not get resolved if they're not important enough. The wider business might find this methodology more frustrating than the old way of working, however, it's actually good that developers aren't wasting their time on things that are not urgent. Smaller issues are likely to get resolved in a project cycle where an entirely new feature or product gets built that's better than any fix that could have been applied during a sprint thus, in the long run, the business is far better off even if it has to suffer minor niggles for slightly longer.

Advantages

Let's do this...

1. Speed. Big projects are completed and delivered quickly. Projects of the size we're able to complete within a 6-week project cycle used to take us at least 12.
2. Higher standards. Developers are able to work on the project intensely and properly without distractions. This has resulted in better code quality and better infrastructure design.
3. Planning. The wider business knows that they will have a product in 6 weeks. This makes their scheduling and planning far easier and more efficient. It also means they don't have to continuously ask the engineering team about updated delivery times.
4. Visibility and appreciation. The wider business can see the results of the developers' work. We deliver features and products that the wider business can see and use every 8 weeks, without fail. This has made the engineers feel more appreciated and look more accomplished.
5. Fewer meetings. We don't need to sprint plan every Friday. We don't need to micro-manage and change things around to suit the latest requests that come in during each sprint cycle. This means more time for development and actual work!
6. Fewer requests. Because the wider business knows what we're doing and how long it will take, we don't get inundated with requests. We are left to work on our project. This, of course, leads to less distraction and a better result.
7. Responsibility. Not everyone wants to be a manager or run a team, but if you do or you'd like to try it, being a lead on a project is a perfect way to get your feet wet. As a Project Owner, you will have the responsibility for ensuring the scope of the project is achievable and, more importantly, that the project gets delivered on time.
8. No micro-management. Because each project is run by a Project Owner, the project gets run in any way the Owner sees fit. This means you get exposed to different ways of working when you're not an owner, and you can trial and experiment with different ways of working when you are. On top of this, it also allows for each member of the team to work the way they like. The best way we've found so far, is for the overall 'to-do list' and timeline to be visible to the whole team, but a person's individual tasks to be managed in any way that person sees fit. This means you're not stuck working in a way that someone else's brain works, you can choose your own tooling and methodology - something that I find efficient, educational and rewarding.
9. Education. As a Project Owner, you could put yourself on areas you want to progress in. For example, if you're mainly a backend engineer but want to do more front end work, put yourself on the front end and elect another backend dev to work with you! So long as the project gets delivered and to a high standard, this is an excellent way of learning on the job and improving your abilities.

Summary

To sum up, with this new way of working, the engineering team are getting through bigger projects more quickly, more efficiently and to a higher standard. Less time is being spent on the minutiae of day-to-day business and the wider team has a better understanding of what the developers are up to, and a better appreciation for what the developers do.

This is a way of working that we certainly intend to continue with. We and the business are really happy with the results and, as a developer, it's more rewarding and more fun!