 In May/June 2020 we spoke to 20 of New Zealand’s leading CDOs and CIOs. We asked them to tell us about the challenges they were facing with their digital transformation journeys. Unsurprisingly we found some common themes and we summarised them in this infographic 5 Top Challenges for Digital Leaders Each post we will look at a specific challenge in more detail. (If you want, you can catch up on the first instalment here: Benefits, Benefits, Benefits). This week we’re looking at agile project management. Running a transformation programme using agile methodologies in a corporate that’s more used to waterfall projects can often feel like you’re trying to stuff square pegs into round holes. And nowhere is this misalignment more keenly felt than the central investment budget allocation process and the ongoing engagement with your enterprise project office. It’s a big topic – so in this post we’re going to focus on the opportunity to better align understanding and expectations for agile projects. Some common issues I’ve heard from transformation leaders:
When you look at this in detail there’s actually some common underlying problems that you need to face into.
A word about Agile: If you look at it objectively Agile can seem a bit like a weird religion or a cult. A bunch of disciples literally went to a mountain and came back with an agile manifesto (aka commandments) and if you don’t believe me you can look it up here. There’s weird terminology (scrum, Kanban, story points, epics) and there’s special ceremonies. When a team moves to Agile it’s a bit like getting religion and you end up with a situation in your organisation of disciples and non-believers. This can cause tension and needs to be addressed. Ok so there's a lot of issues. But here's some ideas to try: One: Get an expert.The easiest and quickest way to lift your agile project management capabilities is to hire a governance expert who has deep agile experience. These people are relatively rare and in high-demand so consider yourself super lucky if you find them. Beware of waterfall folks masquerading as agile (using post-it notes and having a stand-up does not make you an agile expert). You can get a real sense of the extent of their agile experience by asking for specific examples of how they have solved governance issues in the past.
|
|
There are many skilled agile trainers and coaches in the market. Using an outside expert means you’re less likely to dilute best practice because of the way you traditionally “do things around here”. But do make sure the content is specifically tailored to the audience you are trying to reach.
|
For leaders who want some more help with personally walking the talk around agile, here’s some suggestions here |
Step Three: Build an agreed Agile framework with your project office
|
Once everyone is broadly clear about what Agile actually means it is worth investing the time to document the project flow from idea generation and budget allocation, through to deployment and results tracking.
This may seem a bit contrary to agile philosophy (see inset to the right) but a little upfront agreement goes a long way to reduce unnecessary requests for documentation or additional steps during the process. If agile projects have a reputation for being cowboys in your organisation, then briefly documenting exactly how your processes work can goes a long way to dispel the view that you lack discipline. |
Make sure you stay true to agile values. When you’re finished agreeing your methodology ask an agile expert to critique it for you. Do you really need that step, is it adding value? Are you approaching your methodology in the simplest way possible? It’s often really hard for people who are experts in a process to get enough perspective to drastically improve that process. |
Traditional project management methodologies have a number of approval gates that projects advance through. In a large and traditional organisation don’t expect to remove these altogether.
|
The trick is to understand the assurance the old methodology was seeking from each step of the process and then confirm (a) if that assurance is still necessary and if so (b) how you’ll replicate that assurance (but not necessarily the actual step) into your agile methodology.
When you’ve agreed and documented your agile project delivery methodology then:
|
For example – traditional projects ask business stakeholders to sign off on technical specification-type documents (even though stakeholders don’t always understand them) as a way to confirm that what they are planning to build is what is actually required. In an agile project this assurance could be achieved by active participation in regular sprint reviews with a supporting written record of the user requirements, issues raised during development and the agreed resolution of those issues. In other words, you were going to iterate written user stories anyway and now you can use that record as proof that you are building what stakeholders want. |
Next time we’ll focus on another common issue associated with agile project management – the annual project investment process.
If you want to be alerted about a new update in the 5 Top Challenges for Digital Leaders series, please subscribe here
If you want to be alerted about a new update in the 5 Top Challenges for Digital Leaders series, please subscribe here
0 Comments