Light weight product ownership
After learning from the problems faced in my previous large app development project—I wanted to validate some lighter weight Product Ownership techniques I'd been experimenting with. A smaller scale project was the perfect setting to try them in practice with less monetary risk.
Step 1: Gather primary stakeholder info
This app was one that had a simple tile hub to detail screen navigation structure and we'd already received an email outlining and initial set of tile titles. So what I needed to do first was to pin down the specific tile/detail combinations we need to build and how they might best be ordered. Since I had easy access to meet our client (primary stakeholder) in person, we conducted a short feature mapping session with stickies on a conference room wall. I made this quicker by writing some of the stickies before the session.
After that session I took the stickies back with me and put them up in the same arrangement on one of our office walls, before using them to create stories and epics in an online kanban board.
Step 2: Decide on Agile framework and info radiator
The common choices for app development projects are Scrum, Kanaban, and XP. The timeline, budget, and scale of this project lent itself most to Kanban. Anything else would have meant more overhead or didn't apply to our situation.
Our previous large project had teams in different time zones. We'd been trying to use and maintain a physical board primarily for the main office and TFS for the remote members. It was a full time job just updating one and reflecting changes in the other, so the board on the wall no longer made sense and the online tracker had to change.
We had been assessing several tools for tracking projects and found we were most happy with the idea of using Trello with Chrome extensions like Burndown for Trello. Other popular options like Rally, Jira, Pivotal, and the TFS we'd been using had too much overhead of various kinds for simply creating and moving user stories. In Trello I was able to quickly set up a compact Kanban board with the following key elements. In this image, the board is taken from a project endpoint and the burndown is from part way through. That is why nothing is populating the Backlog or the "working on it" columns and the Roadmap dates have all passed (view full size):
Step 3: Transparency for less overhead
As soon as I got enough of the stories defined, I opened the board up to our primary stakeholder so she could both view and participate with the cards and burndown at her convenience. She and I even shared a column on the board (separate from the dev backlog) that we populated with tasks we needed to complete along with the development stories. We all knew what each other were working on by looking at the same board.
Next I chose to design (as I both Design and Own for this project) most of the interface in a browser based tool called Moqups that allows for an equal amount of open collaboration as the kanban board—with all participants.
Finally I scheduled feature demonstrations to include our primary stakeholder. We weren't as able to meet in person later on, so these happened over screenshare and I would follow demos up with a video of the current screen recordings for large and mobile target devices.
Step 4: Internal and external user testing
In order to maximize our end user quality we conducted two rounds of user testing. The first was an internal with a handful of employees not familiar with the project and the second was a small set of beta users from the actual target audience for our client. In the internal round everyone was added to the board and entered their bugs directly into Trello. It was quick and fruitful, catching most issues in less than an hour. After some issues were fixed for a private Store url beta release, our beta users had a turn and found issues more specific to their perspective. We capped their review time to a few days and integrated their enhancement notes into the following release priorities. Another example of quick, easy user testing catching problems early.
Step 5: Keep the line open
Minimizing meetings and maximizing collaboration was another thing I wanted to push further with this project. I was strict with timeboxing every standup, demonstration, and anything that could mutate into being called a "meeting". Working sessions however are different. Being PO, I need to be available to everyone during all core hours. The most can get done with speed and quality whenever we do work together that depends on one another to complete. Two examples from a previous project:
- There was a big deadline we couldn't miss and too much to do, staying late all local people in the same conference room, remote people on an open line, and an ad-hoc mini-kanban board on the wall for every item to be addressed that evening. Apart from staying late (since working too long reduces your level of quality), it was the first powerhouse working session that team had done together and we completed an astonishing amount of work compared to the previous sprint (that project was using scrum).
- On the heels of that evening, I pressed for more of that during normal working hours. Where historically people start scheduling meetings, I just scheduled "keep the line open" hours so that any time anyone remote had a reason to speak to us, they'd just unmute (if muted) and talk.
How that worked in this project was just working in the same fashion we had with non-remote team members: either working in the same room with at least one ear non-headphoned or pairing in some fashion. A lot better collaboration can happen when there are less barriers to do so, however small they might seem.
Adhering to best practices
Sometimes on smaller Agile projects I've seen people forego best practices like keeping stories along "vertical slices" and trying to keep them "I.N.V.E.S.T"ed but especially because I was using this as a testing ground for larger projects, I made sure to do that even though it created more stories that at first looked too small. As time went on though, like any app that does something new, we ran into snags. These technical integration problems ended up dramatically changing the size of some stories, taking what seemed like equally sized tasks and turning them into very different, disproportionate stories. If I hadn't kept to these practices, we would've had a few stories with many tasks that would have dragged on forever. Our burndown would have looked useless and at some points everything would have looked blocked.
As it was, our board and burn down remained a very good reflection of the work taking place and what needed to be escalated. This allowed our primary stakeholder to pivot and adapt right along with us, as we discovered it.
Not all things have a short-cut. Some aspects are pay a little now so you don't have to pay a lot later.
Defining "light weight"
Light weight doesn't mean low quality. It means staying efficient, using methods that are quick to create and change. It means not doing the things you don't need to, so you have more time to focus on what is important.
As you have seen, there are a lot of things we didn't do or make to stay efficient. We didn't write any requirements documents, do upfront planning, workback schedules, Gantt charts, verbose progress reporting, try to use scrum every time, or communicate through email attachments.
I did though, write a lot of user stories and acceptance criteria. I wrote them in vertical slices and we tasked and re-tasked to reflect what the story needed. We were dilligent about marking items blocked and updating the board with progress. I maintained our Roadmap to set the right expectations. I made sure to close the self-improvment loops with user testing and retrospectives. Most of all, I made sure everyone always had access to me and visibility into the shared information. By staying light weight, we were able to do those all that to ship the software on schedule and improve ourselves in the process.
Go light weight whenever you can.