Random Thoughts on Lean Principles

Last night I finally received my copy of Lean Software Development: An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck. I’ve actually had quite a few books on order and as they’ve been coming I’ve hoped that they were this one. Finally it got here.

I started getting really interested in “Lean Concepts” after reading The Goal by Eliyahu M. Goldratt and Jeff Cox, a very well written “parable” illustrating the application of lean principles and the Theory of Constraints to the manufacturing process. This was the first book in a long time that I was completely drawn into – so much so that I actually dreamed about the content after I had finished reading the book. Thanks to John Goodsen for recommending this book to me, among others, while attending a recent training.

This posting is not a book review of the Lean Software Development: An Agile Toolkit for Software Development Managers book – that will come later. However I did want to point out that rarely have I been sucked into a book as quickly as I have been with this one. I think that this is because what I’ve read so far maps so closely with the content of The Goal that it jarred me a bit.

Chapter One starts with the first principle of Lean Development. Identifying and eliminating waste. The authors define waste as “something that does not directly add value as perceived by the customer”. They also assert that “If there is a way to do without it, it is waste”.

Here’s the strongest piece of this argument, taken directly from the book:

In 1970, Winston Royce wrote that the fundamental steps of all software development are analysis and coding. “[While] many additional development steps are required, none contribute as directly to the final product as analysis and coding, and all drive up the development costs”. With our definition of waste, we can interpret Royce’s comment to indicate that every step in the waterfall process except analysis and coding is waste.

The argument that the authors are making really make sense to me. What pieces of accepted software development practices are adding “direct value as perceived by the customer”? Does the customer appreciate the long requirements and design processes that wind up feeding into a process in which documentation then has to be generated to change the design of the system after requirements have been frozen? Do they appreciate the fact that we have a “process” to document each change that we make, even though, when push comes to shove, the documentation is rarely looked at as often as the code is? Is the long, drawn out process we IT people use to try to keep our world under control adding immediate perceived value to our customers lives?

“Perceived value to the customer” is another reason why I have always been confused to see development teams put more value on being involved in “projects” than maintaining current systems, whether it be fixing reported defects or adding requested functionality to an application. In my mind, these smaller changes and fixing of defects found BY customers are the things that make the customers life easier and that they will get value from almost instantaneously upon deployment (not to mention that more times than not, they are “chunked” properly). Larger scale “projects”, mostly perceived by teams as “sexier” work, are essentially (in many cases) just a guess from the busines as to what might create value.

I can see from just the first part of this book that this is going to be a really interesting and valueable read. I think it will definitely get my brain working again – and I know there will probably be quite a few rambling posts like this one about thoughts I have as I go through it. This is an area of thought that completely excites me, mainly because there is so much waste in our industry (IT) as a whole. Its kind of nice to read books every now and again that confirm that many of the thought processes you go through in your professional life are not as crazy as they seem sometimes.

Flowers For The Spouse of an Over Time Worker

Flowers For Ron?

Jonna started a new job a few months ago as a QA Analyst. She has been working tons of overtime over the past few months due to a new site launch. When we got back from the Bristol Renaissance Fair yesterday evening, we found these on the door step. My first reaction was “I wonder who is sending Jonna flowers?” They were actually for me, from her company – thanking me for my patience during the time she put in and the sacrifices I made for their launch.

I made fun of it at first – mainly because if anyone has sacrificed anything through our marriage, its Jonna. For most of our marriage I’ve been the one working all of the time and she hasn’t really gotten anything out of it. When she took the job, it was kind of just an expectation that there would be overtime on my part, coming from almost 20 years in IT (the last 7 in internet based applications with that 99.9% uptime rule). I also spend a lot of non-work time reading to keep up to speed on new developments and learning different languages just to keep current. To be honest, I didn’t think it was anything out of the ordinary for the role she was in.

I guess this just goes to show you that some companies actually do think about the ramifications that overtime has on employees families. After my initial time making fun of the fact that I actually got flowers, I started thinking about what a cool thing it is for a company to acknowledge an employees spouse in this way.

See? You learn something new every day!

iTunes Music Store Faster on a Mac?

I’ve been meaning to throw this question up here for a while. Is it just me, or is the iTunes Music store a hell of a lot faster on a Mac than it is on Windows?

While I like the convenience of iTunes, I absolutely dreaded hitting the music store on my Windows machine. It felt like it took forever to get any decent results. Since moving to the Mac though, the Music Store responds extremely quickly and I have no qualms about doing searches and browsing around now.

I’m just curious – has anyone else that has both types of machines noticed this behavior, or is it just my mind playing tricks on me?

Interview with Dave Thomas on Agile

I found a really good podcast called The Agile Toolkit Podcast, in which the host, Bob Payne, attends agile conferences and interviews people there. Some of the interviews include people like Bob Martin and Mary Poppendieck among many others.

The most interesting show I’ve listened to so far is an interview with Dave Thomas (of Pragmatic Programmer fame) about agile development.

For me, I think I found it interesting just in the fact that it is nice to hear someone that has the same views on development issues as I do. I’ve always been a big believer that methodologies are limiting and that each methodology should be tailored to the project team. One part of the conversation that I found extremely interesting was when Bob and Dave were talking about the dogma attached to many of the methodologies.

Recently I had attended an Agile Development training in which the instructor stated that if you weren’t using all of the components of XP, you weren’t doing Agile development. A good point that Dave made was that as XP was being developed, the teams it was being developed with actually evolved into using all of the practices at different stages of their team development. In other words, they didn’t start using all of the practices specified in XP – because they didn’t exist yet. Dave makes the point that teams need to evolve into all of the practices – and that its very difficult to implement all of them at one time. I actually think that each team will be sufficiently different enough that you may not need all of the practices, but only a core set of practices. Bob Martin also makes this point in his interview and lists the minimum set of practices that include very short cycles, an open office (a room which holds the identity of the project), test driven development (both unit and acceptance tests). He also mentions that its extremely difficult to do test driven development without continuous integration, so there are other practices that will be necessary as you begin to implement the minimum set. I actually believe that source control and automated builds are another of the core minimum practices that should be put in place before anything else – but thats just me.

Another area that Bob and Dave talk about extensively is the necessity of developers to look at other languages in the industry other than the core language they use day to day. One statement Dave makes is that he looks forward to the day that developers refer to themselves as “developers” rather than “Java developers”. I wholeheartedly look forward to that day as well.

I’ve always enjoyed learning new languages. If you run through the articles in this blog, you’ll see that every time I find some language that I don’t know – and understand the practical reasons why they exist, the chances are I start working in it right away (most recently, this language is Objective-C). I enjoyed this part of the conversation a lot, because Dave articulates very well how learning new languages can give you new insights as to how to implement things in different ways.

I’m a firm believer that in software development, you have to have a pretty large tool box. The right tool should be used for the right job. This is why in many of the things I’ve done over the years, different components are written in different languages depending on what I am doing. A web piece might be written in PHP, scripts done in PERL or Python, while other components could be written in C / C++. I’ve made a conscious effort over the years to expose myself to as many different languages as possible.

In order to have the flexibility to use the right tool for the right job, you really have to make an effort to get at least a high level understanding of the different tools available and what their strengths are. Thats the really nice thing about the conversation with Dave is that he articulates the idea that you don’t necessarily have to be an expert in all languages, but know enough to use them and glean knowledge from them and their design.

I have found each of the shows I’ve listened to from the Agile Toolkit Podcast very informative and totally worth the time investment. In the very least, I want my teams to make this a part of their learning program moving forward. There’s no better place to learn about Agile practices than from the people right in the middle of it.

New Things To Learn!

Learning Objective C

One of the really nice things about switching platforms is the plethora of new things one now has the capability to learn that you might not have found a reason to learn before.

I’m a stickler on having something practical to do when learning something. If I don’t have a real thing to shoot for when learning a language, its pretty much a guarantee that I won’t be able to learn it.

The conversion to the Mac platform, the availability of the development tools through the Apple Developer site, and some time spent reading iCon Steve Jobs: The Greatest Second Act in the History of Business has given me a lot of motivation to dig down and learn Objective C.

Free tools have been around for Objective C programming for quite a long time. The GCC compiler has supported Objective C as far back as I could remember. But frankly, I saw no reason to learn it when I had all of these scripting languages available and most of my Unix work has been either web based, or command line driven tools.

However, the last three or four weeks sitting with the Mac and working within the Mac UI has gotten my curiousity peaked on this odd little language that really gets no visibility until a few guys from NeXT choose it as the basis of their development tools. I really want first hand experience to understand why the guys at NeXT chose this language as the basis of their platform.

Now, I’ve done a lot of C and C++ programming in the past, so one might think that learning Objective C would be no big deal. I have to tell you, I’m struggling a bit. One thing I do think is pretty cool is the dynamic nature of the language. To me, it seems very Python / Ruby – ish in that respect. However, its a lot to learn and I’m really going to have to spend some quality time with some books to get familiar with the concepts. Its very different than C++.

I’ve got three books on order from Amazon: Programming in Objective-C, Learning Cocoa with Objective-C, 2nd Edition, and Building Cocoa Applications : A Step by Step Guide. Unfortunately, I received #2 before #1, and #1 is definitely the book I need first.

I think its pretty cool that I have the excuse to learn something completely different. The past four weeks on a new platform has been interesting to me. Its really like starting all over again with a whole new world available to me — which is what attracted me to this field in the first place.

Objective C Resources