I cut my teeth as a software professional in the 90's as my division went from
CMM level 1 to 3. I was a
BDUF guy and would brow beat anyone who disagreed. Needless to say, I was unbearable in my youth! I eventually grew up (to some degree) and learned that I didn't know everything and began to question the
BDUF mentality. I read Beck's
Extreme Programming Explained in 2000 and
stumbled on to Agile Manifesto in 2001. I wasn't convinced at first but the ideas bounced around for a while an by 2002 I was convinced.
I preached Agile to anyone that would listen. I wrote about it, taught it, practiced it and even lived it. I guess you could say I was an Agile disciple. My career has taken me places where agile was used in ways that I would call non-agile and in ways that seemed agile but didn't work well. I began to think that maybe agile wasn't the best way to work. Don't misunderstand me, it beat BDUF hands down, but there where things that I wasn't convinced of:
- Why do we need a definite sprint/cycle time?
- Why does the customer need to split his ideas to fit the developers way of working?
- Why spend time on micro-estimates?
I had read a lot of Lean books back in my agile craze (2002-2005) but never could find a practical approach. I had even had dinner with the
Poppendieck's and questioned how they made the leap from the Lean principles (value, flow, pull, perfection) to their
lean software principles in their
book. They were convincing, but I was skeptical (a common theme).
In my current career I get to wear many hats. I support live systems as well as writing new software. It took a while for me to find a process that worked. I couldn't do my
one week iteration as I couldn't commit to a single day due to the multi-hat issue. My customers were not very available and features were chunky. I did have a co-worker so I could pair and TDD so I went for it. We did one hour blocks, scheduled each morning based on our work load (he had his hats to juggle as well). We still used estimation, but I found that to be a waste of time as we never used the data. We used feature slices (take a feature and define a chunk of work that was visible and could be done in less than an hour, no internal only chunks. I have
examples buried in this post http://mwpolen.blogspot.com/2007_04_01_archive.html) The results were good. We met dates even though some weeks had us meeting only five times. Our quality was good and the
customers were happy.
Lately I have been reading a lot on
kanban (
9 stuffs to date) and like the way they focus on pull. When I find myself in an area where it is not clear what is right I tend to go to the root principles.
Hmmm what are good root software principles? I'm not sure I have any, so I will use
Lean's as documented in Lean Thinking (value, flow, pull perfection). Value and is easy to me as agile got the community focused on that years ago. Pull seems easy as well as I always pull the highest priority item and I think the agile community has done a good job here as well.
Flow...that's tricky. Software doesn't have pieces that come together in a
manufacturing sense. I think software is design so I will use flow to mean the flow of the design as documented in code. I am thinking of a flow of a river and how I don't want trees caught on any rocks in my river (which is a metaphor for my design). I like that idea...probably been used before but my google skills can't find it. Then flow is a clear design (clear river path) which is represented by
clean code.
All that leaves is perfection which I like to state as continuous improvement. This one is interesting to me. The thing I have always done through my career is try to improve. Even in my BDUF days I was always looking for ways to make a better design. Agile talked about this and tended to box this inside a practice commonly called a retrospective. I was a big fan, but I have found that retrospectives are hard to do correctly. I think the reason is that is you box the principle then it's easy to push the box around. I think continuous improvement has to be a focus every day, every hour. There is no time that is a bad time for improvement.
I think I have a better understanding of where I am
philosophically. I'm not sure agile as a term works for me anymore. It did a great job pushing the software off of the waterfall tower. I will always think good thoughts about the movement and I think all software developers owe a great deal to those
authors who banded together and pushed and pushed. Now it's a snowball picking up things they never intended, but that's the
law of unintended consequences. I think lean and
kanban can push us towards a being better and I hope they do as I still see lots of software that doesn't do the job it should. We have come a long way, but there is so much more to do. I guess that's what draws me to software development. No matter how good you are there is always room for improvement.
