Hacks to Crank up your speed in development you must know; Sprint VS Marathon
Every company wants to build the software/product faster and you have a team of dozens of talented and experienced developers. However, time is the most expensive and valuable resource. You can’t waste it on re-work, refactoring, meetings, and physical activities. Right? It depends…
Many companies grow up, slow down, and die. A good development pace is essential for surviving. Imagine, you have a great vision proven in many circumstances by many people and you know for sure that this product will be a real hit. All you need is to complete it.?
To understand the concept of time and pace in development you must understand and go through some of its reasons and complete the roadmap.
Analogy of Sprint Vs. Marathon
Most people tend to think about Speed as a single entity, but it is not. There are two very different types of speed: Short-term speed (Sprint) and Long-term speed (Marathon). Sprint vs. Marathon is a perfect analogy here. In software development, you can’t have both. Let’s take some abstract effort unit, like a point. Working full control in a sprint mode you deliver 100 points per month.
You can’t maintain a sprint pace on a long product development distance. Maybe it would help if you can maintain a 100 pt/month pace for 3-6 months, but it is extremely unlikely you can do that for a year.?
At some point, most of the developers will reach an exhaustion point and drop performance enormously. But your goal is to run a very long distance at the highest possible pace. That is what Marathon is about. You need endurance and evenness.
But how to create software faster over a longer time stretch? That’s a “1 million dollar” question. Most likely, the answer is unique for every company, but still, we can construct a reasonable rough model that can be useful.
?Interval Development: Interval Mode
We are not speaking about Iterative Development. Iterative development can be equally applied to Moderate Sprint or Marathon modes. Interval development is when you mix modes. For a short period, you can do Sprints, then switch to Marathon mode. In my opinion, a good schedule can be:?
Let me explain what we meant about Fast Pace Mode. In this mode, the team or the whole company drops all secondary activities: all meetings about the future, learning events, HR activities, etc. The team focuses on delivering value: writing code, testing, creating documentation, and shipping.
Fast Pace Mode ends with a relaxation week. This week is dedicated to refactoring, discussions, and thoughts about the future.
The benefit is clear — the average pace will be higher than in Marathon mode. Fast Pace mode with a decent Marathon period afterward is not stressful. Moreover, it can be a motivational event, when the team rolls up their sleeves, gets shit done, and ship fast. When you ship something — it makes you feel right. This is an accomplishment, a milestone. It is a narcotic. Maybe that’s why people can work in Extreme Speed mode for some time.
Software Development Speed Model
Let’s start from the overview. The picture looks scary, but after reading its explanation and connecting the dots, you will have a powerful tool to analyze similar problems.
This diagram shows things and activities that affect development speed somehow. Green means that activity increases speed. The more you have it, the better. Yellow indicates that some maximum exists. For say, you can accumulate technical debt and increase speed, but if you accumulate too much, it will slow you down significantly. Red shows things that slow down development, the less of them you have the better it is. The green arrow indicates an increasing effect. As you see, focused work increases development speed.
The red arrow indicates a decreasing effect. Better development skills and experience can decrease system complexity (good engineers create less complex systems).
Now you can look at the diagram and ask questions like What increases development speed? What decreases it? You will understand better.
领英推荐
It is quite obvious that skills improve development speed. More skilled developers solve problems faster and create less complex solutions. Some say there can be a 10x productivity difference between extremely skilled and less skilled developers. I don’t think it is a common case though.
The next trivial question is what can be done to increase developers’ skills? Skilled people tend to work on hard problems that demand their skills. How many companies in the world work on really hard problems? Not so many. On the other side, if your product is not rocket science, you don’t need teams full of PhD developers. So skills for any given company are different. A skilled developer at Google does not equal a skilled developer at some outsourcing company. At the end of the day a company should provide to help its people learn and grow.
Many developers don’t like processes. In general, most of them enjoy the freedom and dislike rules. Experienced developers understand that some rules are required. Cowboy coders just ignore the development process and move forward as they want. That is not always bad. Sometimes it can help you to take control of your speed even If you are working alone or in a team.?
In any company with 20+ people, there should be a defined development process. Extreme Programming is a highly disciplined process. It demands full energy and maximum attention, but it delivers great pace and code quality in the end.
Sometimes it is necessary to boost development in the short run. If you have an important expo or an important customer who insists on a release at a specific date. From a business point of view, it may be fine to trade quality for speed.
You should understand that there is no free lunch. But Sometimes short-term speed boosts may lead to long-term deceleration.
It is quite unclear how team stability affects productivity. Intuitively, we may think that stable teams perform better. In this case, our intuition is right. “Keeping a team intact for the long term resulted in 60% more productivity; teams were more predictable and responsive.”?
Why is that? Every team has a life cycle. Tuckman defines 4 phases of team development: Forming, Storming, Norming, Performing. A team is most productive in the last phase — performing. If you rotate team members, you break the team and all these phases will repeat. And again. And again. In the worst case, there are no such things as the norming and performing phases, just ongoing storms caused by rotation.
Software development is an activity you will think about all the time. When you have a complex problem in the software, you are thinking about it everywhere. It suddenly pops up when you are at your home with family or some thoughts appear in a shower and your brain even tries to reinforce the problem in, well, the most inappropriate moments. It is important to learn how to switch off.
Companies should also encourage people to have some hobbies and support them for more productivity and better results.
Conclusion
Software development pace, productivity, and speed are a complex, interdependent, and multifaceted concept. It has no easy solution. Some activities affect speed greatly, while others do not. You can’t just shout at people. You can’t blindly cut corners and focus on value-added activities only. The only solution is to think deeply about the company, development processes, people, tools, etc. Build a structured model and think.
Thank you for your time! Follow us for more articles.