Evolving A Sprint Process That Everyone Loves

What is fun for a team of 10, quickly turns in to a nightmare for a team of 25, and a disaster for a team of 50.

Every time I see a startup scale up, I find them running in to and complaining about quality issues, communication break-down, stressful work environment, demotivated teams, and chaos. Typically, all the roles that CEO/Founders were doubling up as (Product/Tech/Sales) pretty much need to be handed off. And that demands a quick influx of team members who can take up these responsibilities. And it also makes people adopt standard processes that seem to have worked for others. That, unfortunately, creates even more stress.

When new people join, they bring in new knowledge and experience, and also a baggage of cultural orientation. And they are expected to hit the deck running. So, without being immersed in org culture, they have to take up critical communication and leadership roles. What you end up doing as a founder is distancing yourself from the core team you once managed directly. Even if you are pro flat hierarchy, what you are creating is still a hierarchy. And when done all of a sudden, it creates subtle panic and chaos. While startup life is all about chaos, ability to organize and structure this chaos is what separates winners from losers.

The success of a product is undeniably a function of its quality. And software product quality, in turn, is a function of its development process. You don't realize it initially because passion trumps over the silly hacks, issues, rework. But as you start hiring beyond your core team, you'd have people in the org with whom you communicate via other people. Unorganised/Assumed/Naturally-formed structures often create hurdle in the flow of information.

Even a flat hierarchy is a hierarchy. 

The more distance you have from the last node of communication the more important it is to think about setting up a process and create a communication map for the organization. It is critical since the success of your product is directly affected by what processes are you following to build it. In next part of the post, I'd discuss some abstracts from a real situation I was tasked to change and how we, as a team, were able to evolve a process that everyone loved following.

Software development process 

Let me try to describe at the high level, the situation we were in. We were split across different locations with both the product, the design and the tech teams spread evenly across the two locations. Teams at both locations were used to following their own half-baked development processes and tools and even the culture of interaction and cross-team communication were different. Add to that, multiple products with a common set of features, different technologies, platforms and different leads.

The general expectation was as follows:
 - everyone is occupied enough,
 - everyone knows what they are supposed to be working on and why,
 - are enjoying their work,
 - are working efficiently and
 - at any point in time, it is easy to determine if we are making good progress

Nothing exceptional about the expectations. Pretty basic, right?

None of them were being fulfilled actually.
 - people would generally complain they're either too free or too stressed
 - forget the why part, they were frequently breaking each other's code and spending a lot of time in rework
 - motivation? this wasn't really pushed as much by the management. It was more of a personal agenda as I was interested in making sure everyone is happy and content with what they are working on.
 - we had no way to tell if everyone was working at their optimum efficiency
 - every time we needed to determine status, a guy had to go around in the office and gather status

Most org related issues are non-unique. If you can relate to the situation described above, at the high level, feel free to add the people issues, ego-clashes, old versus new, the quick hackers versus the quality conscious, messy details, the nuances, the little friction points, and other problems you've experienced or can imagine. We've probably had most of those as well, in different quantity and flavor.

So now that we have a real flavor of the situation I'd take you through the journey of how we dealt with it all at once, but slowly.

Now, when I look back it seems easy. But, when you're in thick of things it can be really overwhelming. Because, I didn't know the entire problem, and there is no standard way to solve these that I was aware of. Plus, since it was assigned to me, everyone expected me to give them a fix. Like right in the first meeting, the question was what process should we be following from now on?

Answer - I don't know. But, I guess I can never give you a process. We can try a few things and evolve something that works for all of us.

I could feel the disappointment. People weren't convinced. Decentralization can be painful. (Do you hear it, crypto-fans?) However, stubbornness is a virtue sometimes. A weak argument said with conviction lands better than a strong one said without it.

Here's how we were able to evolve a process:

1. Started with a simple Team occupancy chart and allowed developers to share how occupied they are during the next sprint. Let people know you trust their word. They could simply fill it with any number they deemed fit. Usually, we used to get values like 25%, 50%, 80%, and 100%. That was a good reflection of where we stood, and what we need to make all values 90-100%.

2. Created a Sprint calendar. We decided on 2+ Week Sprints (meaning it should have 2 weeks of development ). It started with a Backlog refinement meeting where we made sure we had enough time for developers to do estimations, development and enough time for the QA to test and release. So technically, it was 3 weeks between the start of the sprint to production release, but in-effect we had releases every two weeks. Religiously did Retrospective meetings to understand the problems and solve them one by one. Made sure it is followed. Trust is important.

3. We identified 3 KPIs that we needed to improve. There were more KPIs on and off, but these stayed throughout. This was the crux of setting up the new process.

•  Minimize creep: the tasks being added in the middle of the sprint.
•  Minimize rework: (reopened tickets) for developers and testers.
•  Minimise residue: tasks left over at the end of the sprint.

The first sprint meeting was not really about introducing any process, but just making everyone cognizant about the KPIs. When we did the first retrospective, people were listening more seriously and suggesting how we could improve stuff. And from the second retrospective onwards we started seeing some improvement.

4. Improve communication, encourage everyone to speak out openly. Not everyone knows how to articulate their issues well so bear with people getting worked up. Accept mistakes. Don't point other's mistakes, allow them to accept it. Don't allow others to point a finger at anyone, let people get comfortable to own up. Give people enough time, keep asking "what else". Once we knew the KPIs, everyone had really nice suggestions to improve them and we just accepted and experimented with most of them.

5. Note down action items. Assign it to people and Convey it to them clearly. Follow up.

6. People felt empowered and started looking forward to this meeting. We started with checking progress on the KPIs, and then the retrospective basics - what went well, what didn't go too well, what needs to change. What initially took 90 minutes started reducing down to less than 60 mins of meeting.

Impact

It took about 4 sprints to have a process that everyone was happily following. Here's a quote from one of the emails I wrote when I introduced the process - "The idea is not to have process overheads but be little more disciplined and organized in our work so that we can get stuff done with less stress." 

The process wasn't created, it was evolved. It was a loosely defined process that evolved over a period of time and everyone contributed to it. It wasn't set in stone but everyone knew how to go about doing their stuff. Most of the decision making was still left to people's judgment. Some of them needed a little handholding here and there, but most of it was smooth.

• Everyone was occupied enough and we knew who's free when. 
• Overall there was a sense of belongingness, content
• Work was more evenly distributed and everyone knew what they are doing through the week (and weekend ;-))
• Every day we had a clue about where we stand and how things are progressing

Achievement (1500% improvement)

The entire exercise did not dramatically improve our efficiency. But, we exactly knew what's feasible to deliver in what time without stressing everyone. The high point came in when we were able to optimize an annual exercise, that historically needed a stressful fortnight. It was reduced to just one late night effort. 15 days and nights of stress got reduced to just 1 night. A 1500% improvement would sound outlandish, but, numbers are funny.

I hope this gives you some clues about how you can improve the development process in your organization. I am happy to take up any questions you might have.

Liked it? Have questions? Write it out.



If you have reached this far you should totally leave a comment about how you liked it and share this post with others.