A most curious interview
Once, quite a while ago, I was referred by a dear friend of mine for an interview for a Scrum Master role in a renown company in Sofia. She warned me in advance, “Hey, Plamen, whatever you do, don’t say you’ve gotten the PMP certification. Better still, remove it from your resume…”. I was very confused – after all, PMP was the most recognized project management certification in the world, right? How would it do me any harm at an interview for a somewhat relevant position? My friend continued, “…they are all Scrum Masters, you know, and I’ve heard them mocking people who have the PMP certification all the time. Please, take my advice, don’t be too vocal about it and you’ll be alright! ”.
At that point, I must had already made my decision that I was probably not going to work for a company whose employees presumably cannot grasp the connection between project management and Scrum. But I decided to go and do the interview anyway – I was more interested than ever to see if these people are truly worth their salt.
A couple of days later I was welcomed in a pleasant minimalist meeting room, where, not one but four (a red flag, I know) Scrum Masters from the company already waited for me. After the usual smalltalk and introductions, they started with their first question: “Plamen, tell us about a recent achievement of yours. Something you’re proud of?”. It was written in the sky… I could not help it… “Certifying as a PMP”, I said clearly. Their faces changed, their eyes opened wide and we continued the interview in a different albeit still friendly tone – them asking their hardest questions, and me doing my best to give the best answers. And I did answer to each and every question confidently and in detail, with plenty of reference to my working experience at the time. Mind you, to this day I still believe this was my best interview performance ever.
Then, at the end, it was my turn to ask some questions. I asked some typical ones about issues that most Scrum implementations struggle to solve, due to lack of knowledge and experience, and I asked them to share their current approach. And, lo and behold, they were simply unable to answer. Awkward silence ensued more than once. I swear I could hear crickets at some point… They were pretty interested in the answers, though – I could see in their eyes that they knew the pain points first hand. The solutions they shared were rather naïve and flawed and they knew it – it was clear to me they were just kicking the can down the road.
A couple of minutes after I had left the building, I got a call from their HR. They offered me the job and asked me to get back and collect an offer letter right away!
I rejected politely and headed home.
The Relation between Scrum and Traditional Project Management
I firmly believe that all methodologies, no matter how agile they might be, raise against the same challenges. In the end, it is all about communication, about establishing some work rhythm, about managing expectations, ownership, visibility, commitments and getting things done. No matter which methodology you choose, you are going to run in these types of problems and you’ll need to find a solution that works for your organization. Traditional waterfall is not a panacea and neither is Agile. None of them solve bad culture.
Those who’ve studied traditional project management know that the PMBOK (Project Management Body of Knowledge) talks about techniques that are in fact, quite agile, way before agile was cool and popular. Some of the interesting techniques follow. See if you can guess their Scrum (since Scrum is the most popular Agile representative) counterparts:
- Progressive Elaboration – “Progressive elaboration involves continuously improving and detailing a plan as more detailed and specific information and more accurate estimates become available. Progressive elaboration allows a project management team to define work and manage it to a greater level of detail as the project evolves.“ (from projectmanagement.com)
- Iterations – these don’t need introduction. I’ll just leave them here.
- Rolling Wave Planning – “Rolling Wave Planning is the process of project planning in waves as the project proceeds and later details become clearer. Work to be done in the near term is based on high level assumptions; also, high level milestones are set. As the project progresses, the risks, assumptions, and milestones originally identified become more defined and reliable.” (from projectmanagement.com)
The new edition of the PMBOK even dedicates a whole new chapter to Agile, but it was all in there for decades for those who read the thing carefully.
But finding “who did it first” is not the point, because as said earlier every methodology has to deal with the same issues. Getting deeper into risk management, stakeholder management, communication, planning, measuring can only benefit a Scrum Master who is serious about his or her job.
Traditional project management does offer a wealth of techniques and tools that could help and give a different perspective when things get real and you inevitably veer off the well-worn path of by-the-book Scrum. That being said, of course, one should still be careful to not turn into a directive and bureaucratic Scrum Master, which is a classic anti-pattern, but it was never exactly a good idea to become such a Project Manager either.
PMBOK tells about the Hybrid Approaches which combine techniques from different methodologies. Hybrid is what I’ve seen working best in most cases.
Imagine a couple of teams – one creating an API, and the other – the team of a customer, who in parallel, develop their business application that will heavily utilize this API. Both teams want to work with Scrum, but they’re over 20 people in total and when they try, everything becomes a mess. They cannot agree on sprint length, on rituals, on framework for scaling. Putting a traditional frame around the project makes everyone’s life easier. Procurement do their work and the project managers/scrum masters and their teams agree to milestones and overarching designs on both sides. Then everyone goes happily about their day, uses whatever methodology sails their boat and in the end they deliver the solution without stepping too much onto each-others’ shoes.
Now imagine a team that works with Scrum, but they want to organize and do a hackathon at some point. The hackathon becomes a mini-project that gets organized while the team continues to iterate. The mini-project has a mini-plan, an owner (who could be a team member), it’s own rhythm and reporting.
In my experience, it turns out that specialists always tend to meet in the middle – you either do waterfall on top, with iterations inside it during the execution, or you do Scrum and iterate, but then use techniques to improve ownership, planning and continuity between sprints for bigger initiatives and features.
This is why I believe the best Scrum Masters all have some project management background or at least good working knowledge of traditional project management.
So here is a heretic thought – Arguments between Agile and Traditional camps are just silly and they only show lack of understanding on both fronts. Project Management and Agile are the two sides of the same coin. They are not mutually exclusive – in fact, it’s quite the opposite – they often complement each other and they did for decades in well-managed projects. Getting to know both as a Scrum Master (or a Project Manager) is a very good idea… And no, Scrum is not dead, neither is any other approach of organizing software development work that delivers good results.