Joint founder of IndigoBlue, James is IndigoBlue’s process director and a recognised expert in the Agile community. His work on Dynamic Uncertainty Management and Incremental Strategy has revolutionised the approach to implementation of Agile at scale.
James has over 30 years’ experience in IT delivery. Having begun his career at Logica and worked with numerous global companies including Shell Oil, Deutsche Bank, Reuters and JP Morgan, he has excellent practical knowledge of traditional and Agile project management on large-scale developments (up to £20 million). His roles have included Projects Director, Project Manager and Chief Architect. He first introduced Agile into an organisation in 1999, and has run a number of highly successful enterprise-scale Agile transformation programmes including Specsavers, IFDS and Aviva.
Amongst other speaking engagements, James presented the keynote at the Agile Business Conference 2011 - Delivering Agile in Government; Learning Lessons from the Commercial Sector.Job Title: Process Director
I am very excited about the level of interest in the new series of talks at the BCS on Agile Business Change, and also honoured to have been asked to give the inaugural presentation on the 17th September.
At IndigoBlue we have spent many years developing and refining the ideas that help people understand how and why Agile works. In a recent workshop I was asked how our ideas differ from the Agile Manifesto. It’s been a while since I analysed the manifesto in detail, and I found the process interesting.
Agile is now established within the IT industry as a means for delivering more business value faster. However, there is a problem. IT created the concept of Agile (with a capital “A”) and many people therefore see it as an IT delivery process and assume that it does not affect other parts of business change. At the same time, on the IT delivery side, there is frustration because so much more could be achieved “if only the business were more Agile”.
Agile with PRINCE2®
This paper presents IndigoBlue’s approach to integrating Agile with PRINCE2® and how this is supported by Adapt 2.0, IndigoBlue’s framework for the effective governance of Agile projects. It explains why the two approaches can be used together at a conceptual level, and also identifies the challenges and how they can be addressed using techniques from Adapt 2.0. This paper assumes that the reader has a prior level of knowledge of both Agile and PRINCE2.
Agile as a project approach enables value creation whilst also empowering sponsors and senior stakeholders to affect governance over the investment. However, this depends on effective mechanisms for translating the team view into a stakeholder view of progress, risk and opportunity. This paper identifies the challenges and solutions in achieving this translation.
It is generally accepted that stories should be Small. Some teams even demand that "no story should be bigger than a few days". Unfortunately, focusing on Smallness can lead to confusion and reduce the benefits of Agile. This is the third blog in a series which aims to provide a clear and practical set of criteria for good stories.
In a previous blog I raised some objections to the acronym INVEST, a widely-used definition of what a good story should be. In this post I introduce the alternative acronym that we use: VISIT. More importantly though, I provide a concrete and rigorous definition of a story.
The acronym VISIT stands for:
With the cricket world cup in full swing (but with games taking place during the working day) I have discovered that you can get a very accurate picture of the ebb and flow of a game simply by checking the standard graphs.
Somewhat bizarrely, this proved very useful in a conversation with a governance group I am working with when discussing the relative merits of different ways of reporting velocity.
There still seems to be confusion around what exactly a Story is, and how you differentiate between good and bad Stories. There are existing answers out there, but there is still too much vagueness. This is the first post in a series proposing a more definitive answer.
The de facto criteria for stories is the acronym INVEST. When an organisation we are supporting tried to use INVEST though, we found ourselves resorting to phrases like: "it should only be used as a guide". This is an unsatisfactory situation.
So what are the problems with INVEST?
I often hear the complaint that Agile reduces the amount of design possible on a project. The typical scenario cited is that design work has had to be "cut short" because the developers are ready to play the story. I get the image of a nest full of baby birds clamouring for food.
The intent is quote the opposite: Agile should increase the amount of design, but decrease the amount that occurs up-front. This requires a fundamental mindset shift: design is not synonymous with up-front design.
I have been doing some work recently applying Agile techniques on a business process reengineering project. This has led to some thoughts on what I am calling the "Solution Gap".
I see the Solution Gap as the gap between the intended value of a system and the solution that is supposed to deliver that value.
The Solution Gap is particularly significant when the intended value is people-oriented. IT systems are a good example of this. An IT system might be intended to make people's work more efficient, or it might be intended to engage with people more effectively. People however do not react in consistent, obvious, or predictable ways.