The fundamentals of project management normally focuses on areas like planning, resource management, risk management and stakeholder management. In the year 2016 it also includes understanding Agile – as I found out at a recent project management event being run by Hemsley Fraser in London.
The concept is simple – bite sized project management learning (in this day session that included stakeholder management, risk management, networking for success, virtual working) – hour-long sessions that covered different areas of project management – all ideal for those who are new to project management or have a couple of years experience. They’ll be running sessions in the future which you can check out – the next one in the Spring.
The final session of the day was from Belinda Waldock – she’s also responsible for Agile on the Beach – which is a lovely concept based in Cornwall I heard about a few years ago.
Belinda’s session wasn’t so much about the basic concepts of Agile but more about the whole environment or culture that Agile needs in order to work.
There were a few insights I wanted to share in this article that I liked (you can see the whole sketch I did during the presentation below too for other insights too)
I loved this view.
“Stop trying to manage scope creep and embrace it instead”
It makes sense, we keep getting told that the world is changing fast so if a customer wants something adding in or doing something different because things have changed since the requirements were first discussed – why aren’t we giving the customer what they want.
If Agile is enabling customers to get what they want – and of course the customer is at the centre of everything we’re doing in projects – we need to rethink scope creep.
Here’s Pareto Again
The whole 80:20 thing – “80% of the effects come from 20% of the causes” so it’s about focusing on the 20% that will really deliver 80% of what the customer wants. (Pareto principle)
The Pareto Principle was used here to talk about the Minimum Viable Product – a term used in product development and heard a lot in Agile developments – which means “A minimum viable product has just those core features sufficient to deploy the product, and no more”. What’s the minimum we can do to deliver something of value.
I particularly liked Belinda’s way of simply demonstrating this – how much of MS Word do you actually use? It’ll probably be about 20% of what’s available but gives you 80% of what you need it to do.
Persevere or Pivot
Do you carry on with what you’re developing (persevere) or do you change what you’re doing (pivot).
This is an outcome to the retrospectives that happen in Agile developments. The retrospectives being the reflecting and learning part of the development cycle. We do something for a period of time (a sprint) then we stop and see where we are with it – look at what’s going well, what needs to happen next etc.
I liked persevere or pivot – two outcomes – it’s simple. Carry on with what we’re doing for the next cycle or sprint – or make the decision now to change what we’re doing.
Agile Gets Things Moving
From an organisation resource point of view – Agile development gets teams together quickly, to start producing stuff quicker.
There are no long periods of requirements development and planning – work that can sometimes take months with waterfall projects – instead people get on and start producing stuff.
The argument here is – do you feel OK with teams producing stuff without a clear idea about what stuff they should be developing? Does the trade-off work between time spent planning vs getting on and doing stuff in terms of a successful outcome?
One thing is clear throughout the session – Agile works very well for certain projects – product development for a start. I think we can all agree that if we have a team of resources who are up for working in this way and are preferably in the same location, Agile is a very attractive proposition for these types of projects.
What was also clear was the role of the Project Manager can still exist – it’s just that the teams have more empowerment about how they’re working and how they’re producing stuff. The role of the Project Manager is about supporting and helping the team – the levels of control have “loosened their belts” which makes sense – you’re either empowering people or you aren’t.
What still remains unclear – and is something which makes Agile still the centre of discussions and debates – is are people on projects ready, able and equipped to work in this way?
What does it really mean to be self-managing?
In persevere and pivot – who’s call is it to persevere or pivot? Does groupthink rear its head and have an influence?
Do we have the space to be Agile? We’ve spent so long in the corporate world getting rid of expensive real estate – do we have the physical space to work together again?
I suspect the downside to Agile is not about the framework it uses or the loose processes it incorporates, just like the traditional project methods before it – the downsides come from the people who use them and their ability to work together to get stuff done.