Louis did a far better job of blogging about the session I facilitated at KaizenConf than perhaps I ever could. He has a three-post series that describes and combines ideas from the session on Activity Modeling convened by Michael Long.
Coming out of the conference, I have way more blog entries that I want to write than I have time to write them. I'm going to put out some teaser titles here to give you an idea of where I want to head over the next month or so. If you're particularly interested in something, let me know, and I'll focus on that one first. Otherwise, I plan on writing in the order listed below.
Single Piece Flow and Kanban are not the same thing
As lean software development gains popularity, many people are blogging about and starting to apply it, with largely great results. But I think that some of the semantics are getting confused, and to a poor end. I'll clarify my concern, and discuss how to move forward with a clearer understanding of Kanban and Flow.
Driving toward the goal: applying standard work to software development
Here, I'll discuss the design of the workshop and my expectations. I'll talk a little bit about some of the choices I made the week before and then while at the conference to adapt to some changing circumstances and personal goals. I'll discuss what actually happened in spite of that, and I'll talk a bit about what I would do differently next time.
Outcome Driven Development
AKA Goal-Driven AKA "On Purpose" Development. How we can use goal statements and intermediate objective maps to increase profitability, eliminate gold-plating, and have more fun writing software.
Inflicting Change and Agile Adoption
With Agile crossing the chasm, many organizations are mandating adoption. This can lead to broad-scale cargo-culting and mis-application of practice. There were several reports of teams having high turnover numbers when adopting agile. What do we need to do to stop that trend?
Start where you are, not where you think you ought to be.
Kanban is receiving a lot of attention lately, and for good reason. Kanban provides a powerful tool to optimize toward flow and recognize which parts of your process require the most attention. One of the best things about Kanban is that you don't have to adopt new practices apart from work-in-progress limits and pull. These two are relatively simple conceptually, but difficult when executed. It is actually dangerous to adopt Kanban and change up the process at the same time.
To why, a who what (where, when, and how much) and activity modeling
Elaboration on a previous post about user stories. Why I think user stories as currently written according to popular practice are actually more hurtful than good, and what I suggest you do instead.
Why stories are better than use cases
[Some] stories are better than use cases, because they focus on the goals of the user rather than the use of the system. By focusing on the goals, we give focus to the use of the system so that we can eliminate gold plating.
Why stories are worse than use cases
Use cases provide more scaffolding and prescription. This can make them easier for novices to adopt and be successful.
SAFE Scenarios
People have goals. We build technology to enable them to attain their goals more effectively.
SAFE and Minimum Marketable Features
I often wonder what makes something marketable. Why do people like to buy iPhones? Why do some iPhone apps get purchased more than others? Here, I'll discuss the S.A.F.E. scenario idea from a naive marketing point of view.
Agile and Sub-optimization
Once upon a time, there was a team. The team was constantly under pressure to deliver, and they were constantly behind schedule and over cost. They adopted agile, and got much better at delivery. So much so that management cut their team in half in a sad bit of cost accounting.
Creating a Structured Environment for Learning using Kanban
This is essentially a regurgitation of the standard work workshop from the point of view of software development/continual improvement.
Improving Day
One of the outcomes of the KaizenConf was to create a day of improving (I'm biased toward "Improving" :). Come up with simple improvement experiments, conduct them, blog, twitter, whatever the results.
