4 Comments
In the same meeting as the proclamation of the “Agile expert” Scrum Master, we were also told that you can’t have a hybrid of Waterfall and Agile, “this simply leaves you with a Waterfall project”. Leaving aside the fact that the supplier was proposing an “Agile” process in which the requirements would be fully documented up-front, this statement betrays a fundamental lack of understanding of Agile.
In a presentation yesterday, I was stunned to find a potential supplier suggesting that their project manager was an expert in Agile because, “he’s a fully qualified Scrum Master”. While it certainly sounded good to those in the room unfamiliar with the label, attendance at a basic 1 day training course does not make anyone master of anything, let alone Agile management. This, I believe is a real problem for the Agile community.
Scaling Agile isn't just about concern with managing bigger teams. It's also about longer term governance and management of the broader programme.
We talk a little about this in our article on Agile Programme and Project Management.
1 Comment
IndigoBlue has been part of a very interesting review of Government IT, carried out by the Institute for Government (IfG), one of the most innovative think-tanks currently advising the public sector. Their report is issued this Wednesday and will be available from our website.
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?
1 Comment
I get to talk to organisations of all shapes and sizes about Agile methods and the key message I hear, especially in the public sector, is that Agile is about applying the best engineering techniques to software delivery. It isn’t. A focus on engineering techniques is attractive because they are easy to understand, they are relatively easy to implement and they produce higher quality deliverables – who could argue with that? Well, me, actually.
2 Comments
Why do projects fail to run as successfully and logically as they should given all the time, effort and resources expended?
Project failure expressed as a financial or time related overrun, or plain simple non-delivery, will be a familiar story to many of us. An often quoted view is that 70% of all changes fail at implementation. Management Consultants utilise such facts to try and justify a better or alternative approach. If the 70% fact is scrutinised enough, some will describe the fact as a fallacy, as surely the change does not fail entirely? The change may not work as intended or put another way, may have other unintended consequences.
During a recent preliminary meeting with a potential client, it became clear they were looking to pursue Agile as a methodology, without really knowing why. They’d been persuaded of the merits of Agile, but hadn’t really mapped this on to their own situation, so were asking us to implement an Agile transition, without having a particular objective in mind.
Agile Programme and Project ManagementScaling Agile to large projects demands balance between the ability to be responsive to change with an absolute business requirement for certainty requiring elements of predictive programme management and control.
Our PhilosophyWe believe that all organisations can benefit from Agile, but there is no single Agile approach that is applicable to all organisations. We therefore help organisations to improve their project management processes within the constraints of the prevailing context.