6 Things Product Owners Need to Know

So I've identified what appears to be an issue for the Scrum Community. It's consistent in that the area of improvement always seems to be the same but the way that the problem manifests can be different.

photo credit

I'm looking at you Product Owners, time to step up your game, understand your role and help take the team to the next level. Here's 6 things that you should know about owning the product:

1) Trust is key:

Particularly early in development for a new product there will be a lot of Product Backlog items which may or may not be understandable without development experience. At this early stage you'll be relying on your Scrum Master and in particular the development team to explain the need for these things so that you can properly prioritize them. My suggestion is to build a good relationship with the Scrum Master and at least one (preferably all) of the developers who can act as a guide for some of the more esoteric work that may need to be done in the sprint.

Likewise, that trust will be needed both ways. If the team knows you well enough to suggest some changes to the product that you may not have thought of or understand (refactoring comes to mind) then take some time to listen. More often than not these types of technical changes will ultimately make development much easier in the long run rather allowing for faster feature development, more reliable code and better performance in the long run. You'll find that this type of really valuable feedback will simply disappear if you don't take the time to earn your team's trust.

2) Your job is to serve the team:

The ultimate goal is to ship great software, that's why you're there, that's why the team is there and in a roundabout way that's why the Scrum Master is there. That being said, which role in a Scrum organization is most likely to get blocked, thus preventing the shipping of said software? If you answered the Scrum Team then you are correct. While it's not something that you can prevent altogether it's definitely not a problem that you should contribute to.

Let's imagine a scenario where the development team is working on various aspects of your product. One by one, (or even all at once) they need some feedback from the product owner so they call you and it takes you day (8 productive hours) to get back to them. One day turn around time isn't so bad right?

By applying the power of math, assuming a 14 day sprint and the loss of one day due to the product owner waiting to get back to the team, that's slightly more than 7% of the sprint lost to the product owner turnaround time which is likely a wide enough margin to cause sprint failure. Part of the whole point of having a product owner is to provide a single dedicated source of feedback for the team since the actual customers are usually off doing other things (which usually don't include software development).

My thought on the matter is that the Product Owner (and the Scrum Master) should adopt a helpdesk mentality when the Scrum Team requests some feedback. That request should be turned around in a matter of hours, minutes preferably. If at all possible, try to position yourself in the office WITH the Scrum Team and make them feel comfortable walking into your office (or cube, or whatever) to ask questions and get feedback when they need it.

3) It's your job to understand our customers:

Q: What do developers know really really well?

A: How to make software.

Q: What is unlikely for a developer to know really well?

A: How to work a warehouse, file insurance paperwork or anything else that your stakeholders will use the final product for.

Ideally you actually are one of the customers and bring a ton of domain knowledge to the party but if you're not (or even if you are) you need to spend whatever time you can understanding the end users who's needs may encompass more than what you're familiar with.

This means contacting customers who provide feedback personally, spending time with customers who actually use the product and/or a legacy solution to find out what they like/don't like. Being an active part of the online community (if there is one) for the business area and just generally getting into the head of the folks who will ultimately use your product.

This also means putting your ego aside in many cases to allow some backlog items you may really like to take a backseat to functionality that may be important to the customer base as a whole.

4) The Team occasionally fails

Each sprint adds value to the final product but that doesn't mean that the Scrum team will always deliver exactly what they committed to. Some sprints may see them over-deliver while other sprints that fail to implement everything. Neither Scenario is good or bad, it simply means that software development (at the team level) is unpredictable at best.

Think of it this way, if the team maintains a planned velocity of 100 hours per sprint but delivers the first sprint with an actual velocity of 90 and the second sprint with 110, what's the average?

The point here is that sprint success or failure isn't necessarily important to the Product Owner so much as the team delivering value to the product so don't sweat the details here and use some of the trust we talked about earlier. The team occasionally fails because they're trying new techniques, setting ambitious goals for themselves and is generally looking to improve every sprint, this results in the occasional failure but will generally trend towards a faster more efficient team over the length of the entire release.

5) You are not a Project Manager:

This part is actually a bit tricky but ultimately, it's your neck on the line as the Product Owner if the Product ends up sucking. But that doesn't mean that you set the schedule for the team, worry about how the allocates the work or god forbid, plan the sprint backlog. It's your job to set the teams priorities at the backlog item level and to provide valuable feedback for the team. If you attempt to control any aspects of development past these levels then frustration and team unhappiness will result.

Here's why, planning the day to day details of development with the individual tasks or even the backlog items reveals a wealth of complexity such as the expertise of the individual developers, dependencies at the task level, individual schedules, sick days, vacation time and various other aspects that have given project managers headaches for decades using the waterfall method. These things don't magically go away using Scrum but we absorb them at the team level which makes life for everyone much easier.

You see the team understands the technical intricacies involved with their work because their the ones doing it, they (should) know each others strengths and weaknesses and even each others schedules better than any Project Manager, Scrum Master or even Product Owner ever could which makes the team the most logical place to hammer out those details. This is the primary reason why the team decides on the amount of work to pull into the sprint backlog rather than any other role.

6) The Sprint Review is not a dog and pony show:

The sprint review is one of the few aspects about Scrum that should be done behind closed doors. The purpose here isn't to celebrate new features, berate the team for missing functionality or anything of the kind. As a product owner, it's your job to see what the product looks like at the current iteration, provide critical feedback, make some tweaks to the backlog and/or stamp the product ready for release. When the Sprint Review becomes a public meeting that instant feedback becomes much harder to give, details get lost, that part of the interface that crashes isn't clicked on. In essence the Sprint Review (while great for morale) becomes much less useful as a feedback mechanism.

Final Thoughts:

I could go on for hours about any one of these six points and you may see more detailed posts about them in the future. The truth is that a strong Product Owner is often the secret sauce that separates a great software development team that amazes customers from a mediocre one that simply pushes out a release every now and then.

Dependencies in the Product Backlog

A backlog item should be big enough that it's not dependent on any other backlog item to be completed.

photo source

Hopefully, you already know that, and in a perfect world, that's how we'd all live, but the fact of the matter that every new feature is dependent in at least one small way. You can't add in a nifty planning board into OnTime if it didn't already do work item tracking right?

So if dependencies are part of our day to day reality then how do we deal with them? I'll answer that by rephrasing the first bit of wisdom in this post.

A product backlog item should be big enough that it's not dependent on any other incomplete backlog item to be completed.

"But Sean" you'll say "Story #231 is too big to accomplish in a single sprint and it's the next story in the backlog!"

"Then break it down into smaller pieces" I'll reply

"Didn't you just contradict yourself?"

"A bit but here's what I mean straw man"

Once you decide to commit to a very large backlog item you'll probably work on it for the next couple of sprints but you need working, tested software at the end of the iteration, what's more you'll probably want to break it down to make it easier for the team accomplish. Here's my thoughts on the matter.

We decide on Story #231 which is Big, we think we'll need roughly about 3 sprints to get it done so we break it up into smaller logical pieces (ideally 3 pieces, but common sense is the best rule here), all three pieces can be accomplished with a single sprint each and they all get thrown to the top of the priority list since that's where they sat before we broke them up. If they're dependent on each other, then the first one will be prioritized highest, the second is next and so on and so on.

Now we've got one big story in the first sprint, which isn't very helpful at all when we begin working, so we'll break it up into smaller pieces again for the development team. Generally speaking, you should be breaking things up at this point to be small enough for a team member (or paired team) to tackle from beginning to end by themselves within the sprint. From there, the individual developers should start thinking about breaking their own work items down into logical steps (or tasks) which should be small enough for us to see daily progress on the steps completed.

You'll repeat this again until the Big backlog item is completed, then dip back into the backlog for the next item.

The tendency with new Scrum Masters and Product Owners (and even experienced ones) is to look at the backlog and break everything down as soon as we get it. The problem is that now we need to maintain backwards traceability to the parent story (software can help with this but it'd be better to not need it), we have to educate customers on the breakdown of their feature request or bug (they think of them as Features and Bugs no matter how many times you use the word "Story" or "Backlog Item") and we end up making more work for ourselves in the long run (which makes my teeth itch) since the parent item will inevitably change right up until the last second. The solution is to decompose your backlog items at the last possible moment before the sprint.

Limiting Work in Progress (WIP) and Scrum

WIP and Kanban are things that I hear about more and more every day and it's worth noting that I'm personally a big believer in both. Let me tell you a little story...

Background Story:


My first tech job was building and configuring enterprise servers and racks in a lab (or a factory depending on your definition). It was a blast because of all the neat toys that I got to play with but it was not without problems.

You see, we sucked. Specifically, we sucked at getting things done in a timely manner.

At least by my estimation we sucked, I was only a 22 year old kid at the time though so it seemed possible that I wasn't seeing the bigger picture, but I thought we sucked at making things with anything even remotely resembling efficiency.

As time went on, I started making notes of some of the things that I thought were strange. We were constantly running out of floor space, so we couldn't start new orders and Techs spent nearly 10% of their time waiting for new orders to be brought in for them to work on. At first I thought these two problems should be mutually exclusive, if we've got so much work in front of us that we literally can't fit in the space anymore, then how can we not have anything in front of us to work on?

The Problem:


As it turns out the problem was simple, A rack is put in front of me, I start building it and run into a problem that I can't solve on my own. I then have to make a call to somebody else to fix it and move on to whatever is next because it's no longer my problem. Before you know it, everything on the floor is waiting for some magical fix that I can't provide, there's nothing left for me to actually do and so I sit on my hands and complain that I can't get anything done.

This was all an intellectual problem for me until I was put in charge of a team that was failing, even by our low standards. This team generally got smaller orders which meant we had more opportunity to get blocked on any one of them, which played a big part in their abysmal performance.

The Solution:


I went about the business of fixing this in the only way I knew how: by being loud and annoying (that's what 22 year old Sean did). There were five of us on the team, so I declared that we would only bring 5 orders into our area. We can be working on fewer than 5 orders but at no point do we put a 6th order in front of my team and I got loud and annoying when anyone tried to do otherwise.

This pushed the other side of things, when an order became blocked it became important to unblock it so that we could really finish it and move on. Sometimes it was painful. Really painful. Really Really Painful. A second order became blocked and it was unbearable.

What happened was that when an order became blocked I would pull the tech working on it to whatever I had my hands on, shot off an email and if I didn't hear back within 10 minutes I went on a manhunt. I didn't send emails asking for a solution twice, I didn't wait all day, I didn't make phone calls. If my order was blocked and you were the person that could unblock it, I was at your desk, or at your boss's desk, or your boss's boss's desk and I didn't leave your side until I had a solution. Generally I made my loud and annoying presence known until I got what I wanted (which is what everyone wanted but was simply inconvenient to provide). Needless to say, I caught a little bit of heat for this behavior, but luckily my team had become the single most productive (and profitable) on the floor and it's hard to argue with the scoreboard.

You see what happened over time was that my team spent less and less time getting hung up on random issues and more and more time actually building stuff since we weren't spread over tens of orders. Over time my little forays also became less and less frequent as well since it became obvious that I was going to bug the crap out of anyone that held up my team for more than 10 minutes. What happened is that the business actually learned how to become more efficient at providing for the team.

How it Applies to Scrum and Software Development:


This was before I had heard of the magic of limiting Work In Progress or Kanban or really any of these, it just seemed like a logical solution for a random problem I had encountered.

So why does this apply to software development? While your team doesn't need to worry about floor space they can very easily become inefficient through working on too many things at the same time. What's more, they'll develop a tendency to start everything early but not finish until right near the end of a sprint which can really play havoc with tracking your daily progress.

The takeaway here is that limiting Work In Progress (WIP) isn't really a secret, it's not complicated and it's certainly not even something you need to take a weekend to learn or read a book on. It's just good old fashioned problem solving applied to a really common problem. While floor space isn't something you have to deal with, integrating 10 features into a product in the last few days of a sprint is.

Summary:

Limiting Work In Progress works in the same way that Scrum does. You see Scrum doesn't really solve any problems for you and neither does limiting Work In Progress, it just exposes the problem for what it really is which makes it easier to solve. If it's a business area problem, then it's easy to show and prove to the business making the solution easier. If it's a tendency of the team to juggle the entire sprint backlog, then bring in a WIP limit and measuring over a couple sprints might be enough to prove to them the virtues of this new idea.

If your Scrum team can't solve a problem on it's own, then they come to you (the Scrum Master). It's your job to hunt down whomever can unblock the team as quickly as possible and solve that problem. What will your developers do while you're on your manhunt? Partnering up on a single programming task would work great, maybe having a WIP limit of 8 for a team of 7 or a WIP limit of two for each single developer. Use your sprints to experiment here if it seems like something you want to implement.

Just remember to wear comfortable shoes since you'll be walking a bit more than normal for at least a little while.

5 Big Issues When Scaling Scrum

I think it's a safe bet to say that if you're reading this blog then there is a good chance that you're at least interested in Scrum. The problem is that for many organizations, even the basic concepts in Scrum begin to break down as we scale it up to the entire organization. Imagine a daily stand-up when the development team consists of hundreds of developers and even more testers. These problems are not small and very often can mean the difference between a successful project or a horrific failure. So what are some of the bigger issues at hand? Glad you asked.

1) Testing is done outside of the Scrum Team:
I'm not talking about unit testing (although those should be part of your definition of done). I mean functional testing, done by a testing professional. If you "finish" up a backlog item, run your unit tests, mark it as complete in the sprint and then ship it off to the separate testing group, then you can't really consider it complete until it comes back. The solution here is to embed at least one tester with each scrum team so they can get immediate feedback within the sprint on the completion of a backlog item.

2) Team size is too large:
Amazon has a rule that any team that can eat more than two pizzas for lunch is too large. Now I'm not going to argue the logic behind that argument but that would allow for me and one other similar sized person and 'm not sure that's what they're getting at. The general rule of thumb that I've come across is that a Scrum Team (including testers) should be about 7 people give or take 2. Meaning that 10 people is starting to get a bit large and 4 people (while better than none) might benefit from at least one more. How does that help me with my team of 100 devs? Well obviously we're not going to fire 93 people and expect the results we're looking for. But we will break the team up into smaller teams of preferably 7 give or take a few developers.

3) The daily standup (and other meetings) are conducted en masse: 
Each individual team will conduct it's own sprint planning, it's own daily stand-ups and it's own retrospectives. From there it falls to the Scrum Master to roll all of this up to the meta-team level to combine into the total project as a whole. For instance the small teams all do their daily standups and and get back to work, the various Scrum Masters (or team leads) all get together for a quick standup to briefly talk about their teams progress, issues and goals for the day. The individual team performs their retrospective and identifies some areas for improvement or things to try in the next sprint and the Scrum Master performs a total retrospective with the other Scrum Masters to discuss the total sprint. And so on and so on.

4) Nobody can get ahold of the product owner: 
What happens when the Scrum team is working on a story and discovers that they don't know what a form should look like? That story stops until the Product Owner responds. Scale this up to 100 or so developers and you've got yourself a problem. The solution can be a little tricky, ultimately you'll want a single product to make big/heavy decisions about the product but spread him too thin and his ability to respond will suffer causing the team to wait for answers (which is never good). In large organizations you may find it easier to have a single Product Owner and several smaller Product Owners to assist the Scrum with their inevitable questions.

5) The Scrum Master has no idea what's going on:
Having a single Scrum Master for an entire organization is a bit like asking a single waiter to handle every table in a busy restaurant. The Scrum Master's job is ultimately to serve the needs of the Scrum Team, spread that out among multiple Scrum teams and that service will suffer along with the teams performance. Ideally there should be one (and only one) Scrum Master for every team. They don't need any special certifications or advanced skills, just a basic grounding in Scrum, good old fashioned common sense and a good grasp of what the Scrum Master does all day.

These are just some general guidelines and issues that I've seen with large groups adopting Scrum. There's certainly other issues that you'll run into and different solutions that you'll try. Let me know about your experience in the comments, I always love being exposed to new problems and new solutions.

I'm doing an introductory Agile webinar soon

Enough of our customers at Axosoft have asked us for an introduction to Agile and Scrum that I went ahead and put together a brief webinar that should act as a decent primer. Chances are if you're at this blog then the material I'll be covering won't be new to you but this should serve a great introduction for any co-workers of your that are still a little leery of this whole "Agile" and "Scrum" business.

We're planning for Thursday May 19th from 10am - 11am PDT. Only about 30 minutes will be canned speech the rest will be a general Q & A about Scrum and Agile.

Check it out at Axosoft.com

Sign up to attend with this LINK

Sprint Lengths and Long Releases

If you're not careful, the length of your sprints may become a one size fits all solution wherein you try to shoehorn every development effort into a 2 week iteration or some other length. I try to caution people from reaching this point for a number of reasons.

Certainly, having a shorter sprint size has it's advantages because the shorter time frame allows for more accurate planning, faster feedback and a bit faster pivoting for the team. There's another side to this as well though, before every sprint you have to have a sprint planning meeting. Ideally your developers will estimate (or reestimate) their work items right before the sprint. Before you plan the next sprint, you need to review the sprint and perform a retrospective. All of these things are good and should be done between each and every sprint, but they also mean time that the development team is spending away from more important things, like development.

And therein lies the conundrum. Traditionally you would try to reach some kind of happy medium for sprint length and that sprint would become the heartbeat of iterations for your software. Every 2 weeks, 3 weeks or 1 week you would finish the sprint and there would be a new potentially shippable iteration of the product. This is good, many teams will start doing this and will likely continue because it works great, but don't let it become a rigid law for your organization.

But here's a thought: no Scrum rules should overcome a thoughtful decision made by an intelligent person (which I'm assuming you are). Which is to say, we should protect the team from being overburdened by the Scrum Framework.

What if we were working on a long-term unannounced project? Perhaps it's a AAA game title or an entirely new product with a deep feature set. In either case, customer feedback isn't that useful since our customers don't even know the product exists. Moreover, for at least the first few sprints, the development team's focus will be more towards achieving a minimum viable product.

This doesn't mean that we throw Scrum out the window, in fact just the opposite. Sprints, retrospectives, planning and the product backlog become even more important. Since this specific article is about sprint length we'll start there.

If this is a new team working together for the first time, short sprints are probably best so that we can loop back in often for retrospectives, maybe a one week sprint or so (shorter or longer, it's up to you). Tuning a team to work together will make your life much easier on the long road to the release.

Once the team is comfortable working as a unit, those retrospectives (while useful) can be seen as overhead if they're done too often and since the product backlog primarily consists of Minimal Viable Product work at this stage, priorities are unlikely to shift too often. As we begin to settle in for a long release you can lengthen your sprints (every two weeks or every month). You'll still track your daily progress via the burndown chart and your daily standups, but will loop back in to finish the sprint less often.

Once you begin closing in on a release, feedback becomes important again, functional testing will provide new insights, tweaks on the original design are made, beta testing will finally allow for customer feedback, etc, etc...

Because of all the new feedback as we get closer to a final release, it can become important to shorten up the sprint length again to allow the team more room to change direction and priorities between sprints.

Using variable sprint lengths are probably not the norm and is usually reserved for longer development cycles with a minimum amount of customer feedback, but ultimately the sprint length is a tool for the Scrum Master to experiment with and use to the development team's advantage.

What are some of the things you've noticed about how sprint length affects your team?