A project management team’s new hire asked her onboarding supervisor a brilliant question – Why?
“Why?” is always a great question, this one was particularly illuminating.
The trainer was explaining the team’s fairly unique binary approach to scrum sprints, which effectively boils down to them having two duration categories – A) one week long and B) three weeks long.
The new hire found this interesting and enquired about the reason behind this approach. In her last job, length and number of sprints would be decided at a goal setting meeting, a twelve-week scrum project could have 15–20 Scrum sprints, which could be as short as a handful of days and as long as a month.
So, “Why?” seemed a reasonable question but it was met with either blank expressions or an unsatisfactory explanation. The trainer did not know, nobody on the team could answer either.
Perhaps worse, it wasn’t just that everyone failed to articulate why the team had selected their sprint game plan, some were trying to explain the purpose of sprints within a wider context – i.e. why do we as a profession and scrum projects have sprints at all – and they were struggling. They had plenty of know-how but limited know-why!!
At the time I just chalked this up as an interesting anecdote and one that might make for a blog one day. Then a newsletter from ProjectManagement.com landed in my inbox … and one day became today! It looks like this wasn’t a one-off happening.
IS LESS KNOW-WHY LIMITING SUCCESS?
In a brilliant ProjectManagement.com post titled “Understanding Why Agile Is the Way it Is”, Andy Jordan writes, “There are … doubtless a lot of those people who learned how to work in an agile environment … without ever considering why things were done in a certain way. To them, it’s just another approach that they learned.”
That’s potentially what happened in the story I just shared. The project leaders who created the organisation’s scrum template eventually moved on, their modus operandi got passed down the ‘generations’ without anyone ever asking or explaining why, so the current talent were just following recognised, received protocols – without really understanding the reasoning behind them.
The current team are all between 25 and 35, it’s been over 20 years since the Agile ‘Software Development’ Manifesto emerged from that meeting at in the Wasatch mountains of Utah. Do practitioners need to be versed in the Twelve Principles of Agile Software to the extent that the pioneers at The Lodge at Snowbird ski resort were? The environment that agile operates in changes constantly – is the Agile Manifesto even still relevant? You know, I really think it is and, what’s more, it’s probably more important than ever that we all understand the “why” of a process, as much as the “how” to get the most from applying it.
I’m not alone!
Writing for ProjectManagement.com, Andy Jordan says, “I am sure that those individuals are more than capable of doing their jobs, but without the context of understanding why things are done in a certain way, I believe that their ability to succeed is limited.”
THE PIPING HOT PIZZA PARADIGM
Returning to the example I opened with, for added context, this organisation with its binary sprint approach had identified some years ago that, despite considering each project on its individual merits, most sprints would end up being planned to last a week or three weeks. So, distilling this decision down to a choice between A or B accelerated the pre-planning/planning stage. This became how things were done, personnel changed as years went by, but no one joining the team ever asked whether this was still the best approach.
Andy goes further in his post, “Someone may well learn that in their organization, sprints are two weeks long and always result in something that can be handed off to the customer for feedback. Without understanding why, they may have no idea which is more important—the two weeks, or the customer deliverable. If they have a background in traditional project management, they are more likely to think that the two weeks is the important part because they are used to set schedules, deadlines, milestones, etc.”
That’s interesting!
Proof reading this for me, a PM friend Steve said, “It would be like reading the cooking instructions on a frozen pizza, sticking it in the oven for 15 minutes, but not checking the food was piping hot before serving it up! The ‘why’ is the hot meal, that’s the only paradigm! You wouldn’t say ‘it can’t be stone cold in the middle, it cooked for the time suggested on the packaging’ – no one wants half melted mozzarella!”
In Scrum sprints, it isn’t the boxed time either, but about delivering better solutions to clients and end-users and the value of the deliverable.
The lesson here is wider than Agile and Scrum sprints and piping hot pizza though.
BEYOND AGILE
I wonder if there are other parts of what we do that would benefit from a closer and more regular look at our “why”.
I asked a handful of Project Management professionals if there were any unconscious or subconscious “whys”, elephants in the room, and general habits that they’d benefit from taking a fresh look at, here’s what came back:
Is the project management software that you use still the best fit for your needs?
Are your stakeholder engagement strategies and team motivational approaches the right ones for your current stakeholders and team?
When there’s scope creep – is it the stakeholder’s bad (cheeky requests) or the project team’s fault (inadequate scoping)? And is it a problem or an opportunity?
Does the team possess the necessary skills to tackle the problem at hand, the current project, the changing project environment?
Are your project risk management protocols fit for identifying and mitigating today’s risks? Is your contingency planning adequate and current for what could cause your project to spiral out of control? (The PM who shared this admitted that their established risk planning didn’t sufficiently factor in the potential for rapidly rising costs – that would be first on the sheet if you started a risk identification and mitigation plan from scratch now, wouldn’t it?!)
Then there’s the oldest why of them all – the Waterfall vs Agile debate. There are libraries of articles about which methodology is best – so let’s not go there – but why are you using the one that you do? Is it the best for you and your projects now – or just the one you always default to? Almost half the PMs I messaged said they should probably give processes and methodology more thought than they do!
Finally, one PM told me he regularly reminds himself why he wanted to be a project manager in the first place. Checking in with his younger self re-motivates him even on the toughest of days! I love this!!
PRACTICING WHAT WE PREACH – PROJECT MANAGEMENT AS A SERVICE
At Stoneseed it’s a conversation that we’re used to having with our clients.
Stoneseed’s Project Management as a Service (PMaaS) gives project teams access to our Project Management and Technical Professionals, from strategy to programme and project delivery, including Project Managers, Business Analysts, Technical Advisory and PMO experts.
PMaaS is a product that is very much driven by customer and project need. It’s important that we understand that need and provide the right talent to meet it. Occasionally, that means challenging ours or our client’s perception of need.
Sometimes, a client will call asking for a Project Manager (or whatever resource they usually take via our innovative on-demand resource model) but, after getting to really understand their resourcing requirements, it becomes apparent that another resource would suit their needs better – a Business Analyst, for example. To not gently challenge the client’s interpretation and perception would feel out of kilter with our customer-first ethos, a pillar that has always underpinned everything we do.
Other times, clients have requested an onsite resource, whereas their requirement would benefit from a more rapid response and a remote resource. All Stoneseed’s PMaaS services are available onsite or remote, by really understanding the client’s why, we can advise the best how!
It’s more important than ever that we continue to check that our recommendations are sound. Our clients’ results and Stoneseed’s reputation depend on it.
IT’S WISE TO KNOW YOUR WHYS
Reflecting on all of this, perhaps the overall takeaway is that there’s great benefit in occasionally checking in on our whys. From why we do things the way we do (to sharpen our practices and get the most from processes) to the reason why we chose the profession in the first place (to rekindle our passion for it), there’s rarely a downside to measuring our habitual whys against a constantly changing landscape.
Conclusion: Run today’s eyes over yesterday’s whys to reach tomorrow’s highs! I’ll get my coat!
Actually, better still, I’ll go check on that pizza.
Find out more about Project Management as a Service from Stoneseed