A phrase Project Managers hear a lot, and one that occasionally proves to be at least partly true.
As it's most often spoken rather than written, it is hard to know whether the speaker means 'agile' or 'Agile'. I find that asking the question ('big A' Agile or 'small a' agile?) can reveal a lot about that person's knowledge of the 'Agile' world. If you find yourself asking the people around you this question and you receive blank faces or confused responses you can be fairly certain you haven't landed in a particularly Agile organisation, rather you're somewhere that has rolled out a buzzword in the hope of improving speed of delivery.
Organisations tend to fall into one of the following categories:
- Comfortably Waterfall - Fine.
This organisation knows how it wants to work and perhaps has reasons why they prefer to keep projects waterfall.
- Waterfall but concerned they need to get on the Agile bandwagon - Confused.
In this position organisations can panic that they're being left behind and either kick off an ironically waterfall project to 'implement Agile' - quite often lead by people with little knowledge, or, if budget is not forthcoming, an unlucky Project/Programme Manager is landed with the task of 'making us Agile' as a stretch objective.
- Adopted Agile Project Management within an otherwise waterfall company - Reality/Expectation mismatch.
Senior Management have spent some money 'making things Agile' (i.e they sent the PMs and BAs on a 2 day Scrum course) and they damn well expect to see results. They now feel justified in saying ridiculous things like "we're supposed to be Agile, now JFDI". At it's worst it means projects running within an Agile framework but using siloed technical teams who have a lengthy engagement process and will only work by throwing Work Products across virtual fences. And on the other side we have business teams who are maxed out in their day jobs and told to support a project they have no interest in. Also support functions whose only focus is statistics and numbers and making their graphs look right, at the expense of pragmatic delivery. And in the middle, an embattled Project Manager and Business Analyst sit absorbing incoming abuse from all angles.
- Adopted Agile Project Management within a genuinely Agile organisation - Unicorn.
This is rare, especially in larger 'corporates' where IT is seen as a room full of nerds rather than the powerhouse of their digital existence. The benefits here come from the fact that someone at the top has recognised Agile for what it is. A different way of thinking and acting, a different culture. The 'business' is probably Lean focused and comfortable in looking for the best way to operate. The Management expectation on projects comes side by side with genuine support. The right resources, the ability to remove blockers quickly and an understanding of the pragmatic delivery of projects.
In the real world, it's a spectrum, and we're all somewhere along it. Much as people want to believe that 'Agile' is a panacea and will improve delivery with zero extra effort, it's a myth. A genuinely Agile organisation is either created that way from the start, or is going to need investment to make it work.
A quick tick list for running successful Agile projects:
1. Business Buy-in (to Agile ways of working) and training (in your chosen project method). Not only in the area you are delivering change to, but all the way up to the Directors sponsoring the work.
2. Agile Change/Project Management - Use of an appropriate PM method that allows projects to be a Agile as possible within a governance framework that doesn't strangle agility.
3. Agile Software Development
a. Development Techniques
b. Testing Techniques
c. Agile supporting teams - It's great to have your application developers and testers working at a high level of maturity, but if your Database and Infrastructure teams create bottlenecks with waterfall patterns of working you'll quickly be frustrated.
d. Architecture - An architecture that supports Agile change (Service Oriented for example)
e. Release/Delivery - Frameworks that allow for the shortest possible release 'tail' for projects and that support multiple parallel projects/small changes/fixes without creating merge nightmares
No organisation is perfect, but some clearly make a lot more effort while others merely pay lip-service to a vision. I would always recommend that wherever a person or organisation is on the Agile journey, never forget what we're aiming for:
Individuals and interactions over processes and tools
As it's most often spoken rather than written, it is hard to know whether the speaker means 'agile' or 'Agile'. I find that asking the question ('big A' Agile or 'small a' agile?) can reveal a lot about that person's knowledge of the 'Agile' world. If you find yourself asking the people around you this question and you receive blank faces or confused responses you can be fairly certain you haven't landed in a particularly Agile organisation, rather you're somewhere that has rolled out a buzzword in the hope of improving speed of delivery.
Organisations tend to fall into one of the following categories:
- Comfortably Waterfall - Fine.
This organisation knows how it wants to work and perhaps has reasons why they prefer to keep projects waterfall.
- Waterfall but concerned they need to get on the Agile bandwagon - Confused.
In this position organisations can panic that they're being left behind and either kick off an ironically waterfall project to 'implement Agile' - quite often lead by people with little knowledge, or, if budget is not forthcoming, an unlucky Project/Programme Manager is landed with the task of 'making us Agile' as a stretch objective.
- Adopted Agile Project Management within an otherwise waterfall company - Reality/Expectation mismatch.
Senior Management have spent some money 'making things Agile' (i.e they sent the PMs and BAs on a 2 day Scrum course) and they damn well expect to see results. They now feel justified in saying ridiculous things like "we're supposed to be Agile, now JFDI". At it's worst it means projects running within an Agile framework but using siloed technical teams who have a lengthy engagement process and will only work by throwing Work Products across virtual fences. And on the other side we have business teams who are maxed out in their day jobs and told to support a project they have no interest in. Also support functions whose only focus is statistics and numbers and making their graphs look right, at the expense of pragmatic delivery. And in the middle, an embattled Project Manager and Business Analyst sit absorbing incoming abuse from all angles.
- Adopted Agile Project Management within a genuinely Agile organisation - Unicorn.
This is rare, especially in larger 'corporates' where IT is seen as a room full of nerds rather than the powerhouse of their digital existence. The benefits here come from the fact that someone at the top has recognised Agile for what it is. A different way of thinking and acting, a different culture. The 'business' is probably Lean focused and comfortable in looking for the best way to operate. The Management expectation on projects comes side by side with genuine support. The right resources, the ability to remove blockers quickly and an understanding of the pragmatic delivery of projects.
In the real world, it's a spectrum, and we're all somewhere along it. Much as people want to believe that 'Agile' is a panacea and will improve delivery with zero extra effort, it's a myth. A genuinely Agile organisation is either created that way from the start, or is going to need investment to make it work.
A quick tick list for running successful Agile projects:
1. Business Buy-in (to Agile ways of working) and training (in your chosen project method). Not only in the area you are delivering change to, but all the way up to the Directors sponsoring the work.
2. Agile Change/Project Management - Use of an appropriate PM method that allows projects to be a Agile as possible within a governance framework that doesn't strangle agility.
3. Agile Software Development
a. Development Techniques
b. Testing Techniques
c. Agile supporting teams - It's great to have your application developers and testers working at a high level of maturity, but if your Database and Infrastructure teams create bottlenecks with waterfall patterns of working you'll quickly be frustrated.
d. Architecture - An architecture that supports Agile change (Service Oriented for example)
e. Release/Delivery - Frameworks that allow for the shortest possible release 'tail' for projects and that support multiple parallel projects/small changes/fixes without creating merge nightmares
No organisation is perfect, but some clearly make a lot more effort while others merely pay lip-service to a vision. I would always recommend that wherever a person or organisation is on the Agile journey, never forget what we're aiming for:
"We are uncovering better ways of developing
software by doing it and helping others do it.
Through this work we have come to value:
software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan"
Comments
Post a Comment