The 7 Software Development Wastes - Part 1

June 28, 2009 by Jack Milunsky

Introduction

The more I learn about Lean, the more I realize how much we can learn from Lean teachings and how they apply to software development practices. Typically, we go about our day-to-day activities without thinking about the bigger picture. Lean specifically addresses the complete end-to-end process with the view of enhancing cycle time and quality.

Lean

Value stream mapping is one of the key areas for helping us learn where we fail, but in particular, what I'd like to address in the next series of posts are the 7 wastes which Lean identifies and which I believe are worth mentioning. Once you hear about these wastes I believe you will be more sensitive to realizing when you see these manifested in your organization and should therefore help you to enhance the overall productivity of your teams.

Who's the owner? Shared code vs. code ownership

June 23, 2009 by Mendelt Siebenga

I think it's widely recognized that shared code is important in agile teams. It's an effective way to streamline your development process, making your teams more flexible and productive. Transitioning from code-ownership to shared code can be hard. Lets compare the two, look at the problems in transitioning from one to the other and see how we can ease this transition.

Shared code is only a corollary practice in extreme programming but most agile teams I've seen implement it successfully. Many other teams are still in a situation where team members have what I call code ownership, the code base is divided into parts that can only be edited by certain persons or groups within the team. Usually the code is divided along lines of expertise, for example database-professionals develop the database, the back-end and domain logic is developed by one or more experts, and interaction designers and UI developers are responsible for the user interface. The reasons for this division are usually efficiency, people work on the parts of the code that fit their skill set, and responsibility, when something is wrong it's easy to find the guilty party by looking at what piece of the code failed.

Chopper Shops

June 22, 2009 by Janusz Marcin Gorycki

Photo (c) Janusz Gorycki

I have been watching an episode of American Chopper the other day. I must admit that I am a bit of a fan of this show – not necessarily because of its main plot premise of a clash of personality between the father and the soon (which is rather cheesy and quite clearly badly acted instead of real), but rather because I like watching “how stuff is built” - in this case, how you can build a gorgeously looking motorcycles from the rusty pieces of metal, using not much more than a set of rather primitive tools.

It was an episode where the guys at OCC bought themselves a super modern, computer-controlled metal-cutting machinery of some sort. At the same time, they had to resort to making order with some misbehaving part of the motorcycle being constructed by whacking it hard with a big hammer.

Watching this show got me thinking: this sort of work is very similar to what I am doing every day creating software. I always cringe when I read somebody likens software development to a factory line. Even if it is an “agile” factory line – like the Toyota Production System, which a lot of people in the agile community hold in such a reverence to that they almost pray to it daily. Because, you see, software development, in teams big or small , organizations huge or microscopic, is always a chopper shop rather than a factory.

Measuring velocity is not enough to determine team productivity

June 20, 2009 by Jack Milunsky

Introduction

Another interesting question was brought up in a LinkedIn discussion thread this week: "Is velocity the right approach to measure productivity of team members working in Scrum. If not, then how can productivity of team members be measured in Scrum?" Here are my thought on this topic.

The purpose of velocity

Like burndown charts, velocity is just another metric which the team can use to reach what I believe is the ultimate goal – sustainable throughput. Velocity in my opinion, is not a metric for determining productivity. Productivity or team efficiency is difficult to measure and probably best left for another blog post.

Burndown charts - It's not about staying below the line

June 13, 2009 by Jack Milunsky

Introduction
I recently participated in a Scrum development discussion thread on Yahoo Groups where one member new to Scrum asked the following: "Our burndown chart's remaining work line always goes up. As a Scrum Master, what do I have to do to make it go down?" This question, surprisingly, generated a lot of response from the community. I found it puzzling to see how adamant some were to introduce solutions to get the remaining work line to go below the estimated work line.

Open Space, an agile way of meeting

June 9, 2009 by Mendelt Siebenga

Last year I went to the European Agile Open conference, two intense days of meeting interesting and interested people and talking about all aspects of agile. I don't think I ever learned as much in two days. The conference was held entirely in the open space format and one impression I left with was that lots of the ideas we talked about there were also applied in the organization of the conference.

This week I had the pleasure of helping to organize my own open space event. The Open Space Code day in the Netherlands. We copied this idea from Alan Dean who has been organizing events like this for some time in the UK. I got the same impression, the dynamics are different, the goal is different but the event certainly feels like an agile project. I want to have a look at the similarities and see what we can learn from it.

Scrum falls short in at least one area in my opinion

June 5, 2009 by Jack Milunsky

Many of us have come to love Scrum, including me. Scrum has been a huge success overall and has turned many a development team around and for the better. Yet in my opinion, I think Scrum falls short in at least one area.

Concept to Cash

Firstly, It's commonly accepted that Scrum does not consider the whole life-cycle. i.e. it's a great framework for helping development teams tame the development life cycle but it does not tackle all areas from "concept to cash". Lean and Lean with Kanban certainly appears to be an alternative to Scrum or at least coupled with Scrum to provide and all round concept to cash highly effective framework for producing software products.

NASCAR. Adjustability gets you the winners flag every time

May 29, 2009 by Jack Milunsky

introduction
Always on the lookout for good analogies to help get my point across, I happened to tune into the Nascar roundup on Friday night. Jimmie Johnson was being interviewed about the upcoming event.

As I am sure you can now guess I am a Nascar fan. Most of my friends and colleagues can’t understand this because from the outside looking in, it’s just a bunch of cars going round and round on the same track – what could be more boring than that. Quite the contrary however, Nascar racing is anything but ordinary. It’s a sport that requires incredible concentration, teamwork and most of all careful strategy and agility to outsmart the competition.

XP2009

May 28, 2009 by Artem Marchenko

I tend to go to one big agile conference a year (doing a PhD helps to add motivation). This year it is XP2009 - the premier European conference on all things agile. Usually I publish some reports either after or even before the conference. This year I got lazy extremely busy having a PhD symposium, a paper and a workshop to run and instead of a creative reporting I just let you see the photos to get a feeling of what the conference atmosphere was like.

If you wonder about the place, everything happens on a very lovely place on the Italian island Sardinia.

Unfortunately I am still bad with remembering people I don’t know very well, so if you recognize an unnamed person, tell his name in the comment and I’ll update the post. This post will be updated if I add more photos later.

First several random pictures of the people talking.

Are you efficient or effective?

May 28, 2009 by Mendelt Siebenga

Efficiency and effectiveness are two words that are often used interchangeably. Many methodologies promise 'increased efficiency and effectiveness'. I find this strange because in a rapidly changing environment like software engineering these two are often mutually exclusive. I think in order to understand agility it’s important to understand the differences between these two and the tradeoffs you are making between them.