• Prev
  • Next

Is Agile Growing Up to Be Lean?

Sue SMS-2063a _cropAfter attending the very well-supported DSDM Agile Business Conference in London recently, it seems more and more organisations are now actively engaged in Agile programmes. As a result, the debate has moved on. Some of the naïve Agile evangelism is gone (or at least muted), and in its place, I am pleased to see that we are beginning to discuss the real business issues around software development. 

I was particularly interested in the closing conference keynote from Dan North. I liked his description of a six-stage Agile journey, which went as follows, if I have remembered it correctly:

  1. First, the people break
  2. Second, the tools break
  3. Third, governance breaks
  4. Fourth, management breaks
  5. Fifth, finance breaks
  6. Finally, the organization breaks

What I understood him to mean by this is that everything has to be re-thought to fully exploit the benefits of Agile. And one of the hardest issues to overcome is governance. Once you get over that hurdle, management, finance and the organizational structure follow.

Governance is the point where we leave the realm of software development and start talking about the organization. Governance is about what the business expects from its investment in applications development and maintenance, not what the developers want from the business.

This is why I believe developer-centric Agile finds governance to be such a barrier – good governance means managing applications development and maintenance with the same discipline as every other business activity. It’s not about coding or “being creative,” but about delivering value for money. Developers should ask business managers to define what they mean by “value,” but they cannot expect a blank cheque on the promise of delivering it. The business will still want to know how long it will take and what it will cost. So, you still need good estimating practice – something that is still poorly done in many organisations, whether waterfall or Agile.

Earlier, on day two of the conference, a keynote from Dean Leffingwell on the Scaled Agile Framework married Agile techniques with Lean principles (as does DCG’s own Agile architecture). This seems to me a more mature way of looking at Agile. The principles of Agile arise from the activity of software development – sure, they can be more widely applied, but if the end-game is business value, it is better to go back to the underlying Lean principles of value flow and customer-focus. Agile may help you get better results, but without the Lean focus on value, they may come at a cost you can’t afford.

Getting value for money from IT is something many organisations have always struggled with, largely because measuring the value of software is not an easy thing to do (whereas measuring the cost is).

Nevertheless, if you want to deliver value from software, you need to manage the delivery of value. And if you need to manage it, you need to measure it, because I don’t know any other way of truly understanding what’s going on, let alone having any real control over it.

So, we end up with those two hardy perennials: measurement (or let’s call it “governance data”) and estimating. Maybe I look at these topics with a biased eye, but it seems to me the case for doing these things better has never been stronger.

Sue Rule
DCG-SMS, Marketing Director

Written by Sue Rule at 05:00
Categories :

The Traditional Software Development Contract Needs to Go

In “The Traditional Software Development Contract Needs to Go,” Susan Atkinson and Gabrielle Benefield assert that the traditional contract model has to bear significant responsibility for failed IT projects.

The three elements of the model (fixed requirements, sequential development and change control mechanism) are all flawed when applied to software development. Traditional contracts call for practices that oppose generally regarded best practices for creating high quality software, increasing project risk and potential for failure. Ultimately, this results in a poor return on investment.

According to the authors – and something we often say here at DCG-SMS as well – most organizations do not consider IT to be a business activity. It is a separate but necessary cost centre rather than a centre of value creation for an organisation.

The traditional contract model perpetuates this idea by generating a process that is neither effective in terms of delivering the software the business needs, or cost effective; therefore, most projects have a low return on investment, and the business continues to see software development as a drain.

The authors suggest an overhaul of the contract model where performance is measured by movement towards goals rather than against a previous plan.

This immediately raises the issue of how such goals are defined, and how progress towards them is to be managed in an efficient and business-like manner. This all comes back to how software performance is measured, and whether ‘traditional’ project metrics are fit for purpose. Outcome-based contracts require outcome-based measurement.

In order to manage the commercial risks of such an incremental approach, we suggest one essential is to improve software estimation practice, to give the development team’s business customers more predictable performance and greater visibility of the cost impact of changing requirements. With the use of any contract model, a good estimation program provides the development team with a better understanding of how and when it can deliver, resulting in an improved return on investment and increased customer satisfaction – and, most importantly, making IT a centre of value creation for the business. IT investment can be prioritized effectively to meet business needs and goals – in other words, software development can be managed like any other critical business operation.

If you’re interested in this topic, join DCG-SMS and Susan Atkinson for webinar on September 17, Contracting for Agile. The webinar will examine current thinking on how contracts for software development can better support the delivery of the desired business outcomes. Register now.

Software Development: Why the Traditional Contract Model is Not Fit for Purpose
Susan Atkinson, Keystone Law
Gabrielle Benefield, Evolve Beyond Limited
Presented at the 46th Hawaii International Conference on System Sciences

Do you agree that the traditional software development contract model needs an overhaul? What changes to the model do you suggest?

Sue Rule

Written by Sue Rule at 02:00

Subscribe to Our Newsletter
Join over 30,000 other subscribers. Subscribe to our newsletter today!