Happy Holidays!

December 24, 2013

It's that time of year, and I'm taking a couple of weeks off from regular blogging. I wish everyone all the best, and I look forward to an exciting 2014!

More Communication, Less Documentation

December 15, 2013

Document-centric processes have taken hold in many organizations, and they are now drowning in that documentation. As companies want to understand how to get faster and be more innovative, one key is to document just enough and have conversations that drive towards more innovative, productive results. As we’ll see, agile development provides a framework for making this happen.

The Product Backlog as Communications Hub
With agile development using Scrum (the most popular agile framework in use today), we overlap product definition and delivery activities by incorporating a coordinating mechanism known as a Product Backlog. Conceptually, the Product Backlog fills that previously blank overlap area between product definition and delivery that I included in my Cone of Uncertainty diagram in my last post. Figure 3.5 shows the Product Backlog occupying this area:
Figure 3.5
As you may thinking based on the previous material, this model doesn’t fit agile development because the Cone of Uncertainty is created by plotting two points that represent the variability present at a given point in time, which are based on traditional project phases of project inception, requirements elicitation, design, develop and test (plotted from left to right on the diagram). And you are quite correct.

This model is useful to illustrate that with agile development, we are striving to keep the costs down in comparison to traditional approaches. The left-hand side of the cone – the Define area – where the cone is the widest and where we have the greatest variability and uncertainty, so we want to avoid overinvesting this area by creating large batches of detailed requirements along with plans and schedules that are cast in concrete based on those requirements. This area is where a great deal of waste originates, as any planning that we are doing is relying on information that most likely will change when we get to the brass tacks of actual implementation.

Agile Development: Learning While Working

December 3, 2013

The amount of variability that we will encounter with software projects depends upon the individual context of each project. In situations where there is very low variability in both the business and technical domains, an agile approach may not appear advantageous since more is known than unknown, but these situations are not common. (However, an agile approach can still be beneficial through its support of things like continuous improvement, low overhead, visibility and transparency.)

Even if we believe that we are in a low-variability scenario, it more likely that we are: a) underestimating the amount of variability involved and/or, b) overlooking something concerning the entire customer value stream where we are a part of a larger process.

Let’s consider the latter point first using an example from my previous post, where I talked about the implementation of home or auto insurance in our software (for a company where I previously worked). I stated that this was all about transforming a previously defined and approved insurance product definition into our software using tools that we provided. Using this perspective, there was low technical and business variability.

But this is also a limited view of the entire value stream from a customer’s perspective. If we expand our thinking a little, it becomes clear that there is an opportunity to combine the actual product definition for regulatory approval purposes and its implementation in our software. In other words, if we actively participated in the upstream product definition activities, we could make things more efficient and effective for the customer.

Moving back to the first point about underestimating variability, the historical track record of software projects delivering on time, on budget, with expected features speaks for itself. As covered in Chapter One, it doesn’t happen often, and odds are that we will contend with enough variability to throw us off our pre-planned track. This doesn’t make variability the enemy, just something we need to acknowledge and manage.