Home > Uncategorized > Controlling Costs in an Agile World

Controlling Costs in an Agile World

26.06.2019 Leave a comment Go to comments

Originally posted on DLabs Medium site by Matt in 2018.  At the time of this posting, there is still not unified thinking in this area.

aka. What every technical and non-technical founder needs to know about running an agile technical team.

Agile Development teams focus on continuous value (to the business) delivery not continuous progress to a fixed feature set. As a result, traditional cost accounting, cost control, and budgeting will not work. This shift to agile changes everything around how founders must do budgeting, cost control, communicating with investors and evaluating progress.

BEST PRACTICES

Understand your unit economics. The team should have a measured velocity (how much progress it can make per sprint) and a basic team structure with a burn rate. Double the burn rate should approximately double the velocity and double the other business benefits the development team delivers (eg. quality of code, usability, feature scope growth, performance, reliability…)

Just in Time Estimations. As the sprint starts, the scope is refined and effort estimation is perfected through a full bottom-up (granular), collaborative techniques (we love estimation poker). Prior to that, larger (Epic) scope stories are estimated in a faster top-down method in larger blocks with less precise descriptions.

  • Work planning (and commitments) need the highest precision and just before work start is when there are usually the fewest unknowns. Detailed estimates only when work is about to start.
  • Overall work prioritization and cash flow planning decisions need less precision and these decisions must be made when there are more unknowns. After a point, more effort spent on estimating does not usually improve the quality of those decisions thus features not in immediate development have only high-level budgetary effort estimates.

Measure Measure Measure. Just because we are developing a new product into a new customer base with a new team with all the associated uncertainty, we still need to ‘do what we say we will do’ and measure what is actually happening. Measure what is actual team velocity (estimated backlog story points/estimated hours completed in the sprint) and confirm that there is a controlled process of preparing the correct scope for each sprint. While you are at it, try to tie this development effort to the expected end customer behavior metrics. Evaluate “business value” velocity as well if possible.

Plan and Assess Each Sprint. The single biggest mistake founders and product managers will make with their new agile team is under invest in the planning (grooming + sprint planning) and evaluation (demo day). Without active participation of founders on the evaluation side, teams are unable to take initiatives, make calculated risks, and otherwise have any execution freedom. Without participation on the planning side, we collectively are missing out on opportunities to dramatically cut back the effort needed to achieve the business goal of any specific backlog item and/or dramatically reducing the risk that the final result will be usable.

Step back and Evaluate. In each “value stream”:

  1. what am I willing to risk to see if this value can be realized in this way? (Act-Learn-Build) and
  2. have we reached diminishing returns in this area?

Another area for evaluation is around the business strategy overall and the performance of the technology team and team leadership.

Divide the Costs & Efforts to Maximize Decision Making not Accounting . Agile technology teams normally organize burn rate (velocity) costs around people / functional areas (eg. front end, UX, devops…). Although it adds complexity, many times it also makes sense to divide the effort / cost into named ‘value streams’ (by tagging Jira tickets with names like “premium upselling” or “partner channel”). This division is preferable to a more intuitive “feature” based costing as it focuses on the value rather than the implementation and creates more opportunities to for the product manager to take action with this data. Old school, feature based effort tracking is usually only appropriate for more traditional ‘waterfall’ development or other special cases.

Non-technical people are critical to estimating. Despite detailed knowledge of the product and technologies, technical people are not always the best estimators. Non-technical people who stay at a high level can often quickly see patterns of mis-estimation better than those “in the trenches”. Don’t let the technical team estimate on their own — guide them and look for ways to correct future estimates.

Feature Completeness. There is no correct “cost of a feature”. Example: a taxi app might cost €250K while Uber has spent 10,000x more on tech for roughly the same functionality. The difference is obvious to the user, but difficult to explain. At DLabs named this difference “feature completeness” — Uber is simply more complete than Acme Taxi. It is these small details that make something great, but also drive the costs into the crazy zone. Communicating and discussing what level of feature completeness is needed initially gives everyone the freedom to approach the problem with more creativity. Avoid talking too much about the ultimate level of feature completeness desired in order to keep “preparation” work leaking into everything the team builds today.

WORST PRACTICES

Defining your specifications in a document and sending it to the team. If your background is technical, your design will assume technologies and approaches that may not be optimized for the team assigned and/or the product. If you are non-technical, you have added even more design constraints. For most early stage products, it is very rare that full specifications would be anything other than counterproductive to the end objective.

Holding the team accountable to the estimates of large blocks of work. If they had the skills to manage a product development effort to a fixed price and scope, they would need to have a slow, complex change request process, remove all aggressiveness from the plan, and avoid any design freedoms within individuals in the team. Estimates are often used as a bludgeon to try to get programmers to work faster. This leads to unhappy programmers and to poor software. No one wins.

Focusing on the feature not on the business opportunity/value. Investors are not investing in product building, they are investing in value creation — building the product is only the tool. Great development teams working with great business facing teams can often solve the most complex problems with simple solutions when given the freedom to creatively assess the problem. Founders need to avoid the trap of over defining product and instead focus on the value they want the feature to create.

Reducing distraction by keeping each team isolated. Drivers sometimes want to isolate the development team from the business side activities for fear of distracting them from their task of coding. While that might make coding lines / day metrics better it is likely to ensure that agile benefits are never realized. Agile has distinct “heads down” days where isolation and no distractions are critical; however, the planning and review (heads up) days need maximum exposure to the big picture and access to the non-technical business drivers.

Building Software Once. Unlike building a coffee table, software products for customers (when successful) are continuous moving targets that are never “finished”. If a feature (eg. annotate a PDF) costs 15K to develop initially and has a business opportunity of 40K of value, then it is better to not start because the total lifetime cost will be many multiples of 15K as the feature evolves, refines, improves, and changes with other tech around it. The upfront cost of a feature is the cheapest part of the software process. Cost savings comes from reducing scope and removing features from the product that don’t have strong user / business value.

OTHER THEMES

Another challenge for traditional cost accounting is when founders enter into what Harvard Business Review calls Act-Learn-Build best practice. With this the focus is on how much we can afford to lose (should we fail) in pursuit of an objective. This amount takes into account alternatives, confidence of success, and cost to succeed. This is a proven, excellent approach that works well with Agile development. (Note: Most professional product managers and some founders, by contrast, are often more conventional and don’t work in an Act-Learn-Build pattern.)

In much the same way that management reporting is different than financial compliance reporting, one great technique is to think about “value streams” rather than projects and features. What is the appropriate rate of spending on a specific value stream and are we making sufficient progress (both technology development and in real life results) to justify continued spending in this area?

Reporting to investors and other founders on development spending is another area where agile development creates problems. Just like the best / worst practices above, try to avoid committing to feature development with fixed time frames and costs. Fixed teams (thrust / velocity) with predictable costs are easier to justify compared to on-demand or project level contracted services. Additionally, founders are suggested to focus on what areas (aka value streams) are getting engineering attention and what is the progress of this focus. On the positive side, if your agile team is being jointly managed properly, you should not have a lot of half finished work or other “invisible” infrastructure building that is usually very hard to explain to other stakeholders.

MECHANICS OF RUNNING A TEAM

  1. Score each backlog ticket for “Business Value” (by product manager). This along with effort / technical complexity is used to prioritize tickets and make sure overall business value progress never gets forgotten.
  2. Separate grooming from final selection of what gets into a sprint. Grooming is usually at the Team/tech Lead level, while final selection and detailed scope and estimation is a democratic process.
  3. Measure velocity of the team. This is a critical factor to “zero out” persistent estimation errors, improve predictability (to reduce waste), and build mutual trust.
  4. Don’t make detailed estimates of work not yet scheduled — keep it high level until absolutely necessary. Estimating wastes time and updating estimates multiplies this waste as well as sets wrong expectations. Remember why we need an estimate (eg. prioritize projects, make sure cash flow is sufficient, etc) and estimate with as little accuracy as possible up until accuracy is absolutely needed.
  5. At each sprint end, evaluate velocity (calibrating estimations and identifying problems), business value progress assessment, and see that all core members are bringing value.
  6. Name business investment streams and assign Jira tasks to these streams. Eg. “premium upselling concept” to all efforts trying to create a new upselling revenue stream to a digital product.

CUSTOMER SIDE ROLES DESCRIBED

Financial Owner

  • Spend Burn rate quazi-limit
  • Confirm changes to core team.
  • Understand development / value progress rate at a high level for value for money
  • Understand the priority of the current engagement (eg. speed of learning or speed of feature roll-out…)

Product Manager

  • Identify work backlog items
  • Score all work for “business value” / priority
  • Negotiate with DLabs team / team-leads to challenge their assumptions on how to achieve the business goal of the work item.
  • Participate in task-by-task selection of what gets into the next sprint and identifying what are priority epic stories.
  • Review the results of the last sprint and give feedback on results:
  • Execution approach feedback
  • Comfort with the number of results within the constraints of the team sizes.

D.LABS SIDE ROLES (REGARDING COST CONTROL) DESCRIBED

Squad Lead / Team Lead

  • Identify team problems
  • Lead the agile development process
  • Negotiate with the business side product manager regarding:
  • Approach and priorities
  • Infrastructure / refactoring vs business value contributing priorities
  • Tasks that need time boxing vs feature completeness limits (eg. research or design)

Tribe Lead / Engineering Manager

  • Collaborate with the Financial owner to plan burn rate
  • Ensure team chemistry is appropriate
  • Ensure Squad Lead is effective

REFERENCES AND FURTHER READING

  1. No comments yet.
  1. No trackbacks yet.
You must be logged in to post a comment.