TFS 2015 RC & VS 2015 RC announcements at //BUILD/

As expected there is a bunch of stuff being announced at //BUILD/.

Catch some of the highlights of TFS & VS 2015 from Brian's post and for a more comprehensive list of changes and features go here

Time to play  

Agile : Failing is a good thing!

I've had this discussion a couple of times over the last number of years, and people tend to not believe me when I say that in the Agile world, we want to fail!
For emphasis I will repeat that : In the Agile world we want to fail

Let that sink in a bit…

OK, now that you think I am full of it and must not have a clue as to what I'm speaking about, lets continue.

Waterfall or Structured methodologies / processes
Let's take the example of a waterfall approach. We analyse the work, get to development and finally deliver the functionality. The only problem is that this could take anywhere from months to years to get the first working software out there.. And now the customer or client can look at it and decide that this is not what they wanted in the first place or the business has changed making it irrelevant.

Here are some very interesting numbers on failing software...
The Standish group released some stats last year stating that "Only 9% of projects in large companies were successful." and that "The most projects, 37.1%, were impaired and subsequently cancelled (Resolution Type 3) in medium companies, compared to 29.5% in large companies and 21.6% in small companies."

With this high rate of failure, how can it possibly be good? Well it is not! Failure is never good, but it is inevitable. What we do however strive for is to mitigate the losses that are incurred due to the failure.
How do we do this?

Fail fast fail often…

Agile methodologies / processes
In contrast to the structured "long running" processed described above, in agile we get working software into the hands of customers, business or clients as soon as possible. They can then interrogate it and communicate where the problems (if any) are and what needs to be done differently or how to fix it. We can then"pivot" to fix the issues, change the focus or scrap unnecessary functionality to continue delivering business value.
The difference here is that if we do "fail", we lose an iteration's worth of work, which should be 2 - 3 weeks. Compare this to the months or years that a structured process could take...

Another difference is that we can then learn from the mistake, make an adjustment and continue delivering value. In structured processes the monolith has been developed and you may very well be too far down the path to make the required changes or fix the issues.

In a nutshell:

Failure is not good, but it is inevitable. Things are changing too rapidly for us to start with a plan and be able to deliver relevant software months/years later.

We need to deliver small chunks of work that can be interrogated and evaluated, gather that feedback and communication and adjust what and how we do things to mitigate the risk and exposure of the failures or losses!