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.
That's understandable that cash can make us autonomous. But what to do when someone has no money? The one way only is to try to get the mortgage loans and short term loan.
Posted by: CindyAndrews | March 29, 2010 at 01:30 AM
For get the Superbowl because, in the words of Saint Snooki:
Oh my god, fucking Christmas.
I feel like I need a cigarette now because this meeting of minds, pop culture and entertainment was so exhilarating.
Posted by: Nike Shox TL3 | September 10, 2010 at 04:46 AM
For get the Superbowl because, in the words of Saint Snooki:
Oh my god, fucking Christmas.
I feel like I need a cigarette now because this meeting of minds, pop culture and entertainment was so exhilarating.
Posted by: Nike Shox TL3 | September 10, 2010 at 04:46 AM
Thanks for such nice and wonderful post. Every time like to read you.
Posted by: Cheyenne | September 16, 2010 at 01:41 AM
Nice blog!and interesting story above.
Posted by: cheap jordans | November 11, 2010 at 01:51 AM
I've noticed two weaknesses in projects that adopt agile:
1. A tendency to suddenly start underplanning. aka "Hey, Agile means I get to fly by the seat of my pants!" No more planning. Let's just write software! Go! Go! Go!
2. A refusal to manage or mitigate risk
They're good at identifying risk (and requirements that contain risk). But goals that contain risky elements are rewritten into multiple goals, one risky and one not; and the non-risky goal gets worked quickly and the risky goal deferred to later iterations. It's too hard. It takes too many man-hours to address. Etc, etc. Addressing it would slow us down; make our demos look as though we're not making any "progress". So the risk gets deferred and deferred til close to the end, and suddenly, the risk BITES, and the whole plan falls flat on its face because the architecture assumed the risky element would, or could, be resolved, but it has turned out in the end that it cannot. Moral of the story: Attack and address the risk early. PROVE it early.
Posted by: Mike Devx | October 24, 2011 at 06:26 AM
Following my own exploration, thousands of people on our planet receive the home loans from good creditors. Thus, there is a good chance to get a collateral loan in all countries.
Posted by: credit loans | December 31, 2011 at 03:10 AM