On Meeting Deadlines Versus Maximizing Throughput
I read a great short post the other day by my friend Robert Reppel on the disconnect in our industry between meeting deadlines and delivering value.
Among other things he wrote:
in more than two decades in the industry practically every single project I have ever been involved in was optimizing for adherence to schedule (using waterfall, scrum, “Agile”, whatever, it doesn’t matter) instead of optimizing to maximize throughput.
Where is the disconnect? What am I smoking?
Sadly, I have to admit that has been my experience as well.
Many players in our industry appear to have forgotten that the purpose of what we do is not building software, but delivering value to our stakeholders (i.e. “the business”).
Anything we build that is not useful nor used is a waste of time, money, and space, not to mention lost opportunity cost.
In my experience the impulse to organize around a schedule of dates has been driven by project managers (and sometimes stakeholders) who are, understandably, more attached to calculating “when will this be done” and “how much this will cost” so that they can manage expectations and the bottom line. This is often, after all, the role of key decision makers on the business side of any venture.
I think the emphasis on dates over value is a reaction to decades of being disillusioned by software projects that have gone over time and over budget and still delivered under value.
So what, as software practitioners, can we do about this?
Empower Our Clients to Make Effective Decisions
There are many shifts we can make in our development process to help regain the trust of our clients and customers.
Scope down our commitments
Large software projects rarely work. This makes sense, as the more we commit to at any given time, the greater the amount of undiscovered details and the greater the risk that we won’t complete scope within the agreed timeline, or that a big chunk of value gets delayed due to some small details.
Also, with greater commitment often comes greater impact to the business when we are late or deliver bugs into production.
Large projects often get planned in phases, however, so why not structure each phase as a discrete project with its own resource requirements, deliverables, and budgets?
A series of smaller projects not only helps us to start delivery sooner but also shortens the feedback loop between analysis, design, and the insights that only come from watching your app get put through it’s paces out in “the wild”.
Shorter projects also allow us more flexibility to scale our teams up and down as needed to cover the commitments of any individual phase, thus minimizing our burn rate.
Organize our work into discrete chunks of deliverable value
Even while we are shortening the length of our commitments, it is important to organize those commitments into discrete chunks of value such that we can minimize churn and disruption.
It’s important to be agile and flexible to changing needs on the part of our clients and customers. It’s also important to reduce the churn that can arise from trying to integrate changing requirements in order to stabilize flow of work through our pipelines.
After all, a smooth and stable flow can move faster than one with a lot of competing currents.
Finding the sweet spot between short commitments and reasonably-sized chunks of deliverable value can protect our dev resources from distraction allow them to experience a rhythm of follow through and delivery that builds spirit and confidence even amidst shifting long-term goals.
Implement lightweight and transparent metrics on our velocity from day 1
In order to make good decisions we need to have good information. How fast are we producing features? More importantly, how fast are we adding value? And the answer to that question needs to be expressed in terms that make sense to the client in the context of the business problem we are trying to solve.
Agile methods like story points and burndown charts can help surface statistics about our speed, but make sure that you’re not burdening your dev team with cumbersome reporting.
Raise the visibility of our status and metrics to our stakeholders
“kanban” boards share information asynchronously, often showing what tasks are on deck, what is currently being worked on and by whom, and what is recently completed. Tools like AgileZen.com even surface metrics about average time that cards spend in each phase of the pipeline.
I find that when a status board like this is visual and easy to update, it can empower any team member, manager, or stakeholder to gain an overview of the current state of your production system at any time without diverting development resources to generate progress reports or answer the “what did you do yesterday?” and “what are you working on today?” questions of a traditional scrum.
When I switched from a daily scrum to using AgileZen to manage flow on my last project, for example, our throughput increased because with the current status and workload clearly visible on our board to pull at any time our face-time could then focus on moving the project forwards.
Realign our release strategy
Let’s start by making our deployment process stable and repeatable (see below) so that we can actually deliver releases to our clients and their customers.
Then let’s commit to releasable (or released!) software on a regular basis.
Let’s remember that the goal of iterative development is not simply to branch and merge every two weeks. Instead, it aims to achieve a stable and releasable state repeatedly on a regular basis to give the customer value and options on an ongoing basis.
Empower your clients to release value to their customers.
Put them in the position to look good in the eyes of their stakeholders.
Put them back in control of how we spend their money and watch the trust redevelop.
Adopt Coding Practices That Empower Us to Respond with Speed and Grace
- Apply the 4 rules of simple design
- Automate test coverage (to catch mistakes)
- Automate deployments (to drive out risk in getting value into the hands of clients and their customers)