Agile Faux-Pas: Lack of a Product Owner

Agile Software development has taken the world by storm and its adoption is at unprecedented levels these days. Almost everyone these days talks about Agile software development and agility as a discipline. So you would expect that everyone learns and practices Agile Software development the right way at the right pace. Sadly that is not the case. There are countless examples where Agile Software development is not practised correctly.

That is the point of this new series of blogs, the Agile Faux-Pas series. While none of these will kill your software development (or may do in extreme cases), they definitely make you less Agile and often defeat the purpose of going Agile.

One very common ‘faux-pas’ is the lack of a proper Product Owner.

It usually manifests itself in the following ways.

  • Many teams and companies assume they don’t need a Product Owner(PO) or they have someone take over this role part time.
  • Others go the waterfall way and use a requirements document as a product owner.
  • Still some others improvise and have neither a requirements document or a PO. They just get the senior most team member or someone from management to act as a PO when needed.

This is a clear departure from Agile Principles. One of the main reasons for this is a wrong understanding of the PO’s purpose. Or even a total lack of understanding. Let me elaborate on that a bit and also throw light on how the PO is essential to the success of Scrum. For that let us first see what are his roles and responsibilities (in no particular order) and why they are important.

  • Demos and Constant Feedback: For the dev team’s point of view, the PO is the customer. In every Sprint review, the team gives the PO a demo of an incremental version of the product that has more value (features, bug fixes, enhancements) than the last one. This demo gives the PO an opportunity to look at the product and answer queries about whether the stories taken up for that sprint were done right. The PO should already have talked to the real customer or their representatives to get detailed product specs and the priority of each spec. Armed with that info, the PO should be able to answer any product specification related question the developer might ask. Also, the PO should be available to answer requirements related queries at any time during the sprint. Overall this provides much better feedback than a document, even a constantly updated one. The point to note is that while the PO maintains requirements in the Sprint and Product backlogs, they are not alternatives for him being personally available to look at the product, give feedback and clarify queries. It is this face to face communication that allows the dev team to constantly build the right features in the right order. Without that, there would be a great deal of wasted effort and rework.
  • Backlogs and their grooming:
    • Product and Sprint Backlogs are the most important artefacts maintained by the PO for each product under development. The Product backlog contains stories that need to be go into the product while the Sprint backlog has stories that need to be completed in a particular Sprint. In both backlogs, items are arranged according to Priority and this Priority is sacrosanct. At all times only the highest priority items should be taken for processing. These backlogs and their priorities are the PO’s responsibility and they are arrived at by constantly talking to the customer or their representatives.
    • Also before a sprint begins, the PO along with the scrum master works on making user stories for that Sprint “Sprint Ready” which essentially means the following.
      • Latest requirements: Requirements can and will change while the product is being built. The PO makes sure that before each sprint begins, each backlog item contains the latest specs.
      • Clear and well defined stories: The PO makes sure that there is no lack of clarity about what each story means. This can be achieved by mentioning the specs clearly with the stories in the backlog and also by being personally available to resolve queries face to face.
      • Acceptance criteria: The PO defines what constitutes successful delivery of each story before the sprint begins, allowing the team to demonstrate success (or not) for each feature developed.
  • Business inputs for the product: For any product, business inputs are key development drivers. As I mentioned earlier, the PO is a virtual customer for the dev team (including QA). The PO has all data about how the product is supposed to run in the field and is the single point of contact for the dev team to be able to get these insights. And since the PO has all the data, he usually is the best judge of the correct expected behaviour of the product in the field. The availability or lack of these insights could make or break a product.

As you have seen, the PO overall brings clarity to the developers, a clarity that probably cannot be matched by other substitutes. It is this very clarity and constant availability for face to face clarifications that make the PO’s an indispensable role for a truly Agile team.

There however are many reasons why teams are not able to have a proper Product Owner, I will look into some of those reasons in another blog and hopefully be able to provide solutions for that. I will also be looking into some best practices and anti patterns with respect to a PO in that blog.

Also, please share your feedback in the comments. I would love to hear your opinions and questions. Do subscribe if you feel that this blog is useful for you.

References

  • Implications of your PO being missing in action here.
  • What happens when you don’t have a PO at all. Read a thoughtful perspective here.
  • And here, why you need a dedicated product owner.

 

Tackling hurdles to Agililty

Agile methodologies, in some or the other form, have been around for close to three decades now. They have been immensely popular for software development across the world for a better part of a decade now. But there still are people who do not want this change. There still are pockets of resistance towards Agile and Agile Principles. There seem to be so many reasons why somehow Agile does not seem to be ‘right’ for them. Some are valid, others not so much.

Over the years, I have seen a lot of misconceptions people had about agile people which prevented them from transitioning to agile. In this post I wanted to dispel some of them. This may not be an exhaustive list but here are some of the most prominent ones. I will probably write a sequel to this post as and when I am able to find more ‘hurdles’ to Agile and how to tackle them.

So without much ado let us see how to tackle the first few ‘hurdles’.

‘I don’t want to restrict a well performing team with unnecessary ‘process’.’

No one likes unnecessary and heavyweight ceremonious process that exist only because someone mandated it. And none of the Agile processes are exceptions. Agile only expects a few specific conditions to be met.

  • Each iteration should finish with added value for the customer.
  • Software gets continuously validated.
  • Stakeholders should be actively involved.
  • Self organising teams.
  • Continuous improvement.

Agile doesn’t mandate how you achieve this, nor advocate a standard. If you are able to achieve these then you are agile. So there is no extensive and unnecessary ‘process’, there is no bureaucracy and no process that no one understands. Teams only work on those ‘process-things’ that satisfy the above 5 conditions.  Everything else is extra.

‘A daily status meeting: Oh! Its too stressful’

If you or your company see it as a status meeting, then you are doing Agile wrong. The point of this meeting is that everyone in your team knows what everyone else is doing, with the specific intent of making sure that the goals for that iteration (Sprint if you follow Scrum) is complete. It can serve as a status meeting for management, but if that is all that is happening then it is wrong. The point of a daily short meet is to ensure that everyone in the team knows the progress, can ask help or be of help if possible and to make course corrections if it seems they wont meet the goals for that iterations. And most importantly convey it as early as possible if it seems that the goals for the sprint will be missed.

All Agile methodologies accept failures so long as we learn from them. In fact the Agile way is to fail fast, fail early when too much effort, time and money hasn’t yet been committed to the project. So if you look at it as a status meeting, then you are doing it wrong. For a developer it is a forum where developers tell what they did, what they plan to do and most important try to predict impediments so that the scrum master can work on clearing them as soon as possible.  Also management need not be present in that meeting. If they are, then they need to be only listeners and provide input when asked for. The scrum master can brief the management in another meeting.

‘Agile gives license to throw away all discipline’

This misconception hurts both ways. It scares away people who want a disciplined execution of the project and it attracts those who think discipline is a chore.

The truth is that agile expects a lot of discipline from developers. It just doesn’t expect the processes and ceremonies to be imposed by the management above. On the contrary, it expects the team to be adults and evolve a process that works for them and also helps them meet all agile and project goals. Discipline is not stressed but it is implicit, and without discipline you can’t hope to succeed. The only difference is that the team follows rules and processes that make sense to them and not some company diktat that they comply with without understanding its purpose.

‘Agile is for short-term projects’

It is easy to see why there could be a misconception like this. The dev team usually focuses only on the goals for that particular iteration. So an outside observer might see a very short-termist outlook. And hence the view that this probably wont work for long term projects. And unfortunately many teams do work in this way, hacking up the code just so that the demo at the end of the iteration can be done. If a team works that way, then they are not agile.

Agile does say that you concentrate on just enough architecture and design to make sure that your sprint goals get met. But nothing stops you from having architectural issues and bugs in your sprint backlog. Usually if your architecture and design are not up to the mark, there definitely will be bugs. Nothing stops you from revisiting design once a feature is done. In fact you cant be truly agile without being constant, ongoing, small doses of refactoring. When the product owner is pushing features to the sprint backlog, the team also should be able to push architecture and bugs to the sprint backlog and then prune the backlog to make sure that only those many items that can be finished in the iteration remain. This way you can be truly agile and work on a long term project.

There are many more hurdles to Agile, that I will discuss in subsequent posts. For now I am leaving you with these. Do share your feedback in the comments. And don’t forget to subscribe to BeingNimble to get the latest posts right in your inbox.

References

  • A bit of an explanation about the conditions for agility here.