Collective design & agile framework
Context
After bringing on a product owner and a product manager, neither of which worked out it occurred to us that these were jobs that we could do collectively. Because our company was relatively flat and the people we hired tended to be comfortable in multiple roles, sharing this work made sense.
Challenge
We outsourced our non proprietary code. For the sake of efficiency this meant that we always needed to have a critical mass of stories designed, estimated and ready to be built. Because of our decentralized culture, we were barely able to get enough stories ready for estimation. We were, as they say, “behind the eight ball”.
Reframe
One day I realized the people were not the problem, it was our system. We needed an agile approach to our design cycles. My vision was a centralized, collective project management system unique to our circumstances. Like all ah-ha moments this sort of sprung into my mind one day. I got a free version of Monday and mocked my idea up for our CEO. It probably took 2 hours of elapsed time, but this reframe fully optimized our talented team and the stories ready for estimation started to pile up!
Design collective
- Business analysts
- Sales
- Dev project manager
- CTO
- CEO
Product design in agile framework
I made a product design board that framed our design projects in agile. The board acted as a backlog where each project was a line item and they were grouped according to completeness (ready to go into a dev sprint):
- Q&A in JIRA – The story is in JIRA and the dev team is vetting it. We are answering questions or adding further definition/clarity.
- Design Sprint – The project is in the ideation, prototype and test loop.
- Definition – The project has arrived from the road map. It is in discussion and synthesis.
- Done – The story was built, tested and is in the release queue.
Collective project management and design administration
Each line item contained all the information anyone needed to see where things were at. This saved a great deal of time because all the data was there. You did not need to go to someone to ask about the status of a project. Here are some of the helpful pieces of information we utilized:
- Owner – who is bird-dogging the project?
- Status – what is going on? (project management)
- State – where in the process is it? (design administration)
- Time est. – how long did we think it would take?
- Time Tracking – how long did it really take?
- Story(s) – what epic, story or micro service is this for?
- Roadmap – what roadmap item did this stem from? (product management)
No loose parts
Each project line item had a comments popover. This allowed us to maintain a comment thread, post updates and store related documents. We effectively got the benefits of JIRA and confluence combined in our Monday product design board configuration.
No lost feature ideas
Based on synthesis of sales needs , stakeholder ideas, and design realizations I came up with a features board where anyone could post a feature idea. Not only was this time saving and empowering it was also democratic, because everyone in the company could vote on features without having to use JIRA. Product design tracked and organized the ideas. Some of them were transferred to the roadmap, and others got resolved in a similar story/epic. This was one of my favorite tools, because it removed the idea communication bottleneck and ideas no longer got lost.
