At a time when other conferences are splitting into smaller and smaller regional and micro-tech events, the Agile Conference, with its 1,700 attendees, stands alone.
Alone and overwhelming. The event had sixteen different tracks spanning everything from DevOps to coaching and mentoring, leadership, and lean startup to classic elements like development, testing, and quality assurance.
Not to mention the vendor booths, the Stalwarts Stage (where experts "just" answered questions for 75 minutes), the four-day boot camp for beginners, and the academic track. The 215 sessions brought one word to mind: overwhelming.
Instead of focusing on one track or concept, I spent my time at the conference looking for themes and patterns. What surprised me was where I found those ideas -- to the left, in product design, and to the right, in DevOps, not in the middle, in classic software.
Extending Agile to the Left
It was Richard Tripp, the CEO of the POV Method, who first described the difference to me. Richard drew a line down the whiteboard, describing the items on the right as software development practices (code and test). He drew a small white box just to the right of the line and labeled it the product backlog. According to Richard, "Software Staff expect to pull items from the backlog in priority order. They don't want to have anything to do with the list; it is someone else's job. When we get the list wrong, we tend to blame and label the product manager as incompetent."
The left side of the board is what to build, or perhaps, why to build. Not only is it a challenging activity, but Tripp suggests it is essentially impossible for one person. Instead, Tripp wants teams (the whole team) to create a model of the ideal customer which can stand up to scrutiny. According to Tripp, once the team does this, the "what to build" starts to pop out the other side. His statistics are impressive too, with a software development customer moving from 15% annual growth to 50% in a three year period, while increasing average customer lifetime 600% in the same period.
Richard's idea of having traditional software teams "move to the left" in order to figure out what to do was not unique -- the conference had a half dozen different ideas to figure out what to build, from story mapping to lean startup, and the product owner team.
Four More Ways To Shift Left
Diane Zajac-Woodie, a Business Analyst from Erie Insurance, talked about how her role changed beyond requirements dictator in her session by the same name. Diane talked about story maps, which are essentially a two-dimensional diagram, with priority going vertically and the business process horizontally. This allows iterative development, because the team can implement a slice horizontally.
There's more to it than that -- the slice need to make sense. Diane's presentation wasn't on the concept of a story map, but instead how to bring in the whole team to create the map, and over time crowd source the backlog, the items in the backlog, and the priority they go in.
Matt Barcomb ran an open-space session called "The Product Owner Must Die," where he suggested that the role was inherently compromised -- that focusing on what the team should do and being available to answer questions has a direct conflict with the market research to figure out what the customer needs. At the very least, Barcomb suggested this be two roles -- if not taken over by the team as a whole-team activity.
Then there's lean startup, a way to conduct experiments to figure out what to build based on customer adoption. By making these experiments cheaply, a company can use feedback to build the right product. In fact, there was an entire track at the conference devoted to moving these strategies from newer, web-based companies to more established, larger organizations.
Finally, the last left shift model I saw is something called Cost of Delay. You can think of cost of delay as a way of measuring the value of having a feature right now, something like: "It is costing us $10,000 a week to not have this feature." By looking at that cost over a two-year window and dividing by the cost to build, the product team can created a weighted value of each feature. Don Rieinertsen covers cost of delay in his book Developing Products in Half the Time; the deep application at the conference was a session called "Black Swan Farming Using Cost of Delay" by Joshua Arnold and Ozlem Yuce.
Using this model, Ozlem and Yuce found that some features were 1,000 times more valuable than typical, hence the term black swan farming.
The other thing that Ozlem and Yuce did with the model was quantify the cost of extra time spent at the fuzzy front end, the time period between idea definition and beginning the actual work on the code. They found that simply listing the cost of projects in-pipeline allowed the business to focus on getting things done, which reduced multitasking, churn, and waste.
Stick in the Middle with Dev
By the end of the second day of the conference, I'd spent eight hours in sessions, and realized that it was almost entirely about improving the selection process on what to build, not on how to build it. (In one hallway conversation, someone actually called the focus of the show as doing the wrong thing righter.)
I found this talk of shifting left exciting, and decided to spend more time in the Open Jam, learning about moving to the right and coaching ... but you can read more about that in my next post.