Tag Archives: agile

Your Agile Project Needs a Budget, Not an Estimate

Leave a reply

from hbr.org/2014/12/your-agile-project-needs-a-budget-not-an-estimate

Nearly every software development project starts with one question: How much is this going to cost?

….
Maybe it’s been asked another way — How long will this take? How many stories can we get into this next sprint? How many people do we need to hire to get this done? How much money do I we need to raise?

These are all variations on the same question — how much effort is this going to cost in terms of time and/or money?

There are two common replies to this question: 

  1. We don’t know;
  2. Let us estimate and get back to you.

Stakeholders and decision-makers don’t like the first reply because they desperately need an answer to their question and they don’t have the knowledge to answer it themselves. Technical teams don’t like the second answer, because estimating takes a ton of time and it’s often abused

….
To minimize the risk of having your next technical project go awry, stop estimating and start budgeting.

For most strategic decisions, estimating is too precise.

….
tactical approach to budgeting. [update throughout the life of your project]

Step 1: Identify Decisions
….
Step 2: Match Precision to Decision
….
Step 3: Budget

the case for continuous delivery

Leave a reply

from www.thoughtworks.com/insights/blog/case-continuous-delivery by @jezhumble (emphasis mine)

many of us are aware of the wide adoption of continuous delivery within companies that treat software development as a strategic capability that provides competitive advantage. [Amazon, Facebook, Google]
….
Still, many managers and executives remain unconvinced as to the benefits

….
Continuous delivery is a set of principles and practices to reduce the cost, time, and risk of delivering incremental changes to users.

….
high performing organizations ship code 30 times faster (and complete these deployments 8,000 times faster), have 50% fewer failed deployments, and restore service 12 times faster than their peers.

….
Implementing CD has second-order effects that reduce the costs of software development

For me, perhaps the most interesting effect of continuous delivery is the cost reductions it brings about by reducing the amount of time spent on non-value add activities such as integration and deployment. In continuous delivery, we perform the activities that usually follow “dev complete”, such as integration, testing and deployment (at least to test environments) — continuously, throughout the development process.

By doing this, we completely remove the integration and testing phases that typically follow development. This is achieved through automation of the build, deploy, test and release process, which reduces the cost of performing these activities, allowing us to perform them on demand rather than on a scheduled interval. This, in turn, enables effective collaboration between developers, testers, and systems administrators.

This change in process has extremely powerful second-order effects on the economics of the software development process.

my note:

a big part of this is due to reduced delay in the lifetime of a work item, since increased lead/cycle time for work will lead to increased amount of work for the same output, for a variety of reasons.

rushing without automated tests is a business mistake

Leave a reply

excerpts from article by Joseph Puopolo, An impassioned plea to other Start-up founders to use automated tests.

Working on the business side of the shop, I have fought against automated tests for a while. That all changed recently
….

The conclusion I reached was that automated tests save developers time and let you deliver more. This was a painful admission, but a correct one.
….

I have been in multiple start-ups where automated tests didn’t exist, and let me just say the QA overhead was astronomical.
….

While it seems counter-intuitive, building tests saves you time in the long run. The knee jerk reaction is to spend your time building new features. I have had this reaction many times
….

One of the biggest time sinks in development is finding the problem. With proper tests in place you can isolate and figure out where the issue is.
….

With automated tests in place, it is easier for new developers coming into the system to understand code that they didn’t write.
….

automated tests save time and help you get to market faster. If your goal is to rush to MVP without putting in place a scalable infrastructure that allows you to grow your code base, you are not only making a technical mistake but a business mistake.