Reading Time: 5 minutes
Meetings are unpopular
In development organizations, software engineers often question why they need to spend time in meetings and tracking their work. They label time spent not coding as “ritualistic overhead”, “agile bureaucracy” and a waste of time. This point of view is natural, as developers learn to write code by themselves. To a developer writing code alone, any distraction is a waste of time. Phone calls, idle chats, bathroom breaks, or anything that is not writing code, interrupt the flow.
There is a significant difference between writing code alone, and being part of a team. A lone developer is free to code unbounded 100% of the time. Things get more complicated when a lone developer becomes a team. I am going to present a model of development teams as subject to the cold rules of economy. I’ll start by shedding some light on the needs of the larger organization. Then, I’ll discuss why process and coordination is a necessary part of the engineering work itself, and not something in the way of progress, like a pothole in the road.
The cost and value equation
Businesses are subject to basic economy rules; they need to estimate cost and value of any investment made. While software engineers are busy at work, the business is paying salaries, benefits, and bills. The cost of development must be lower than the projected value of the work produced. For-profit organizations expect to see a positive return on investment, directly or indirectly, in one form or another.
For any given software project, the business must be able to estimate its market value over time. That market value, in addition to the overall financial situation of the company, helps establish an upper limit of the cost of the implementation of the project. The engineering organization needs to work with the business to decide on a balance between feature set, quality-bar, and implementation longevity, to stay under that upper limit. This is not simple. In many cases, it is complex to estimate the cost of building software, and it is also difficult to estimate the market value of the product. Investing in creating software is a high-risk bet, and the engineering organization needs to give information to the business to lower the risk of that bet. The more accurate the information, the lower the risk.
During my career, I have seen projects and business relationships fail catastrophically when the estimation of the cost of building a large software project was done without due diligence and engineering discipline. Business leaders should never make estimations of cost based on hopes. That is a terrible strategy; in fact, it is not a strategy at all. Wanting to please customers is a good thing, but inventing reality out of thin air is reckless.
Development is a team sport
Solid engineers need to have strong technical skills, but they also need to operate well in the context of the organization. Since most companies need estimations of costs, developers need to be able to provide that information. When hiring developers, you should methodically look for candidates who have the experience, skills, knowledge, and willingness to evaluate the relative size of projects and track and communicate progress.
Since developer’s time is expensive, and uninterrupted flow is important for productivity, minimizing the burden of non-coding activities is important. This seems in contradiction with what I said earlier, but it is not. It is a healthy and well-controlled tension.
Let the professionals help
Scrum Masters are the managers of that tension and give relief by being responsible for the process. Developers can save an enormous amount of their time by trusting the Scrum Master expertise. Additionally, since agile processes include a constant reevaluation and adjustment of the process itself (self-organization), developers are in the driver’s seat when the process doesn’t work.
Scrum Masters cannot work without the support and trust of the engineers. The more senior engineers in the team commonly drive the technical discussions necessary for planning and estimating the work, but the participation and direct involvement of the entire team are still necessary. The people doing the work have the best knowledge of the amount of effort required to complete a project; therefore, they need to give the estimation. They also know what they can commit to. Moreover, the engineers doing the work know the status of a project better than anybody else, making them the authority on status. Finally, being part of the process gives them control on what they are committing to.
Estimation adds to the cost and requires skills
Estimating and planning work is not an easy task. It requires skills that take the time to build and refine during a developer’s career, and it is far from being an exact science. Similar to budgeting, estimating development efforts is a process of casting educated guesses. The accuracy of the estimation depends on variables such as experience and skills of the engineers involved, expected size of the work, type of work, how clear the requirements are and known unknowns. An exact estimation is often impossible, but giving the best guess with the information available is always possible.
For all the reasons mentioned, and some that I am sure I didn’t mention, the estimation of development efforts is not free. It is an expected cost that adds to the overall cost of building software. It’s also necessary, as the cost of not estimating far outweighs the cost of doing it. Planning and estimating allows Product Owners to help the business decide if investing, or continuing to invest, on the implementation of a piece of functionality is a wise undertaking.
Product Owners have a difficult task. They need to take imperfect cost and value evaluations and use it to make important decisions. They need to decide if an investment is worth the cost, and they need to revise that decision in an ever-changing landscape.
Types of cost
Overall cost estimation is not easy. Any software project has three main costs requiring evaluation by the Product Owners and the business as a whole:
- Direct cost. The monetary cost of the time spent working on the project. Stuff like salaries, rent, equipment, and bills.
- Opportunity Cost. The value of the work you choose to not do in that amount of time.
- Innovation inflation. Time passes, and the world doesn’t hold still waiting for you. During the time you are taking to build something, both market and competitors move forward. Your customers grow more demanding of stronger solutions, and the technology world makes progress with or without you. As the market around you evolves, your existing IP becomes slowly less valuable, unless you invest in improving it.
It takes a village
When you setup a development process, considered the economy model presented in this article. If you decide to use an Agile model based on a Product Owner, a Tech Lead and a Scrum Master (I call this the triumvirate model) things work well only if the three sing the same song, and if the team follows their tune. For the three to work well, each of them needs to help the others get the information they need to do their work efficiently. It is an interlocked mechanism, with a constant and benevolent internal tension, built-in by design.