Category Archives: Scrum

Why the Sprint Goal is not an Essential (Mandatory) Artifact

Posted on by

Guest Article written by Piyush Rahate – here’s a little something about him in his own words:

Inspired by the complexity surrounding us and by the fact that there could be simple solutions to everything, Piyush is working to create a significant difference in how software delivery is done; inspiring others and staying humble.

He is Professional Scrum Trainer and a SAFe Program Consultant; but before that he is an engineer with over 14 years of experience, who loves fixing code, writing poetry and clicking photographs.

******************************************************************

 

As many Professional Scrum Trainers have experienced, there is always a good discussion around the Sprint Goal. A similar discussion recently led me to address this not so well understood aspect. Of-course, I cannot say on behalf of Ken and Jeff, why they kept Sprint Goal out of the 11 essentials, I would like to present my thoughts on the same.

Before that, let us start by understanding what the Sprint Goal is, so that we all are on the same page.

Sprint Goal:

An objective that is crafted by the Scrum Team during the Sprint planning session, which provides an overarching guidance to the Scrum Team as to WHY they are investing their time, money and effort into the Sprint.

Sprint Goal

From the Scrum Guide:

The Sprint Goal is an objective set for the Sprint that can be met through the implementation of Product Backlog. It provides guidance to the Development Team on why it is building the Increment. It is created during the Sprint Planning meeting. The Sprint Goal gives the Development Team some flexibility regarding the functionality implemented within the Sprint. The selected Product Backlog items deliver one coherent function, which can be the Sprint Goal. The Sprint Goal can be any other coherence that causes the Development Team to work together rather than on separate initiatives.

 

Why the Sprint Goal is not an artifact among the 11 essentials:

Scrum, is not prescriptive and the Scrum Guide reflects the same philosophy. To start doing Scrum the 11 elements – 3 Roles, 3 Artifacts and 5 Events are good enough. Again, as Scrum thrives on self-organizing teams, allowing them to decide on what serves their purpose and maximizes the impact of Scrum in their context, is of more value than telling the teams what needs to be done.

The Scrum Guide has evolved over time. The earliest edition of the Scrum Guide was bit more prescriptive. It cites the chicken and pig story, talks about burndowns etc. As a result, there were some anti-patterns observed. Teams fell into the trap of following only things mentioned in Scrum Guide. The idea, however was never that. The idea was to create self-organizing teams that could find what works for them, inspect and adapt.

Sprint Goal has been an integral part of Sprint Planning since the beginning; the Scrum team crafts it and it is one of the outcomes of Sprint Planning. If we read through the Scrum Guide, Sprint Goal/Goal is mentioned about 37 times which is equal to number of mentions of Product Owner and is more than the number of mentions of Scrum Master. If we just look about for the specific word Sprint Goal it is mentioned more than Sprint Backlog itself. This clearly indicates and emphasizes that Sprint Goal is an integral part of the Scrum framework; however it is left for the Scrum Teams to discover its importance and use it to their advantage.

Not making it mandatory also allows teams to be flexible and decide whether it makes sense for them to have a Sprint Goal or not. What if, the Sprint Goal is made mandatory as an artifact and the teams start defining the scope of the sprint as a goal (I have seen many teams doing that) to be achieved to be in adherence to Scrum; what purpose would it solve?

Remember, Scrum is not about being prescriptive, it is about providing an environment where self-organizing teams can thrive and choose what works best for them. And for that matter, the 11 essentials are minimal but sufficient.

 

Conclusion:

Although,  the Sprint Goal is not defined as an artifact within the Scrum Guide it is an integral part of the Scrum framework. It provides an overarching objective for the Scrum Team which helps them to focus “WHY” is the team invested in the Sprint.

The only way to “Empower”​ someone

Posted on by

Time and again we hear professionals talk about empowering a being and how it’s the right way to go. How empowering a gender, race, team member or an organisation helps in improving accountability, ownership and peaceful collaboration. How this makes a robust community of respective subject matter to cohabit with shared goals.

Love the idea, it’s marvelous to see many people are embracing these great ideas. With that in mind, I asked handful of them –

How do you empower someone or a group?

 

Majority of the replies had a short pause, usually with a raised eyebrow, followed by a somewhat vague response like “By giving them chance to see the big picture, allowing them to contribute to the greater cause, authorising increased accountability/ownership and removing anything that blocks them”.

Seriously? Isn’t that what we should be doing anyway?

Technically anyone who is claiming to “Empower” someone is not really doing anything productive. Rather they are stopping their own unproductive interference. They are simply backing down from where they shouldn’t have been in the first place and they are taking credit while they do so. *Mind Blown*

Truth you came here to find:

The ONLY way to empower someone, is to stop dis-empowering them.

And stop taking credit while doing so. If we do, we are again not really giving them the credit they deserve while we steal the attention.

A person/group can be “Empowered”, only if they want to be!

The notion of empowering a being or a group also creates an illusion that it’s in our control. Sadly it isn’t. Fact it, if a person/group doesn’t want to be, we cannot really make them. It’s a personality trait where some like to do what they have been told.

What sort of person wouldn’t want to be empowered you ask?

  • “I did what I was asked, ask X who owns it now”. Silos – yes, some do love it and it’s all personal.
  • “Trust me I want to help but last time when I tried, your manager turned on me and requested me to mind my own business” – Fear of rejection.
  • “I told you this wouldn’t work. I can help you if you like? No? Alright then” – Ignorance of Skilled opinion over superiority.
  • “No, don’t want to get involved again. Last time I made a mistake and it affected my bonus. It was not even my domain of work.” – Outdated and demoralising KPIs

What can we do about it? Surely we can do something to Empower as Leaders

There are many ways obviously. I have found the following are good enough to start with –

  • Give them an achievable goal and back off. Support and Serve. Delegate and show trust. Allow failure that can be reversed. Make sure they understand they failed and ask them what they learned from it. REPEAT.
  • Find out what the impediments are and why can’t they remove it themselves. Let them try. If they ask for help, without passing a judgement first sort it out. Revisit on how much more we can/should do to remove the blockers in future. REPEAT.
  • Tailor our KPIs based on Team goals over individual performances. If we really care, let peer pressure handle it and monitor how are they performing as a team.

 

And yes, we should stop empowering people or tell ourselves that we can somehow.

As leaders, create a sustainable culture where people can Empower themselves.

“Agile”​ in Scrum​ context – It’s not what you think it is!

Featured | Posted by

Almost everyone within a software industry must have heard about “Agile” or “Scrum” or both on every project management context. People often use them interchangeably to refer to something that matches with their confirmation bias. It’s appalling how both are misinterpreted, tailored to avoid change and lied about. It causes irreversible damage to a company’s growth, revenue and prosperity guided by employees who may have no idea what “Agile” and “Scrum” actually stands for.

Few common misinterpretations of “Agile Scrum”

  1. Scrum will make you Agile
  2. If you want to do Agile, start with Scrum
  3. Scrum is a great training wheel to become Agile
  4. Scrum is a branch of Agile Project Management

Each of these misinterpretations will be explained later in this article. Feel free to scroll down to that section, after all it’s part of your daily social media read. Although I would strongly suggest you read the following material before that.

Scrum isn’t about “Agile”

If you believe in Shu Ha Ri way of learning, please do the following as your “Shu” step –

  1. Open the following PDF online (No it’s not a phishing link, it’s the Scrum Guide)
  2. Search the word “Agile/agile/AGILE” within it.
  3. Note down the number of times it appear in the PDF.
0

The number of time it appears here = The amount of truth you have been exposed to when you first heard about “Agile” in your career.

Now, search for “Goal” in the same document. If there’s no new version of this live document since I started writing this article, “Goal” should appear 37 times.

0 (1)

Scrum is about setting a Goal which is the base of every discussion, development and mechanics to achieve it in a time box, Sprint. Then we inspect and adapt the goal.

If that makes us “Agile” – it’s simply a useful byproduct. It’s not the intent and reason why a lot of teams fail in establishing basic agile mindset/attitude within a Scrum implementation. They are simply chasing the wrong intent. Failing that they end up blaming Scrum and Agile. It’s doing more harm than good.

Agile (noun) vs Agility (noun) vs Agile (adjective)

This may sound like “Old shit rehashed”. In fact it is, but with a twist. It has been mentioned, told and explained many time by many professionals in several occasions. Feel free to scroll down to the next section if you heard this before.

Agile (noun) – Usually refers to the Manifesto for Agile Software Development. These are a selection of carefully worded statements which radiate Simplicity during collaboration.

Agility (noun) – Refers to the true essence of the above, it’s values and principles. This is misinterpreted often, as we cannot measure this by numbers or metrics. Can you measure your principles and values?

Agile (adjective) – This is misinterpreted in way many cases and by far the most useful way we should approach a solution. To be agile doesn’t mean “fast”. It’s about being “adaptable” on our approach to achieve a focused goal with no set rules, practices or methods. Turn when you need to, where you need to and how you need to – but focus on the valuable outcome.

Can Scrum be the way to Agility?

Sure. Scrum can be one of the ways but being a framework, it doesn’t include any method, practice or techniques. This is on purpose – because, again, it’s not about making us Agile.

Scrum is about complex product development where, at most part, the output is unknown but have a possible outcome as a goal.

“Complex” can be subjective. Easiest way to know when to use Scrum is asking this question to yourself – “Do we know what we are building?“.

If No, you definitely need Scrum. Forget about being agile, you have no idea what you really want to build. You have a clear “Why” in mind and you need to get there by any mean possible.

If Yes, there are 2 ways to interpret –

First – may be you think you know but you don’t. How sure are you?

Second – may be you are right. Then you probably don’t need Scrum.

Clarifying the Misinterpretations

1) Scrum will make you Agile

You can follow Scrum by book, exactly as it says on the Scrum Guide. You can have dedicated roles as it suggests. It is still possible to be not be agile. Here’s how the Scrum roles can be misused –

Product Owner (PO) – Starts dictating the product roadmap without consulting anyone. Becoming a Stakeholder (not customer) proxy with no real input based on data or own analysis.

Scrum Master (SM) – Starts managing people rather than the flow of work, thinks of him/her as the team’s manager and collect stats on how many hours the DTMs are working.

Development Team Member (DTM) – Starts dictating the technical aspects way before the intended value is established, disregarding PO or SM’s suggestions and creating an anarchy which leads to well engineered product which no one will ever use.

2) If you want to do Agile, start with Scrum

If doing “Agile” is the goal, the person needs to read the Manifesto few more times before saying those words. You cannot do “Beautiful” or “Nervous” or “Green” or “Strong” or “Happy” or “Surprised” or “Spicy” – wait where was I? Of yes, stop doing things which are descriptions. And if you are doing the nouns, I would be very concerned on a very different level.

“You know” – No, I don’t know. Unless we start using the correct semantics, we should stop discussing anything around Agile or Scrum.

3) Scrum is a great training wheel to become Agile

This is by far the most sophisticated way to sell Scrum. Selling is not bad, although selling a solution that doesn’t help remove the core problem is wrong.

I am a servant leader and I am freaking proud to be one. Although, I would never recommend anyone to implement Scrum just because they want to become Agile. Everyone should suggest a solution which is appropriate to the problem. You call yourself a Scrum Master or Agile Coach or Enterprise Superstar.. just don’t sell a hammer when they need a scissor.

Most companies we work for do know what they want as they have a huge requirements pool (1000 Tickets on a Jira backlog) already setup. They intend to break them down in chunks as “Sprints” and call it a feedback cycle. If they have everything prepared, may be a well governed Waterfall is a better choice isn’t it? Why bother with the names like Scrum or Agile or similar?

If you want to become Agile, focus on value and the value stream.

4) Scrum is a branch of Agile Project Management

No comments, except, on behalf of all true Agile practitioners –

Lead time & Flow efficiency measures a system’s Efficiency – Not Effectiveness

Featured | Posted by

X: We have to improve our Flow efficiency & Lead time.

Me: How come? Our Flow efficiency is around 50% which is actually better than most development teams.

X: Yes it’s above average but still not reflecting on the revenue though. We need to improve it even more, some even have 80% which I think we need.

Me: I have my doubts. We have made the system as lean as we could. If we push too hard, we will start hitting bottlenecks. Also we are not a manufacturing company so we have no choice but to keep experimenting new features.

Neither of us above were totally wrong. We simply had different opinions towards what was important for the business under discussion. “Business” – what kind and why it exists is very important here. Not all businesses can achieve high flow efficiency as they have to experiment too much and fail many times to understand the end user’s real problem. Value is what we want to focus on. To make sense of this article let me define what efficient and effective means to me:

Efficient – Moving from A to B within a predictable system and defined route, repeatedly. (Manufacturing)

Effective – Starting from A with no idea where B is and identifying several options to get to B or C or D. (Development)

My views comes directly from few known facts –

“Nothing is less productive than to make more efficient what should not be done at all” – Peter Drucker

“Simplicity–the art of maximizing the amount of work not done–is essential” – Agile Manifesto, Principle #10

An Efficient system (simplified)

This (below image) is what we can think of when we talk about an efficient lean system with reduced waste. Vast majority of the system is being used to work with a good Flow efficiency of around 80%.

There are few prerequisites that we often ignore. The most important one is “Predictable” work flow. We can plan to remove every muda (waste) we find and can end up in an extremely lean and efficient work flow that produces a desired output with perfection. Problem with that is, we assume the same Lean principle applies to every knowledge work which cannot be predicted at all. All we can really do is to project a trend based on historical data and come up with an average, which again may or may not be useful.

If the Business is about making predictable product with TQM and adherence towards a specific output repeatedly, higher Flow efficiency is a must. This is hence necessary for every manufacturing business where development (R&D) phases usually exist out of the structured and well defined lean system to meet the high demand of a predictable product.

A sudo-Effective system (simplified)

sudo-Effective: An efficiency focused system confused as an effective one while trying to use Flow efficiency & Lead time as their KPI.

This (below image) is what we can think of when we talk about a sudo-effective & partially adaptive system. Vast majority of the system is NOT being used to work with a rather poor Flow efficiency of around 20%.

In the above example, the Discovery & Prioritisation is shown as a separate phase which is true for many companies. A request from a customer or stakeholder stays on a product backlog for quite a long time without getting prioritised for months. When it eventually gets prioritised, it might be too late and may have lost it’s intended value completely. I am pretty sure a majority will relate to this example as this is the naked truth of majority of so-called “Agile” departments of an organisation.

An Effective system (simplified)

This (below image) is what we can think of when we talk about a truly effective & highly adaptive (agile) system. Vast majority of the system is being used to work but in extremely unpredictable fashion with overlapping development phases. The majority of the system is focused on doing the “right thing” and frantically experimenting all possible outcomes and collecting feedback on the go.

Are we building the right product?

This question is being asked, as the business regularly faces the challenge of changing requirements heavily influenced by continuously improving competition and their new products. It’s neither predictable nor has an option to make it lean by removing waste. In fact, it is full of wastes that the system is actively creating to learn what doesn’t work.

The Flow efficiency can be very hard to establish in such systems making the KPI irrelevant in this case.. working prototypes are the true measure of agility. We shouldn’t measure Flow efficiency when true effectiveness has to be achieved.

Agility is about continuous adaptation, Lean is about perfecting an adaptation. Providing value is a common goal for both, in very different context.

Some recently posted wisdom from influential & respected community members around it:

Value – Define what it means for the Business in context!

Be it Lean or Agile principles, both defines Value as end user consumable products/services. Who the end user is, defines what the Value might be and therefore what principles to follow to provide that value.

Few example of industries and recommended focus

 

Product Development aka R&D – Based on current generation’s need we have seen time and again that being adaptive is what make or break it. If a development team focuses too much on lean principles to become super efficient, there is a good chance that they forget to consider whether they are really working on the highest priority value according to the customer’s need. They start focusing on processes, tools and intricate mechanics with a partial or complete disregard of the “WHY”.

Hence the recommended focus of such teams and organisation should be to follow Agile principles to become more effective while keeping the necessary efficiency which supports it.

Service Delivery – Any company responsible to provide a part of the system usually 3rd party service providers. consultancies, call centers etc. you name it. Every such industry have very different end users with very specific definition of Value.

For simplicity of explaining, say you are part of an IT consultancy who is responsible to migrate all data from a decade old infrastructure to AWS. There’s a good possibility that the steps necessary for the most part is a mix of finding unknowns and known facts about the migration. End user is the company paying for the service to get it done, a consultancy has quoted a price & date to make it happen. For the consultancy the value hence is defined as “Provide solution by <date> with a £x budget all inclusive.”

To Conclude

There is no right or wrong, just a variable business context and how we define “Value” as.

Sometimes we want to focus on efficiency and sometimes we focus on high effectiveness over efficiency. If you are measuring Lead time or Flow efficiency for a development team, be prepared to get a useless KPI which neither helps you nor the team developing. Measure what is needed to achieve the value rather than trying to fit the same principles everywhere. A simple rule to remember where to apply –

1) When we hear “development” assume obvious complexity, unknowns, learning and adaptation where Lead and Cycle time is very hard to establish.. and at best can be totally wrong. Be agile.

2) When we hear “production/manufacturing” assume predictable known steps with defined output at mass where Lead & Cycle time are extremely useful KPIs. Be lean.

Justice League has a Single Point of Failure – Does your team have one too?

Posted on by

**Spoiler Alert** – If you haven’t seen the 2017 Justice League movie, reading after the below introduction may spoil it for you. It’s important to go deeper in the story to explain the intended purpose of this article.

Zack Snyder directed Justice League, released last year, is a great example on my team building workshops. Although, IMHO, this is not the best DC movie ever created in terms of mediocre script, predictable plot, over-hyped and overwhelming special effects. My complain is more towards the movie itself not the team. Only good part of this movie is, the absence of Superman – the humble man of steel. Usually, his presence is counter productive in strategic situations that need true leadership like Batman & Wonder Woman.

Not everything needs power, sometimes it’s about tuning down, so your team members can rise.

Most important fact we can learn from this movie – what happens when your most powerful member of the team aka Superman, gets “Hit by a Truck” or in this case already dead. By the way, this was apparently the 2nd most expensive movie ever made.

Single Point of Failure? – Guess What!

Detailed plot can be found here but I will only highlight the part that is relevant to our topic of discussion today.

Relevant Plot – The movie only shines for like 5mins when a zero memory Superman is resurrected. A small mistake by Cyborg’s reactive weapon angers the man of steel and the wrath of Superman begins when he alone dominates every member of the league and almost killed Batman with a pinch. Thankfully the contingency plan pre-calculated by Batman saved his own puny human arse.

Enjoy the moment below:

We all have seen a Superman in most teams; without a plan B when they turn hostile.

Let’s give you an example that might relate to our profession.

Think of a person in your software development team (or any team) – an exceptional developer with a plethora of domain knowledge is being “Productive” with his/her headphones on. He/she might also be known as a “life saver”. You ask a question and most probably get all your answers and your problem is sorted. The rest of the equally competent new team members have potential but lacks the domain knowledge collected over years. But it was never shared neither there are any documentation anywhere. The superhero believes he/she is too busy and someone else should do the useless documentation while he/she can “Do Some Real Work”.

Now imagine the below 2 scenarios when that person becomes the bottleneck –

1) When the Superman is “Hit by a Truck”

Now, one unfortunate day that awesome developer calls in sick before a product launch. After hearing that, if you don’t feel a chilling flow of blood running down your vein right now, possibly in the stomach, I have no words for you. It’s hard to even write about it as an example, as it’s so common. The next thing we know, the product launch is cancelled, stakeholders are furious and our lives are hell.

So what do we do? We call that same person, apologise for calling when he/she is actually unable to stand, requests him/her to connect to VPN and troubleshoot the issue. In most cases, it doesn’t get resolved and we are all in a over-salted pickle topped with habanero bits. Like what happened in the above movie. Superman is dead, so the world is doomed as we were relying on him too much the whole time and never thought of having a Justice league until the shit hits the fan.

2) When the Superman becomes hostile

The person isn’t sick but need a raise 😉 for obvious reasons. Performance review time –

Manager: As you know we didn’t make any profit last year, so no one is getting any raise this time. Not even me.

Superman: It’s not fair. I have been working hard, more than anyone else in the team and usually I am the only one on call even though I never get paid for those live issue troubleshootings. No one else seems to do that neither are capable to do it.

Manager: Well, yes that is true but you never wanted to document anything, pair with them or taught them how to do it either when they asked for it. I understand you are over stressed sometimes but it is because of the unshared knowledge.

Superman: When do you expect me to do it? It’s a 5mins thing when I do it, it’s 1hr when someone else do it. Are you saying you rather wait for an hour to get a live issue looked at or even fixed? Anyway, I will need that raise unless I will have no choice but to leave. I always help out when the company needs it, I deserve it.

Can you blame the superman in this case? Especially when he/she has a point.

Superman will never ask for help !

What we should ask ourselves:

Why wait for that moment to come? Why not be ready for a moment like this?

If you have been to this situation, the first thing you ask – “Only if we had someone who knew a little bit of this person’s work. Doesn’t have to be as efficient but to do the job in anyway, a quick fix” We have all been there and pulled our hair out.

The trick is to not tolerate a superman like the above. It may sound weird, why would anyone not want a superman in the team? Well a Superman is only necessary for short term benefits and when we keep repeating the behaviour and tolerate a dysfunction, no long term benefit can come out of it. Also it’s not really good for the Superman in the team which the person may never realise.

The reason a person tries to be/stay a Superman is to create a bottleneck so his/her presence is felt for personal gain, like the salary negotiations or promotions. There are some who don’t do it on purpose though, they simply are not team players and would rather do anything asked without even thinking if it has any business value at all. These members hinders creativeness among other team members who are equally capable but have their hands tied. On above scenario 1, no one wants to work and that’s their punishment if they are doing it on purpose.

In some cases, the person who is a bottleneck may be an introvert or very shy. it’s very common among developers due to the profession. Hence they may not even ask for help even if they know they need, making themselves overstretched in daily tasks. Eventually on one day this shy person won’t be able to cope and simple resign.

 

Create your Justice League before the Superman dies or turn hostile. Shared skills & knowledge are the key to crisis management.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

Posted on by

When we talk about Servant Leadership the first role that comes into our mind is the Scrum Master. It is the first role ever, of it’s kind, which was created specifically for the sole purpose to “Serve”. Only if Robert K. Greenleaf was alive until 1998, he would be the happiest person to know that his whole life’s contribution has an effect on a dedicated leadership role; it changed everything especially the way we see management and leadership now-a-days. Then we started seeing the rise of “Agile Coaches” which was created, I guess, to differentiate that servant leadership exists outside Scrum as well in a equally dedicated role.

But this article is not about the Scrum Masters/Agile Coaches or their unbiased contribution to their teams. Today we are focusing on the role Product Owner (PO); the role which is often seen as biased towards “more and more work in less time”. There’s a reason.

According to the Scrum guide – “The Product Owner is responsible for maximizing the value of the product resulting from work of the Development Team”.

This is often misunderstood by new POs and their organisation, where they believe it means “maximising the output from a development team”. It is not the same and that subtle difference decides if the person is a traditional Product Manager or a Scrum Product Owner. PO serves the development team (explained later) and ofcourse their job is to serve the organisation, but in very different ways.

For a Product Owner, Maximising Value ≠ Maximising Output

A typical Product Owner will prioritise and try to add work items in the Sprint backlog which may not be part of the Sprint Goal. There is nothing wrong with it, sometimes we have to, if we have higher capacity and we need a live bug fixed asap. As long as majority of the work relates to the Goal, we have a focused sprint.

Things start to become gloomy when a PO knows the true capacity of their development team but still try to negotiate to add that “small” Story, in case someone is free. That’s the biased “leader-first” side which overpowers the unbiased “servant-first” side, so that extra work can be shown as an achievement to a stakeholder who is constantly chasing. Typical phrase on these situations is like “If we manage to finish that too, we will make someone very happy when they are not even expecting it”. That’s a trap.

If it gets done, the stakeholder will assume it is not a one time favour and they can pressure anytime to get more work out of the development team, by going through the PO. If it doesn’t get done and the stakeholder finds out they will most probably be annoyed and blame the development team. Both have side effects and not a very good one. Both fails to manage expectations. On top of that, the development team will now feel guilty when it was clearly not their fault.

The trick is to align, orchestrate and trying to link the work items in a way which have a combined value to someone.

Value doesn’t always have to be for the end user. It can be for an internal stakeholder, operational requirements, legislation or something else. PO should fish for opportunities to “maximise the value” from any form of output. PO should known the capacity of the team from empirical evidence collected on past sprints.

Skill levels play a huge role in slowing down or speeding up the outputs, based on the team we are working with. If we have new team members, expecting same speed of development is futile. Know your team, know the people. If they are new and are on the learning phase, plan more Spikes and let them explore bugs raised which will help them learn the domain. It will also help the more experienced members on those domains, by collecting keys facts that can be used on next sprint. It helps everyone to keep the morale up and have a long term benefit.

Product Owner “Serve” the Development Team

As a Product Owner, we have to choose a “leader-first” bias as we are accountable for the product’s success but we can also serve when it matters the most.

  • While facilitating the refinement activity, PO focuses on the business value while keeping the known format of “must have”, “nice to have” and “can live without” in their head but never writes them down for negotiation purposes.
  • While fleshing out more and more acceptance criterion from all development team members, PO becomes their scribe and does the admin work which liberates the members who needs to think than focusing on where to add a comma or semicolon.
  • If a PO have to be part of the discussion, they ask for help from the Scrum Master to do the same. This is where negotiation begins but with a “servant-first” mindset which is backed by empirical evidence or UX decisions.
  • After Sprint starts following the planning session, PO serves the development team by being present on all the daily scrums to answer any query they may have. When they do this, they serve. Taking status updates is not a service; it’s an anti-pattern.
  • During the work day, PO again serves the team by simply being accessible to them by any mean. Just being there makes all the difference.
  • PO serves by not chasing the team members to create a sense of urgency.
  • PO serves by creating a big picture for each work and explain how it impacts the end users. Creating enthusiasm and showing the purpose is one of the most underrated skill.
  • PO serves them by showing trust on their commitment and being patient even in the most stressful times.

Product Owners are torn between being the “Leader-first” and the “Servant-first”

From above we can see where the true confusion lies and why POs may be torn between two contradictory ways of leadership. PO is accountable for the product success, a single emotional bias can affect the potential ROI. Unless they lead and focus on getting them done fast, it might seem impossible to even finish in time as every work has a cost of delay. We cannot have the “Servant-first” approach all the time with the development team as we are serving an even bigger team, the organisation.

When it’s possible POs can show the “servant-first” side but is it real? May be, may be not. Usually one person cannot be both.

POs will always remain biased towards the product, the goals and faster delivery. Reason why we have Scrum Masters to neutralise that dominance by guarding the development team when needed. Every role on Scrum has a purpose of why they are dedicated, this is one of many.

Are you a Product Owner, what’s your take?

Do you Lead first or Serve first?

Let us know.