Click here to Skip to main content
15,066,156 members
Articles / DevOps / Agile
Technical Blog
Posted 27 Feb 2020

Tagged as

Stats

11.2K views
1 bookmarked

How to Resource Projects and Products--Optimizing for Elapsed Time, Motivated Teams, and Budget

Rate me:
Please Sign up or sign in to vote.
5.00/5 (1 vote)
6 Mar 2020CPOL3 min read
Given increasingly shorter time frames for product life cycles, time is an increasingly undervalued resource.
In my last post, I explored the implication of a shift in importance and value of resources. Given increasingly shorter time frames for product life cycles, I think time is an increasingly undervalued resource. Zooming in to a sub-micro level, I think we're also looking at a paradigm shift with resource allocation within high technology companies too.

Image 1

Regardless of technology background, all stakeholders usually negotiate around schedule. Time is the least common denominator, from an accountability perspective.

In a traditional project approach, the team would figure out and agree the scope up front. These requirements would be fixed, once they are translated into cost and time estimates. Dates would also be agreed up front. In this case, there is a lot of analysis and scrambling up front, to try to learn and decide everything before knowing it all. In practice, this front-loaded exploration takes time. Regardless of whether the product delivery team is actually working on the product, this elapsed time on the "fuzzy" front end is added to the final delivery date. It takes a lot of time to define and estimate all of the work needed to deliver the scope. And in practice, this backlog will only help us figure out when the project or product is "done", which in and of itself, has no meaning to clients or salespeople. It is easy to overlook this full-time cost of trying to fix and define all work up front, particularly since the people doing this work can usually get away with not "counting" this time as part of delivery.

Image 2

Standard approach: Agile in a waterfall wrapper

And since scope is fixed, and something actually needs to be a pressure release valve, typically one of the bottom three triangles on the left suffer: time, quality, and cost. Then. spending months tracking project progress and with limited client interaction (because it's not "done" yet) is yet another waste of elapsed time.

There is a way to significantly reduce this waste, by bringing in the client early and maximizing learning in a highly disciplined structure. In an Agile approach, the exact opposite approach is taken. We don't try to fix scope up front; we fix the rules of engagement up front to allow both business and technical team members to prioritize scope as they go.

Instead, we strictly define business and technical criteria for a project up front, without fully agreeing what the scope is. So, we agree that we will spend up to $185k, quality is ensured with automated testing, and we have 3 months-to deliver something sellable. We may only deliver 1 feature, but if it's a valuable feature then clients would pay for it. If all of these are unambiguous, then the product team itself can prioritize scope operationally based on what it learns from clients. For all types of products, ultimately the clients and the market will decide to buy whatever is being built.

Image 3

Start work sooner, ship more, and incorporate client feedback sooner

What's fundamentally different here? Scope is defined by a series of operational or tactical decisions by the product team, not strategic ones defined externally to them. Senior business stakeholders shouldn't need to follow and know the technical details of what's in a product and what part of the project is "done". It's getting down into too much detail and communicating a lack of trust in judgement to a highly paid team of technical experts they meticulously recruit and train. It also undermines a sense of outcome ownership by the team. Because everything about their work is defined exogenously and just dropped on them.

What Is the Total Cost of Having a Waterfall Wrapper Around Agile Teams?

Clearly, efforts need to be coordinated across an organisation. Trying to use detailed waterfall-style up front planning will cost you elapsed time and may cost you the market opportunity you've identified. It's better to have shared access to backlogs and agile's drive to deliver potentially shippable software on a short cadence. Because you know you can use anything that is done by another team. And you can estimate or prioritize based on an open discussion among teams.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

Lukasz Szyrmer
Program Manager
United Kingdom United Kingdom
Lukasz Szyrmer used to develop in C++ and C# and now manages development teams. He writes about agile, lasagna, and the cost of delay. If you are hungry for more, check out Debugging Velocity for a free chapter in his upcoming book.

Comments and Discussions

 
-- There are no messages in this forum --