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!