Skip to main content

Waste in Software Development

I’ve been dipping into ‘Lean software development’ a little and have become very interested in waste detection. I have plenty of ‘a ha’ moments when I read about examples of waste in software development, but sometimes I wonder if authors talk their topic up for dramatic effect. Here are three examples of wasted time and effort I found by paying attention for just one day at work.

  1. We have regular status meetings when it’s getting close to releasing software in our department. We discuss any issues that are putting the release at risk, but mainly we discuss any defects that are outstanding and our chances of fixing them in time. During one of these meetings I enquired about the quality of software in general. “They found a severity 1 this week” somebody mentioned. I was interested and asked for more information. Turns out the severity 1 defect was found in BAT, however when the business was asked they reported that no one ever used this function/pressed this button. Some code(!) was being written to disable the functionality going forward, hence the severity 1 defect would go away. This was doubly depressing; not only had we wasted time in creating the un-used functionality in the first place, we were writing MORE code to disable the functionality.

  2. In the same meeting we discussed a defect that was a Severity 4 (least serious, usually cosmetic) It was for columns in a grid that did not automatically order when you clicked on them. The text that went along with the defect was something like “columns in grids are not ordering when clicked on, as they do in production” So we had effectively taken away some functionality from our production system. This was a real kicker, my first instinct was to increase the severity of the defect to be higher, to re-institute the ordering of columns. I really had to force myself to stop and ask whether anyone who used the columns cared if they could be ordered. Prior to that I was on the brink of becoming a perpetrator of waste myself! As I mulled over the wrong-ness of no one in the room knowing the business use of the control, I remembered the power of having high levels of engagement with business representatives as is the case on agile projects. Perhaps it should not be a QA or a BA or anyone but a business representative in that room telling us what severity should be attributed to each defect. It also made me reflect whether having a bunch of managers in a meeting discussing release progress, instead of the team that sweats on the system day in and day out, was not a waste in itself.

  3. My third and favourite example of waste discovered last Wednesday is akin to something you would set as a coding challenge. Our application has “Radio boxes” these are check boxes that behave like radio buttons. We were in a meeting discussing UI standards when I heard about these bespoke controls. Invented by a long gone BA who insisted they were ‘Vista UI standard’ a few years ago, these controls have been coded to override the paint event, and be check-box-like in appearance. Not only have they been coded to look different (waste number 1), they are a nightmare to maintain (waste 2); each time someone new to the department discovers a radio box they need to spend time thinking about why it is that way then spend time to understand the code so they can use the control (waste 3), or speak to someone else about them (waste 4). Users new to the application may even have to spend time thinking about why this control is different to every check box they have ever seen before (waste 5). They are coded so potentially could spawn defects also (waste 6). Six potential wastes because a BA wanted to diversify from the norm.

The probability for waste appears to be high in our software development life cycle. I’ve always loved agile development and never fully appreciated how close collaboration with business and development team prevents the creation of waste. I’m very hopeful for our new pilot agile project commencing in April and aiding the cause for minimising waste in the department.


T Ashok said…
I enjoyed your blog. Most often we are focused on activity and the attributes associated with the activity and not on the final goal. Hence it is common practice to look at defects and its severity attribute and make decisions, when we should look at the "business aspect(in this case how this affects the intended value") and make meaningful decisions.

What i have commonly observed is that we are are activity-centered and spend time creating reports that contain "the stage we are in" i.e. finished testing, done documentation etc. and not much as the intended purpose and the value it delivers.

T Ashok
AlexandraGeorge said…
So true Ashok, it takes an effort to break out of the processes we always follow and think laterally about the tasks we are doing and value we are adding. I catch myself several times a week doing this and try and remind all of us to continually question what we are doing and why. It's hard.

Thanks so much for dropping by, you are my first commentator!
Nice article, I was looking for these kind of information on software development. Please continue writing....

Popular posts from this blog

Business Requirement Documents are just no good and should be abolished from the world of creating software

I had hoped the world could have wholeheartedly rejected Business Requirement documents by now. For too long I’ve seen the repeated scenario of only commencing the creation of a new initiative with a requirements document.Unfortunately most organisations that have teams developing software still use these flawed anathemas to creativity as the status quo. Despite agile approaches maturing and customer-centric modes of design emerging, requirements documents still persist. 
If you work in an organisation that doesn’t use business requirement documents any more, read no further. You are lucky; sense has prevailed at your place however in my experience, you are still the minority.
Let's face it; addressing this issue is not always the point you want to start your improvement work when there's much that could be dysfunctional with how a team is delivering software. But now, I find myself as mad as hell, and I'm not going to take business requirement documents anymore. I want to …

Gamify your children

Inspired by James Ross’s LAST conference talk on The Shamification of Lamification and the Reclaimification of Gamification I was motivated to try and “Gamify” the school holidays for my three children, Leo aged 8, Chloe 9 and Max 10.
Buy-in is everything, so the first thing we did was a quick workshop to extract the kids ideas. I asked them to write their ideas for good rewards on sticky notes, with a few examples for context, such as ‘trip to the movies or ‘play date with a friend’ . They had 5 minutes to come up with their ideas – one idea per sticky note (as always).
They then read out their ideas for all of us to hear, there were a few duplicates and also a few comedy suggestions. Even though we had ruled out crazy stuff, such as rewards of a million dollars, Leo had written down ‘A unicorn for the back yard’ reading it out with gleeful giggles.
Then they spent 5 minutes writing down tasks that they could do to earn rewards. By now they had the hang of it and quickly came up with t…

Agile Australia 2011 Series - Agile Governance

If you are in an industry that is heavily into governance you need some structure and process around your projects or you could find your Agile projects getting usurped by the culture of command and control. So it’s important not to shy away from the topic but to work with the entities that enforce and monitor governance. In this way you can create something that is fast and easy and not laborious to work with.I work for an Apra regulated organisation and we made keenly aware of our obligation under Apra to evidence documented change when audited. However in all organisations I’ve ever worked in, there are boundaries that bend quite a bit, ways to change things and ways to get by that satisfy governance process without crippling your agile process.There’s almost two alternating schools of thought here which are ‘work within process’ and ‘decide to change the process’. It’s actually pretty easy for my team to work within process. Project approvals, mandates and PIDs that are important …