Since a couple of weeks and I am walking alongside a person who is introducing an agile methodology (Scrum) to a company I work for currently as a consultant. Sometimes, when there is a decision a person needs to make they consult him. Most of the time one gets the feeling that this consultant is doing following a certain path, at which end a certain portfolio of ideas wait.
Definately the portfolio includes experience and a certain amount of grey cells as well, but there is a bit more.
He actually follows the vision of the agile manifest. In case you didn’t read it, but they are actually pretty much customer focused. If a customer asks for an IT-based solution, he seldom asks for good documentation, good processes within IT or nice and shiny architecture solutions – he actually asks for the functionality, which brings business value.
The focus on delivering a working software as fast as possible and introduce the customer as early as possible to the approach taken by developers, architects etc. is in my opinion the most crucial point in software development and delivery at all.
Especially in projects within large organisations – and especially in large projects in large organisation there is the habit of having a generic set of rules upfront, which in most cases slow things down and shift the focus of delivery to processes, task tracking and quality tools, project management issues and organisational dependencies.
This said it’s no wonder that these large organisations have a big problem delivering an IT project on time, in budget with the correct quality. Most of the project managers I know do not insert feeding buffers for internal processes. The overall anticipation is that you for instance define a hardware spec, go to procurement – order it and inject an delivery period buffer – tada: you’ll receive your hardware on time. The time you actually need to justify, order and organise the ordering itself is seldom really accounted for.
There is little willingness to make inefficient processes obvious and visible. These people would like to concentrate on their project, if they start taking care of the hiring process in the very company they work for – in the best case they lose a lot of time fighting against bureaucracy or worse getting problems with the colleagues since they rattle on the holy processes which worked so good thousands of times.
The way of thinking in the agile manifest is together with an agile methodology still setting up processes and creating overhead – but always in a way where you can see that there is the goal to deliver business value in the first place.
So maybe some homework for project members, either leads or workers: What is the current project result? Does this result has business value, if yes every part of the result? Is it worth realising things which do not deliver business value?
John Kotter wrote a book about “Leading Change”. One part of that is actually bringing a vision upfront. If you don’t define a proper vision you will lack people’s understanding in which direction to go, whenever they have to make a decision. The agile manifest is actually a vision provider and this goes now back to the beginning – where difficult decisions can be easily made if you follow for instance the vision of the agile manifest. Or simply question for business value and the shortest path to it.