Product Owner and the Daily Stand-up

Should the Product Owner attend the Daily Stand-ups?

Everybody who has worked in a Scrum team would have an opinion about it.  The Scrum Guide tells us the following:

The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum.

This is interesting.  This is how I interpret it: If the Product Owner attends the Daily Scrum, they shouldn’t actively participate.  They should let the Development Team do their thing.

Personally, I don’t like such constraints.  I like those meetings where everybody present in the room is enthusiastic about the work the team is doing, has an opinion on things and is willing to participate.  But Stand-ups are different.  And I can see the wisdom in having the Product Owner not participate in the Daily Stand-up.

Here is why.

In many Scrum teams, I have observed that the Daily Stand-up turns into a status update meeting.  And that’s bad, specially in a setting where some members of the Development Team are external contractors.  The Product Owner really represents their client.  In their minds, the Daily Stand-up is about keeping the client informed on the progress of the project.  It becomes a daily ritual for them where they tell the client “Look, I am doing what you are paying me for.”

And when that happens, your Stand-ups become useless.

The objective of Daily Stand-up is to come up with a plan for the next 24 hours.  It is a plan that should increase the probability that the team will meet the Sprint goals.  Now, a Product Owner doesn’t get to tell the team how they should meet their objectives.  A Scrum team is self-organizing: they choose how best to accomplish their targets.  And that should be the focus of Daily Stand-ups.

I would therefore argue that anything that distracts the team from meeting the Sprint goals should be avoided.  If the presence of Product Owner turns the Daily Stand-up into something else, I would avoid that.

But then, this doesn’t necessarily happen in every team.

Sometimes you get to work with Product Owners who really understand Scrum (although that’s rare).  They actively try not to distract the team in any way.  Sometimes they choose not to show up for the Stand-ups daily.  They come to the meeting may be twice a week.  I think that’s a good idea.  But if your Product Owner needs help with that, you as a Scrum Master can/must educate them.  This should all be part of the culture of continuous improvement.

The worst thing I have seen is that the team decides to cancel their Daily Stand-up because the Product Owner wasn’t available.

If that happens, I would advise you to send your team on a good Scrum training course!

Developers and the Development Team

“Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule”.

This is what the Scrum Guide says about the Development Team.  I find this last bit about “no exceptions” quite amusing because I haven’t seen many rules written in a way where the authors have explicitly said “no exceptions allowed”.  It’s as if they are saying “we know what you are thinking: we know you will endeavor to break this rule at some stage.  Let us stop you before you realize you want to break the rule” 🙂

But this use of the word “developer” causes some confusion.

A recent conversation on our internal Readify Yammer became somewhat confused when somebody claimed that BAs and testers are often part of Development teams as well, and not just developers.  That seemed to be a very innocuous statement at the time and I obviously didn’t disagree with that.

But when I thought a bit more about it, I came to realize that perhaps, we need to acknowledge the distinction between a developer and a Developer!

So everyone in the Development Team is a Developer.  A BA is a Developer. A tester is a Developer.  A developer is also a Developer.  A Product Owner is not a Developer.

To me, it seems that the general usage of the term “developer” in the industry refers to a person who writes code.  Software engineers, programmers, coders etc are some of the other terms often used.  In fact, in job interviews in the past I have been asked if I knew the difference between a programmer and a developer, a software engineer and a developer, a coder and a software engineer etc.  As soon as the conversation takes that path, I know I am not getting this job, and would have to keep looking.  To this day, I don’t really care about these distinctions.  You can call me whatever you want, as long as you let me write code to solve your business problem.  It’s a bonus if the term you use to describe my job is respectful as well 🙂

But within the context of Scrum, everybody in the Development Team is a Developer.  Everybody contributes to the creation of the releasable Increment of the product.

They may use their distinct skill-sets to do that.  That’s ok.

Why is this important?

I recently came across an article which talked about some new Scrum meeting that isn’t described in the Scrum guide, but was purported to solve some specific problems many Scrum teams have.  The meeting was supposed to be attended by BA, a developer, and QA.  Note that the Product Owner isn’t invited to attend this new Scrum event the writers were proposing.

I do have many issues with the whole approach of that article, but here I only want to focus on the issue of terminology.  When you are proposing something new that is going to be so fundamental to a methodology (a new Scrum event in this case), you should stay true to the terminology used in the original body of knowledge.  You shouldn’t try to introduce new concepts, and you should try to stick to existing notions that have specific meanings within the framework.  When talking about Scrum, it makes sense to say for example, that in a specific meeting Product Owner and Developers must be present.  That’s ok because within the context of Scrum, I know what these roles are.  I feel uncomfortable if you start distinguishing between team members by assigning them roles Scrum doesn’t care about.

“Business Analyst” is not a Scrum role.  If you say that only BA, developer, or QA are supposed to do something, attend some specific Scrum event or do something specific to a particular Scrum artifact, I would humbly advise you that that statement didn’t mean much.  Distinguishing between team members on these lines goes against the spirit of Scrum.

This may sound like a useless semantic argument, but I strongly feel that thinking of everybody as a Developer ensures maximum visibility for the whole team.

 

 

Scrum and Empiricism

“Scrum is founded on empirical process control theory, or empiricism.”

What?  Empiricism?

The first time I read this line in the Scrum Guide, I was quite impressed.  Being a pseudo-philosopher, I had a vague understanding of why empiricists and rationalists don’t generally like each other.  It’s an ongoing argument in the history of human thought.  To confuse the matters further, technically you can be a rationalist in one area (say mathematics) and an empiricist in another area of physical sciences.  But the dispute generally holds true.

The fact that Scrum takes inspiration from empiricism tells us something important about it.

The question underlying the philosophical debate is this:  How can we gain knowledge?  More specifically, we want to know what is the fundamental source of our knowledge.

How would you answer that question?

If you think your primary source of knowledge is your sense perception, then I congratulate you for being a child of a Scientific age that relies heavily on empiricism to learn about the world.  The Scientific Method, (if there really is such a thing) relies on sense perception.  I would argue that in modern societies the need for “evidence” to make any claims to knowledge is so pervasive that we can’t imagine any other possibility.  The rationalist positions would sound silly at first, unless we think very carefully about rationalists’ view of how knowledge is achieved.

An empiricist would believe that all our knowledge is derived from our sense.  We don’t have any innate knowledge.  Now this has worked well for Science in the last 500 years or so.  Scientists like reproducibility of their results.  In fact, recently there was a story published on BBC about a “reproducibility crisis” in the scientific world.

“Replication is supposed to be a hallmark of scientific integrity”, the above article tells us.

Rationalists, on the other hand hold that at least some of our knowledge is derived from reason alone.  There is a wide range of opinions among rationalists regarding the relative importance of reason for acquisition of knowledge.  Plato is probably one of the earliest philosophers showing rationalist tendencies.  His whole idea of eternal Forms and doctrine of knowledge by recollection have strong smells of rationalism as it was developed subsequently.  I guess what unites rationalists is their refusal to treat sense data as the only foundation for knowledge acquisition.

And that’s exactly the problem I have with empiricism: exclusivity.  Empiricists don’t leave any chance of any other source of knowledge.  What my specific problem is with empiricism is perhaps not important here, and I don’t really feel like defending my position.

But I do agree that Science totally relies on empiricism.  Being scientific about something means being an empiricist.

And that makes Scrum sort of a scientific enterprise.

And don’t get me wrong: it’s a good thing.  Scrum is all about inspecting and adapting.  As the Scrum guide tells us, each event in Scrum is a formal opportunity to inspect and adapt something.  If findings of a team are backed by evidence and observation, we have something tangible to talk about.

If, for example, we observe that not having an automated CI/CD setup adversely affects team performance, and if it is an observation that is shared among multiple team members, we can then do something about it.

Empiricism makes it possible to have a conversation.  It takes away opinions that can’t be substantiated with evidence.

I feel that is a huge contributor to the success of Scrum as a framework.

 

 

It’s not just the Bell Curve

The Bell Curve is our friend.  In a recent post, I argued that in Scrum teams the story point estimates work very well because we will inevitably overestimate effort required for certain stories and underestimate effort for others.  The net effect is that the overestimates will cancel out the underestimates in the long run.

But, there is something else that goes on in a Scrum team, that makes our estimates more accurate.

A Scrum team inspects and adapts.  One way that happens is that as the team goes through sprint planning sessions over many Sprints, a shared understanding of “What a story point means” starts to emerge.  The team develops an intuitive sense of what a typical 1 story pointer looks like; what a typical 2 story pointer looks like, etc.   The team members may or may not be able to articulate it precisely, but it’s there.

This sense of worth of a story point is unique to a group.  To me that’s exactly the reason why we should never compare the velocities of two Scrum teams.

But the fact that there is a shared understanding among the group members means that the estimates by different team members start to converge over several Sprint planning sessions.  As the project progresses, the instances of “this-is-a-3-pointer-not-a-13-pointer” sort of conversation become rare.  The team just knows what a 3 pointer means.

The variance of estimates goes down.  You notice similar estimates from different team members, which probably indicates that estimates get better over time.

And that’s another reason why story points work so well in Scrum.

P.S.  Special thanks to my good friend Ahmadreza Atighechi (http://ahmadreza.com/) for the thought provoking conversations that inspired this post.

Story Points – A Mathematical Perspective

In sprint planning meetings, The Development Team works to forecast the functionality that will be developed during the Sprint.  This often involves estimating the effort required to complete work on user stories.  Story points are an abstract measure of the effort required to complete a story, and it’s fascinating to me how a set of educated guesses turns out to be a fairly accurate estimate of the effort required to meet sprint goals.  Planning poker or some variant of it makes the whole exercise seem somewhat arbitrary.  But it works well in the end.

Product owners want estimates to be as accurate as possible.  It helps them set their timelines of delivery, make commitments to the stake holders, and make decisions that affect the project and possibly the entire business.

An accurate estimate!  Do you see something weird going on here?

According to Cambridge Dictionary, an estimate is a guess of what the size, value, amount, cost, etc. of something might be.  Note that it is just a guess.  There is no guarantee that your story points estimate represents true effort you would eventually require to complete the user story.  It can be accurate if you are lucky though.

But then, how can we rely on a series of story points – which are really a set of estimates – for planning and decision-making purposes?  If each estimate is potentially wrong, then how do we deal with the accumulated error of estimation for an entire sprint plan?

At this point, statistics comes to our help.

Statisticians tell us about something called a “normal distribution”.  It is a distribution that occurs naturally in many situations.  A quick google shows that this distribution is applicable in following scenarios:

  • Heights of people.
  • Blood pressure.
  • Points on a test.
  • IQ scores.
  • Salaries
  • Measurement errors.

The last application in this list is of interest to us.  I would argue that in case of story points estimation, our error in estimation would follow normal distribution, or something very close to it.

b1

So, what does that mean?

Note that this curve is symmetric.  It’s reasonable to assume that the number of times I overestimate the effort required to complete a story (or the amount by which I overestimate some stories) will be roughly equal to the number of times I underestimate the effort (or the amount by which I underestimate).  With this mathematical intuition, I think it’s safe to assume that the overestimates will cancel the underestimates over many sprints!

And this shows why story points work nicely for planning purposes.

A consequence of this perspective is that there is no need to read too much into how many story-points a team has completed in any given sprint.  Many factors might have affected a single sprint.  The real value, from a planning perspective, is in the averages; for example, average story points completed in, say, last 5 sprints.

b2

The above graph shows story points in an actual project I was recently involved in.  The lumpiness of this graph makes us feel that something is not quite right here.  But the situation makes more sense if we consider the averages over 5 sprints.

b3

This graph shows the progress the same team made as the project progressed during the first 4 months or so.  After a rather slow start the team did gain some momentum.

As long as we are able to identify the reasons of lumpiness in any given pair of two consecutive sprints, I think we should be reasonably happy with this sort of progress.  The longer-term trends showing the averages are better representatives of the progress a Scrum team makes during the course of a project.

So, this is what I propose.   Next time when somebody passionately defends their estimate during a sprint planning meeting, just give up.  Make them happy by acknowledging their estimate as the correct one (within reason, of course), and take comfort in the fact that even if their estimate is wrong in your judgment, normal distribution will take care of errors of estimation in the long run.

Software Consulting

About two years ago, I joined Readify (http://www.readify.net) as a Senior Developer.

Readify is an award winning IT consultancy.  It won the 2015 Microsoft Country Partner of the Year Award for Australia and the 2015 Microsoft Application Lifecycle Management Partner of the Year Award.  The great thing about joining Readify is that you get to work with really smart people.  As a result, you learn a lot.

But the most important aspect of this experience for me is to learn about the business of consulting.  A consultant’s mindset is very different from what I was used to.  My career as a developer spans over 19 years working for various companies in three different countries.  But I have never worked for a consulting business before.  I have always worked for businesses that develop software products and make money by selling those products.

What’s so different about consulting?

I think it took me a while to understand why any business would engage a consulting firm for their software projects.  There are various possible scenarios in which consultants are engaged:

  • To increase the developer head count to get the project done within acceptable time-frame.
  • To use the expertise of the consulting firm in technologies being used.
  • To use the expertise of the consulting firm in a specific business domain.
  • To get help in designing overall architecture of their software project.
  • To get help with how the projects are run (think Scrum masters).

There are probably other scenarios as well.

I have come to realize that its absolutely crucial for consultants to understand why they have been engaged.  Our top priority must be to support our customers.  And that support can take different forms.  But primarily it’s all about giving the customers what they want, and help them make informed decisions.

Suppose you are asked to make enhancements to a product developed over a period of time.  You discover a few problems at the architectural level.   Would you go on and refactor to improve the design, or would you just follow the existing architecture, and implement the features/enhancements you were asked to implement?

Perhaps there is no clear answer here.  It depends.  But my point is that if you have worked in a product development environment, you will probably have the tendency to fix those architectural issues before you build anything new.  That’s what I was doing when I first started as a consultant.

I even started to tell my customer what exciting features they needed, as opposed to what features they were actually asking for!  That habit comes from years of working in a product based business where it’s not unusual for developers to help set product road-maps, because in some cases developers have spent a lot more time with the product than the recently employed BA or product owner.

You can’t always do that as a consultant.

In a short engagement of say, a month or so, you have to trust your clients; you have to accept that what they are asking for really fulfills their needs.  You might be working towards a deadline to ship the product.  You may feel that there are bugs of high severity in the system which will stop you from shipping the product in the given time-frame.

The point is that, that’s not your call to make.

What bugs get prioritized to be fixed; what features get into the next release and what gets relegated into future releases; these are the decisions a product owner must make.  We must help the customer make those choices.  We must explain the pros and cons of all options in front of them.  But we must not make those choices for them.  If you make those calls for the customer, you are taking an unreasonable risk on your shoulders; risk that client may feel they didn’t get what they wanted.

That’s perhaps the most important lesson I have learned so far.

A good post on the subject:

https://spin.atomicobject.com/2015/06/10/software-consultant-mindset/