The Critical Role of Technical Leadership
The easiest way to derail the delivery of software development is to spend time on the architecture for future needs instead of the needs of “right now”. Success depends on delivering the simplest thing that could work right now. Otherwise, you can spend years building out a full, robust solution which may be technically perfect, but is delivered so late you miss the market opportunity. On a Scrum team, the best way to safeguard against these pitfalls is to have strong, business-oriented, technical leadership.
Right-sized is Key
It’s not just the feature functionality that needs to be viewed through the lens of MVP – but also the technical maturity of the product. While all software developers on a scrum team own the “How”, it is the Technical Lead, sometimes referred to as Architect, who is ultimately responsible for the technical decisions for the product. Sometimes embedded on a team, or sometimes operating outside of the daily Scrum model, this individual must be able to simultaneously push for technical greatness but also keep an eye on the high-level ROI of the development.
One of the easiest ways companies, especially large ones, fail in software development is building the first version of their new product too big, too robust, or for more users than needed. For good reason, most companies maintain technical standards that ensure the best quality products are released into market. Often they’re developed over time, through learning and best practice. But these standards cannot be one size fits all. Some standards certainly shouldn’t be relaxed, such as security practices. However, something like the size of infrastructure should be right-sized to early product needs, and not sized for the final full-featured product. This increases project margins because the cost of development is based on only the requirements that are required, and not on requirements that play second fiddle to your business priorities.
The best way to achieve success in new product development is to focus on the smallest amount of functionality that can be released to a customer, built in the simplest way possible, as fast as possible, without over-investing in infrastructural or architectural needs beyond the current product market maturity demands. These things, just as the feature set of the product, can be grown over time as the product’s market position matures.
For example, a critical component for achieving this development speed is right-sizing infrastructure. The effort involved with infrastructure setup can make or break a project’s bottom line. Often, especially in the case of new technology, the research, design, approvals and organization alignment can be an arduous process, slowing delivery and crippling the ability to respond to market demands before a single line of code is ever written.
While choosing the right technology for the long term is incredibly important, often the most robust, newest and most flexible back end is not needed at the time of a product’s initial launch. In fact, if all of that investment is done up front it may make the project’s margin so unattractive it’ll be dead in the water before it even starts. Technical leadership must be able to balance architectural and technical goals with the business’s evolving needs. This practice is referred to as emergent architecture, and it’s a crucial concept for developing and delivering innovation success to market. The Technical Lead must iteratively right-size the infrastructure to the needs of the release in order to reduce risk from building a solution that’s over-engineered for initial introduction.
Watch a short video to learn more about emergent architecture: 3 Software Tools for Shippable Software
Identifying the “Last Responsible Moments”
Technical leaders must be able to look at the product roadmap, market release plans and anticipated growth, and identify the “last responsible moments” for evolving the architecture to meet those needs. Sometimes that moment may be early in the life of the product, sometimes only after a certain number of users, or penetration into a particular region has been achieved. Often the architectural needs grow over time. Essentially, to achieve the best possible margin and reduce risk, the underlying architecture must evolve with the product, expanding and changing to the appropriate technology at the last responsible moment to meet the needs of the demand.
For example, if you know you are going to pilot a new piece of software with just a few customers, then the infrastructure likely does not need to support guaranteed business continuity for 5000 simultaneous users. Maybe one day that will be needed, but the Technical Lead must be able to identify when those moments are based on the product’s path to market, and they must know the costs associated with each “size” increase. Only through the matching of product lifecycle and technical maturity is the risk of building more than you need, and therefore spending more than is necessary, diminished.
Read Chapter 15 in the Epic Guide to Agile for More on the Last Responsible Moment: Read the Book
Incremental Delivery is Everything in Innovation Success
As we’ve mentioned previously in earlier posts, markets move quickly. Taking too long not only risks missing market opportunities, but it also costs more to the business over time. Releasing and selling something means being able to collect some revenue immediately. Over time, this creates a better ROI; a critical goal of anyone in technical leadership.
This post is one of a three part series on Scrum roles and their part in innovation success. The first blog in the series looked at How the ScrumMaster Helps Create a Better Alignment Between Innovation Goals and Business Needs. The second blog looked at Product Owner Innovation: An Integral Role for Delivering your Product to Market
