- 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.
- 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.
- 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.