I have been working in software for 8 years and I have held a number of positions including Frontend Developer, Backend Developer, Scrum Master, Product Owner, and more recently I have adopted the role of Delivery Lead. It isn’t a commonly seen role in software development, not a “sexy” title worth its weight in gold according to the Agile Alliance, but it is a more accurate depiction of what I do, and it is effective.
I started as many do on the software development ladder as a junior developer. I watched and read and did, and repeated that process gradually improving. I observed as Agile and in particular Scrum became the key to solving all our problems as a provider of software development services. I will focus on Scrum in this article
Scrum brought with it these strange roles such as Scrum Master and Product Owner. I have never seen a true Product Owner, willing to make decisions or define requirements or decide priority, or even be available to the team when needed. I always understood that the Scrum team was a combined unit that worked together to ensure the “ball moved up the pitch and across the goal line”, and any kink or omission in the chain would lead to the teams downfall. I’ve seen projects succeed and fail regardless of the competence (or existence) of a product owner, and in most cases the Product Owner is pushed into the role rather than chooses it of their own free will.
Perhaps it is the term ‘owner’ that intimidates people, after all whatever is delivered becomes the responsibility of the Product Owner. Frankly the role is not hard, you just make decisions based on the information you have at the given time, and each sprint you assess and adapt you decisions where needed to better fit the vision based on the information you have at the given time. Maybe the problem isn’t in the person doing the role and instead is the misunderstood opinion of those higher up that shape the role into something to be feared rather than embrace.
That brings me to the Scrum Master, apparently the most valuable role in the Scrum team at least according to the number of articles and videos about the importance and value of the role. One of the key responsibilities of a Scrum Master is to “Protect the team”, apparently this undeniably successful concept that has not, I repeat NOT, been stolen and rebranded in an effort to make as much money from teaching people how to deliver products in the new modern landscape of software development needs protecting. Protect it from who?
Protect your team from those that don’t truly understand Agile, those that have operated in business for years, decades and in some cases centuries, somehow growing and expanding before, during, and after the birth of Agile and the formative years. Francis Bacon, Shewhart, Deming, Takeuchi, and Nonaka must be looking down and wondering how this concept has grown through their respective careers, and turned into a cult. Sweeping through businesses the world, guaranteeing results so long as you follow the rules to the letter, and yet somehow there needs to be a protector in every team.
Time To Adapt The Process
At the root of succeeding in Agile is the ability to adapt, at the end of a sprint you stand back and look at what you have produced and how you have produced it, and you make changes to adapt. Why must the process that encourages adaptability follow fixed rules masquerading as loose guidelines?
Free yourself of the Product Owner and replace that role with the Decider role. This person is responsible for making decisions in a timely fashion based on the information they have at the given time. Hindsight is a beautiful thing, you know the outcome and you can make the judgements understanding the impacts after they have happened. The Decider is immune from persecution should their past decision turn out to be off in hindsight. Team members are encouraged to challenge a decision and ask questions, test the defences and work as a team to ensure the decision is a robust decision.
Scrum Master – protect nothing. Let all challenges come and test the tolerance of the process, remove yourself from the echo chamber and hear reasoned arguments from those that may hold the key to the next evolution in this improvable concept.
When you find yourself on the side of majority, it is time to pause and reflect.
I have since rebranded myself as a Delivery Lead (hey, if the Agile Alliance can brand themselves, why can’t I?). My job is to get the product delivered on time, in budget and within scope. This is a fundamental of business, ensure you bring in more money than goes out. People pay happily when you deliver.
I know the “budget is tight”, and there is “no time”, and the “scope is creeping”. The budget has been decided, the timeframe has been plucked out of thin air, and the client expectations need to be managed if you want to protect the scope of the statement of work. Be willing to have the hard conversations and your team, your boss, and eventually your client will thank you. Pushing back on scope creep is not about fighting against your client, it is about guiding your client through the period to ensure what was promised gets delivered.