I’m currently on a break between job contracts, and preparing for interview questions. This has set me thinking about the dreaded interview question, “What is your greatest weakness?”.
To be honest, I haven’t been asked this question for a long time, but it has been a useful reflection point. Let me explain:
My greatest weakness: I can be too pragmatic
Being too pragmatic means that I sometimes accept less-than-perfect solutions to keep product delivery moving, where if I held out for a better fix, the problem might get resolved rather than leaving me stuck with an imperfect situation for longer.
Looking at this concept and turning it over in my head has been really interesting, because surely rather than a weakness, this is actually a strength?! I would rather be pragmatic and get things done, than idealistic and slow down delivery. Especially in Agile Software Delivery when the correct way to do things can be a matter of opinion anyway.
This is just another way of rephrasing the ” one size does NOT fit all” mantra when performing Agile Transformations. The methodology needs to be tailored to fit the situation, and rigidly following a plan for the sake of it should be avoided. I’d go further, however, and advocate to push this to the extreme and even mess with some of the sacred ceremonies and practices of Agile SDLC.
Pragmatism in action
Example 1
I have recently had someone outside of the team challenged me on the fact that my team rarely completed their iteration commitment and sometimes rolled over 50% of their commitment into the next iteration. This person wanted the team to commit to less work to resolve this problem. I can see the benefit of having a strong commitment from the team which is delivered say,75% of the time. However, to do this by slowing delivery down would be a mistake in my view.
The over commitment issue was caused by three factors –
- Requirements from the product team were created too close to the iteration start date and a technical solution wasn’t created before estimation
- The QA team were not sufficiently organised (resourced)
- Team members were reluctant to share tasks
If we only focus on the team overcommitting without addressing the root causes, delivery will slow down. It’s more effective to fix underlying issues first, then apply the Scrum framework as intended.
However, on the flip side, because we continued to ‘make do’ there was little incentive for the product owner, QA and developers to change.
We had a really tight customer delivery date, and we needed to make progress, and I had included these inefficiencies in the team pace within the scheduling plan. So, in this situation my pragmatism enabled things to get done where an idealistic mindset of “stick to the methodology” would have slowed down delivery.
I would rather be pragmatic and get things done than idealistic and slow down delivery
Example 2
I was a Scrum Master for a team where the requirements for an iteration from the product team were one line, actually just a title.
Did this cause issues? Yes. Development took longer, there was functionality missing, testers took longer to test, rework was required.
Did we make progress? Yes. And we learnt lots too, about what the product should do, what the testers needed, what the team needed.
If I held the “Ready for Dev” line and made the Product team go away and work out their exact requirements, we wouldn’t have got those learnings.
It took six months and a lot of follow-ups to get our tasks clearly defined. If I’d have rejected the poorly defined tasks in the first sprint, we could have resolved this in one month and sped up from month two, but it would have cost me goodwill with the product team at the same time.
So, rather than putting barriers up to this project at the beginning I made sure the team just rolled with it, and the project was delivered to the requirements.
On balance I think it is better to progress than stand firm.
How to run a pragmatic Agile project
In order to be pragmatic in your Agile process, pretty much everything is up for grabs in the debate about what is actually required. How about trying these:
- Daily Meetings – Don’t meet daily. If the team still deliver, meet once a month, or three times a day, or never! What ever helps your particular team get through their particular project.
- Sprint Planning – Don’t do planning as a team. Do it individually, or the product owner decides.
- Backlog grooming – Never do it if the tasks are simple or the product owner is always available to discuss the requirements.
Don’t get me wrong, I don’t recommend doing any of these! Some of them made me feel terrible for even writing them down, but if they work for the team and it means you deliver value to your users faster – do it!
However, I have 2 non-negotiables
- Inspect and Adapt – You have to do something with the team that reviews performance and generates actions to improve the team at the end of every iteration, otherwise how do you know things are working?
- Review progress with Stakeholders – You have to demonstrate work completed to the stakeholders otherwise how do you get feedback, learn and plan the next steps?
My actual greatest weakness?
I am colour blind. At school, I once coloured in the oceans on a map bright pink. I can still hear the teacher laughing – it was the ‘80s!
Have fun colouring outside the lines!
Pragmatic Agile 