Many people think of DevJam as a place to go to get coaching and courses that produce real and lasting agility. While we are stoked that we are a trusted source, we are on a quest to share our product development stories and our lean and mean(ingful) approach.
If we were to build your product, the experience starts when you step inside DevJam Studios. Walking in the first floor door, you might wonder “Am I in the right place?” That’s because the first floor is home to Studio 2 , a coffee shop / wine bar that takes it name from the famous Studio 2 at Abbey Road Studios where The Beatles created so many lasting gems..
Studio 2 welcomes families, friends, neighbors and any technologist who wants to buy a cup and hack for hours, guilt free. Studio 2 also serves food and drinks to all the DevJammers working on the second floor. To make life simpler for the DevJammers, they can eat and drink for free in Studio 2.
Leaving Studio 2, you head upstairs to DevJam HQ. The second floor is home to product developers and producers. Borrowing from other creative eco-systems, like Abbey Road Studios and Paisley Park Studios, our focus is on producing and not simply doing or coding. Small groups of product developers are led by a producer who fosters learning in product and challenges everyone to continually advocate for the customers and users.
Product Development and Product Developers
Product developers are allowed great freedoms as they take on great responsibilities. For example, while we value sitting together, we allow for people to work outside the studio as they see fit, until evidence shows us that we need some hang time, or what software folks often call face time.
As a way to let creative ideas flourish where geekery is rampant, we have a newly forming lounge with beverages and guitars. We also try to get out and walk a bit. In fact, we are trying to avoid using the term meeting and instead hold jam sessions. Going further, and in homage to the strolling jazz bands of New Orleans, a walking jam session is called a Mardi Gras.
The Importance of Being Uncertain
To further feed the vibe alive in a creative space where people focus on producing, we promote “the least amount of process with the most real and measurable value.” Or put another way, “just enough process.” The just enough mantra keeps us open to a healthy amount of uncertainty as we dig into discovery for an idea or a contract. We use a simple set of tools to help us discover what is known, what is desired, what is unclear and what is not known.
As Nassim Taleb says, “It’s what you don’t know that hurts the most.”
When a critical mass of people come together at the studio, we use Post-Its and whiteboard walls to narrow the set of all product ideas into an initial collection that we can validate early. If you walked in on a discovery session you might see the Studio Producer (Matt Bjorson – the guy with the Telecaster) leading a collaborative chartering session, or framing some design target using pragmatic personas. You might also see a product developer and a client exploring customer journeys captured by using examples to create a story map.
If the group were distributed, we would opt to use CardBoard, a tool we built to promote collaborative design discussions. As part of the design, for distributed and collocated teams, we select journeys through the map that are our primary tools for moving to planning. We do size the work as well, but we value learning in journeys over completing work in iterations. We use iterations as cycles that helps us stop and learn as well as connect with validators who may need a schedule as part of their busy lives.
Agility, Delivery and Reality
With plan in hand, and an openness to being wrong, we start product development by getting a learning environment in place. Continuous integration feeds continuous delivery which promotes continuous learning. Journeys are mapped against iterations so we can see when we might have something to validate. The view across iterations helps clients see a product road map and the journeys help us validate when we are ready and not merely when an iteration (sprint) ends.
We use tracking tools but we think in use and validation not points and iterations. When possible, we connect product developers with real users, allowing them to learn from their product arrogance: the difference between what people need and what the product developers (or the client) think is then need. Planning in journeys challenges us to focus on where we want to take the users so we can see if they want to go there and why or why not.
Like test driven design (and programming), having a failing test allows us to learn by being wrong. It’s often as important as being right. Learning sooner, both about what is wrong and what is right, helps us guide our clients toward what we call the next best investment instead of talking about what is planned for Sprint 4.
To keep this post on the shorter side, I will wrap it with an invitation. If you want to see product development, where software development is one part, drop in or give us a call. We will be happy to show you around and buy you an espresso. If you are not near to us, watch for upcoming video from the studio. We plan to post some videos soon, but we need to improve our guitar playing a bit before we do.