On Friday, a large group of us gathered in the office for a full day of looking at how we are currently managing our requirements over the course of a project. In the room we had folks who play the roles of technical leads, scrum masters, and product owners, all chatting over some giant muffins, lots of sticky notes, and one too many rehashings of the insanely catchy Lego movie song.
Cue “Everything is awesome” to be stuck in your head for 4 days now.
A lot of our focus was on the various artifacts we need to pull together, and how they depend on each other. Really, what we were trying to do, was expose the details of why our Product Owners have been needing to pull off heroics just to keep on top of things.
All the eggs in one basket
The biggest finding that we had was that we were often expecting our Product Owners to do the work that a team of individuals would normally do: Wireframes, Information Architecture, Design Comps, Usability Testing, Road Maps, Release Plans, Backlogs, you name it… if it wasn’t code or a project plan, it seemed to be falling to a single person.
Sure, we have awesome Product Owners who can do all those things, but without working ridiculous overtime, it means you’re cutting something in order to have the time to get it all done. That could mean the fidelity is lower, or that the quality of the output just isn’t as crisp as we’d want it.
Feeling the waterfall: heavy design up front
We also noticed that even though we want to do completely agile evolution of the design, the actual design elements like IA, Wireframes, and Design Comps do have a heavy up-front component in our projects. Very few groups are comfortable moving forward with spending budget on development until there is some sort of agreement on what is about to be built visually. It is actually much more common to have clients who are willing to have delayed discussions on the particulars of functionality, while for some reason the discussions on pixel widths and colour palettes needs to be firmed up in concrete at the beginning.
I’m not a designer, nor would I ever pretend to be, so I don’t understand the psychology behind this. My guess is that people just care more about the packaging then what the package is doing. I’m not entirely surprised, even I fall victim to this. When presented with two completely equal pieces of software, I will inevitably pick the one that appeals to me from a user experience point of view.
Regardless, it is the truth of many projects. Either we go completely waterfall with our design and start execution afterwards, doing minor refinements, or we need a way to be able to efficiently build and apply the ‘design’ after the fact.
With some platforms, this is a little bit easier. My colleague Tom was explaining that the way Sharepoint works they can make ‘design’ decisions late in the game and just apply it. The development team doesn’t need to wait for things to finish on the design side. Our digital group, which largely deals with custom web design applied over a Sitecore CMS platform, doesn’t have that same luxury. The design actually implies the content author experience as well as the component structure that needs to be constructed. At the very least, confirmed wireframes would be needed to have an idea of the page types and component structure.
Personally, I think we just need to have a rebuild cost in our budgets so that development can get started while folks are still pushing the pixels around. There are so many important pieces of our solutions that need to be built that do not depend on the visual, and I feel that getting these started early can help the project keep moving and tighten up delivery.
Giving the Product Owner a team
Now, that being said, if the person running that design flow is the same person trying to keep your backlogs ready for your development team, you’ve run into a problem. Suddenly, this person is feeling pressure to run two parallel projects that have impacts on each other at the same time. I just don’t think this can be done. The Product Owner needs to have some help here so that they can oversee the work, but not necessarily have to execute on all the details.
My suggestion would be to have the Product Owner have some execution staff: backlog writers and designers. The Product Owner has the overall branding vision and sketches it out, while the designers work on the execution of creating PSDs, putting together wireframe documents, and getting prototypes put together. Meanwhile, the Product Owner is also putting together the high level epics and letting the backlog writers work with the development team to make sure the stories are broken down enough for estimation and also have enough detail to be built.
The Product Owner can then review and make suggestions for edits (or make the edits themselves) without having to be involved in the detail of every change. On our development teams, we have a similar lead role that we call a Solution Architect that isn’t involved in coding every line of the solution, but makes sure the developers understand what the best practices are, what the stories mean, and review the solution provided to make sure that we are delivering a quality product.
Over the next few weeks, our team will be brainstorming from the results of our session on some revisions we can make to improve our process, but if you have any ideas, feel free to send them my way!
St-Cyr Thoughts 
Funny I was thinking about this today and wrote this down…
You know how the internet is full of lists? Like ’11 Things You Need to be an Agile Product Owner that Nobody Told You’.
1. You know everything. You are all powerful. You call the shots and you take the falls.
2. You are supposed to say what features get built first based on what’s most useful to your users. But… before you get A built, there may be a whole bunch of dependencies that need to be built first. You don’t know that because you are a business expert and not a software expert.
3. You have no real way of knowing what features are most important to your users.
4. You are supposed to write the user stories for the developers to code from, except you probably don’t know how to do that
5. Because you don’t really know how to write a complete user story, when you try to persuade the developers the story is ready for them to code, and you want it in the next sprint – they won’t take it because they say it isn’t ready.
6. Figuring out how to write complete user stories to keep developers busy and on track is hard
7. Your life will increasingly be taken up with making sure your development team is busy. Busy – but not necessarily effective.
8. You will have to sit through lots of not very interesting product demonstrations after each sprint, in which you will be unsure if what you have asked to be built, has indeed been demonstrated. You will probably be too shy to ask, and just let it go.
9. Your boss wants to see progress and to know when the project will be complete. You won’t be able to tell him.
10. When you successfully get the developers to accept your user stories, you will have to immediately start working on completing more stories, for the next sprint. But in the meantime, there will be questions you have to answer about this sprint’s stories. So, you will wonder how you are supposed to to keep up with all the things you have to do.
11. You will constantly be worried about having enough stories, the right stories and the right size stories in your product backlog. And it’s all your responsibility.