Posts Tagged “waste”

A few years back, when my wife and I still had enough free time to do our home remodeling ourselves, we gutted our kitchen and rebuilt it with free-standing kitchen cabinets from IKEA. (For what it’s worth, IKEA kitchen cabinets are surprisingly robust.)

I was recalling this activity earlier today as I reflected upon the flaming waterfall project that I am currently attempting to douse with a steady spray of agile practice and discipline. What would have happened if we would have taken a waterfall approach to our IKEA kitchen?

The high-level design and scoping decisions would have been the same. Basically, we still would have needed to measure and select the right assortment of cabinets to fit in the space and correctly distribute our appliances. But, then, implementation would have been fundamentally different.

Tough as they are, IKEA cabinets still come in flat-pack boxes, and assembly is anything but simple. We worked our way through the cabinets in an iterative fashion. Unpacking all the parts for a single cabinet, reviewing the instruction, assembling the cabinet, then leveling it in place. At the time, I never thought of this as iterative. In retrospect, I realize it was.

Had we waterfalled our kitchen we would have emptied every flatpack box. We then would have confirmed, cabinet by cabinet, whether we had each and every part required for each cabinet. Next, we would have read all the directions for every cabinet, ensuring we had all the tools and skills to build each cabinet. We then we would have assembled all the cabinets in an allen-key-twirling frenzy. And finally, we would have positioned and leveled the cabinets in one fell swoop.

Waterfalling the kitchen would have posed two significant challenges. First, we did not have the physical space to unpack and sort everything without falling over ourselves and–much more serious–mixing different pieces from different cabinets.

Second, since every cabinet was different, surveying all the pieces and reading all the directions in advance would likely have done more to confuse than help us. Only one cabinet needed a hammer, but two others needed a rubber mallet. One cabinet was built from the countertop down. The others from the shell up. The sink cabinet required modifications as we went, since we were repurposing a corner cabinet for that purpose (and we needed additional tools for that). We didn’t need to know all these things in advance. It would have been overwhelming. We needed to know these particulars in context, as we were working on each cabinet.

We even discovered a piece missing from one of the cabinet packs, and it was no simple screw. We discovered it as we were assembling that cabinet and took a fifteen minute trip to the local hardware store (NOT Home Depot) where the owner disappeared into the back and returned five minutes later with a stisfactory substitute part. No upfront review needed; and no arduous trek back to IKEA required.

Now, some will argue that many software development projects are vastly more complicated than my weekend kitchen project. Such statements play exactly to my points above.

First, just as we would have had physical constraints around unpacking and assembling everything in our not-so-small kitchen, software teams have to contend with similar limiting factors. A development team that shifts from an all-encompasing design phase to a full-system buildhas to orchestrate branching and merging strategies, the sharing of test environments, and access to domain and technical experts across the entire system to be built, all at once.

Second, the all-encompassing deign phase (which would have be preceded by a requirements gathering bonanza) fills the team’s heads well beyond the brain’s saturation point with concepts, ideas and hundreds of details critical, trivial and everywhere in-between. When waterfalling into the build phase, you are letting a design-drunk team loose on your codebase. Because they’ve digested and designed everything, they’ve already forgotten significant portions of the system. They’ve likely misplaced and confused requirements and design details across features and components. This only gets worse the bigger and more complicated the system is. You could argue that the team must go back and reread all the requirements and design documentation before they start coding each part of the system, but that certainly sounds like unnecessary rework that most any self-respecting developer will ignore. It’ll all come back, naturally, as they write their code.

Thank God we didn’t waterfall the kitchen. It’s anyone’s guess where the sink would have ended up.

Comments No Comments »

Vision – or the lack of communicated vision – is a problem I’ve been trying to tackle on multiple teams for the last several months. The specific problem is caused by Product Owners (or Customers) who do not have a vision for the system they own.

It’s not that there isn’t anyone in the organization who has a vision for the system–that’s often the Product Owner’s boss. Rather, the troubles start when the boss delegates responsibility for product ownership but doesn’t take the time to instill that same individual with his or her desires and dreams for the system.

And what is the result of this failure to delegate vision with product ownership?

  1. Teams focusing on less, and even unimportant, features such as sophisticated admin functionality that only benefits Product Owner.
  2. An undercurrent of doubt within that team that the development path is not directed toward an overarching, understood, and meaningful goal. (This undercurrent will, at best, draw away productivity and, at worst, foster team-wide infighting over the development direction.)
  3. A completed system that does not deliver business value.

In one word, it’s waste.

Comments 3 Comments »

I’ve spent some time over the last week devising the simplest agile process I could come up with. Why? Because sometimes it makes sense to strip a process down to its absolute bare essentials and to build it back up again. This way we challenge our assumptions about what really needs to be in the process. We identify false safety nets, white elephants and non-obvious impediments. More generally, we can locate and eliminate the waste in our process.

So, what goes into the most simple of agile processes? To be both agile and effective I decided that the process had to be iterative, it had to encourage communication, it had to focus on delivery, and it had to be drawn entirely from techniques that I have seen work in practice on real teams.

So, without further ado:

Pretty simple, huh? A lot of this should be self-explanatory, but I’ll dive into the detail in my next post.

Comments No Comments »

Just one day after I wrote my first post on the CTA here in Chicago I was exiting one of the shiny new stations that the CTA has been blowing my hard-earned dollars on. Apparently, the station is too shiny. It was a rainy day and I was descending from the train platform. As soon as I hit the bottom of the steps I saw they guy right in front of me nearly do a face-plant on the flashy marbled floor.

More than one hundred years in the mass transit business and the CTA cannot even select the right flooring. Concrete may not be all that pretty but at least it’s not a lawsuit magnet.

The coup de grâce came as I was exiting the station. The attendant began shouting over the public address system: “Passengers enterring the station be careful. The floors are slippery when wet.”

Comments 2 Comments »

Remember, back in grade school, when we used to get snow days? That is, when there was so much snow that they announced over the radio that school was closed for the day and — even better — we got to spend all day playing in the snow? Remember that year when we had so many snow days that we had to stay in school a couple extra days at the beginning of summer to make up for them while kids from other schools got to start vacation? That kind of sucked.

On agile teams — even experienced ones — I often seen people take snow days. Sometimes the estimates were simply too conservative, and sometimes all the remaining development tasks get blocked by external dependencies. Either way, team members find themselves with no open tasks to complete days before the end of the iteration and, instead of going to the team, the project manager, the tech lead, or the team customer to ask what they should work on next, they take a couple snow days. Of course they come to work and of course they do work, but they often spend the snow days on interesting but low priority tasks.

Read the rest of this entry »

Comments No Comments »

You can get stuff done faster and be more green by reducing the amount of documentation your team produces. Who would have thought that agile and environmentalism can coincide? Of course, sometimes we do need to document, because it will save us trouble, pain and money down the road. But how does an individual or team decide when to invest in documentation? Here’s a handy checklist of questions to determine whether that document really is worth creating. The answers (or lack thereof) to these questions will shape more valuable documents and keep you from generating unnecessary ones. Read the rest of this entry »

Comments 1 Comment »