Archive for February, 2013
Having just completed the 35th iteration of a significant project in which I’m pretty heavily invested, I thought I’d reflect back on some of the major trends visible in previous iterations.
Looking back, the first few iterations were heavily focused on getting our feet under us, discovering the important aspects of the project environment, and getting a feel for how things worked. While informal learning was very consistent through these early iterations, our primary stakeholders determined that the team needed formal training in some of the key areas associated with the product’s development and invested heavily in that training starting around the fifth iteration. These training efforts continued in parallel with development activities throughout the first 20 or so iterations.
Meanwhile, the team was able to successfully release incremental business value into the retail market starting around the 15th’s iteration, with the value of that contribution increasing steadily each iteration. The market feedback from the first few iterations in the retail market fed heavily into determining future product direction, and as a result the product team was able to achieve some significant strides in understanding the target market. This led to a strong pivot into an engineering market, including carefully arranged deep market training for the team over the next few iterations, including at least one significant gemba visit for each iteration. In return, this training allowed the value delivered soon after moving into the engineering target market to be heavily aligned with the future direction of the product.
The product made major strides over the ten iterations following the team’s deep technical training, investing nearly ten thousand hours each into creating major capabilities for both the technical engineering market and the engineering leadership market. Throughout this same period, two major stakeholders moved to an advisory role, the project merged with another project, bringing new stakeholders on board, and even spun off a new project around iteration 29 that is intended to explore new markets (although still demanding quite a bit of training and guidance from members of two merged projects).
Despite significant and profitable market penetration based on the product’s capabilities, the product team wasn’t satisfied with the product’s current positioning. As a result, the team worked to pivot again, bringing the product team into the training and development market. This has allowed the product team to achieve significant leverage towards the overall core vision, while increasing market awareness and continuing to experience significant market demand. These actions have also led to the product being featured in a number of trade shows, as well as being involved in the creation of a variety of market literature.
This leads us to our current reality, in which the team is sitting down to celebrate its achievements and consider future directions using the classic ceremony known to facilitators everywhere as “Birthday dinner.”
Happy birthday to me!
I worked with a group last week to help them get started with kanban, as I do many weeks. As we moved into the last stages of the class we were at the point where we’ve articulated the work they do, how they do it, what the constraints and policies are in their day to day, laid out the columns they’ll use to represent that work… all the good things that happen when you design a kanban system. As is pretty typical at this point, the question arose “How do we choose our limits?”
I started into my typical list of the different ways of limiting. I shared how it works in manufacturing, taking the ratios of work time to each other. I revisited the idea of focus and talked about avatar limits and not having more than one or two items in the system per person. I talked about the need to smooth flow, and how the various column limits will change once you achieve a reasonable flow through your system. I even talked about the “pull it out of your experience” approach. Then I realized… all of these missed the point.
It’s not about “choosing our limits,” it’s about “choosing our limits.” It’s about the choice being a choice, fully embraced by the team doing the work. It’s about a team inspecting its own work, accepting the need to constrain themselves, and respecting that constraint.
With this realization, my advice became “Pick something that’s actually a constraint, something that encourages you to work a little differently, but doesn’t prevent you from delivering how you deliver today. Get in the habit of respecting the limits, but recognize that whatever you pick today will be wrong in three months. There will be a time when the specific choices make an impact on your flow and help you shine light on impediments, but that’s not now. Right now, learn to focus on finishing work instead of starting new work, and use the limit to help you achieve that focus.”
The self-discipline to limit behavior while standing up for what one believes is among the attributes that I respect most in people. Why should I respect it any less in a team?
We are a community that values delivering early and often. Releasing incomplete work in order to gather feedback and improve our materials is in our DNA, right? So I fully expected to see a nice, smooth line of submissions entering the Agile 2013 submission system over the two months it was open. Yeah, right!
I get to see a few interesting behaviors in my role on the Agile 2013 program committee, but the most interesting is just how strong student syndrome is in our community. A couple of the more interesting things I noted:
- The several emails to the program committee asking what time of day a two-month-long window will close for new submissions
- The several people who potentially lose their ability to submit due to technical issues in the last hours of the submission window
- 70% of submissions were submitted in the last 7 days
- 54% of submissions were submitted in the last 2 days!