By John Yorke
Have you noticed that many agile practices seem to fly in the face of traditional notions of efficiency and productivity? While traditional management focuses on keeping resources busy, agile focuses on delivering value sooner—even if it is at the perceived expense of compromising efficiency and reducing productivity.
Why shouldn’t we do work that we will need later if it is more efficient to do it now? You have already dug the hole—doesn’t it make sense to do all the work in that area together now?
This is very similar to the argument for splitting stories horizontally along business layers, “we can be more efficient if we optimize and specialize. Yes, you might achieve local efficiencies by taking these steps, but local efficiency is not the most important factor in your decisions.”
Efficiencies and optimizations should be considered in the context of the whole system. A focus on local efficiency sees us saving a dime, but costing us a dollar.
Primary Goal is to Maximize Value
For both project and support work, the goal is to maximize value for the organization. In a consultancy firm, there is a slight abstraction as work is paid based on time and materials and these steps are distributed between client and team. But regardless of who owns the following steps, success depends on shared awareness of these priorities.
The Four Steps
The four steps are designed to focus energy where it will have the most impact first, and then building upon the previous step by shrinking the focus area through each subsequent step.
In descending order of impact they include prioritization—choosing the right product to work on; direction—building the right product for your users; agility and adaptability—use practices that enable flexibility to quickly meet the needs of your customers; quality—building the right product; and efficiency and improvement—seeking ways to improve your product and your process.
Prioritization
The most important decision your organization must make is which work brings the most value next. This has the most impact on your company’s bottom line, and so it should get the lion’s share of effort and focus. Describing the value a project brings the most important aspect of software delivery. If possible, create a formula for calculating business value to help with these decisions. If you are unable to quantify or qualify the value to the organization of the work being undertaken at a high level, then you are likely working on the wrong thing and all other actions you take could be a waste.
Some projects/products bring in huge revenue. Others may save in manual entry and work hours. Some may support business-critical systems that, if not supported, create extensive risk and potential cost. A project might also fulfill a safety or regulatory concern or business objective. Naturally, this is complicated and can be difficult. Priorities often change. Time factors and organizational politics come into play. A lot of the time, businesses make informed guesses about value and costs. But this decision dwarfs all of the others in the impact to the bottom line, so it’s critical to put the right amount of effort here.
This could be considered the responsibility of the program or project management office, but the responsibility is to identify the projects that bring the most value to the organization as the end of their role. Day to day project management responsibility lies elsewhere.
The decision-making process should be transparent and inclusive. Hold a regular project review board and invite the stakeholders, make the process clear, and help everyone understand how decisions are made. It is also a good idea to create a visible roadmap of work planned.
Finally, don’t plan beyond your company horizon. If new work is likely to emerge in the next three months that may significantly change priorities, then only plan for three months. Only start products or projects at a point you feel committed and certain that it will be completed. Starting something with the expectation of pausing or pivoting suggests it isn’t the most important thing to work on next.
Direction
Whether this is a new product or supporting an existing product, it is important to ensure that you build the right product.
Like the prioritization step, the most important responsibility in product ownership is maximizing value. Are you working on the most valuable thing next? You do this through experience and feedback from users and stakeholders.
Feedback is crucial. To get frequent user feedback, consider how you intend to deploy and then regularly update software.
Deployment and ongoing updates should not be an afterthought. Product ownership is also about maximizing the work not done. The product should meet the needs and goals but only do what is necessary. There is a point when returns diminish. All work carries an opportunity cost, and at some point your time is more valuably spent elsewhere. Understanding this is vital.
Finally, it is important to get value to the customer quickly. Value is only realized when software is used. Strive to have the software in use as soon as possible. This may be in an unfinished state. It may be only a partial solution, but it should add value. For example, use it alongside an existing product or in place of another tool. Feedback from people actually using the software is valuable. Just like prioritizing projects, prioritizing stories has more impact on the success of the project than the following steps.
Quality and Building the Product Right
Building the right product is more important than building it right. Building the wrong product is just a waste, but that does not mean quality is not important.
When assessing cost of software it is easy to focus on the initial development cost alone. But support maintenance and future enhancements fall into the total lifetime cost of a product. The cost of defects magnifies over time, and the cost of supporting poor quality code is significantly higher and riskier. Re-learning and knowledge transfer are costly to an organization and there are numerous examples where companies are forced to abandon projects or replace software because they lost a key employee who had the knowledge locked in their head—or software so fragile no one dares to touch it.
Good Practices
Development and automated regression testing may seem costly at first. But when considered in the context of lifetime cost, they are a sound investment. More importantly, they enable the right business decisions because there is a confidence in the software.
Quality code with a solid set of tests enables refactoring and new features to be added with the knowledge that you are not causing unintended consequences elsewhere by breaking older functionality. This risk reduction is a considerable advantage, especially when supporting older applications.
This is not a carte blanche to gold plate or over engineer. Quality code is the right code for the
story and no more. We write just enough to satisfy the story and we write it well. Over engineering applies to the graphical user interface, too—we do not add features or over engineer.
Efficiency and Improvement
With this point, we work on the most valuable product to our company. With that taken care of, the next focus is to work on the most valuable feature or story for our users/customers. We should do so in a manner that enables confidence in the work and able to expand it later.
But guess what? You can do it better. Reflect on the decisions made and how we make them. Are you making the right decisions? What helped you make those decisions? Are you making the wrong decisions? If so, what could be changed to avoid repeating those mistakes?
Reflection and improvement should be done at all steps and incorporate the learning from all stages. If you continually look for ways to improve, it will consistently get better.
Efficiency of Developer Effort
So what about the original question about being more efficient with horizontal splitting of stories, or the perceived inefficiency of re-working the same area of code later?
It is a question of impact and perspective. In both cases, the question is founded on efficiency being a measure of the developer’s efforts. We should consider that in terms of delivering value to users, company efficiency should not be measured in terms of developer effort, but be ultimately measured in terms of delivered value.
Efficiency should not be measured in terms of expended effort, but should be measured in terms of delivered value. The most valuable decision is to work on the right project, this dwarfs all other decisions by an order of magnitude. But it is at a different level of scope than this question.
The next most valuable decision is what to work on. This generally best considered from the perspective of delivering value to the customer quickly and of being able to respond to changing and emerging needs.
When we split horizontally or when we do extra work, we know we may give the appearance of making more efficient use of developer effort, but in doing so, we reduce our ability to adapt to changing needs, and more significantly, we delay the time to deliver the next most valuable feature.
This is an example of working with a waterfall mindset. The measure is that while it delays us this week, we will make back the time next month or next year. So if we are not planning to deliver this to our customer until next month or next year, it might appear to make sense. But you may not have considered two factors.
First, if we are deploying frequently, we realize value with every release. If the value of software isn’t massively more than the cost of developer time to create it, then it is likely we shouldn’t be working this project at all. So ultimately the cost of developer effort for having to rework the same code later, for a new feature, is insignificant to the value gained by delivering sooner. We should measure ourselves based on value delivered not the effort to deliver it.
The second consideration is that the work you do on the assumption of needing it for a future feature may not actually be needed. That feature is by definition lower value and less important as it has been prioritized lower. There is a reasonable chance that the customer may change their needs or there is the possibility of the project being cancelled or considered good enough as it is. That work may never actually be needed and you would have delayed the project for work that had no value. The efficiency you are trying to achieve may just be an illusion.
Maximizing Value
When considering efficiency and improvement, remember the goal is to maximize value to customer and to realize the value as quickly as possible. Ask yourself if the efficiency improvement you propose fulfills those goals. If not, it may just be an illusion. SW
John Yorke is an Agile Coach at WWT Asynchrony Labs. He assists with the company’s development teams, and is a former Scrum Master with more than 20 years’ experience in software development.
May2018, Software Magazine
