Waste!

In our industry no one recommends increasing waste, there are no waste evangelists, and no pro-waste lobby. So why is there so much of it? As we scramble frantically through the day to please our customers we are often not even aware of the pointless trail of half done work and unwanted features we leave in our wake. This article helps you understand what waste is, where it comes from, and what you can do about it by mapping the seven wastes of Lean Manufacturing into the software development field. If you want both better software and happier customers then quit wasting time and read this article.

This article originally appeared in the October issue of No Fluff Just Stuff magazine. The full article is available on the Canoo blog. As always, you can upvote at DZone.

Thanks for bearing with the teaser/redirect thing I keep having to do.

Lean Groovy 7 - Optimize the Whole

The successful software project is dependent on more than just the proper functioning of each part of the life-cycle: coding, testing, analysis, and deployment. Success hinges on how well all of these pieces fit together. Optimizing the Whole in Lean refers to making sure you always measure up. Improving your business is too often an exercise in sub-optimization: you may spend all your effort on improving the unit testing experience without realizing that it’s your interactions with operations that are derailing the project, or you may perfect your team’s delivery process while the rest of the company continues behaving wastefully...

Yep, it happened again. I put a two sentence teaser here only to redirect you to the full article over on the Canoo web site. That's just how I roll. I've got tiger blood from a different terrestrial plane. Or something.

Anyway, check out the full article and vote at DZone!

Beginner Bash: Must-Know Bash Commands

I switched full time to Ubuntu Linux last year and haven’t looked back. In this year I’ve learned to love the Bash shell (which includes the Terminal in Mac and Cygwin on Windows). At this point, I can finally say I’m faster in Bash then I was in Windows Explorer, Commander, Nautilus, or the Windows command prompt; and I prided myself on being a guy with a lot of .bat files. My goal now is to write some tips I learned in the last year. Before explaining the more advanced stuff I want to introduce some of the most basic basics.

So here it is: "Stuff I wish someone had explained clearly to me a year ago". Almost all these apply to Cygwin in Windows as well as Mac/Ubuntu Terminal.

As is usual these days, the full article is available on the Canoo blog. And if you want to upvote then head on over to DZone or clicky clicky on up arrow at the bottom of the post.

Slimmed Down Software – A Lean, Groovy Approach Part 6 – Respect People

Respecting people means creating an environment where the human element drives innovation and value. Creative problem solving and spontaneity are our most valuable assets, and great companies arrange their development process to let every single employee be able to exercise these traits...

The entire article, as usual, is available over to the Canoo Blog. And you can of course vote on DZone.

This article originally appeared in the September 2010 edition of GroovyMag, the Groovy and Grails magazine. Part 7 is currently available for download from the magazine’s site, and more will come each month. Previous articles in this series are on the Canoo website: Part 1: Eliminate Waste, Part 2: Build Quality In, Part 3: Create Knowledge, Part 4: Defer Commitment, and Part 5: Deliver Fast. Lastly, if you like this, you may want to check out some of my older blog posts from my personal site under the ‘craft’ category. Enjoy!

Slimmed Down Software- A Lean, Groovy Approach Part 5 - Deliver Fast

"It is clear and logical that developing features in small increments means you deliver sooner, and there is value in that. Delivering a partial system on an earlier calendar date means the customer starts accruing a return on investment before project completion, and this can even result in the system paying for itself before the project is even finished. But will delivering smaller increments really increase your output in the long term? The answer from queuing theory research is a resounding "yes"...

Part 5 of Slimmed Down Software is now available on the Canoo Blog. To read the entire article please surf on over there. And if you want to be kind then upvote at DZone.

This article originally appeared in the August 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 6 and 7 are currently available for download from the magazine’s site, and more will come each month. Previous articles in this series are on the Canoo website: Part 1: Eliminate Waste, Part 2: Build Quality In, Part 3: Create Knowledge, and Part 4: Defer Commitment. Lastly, if you like this, you may want to check out some of my older blog posts from my personal site under the ‘craft’ category. Enjoy!

IntelliJ IDEA Shortcut Wallpaper

The fastest developers use the keyboard almost exclusively. To help you learn the IntelliJ IDEA shortcuts, I created a desktop wallpaper that lists the most common ones for Linux, Mac and Windows users. Can't remember the command? Just pop up the desktop and check it out. Bored while waiting for a compile? Ditto.


There are a few resolutions:

IntelliJ IDEA Linux/Windows 1440x900
IntelliJ IDEA Macintosh 1440x900
IntelliJ IDEA Linux/Windows 1680x1050
IntelliJ IDEA Macintosh 1680x1050
IntelliJ IDEA Linux/Windows 1920x1200
IntelliJ IDEA Macintosh 1920x1200


Not on IDEA? You can download the Eclipse Desktop wallpaper from us, or the vim quick reference from our friend Ted Naleid.

doce ut discas - Teach, that you yourself may learn.

Eclipse Keyboard Shortcut Wallpaper

The fastest developers use the keyboard almost exclusively. To help you (and me) learn the Eclipse shortcuts, I created a desktop wallpaper that lists the most common ones for Linux, Macintosh and Windows users. Can't remember the command? Just pop up the desktop and check it out. Bored while waiting for a compile? Ditto.

There are a few resolutions:

Eclipse Linux/Windows 1280x1024
Eclipse Linux/Windows 1440x900
Eclipse Linux/Windows 1680x1050
Eclipse Linux/Windows 1920x1080


Not on Eclipse? You can download the IntelliJ IDEA wallpaper from us, or the vim quick reference from our friend Ted Naleid.

doce ut discas - Teach, that you yourself may learn.

More Pecha Kucha Lessons Learned

Last weekend was Canoo’s annual Continuous Improvement workshop, where we retreat to our secret Alp fortress to discuss the coming year and where we want to go as a company. My favorite memory is getting licked by a cow in a breakout session. Only in Switzerland. My second favorite was the Pecha Kucha contest.

A Pecha Kucha is a 20 slide presentation where each slide is presented for only 20 seconds. That’s 6 minutes and 20 seconds total. It’s a lot different than a normal presentation, and I’ve already blogged my “9 Beginner Mistakes” a few years ago. After watching 6 other people give Pecha Kuchas, I was struck by a couple common themes in what was working and what wasn’t. Check out my Canoo.com blog post "More Pecha Kucha Lessons Learned" to read more about Pecha Kuchas and what I think it takes to deliver a great one.

Slimmed Down Software – A Lean, Groovy Approach Part 4 – Defer Commitment

Just published a new blog post over on Canoo.com. In my humble opinion, this is the best one of the series. Less code, more jokes, and more ideas than normal. Check it out here:

Part 4 of Lean Groovy - Deferred Commitment

(or be kind and vote at DZone.)

This article originally appeared in the July 2010 edition of GroovyMag, the Groovy and Grails magazine. Parts 5 and 6 are currently available for download from the magazine’s site, and more will come each month. Previous articles in this series are on the Canoo website: Part 1: Eliminate Waste, Part 2: Build Quality In, and Part 3: Create Knowledge. Lastly, if you like this, you may want to check out some of my older blog posts from my personal site under the “craft” category. Enjoy!

Slimmed Down Software – A Lean, Groovy Approach Part 3 – Create Knowledge

Alright, another episode of Lean Groovy has entered the public domain.

This month we take a look at the Spock framework with "Slimmed Down Software – A Lean, Groovy Approach Part 3 – Create Knowledge".

Part 4 and 5 are available today from GroovyMag. More to come shortly.

If you like it vote at DZone: http://is.gd/eenuZ

Ubuntu Kung-Fu – 10 Best Tricks (and some even work on Macs)

I switched to Ubuntu at home about a year ago and at work on January 1st. At this point I don't think I could ever go back to anything else (including my wife's sleek looking Macintosh).

Over my summer break I bought the book Ubuntu Kung-Fu. It was a fun and valuable read. I wrote up a quick note about my 10 favorite tricks over on the Canoo blog. You can read it there or head over to DZone to show your love with an upvote.

Slimmed Down Software – A Lean, Groovy Approach Part 2 – Build Quality In

The 2nd part of "Slimmed Down Software - A Lean, Groovy Approach" is posted over on the Canoo Blog.

This was originally printed in GroovyMag, and parts 3 and 4 are available now from the GroovyMag website.

If you like it then be sure to vote at DZone.

IT Certification Alternatives: Cost Benefit Analysis

I wrote a blog post about IT Certifications over on the Canoo Blog.

IT Certification Alternatives: Cost Benefit Analysis

I think there are a lot of good opportunities outside of the traditional MCSP/SCJP track that are lower risk, higher value, and lower cost.

As always, votes at DZone or Reddit appreciated.

Slimmed Down Software – A Lean, Groovy Approach Part 1 – Eliminate Waste

GroovyMag is currently running a 7 part series I wrote called "Slimmed Down Software - A Lean, Groovy Approach". Part 1 started in the April 2010 edition, and now that it is June the copyright has reverted back to me and I get to self publish it on the web! If you like this then consider buying the May and June issues.

The full article is published on the Canoo Blog. As usual, up-votes at DZone are welcome.

Here's the summary:

The Groovy Programming Language advertises itself as an “agile and dynamic language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

Slimmed Down Software – A Lean, Groovy Approach in GroovyMag

The newest issue of GroovyMag is hot off the presses, and it contains the first of seven articles on Lean Software and Groovy.

The title is “Slimmed Down Software – A Lean, Groovy Approach Part 1 – Eliminate Waste”, and from the article:

The Groovy Programming Language advertises itself as an “agile and dynamic language for the JVM”, but what does this mean exactly? This series of articles explains Lean Software Development, and shows how your choice of programming language can make your entire process remain nimble and adaptive. Each month will cover one of the seven Lean Software Development principles and explain how Groovy and the associated ecosystem help eliminate waste, defer commitment, and build quality into your product.

Enjoy!

60 Second Agility: ROTI Meetings

Always in search of the absolute minimum of ceremony, my last team "discovered" a useful agile practice that takes 60 seconds from start to end: the ROTI Meeting.

After every meeting, on the way out the door, draw a diagonal line on the whiteboard with the labels 0, 2, and 4.
Each person in turn gives a number on how the meeting performed as a "Return on Time Invested" and the person with the marker draws in the rating. Here is the rating scale we used:

0 = "I'd have been better off making a Starbuck's run. Complete waste of time"
1 = "You really should have let me stay at my desk and code"
2 = "This was an OK meeting. About as valuable as if I'd been coding"
3 = "Surprisingly, this was more valuable than if I'd been writing code"
4 = "Wow, this meeting saved me tons of time. Thank goodness I didn't skip it to code"

And then each person answers the same question, "What could be done to improve your number by one point?"

To do this in 60 seconds means there is no discussion. The feedback is what it is; no debating, no fixing problems, and no hurt feelings.

ROTI meetings create tacit, organization knowledge that can be acted upon by team members in the future. It drives a team towards less meetings (almost always a good thing), pushes team members to be more respectful of each others time and expertise, and influences meeting organizers to craft more succinct, on topic, and meaningful gatherings. It takes only 60 seconds so you might as well try it a few time!

... and now the historical details.

ROTI analysis is nicely described in Esther Derby's great book "Agile Retrospectives". The practice in the context of iteration retrospectives takes more lie 5 to 10 minutes. Our team found ROTI to be so effective in retrospectives that we shortened it and held one at the end of every meeting.

The actual ROTI scale is a bit more formal than what we created:

0 - Lost Principle: No Benefit Received for Time Invested Break-Even:
1 -
2- Received Benefit Equal to Time Invested High Return on Investment
3 -
4 - Received Benefit Greater than Time Invested

Lastly, ROTI charts are covered in detail a few other places as well.

For a mere 60 second investment, this practice is worth trying on your team.

The System Metaphor is Still Lame

The eXtreme Programming System Metaphor practice makes a pretty easy target. I've seen large development teams grind to a halt because of persistent broken builds without any continuous integration. I've seen teams' productivity drop to a crawl under the burden of technical debt and lack of test driven development. But what happens when a team lacks a good metaphor for how the system works? Can you really name a reasonable, realistic negative impact from a lack of system metaphor? Just last week I was dismissing it in an internal agility training as an unneeded XP practice. So I was surprised to see Joshua Kerievsky's and Brain Foote's "System Metaphor Revisited" talk at Agile 2009. Seriously, the guy who wrote Refactoring to Patterns is also hyping the System Metaphor? We'll see...

The thesis of the talk was that a System Metaphor provides illumination, inspiration, and integrity (...and alliteration). Briefly and in my own words, it illuminates an unfamiliar design by providing a reference point in the familiar. It inspires unexpected design ideas by providing a frame of reference in which to apply your creativity. And it builds integrity by suggesting a single, coherent, and consistent framework and set of names into the system.

And the Industrial Logic case study is just so cool. I've loved their marketing since they started with the "Let the Good Designs Roll" idea. I want to be a rock star and I want to take their training classes. And now their trainings are all hinged around the ideas of albums, tracks, and playlists. Very cool. I guess it helps to have a great product.

I have no doubt that the guys presenting have deemed their system metaphor a qualitative success for the project. But I still think the practice is totally lame.

A metaphor embedded in code is rigid. Having a great marketing metaphor is fine; marketing campaigns sell products. But they're also easy to change and refine, while an IT system is not. How many defects will be introduced if you change your marketing metaphor from a rock and roll concert to a book store? Not many. How many defects are introduced by changing the code to reflect this? Is none really the answer?

A metaphor is a 2nd ubiquitous language. One universal domain language is of clear benefit to a project. And that language should be the language of your users, domain experts, and programmers. A system metaphor is usually not this same language. For my projects, it's hard enough to try to get all the stakeholders to agree on terms of use. Introducing another layer of abstraction and the associated verbiage isn't going to help things. Ubiquitous language is important; but create it out of your domain not your metaphor.

A metaphor illuminates in the large, but confuses in the small. A metaphor guides you towards understanding when contemplating projects as a whole. It provides familiar signposts and a framework on which to hang ideas. But a lot of programming involves making small changes to systems you only partially understand. When this is the case, the metaphor becomes accidental complexity in the system. Having postage stamp, postage meter, and postage machine objects in your system helps the original design team, but doesn't help the contractor being asked to figure out why reports aren't printing.

A metaphor will likely become a mixed metaphor over time: consider a system that treats all data as streams. It's consistent and elegant. But eventually the Enterprise knocks on your door and you develop some sort of messaging service. Now your streams have mailboxes and can be put in message queues. This undermines the benefit of integrity via consistency. We live with this sort of ambiguity every day, but it doesn't mean we should accept it.

Metaphors do not decompose well. You system will grow, it will take on technical debt, and eventually it will need to be refactored, decomposed, and modularized. This is the natural rhythm of agile systems. When it comes time to break out components, will your modularization boundaries be natural boundaries within your metaphor? At a minimum, you'll probably end up discussing how the two don't line up correctly, and now you're spending time solving a self-created problem... surely a bad process smell. It seems like only the most dependency-obsessed team leads could foresee and prevent this. A YAGNI approach may not be your ally here.

In the end, I see a metaphor as a set of constraints. Humans can do their best and most creative thinking when provided rigid constraints. But constraints limit design ideas as much as suggest new ones. I'm sure some people have had success with a system metaphor, but I find success because of system metaphor a much harder pill to swallow. To all those espousing the use of system metaphor as a useful practice, I quote a famous and apocryphal doctor and say, "Clearly I can see you're nuts".

And just for fun, I used eight metaphors in this blogpost. There is no prize for finding them all.

Counter-intuitive Agile Coaching Tips

Just finished the "What Do Agile Coaches Do?" session from Rachel Davies and Liz Sedley at Agile 2009. It was a great workshop based on their new book and J. Richard Hackman's "Leading Teams".

Hackman defines three types of coaching intervention:

• Motivational - intended to improve team or team member's effort
• Consultative - intended to improve a team's process
• Educational - intended to improve a team's understanding
  

Today's first insight is that I personally focus on educational and consultative interventions, to the almost complete exclusion of motivational intervention. I'm not interested in giving people pep talks, so clearly I'm lacking some motivational skills and techniques. Anyway, Hackman defines three key times when these interventions should be used within a project:

• Beginning - focus on motivational intervention
• Midpoint - focus on consultative intervention
• End - focus on educational intervention
  

Delaying education until the end of a project sounds ludicrous. Wouldn't the begining be better, when people need it? The answer is to think of a project as an iteration, not a full release. Iteration start is when the team needs energy to commit to work and kick off the sprint. Makes sense that the "sprint" start is when you want to get a good start out of the blocks, huh? So the beginning is a good time for motivation after all. The iteration midpoint is when the team is neck deep in implementation and sees that not all their practices are working in their best interest. What's the solution? A small process tweak via consultative intervention. The end is the retrospective is where the whole team has a forum and opportunity to make big changes to how they work. That's the time where education on a new and unknown practice can make the biggest impact, because the team can commit to it and take action immediately. Hackman's description of when the interventions are most effective sounded fishy at first, but when viewed against an iterative process it makes sense!

But non of this is counter-intuitive coaching. The most interesting part of the workshop was our group's breakout session where we discussed coaching in the context of some manufactured scenarios from the speakers. We came up with these unique coaching strategies:

1) Coaching Through Absurdity
In my group was Alex Chin, and in order to get his team to estimate at the task level he added huge estimates to each task. These grossly absurd estimates forced the team to come back and add better estimates. Awesome idea. Next time my team won't make a decision I'm going to make an absurd one for them and wait for a reaction.
2) Letting People Fail
We spent a lot of time discussing how to guide a team down the correct path. If your team insists on walking precariously close to a metaphorical cliff, then don't waste your time each week shepherding them off it. Let them fall of the cliff once. Surely that will teach them to avoid it next time. Right?
3) Doing Nothing is Doing Something
You can lead a horse to water but you can't make him drink. Likewise, you can't force a feedback loop. Coaching is not just about knowing when to intervene, but when not to. If there is a team issue that needs resolving, sometimes you just need to get the people together and wait. Do nothing and let the team decide. The most effective way to coach is to set the stage for team emergence and then get out of the way! Agile isn't about the coach solving your problems, it's about the coach getting you to solve your own.

Agile 2009 Day 0: Kanban Bag Stuffing

Spent about 4 hours today packing 1500 conference bags for Agile 2009. Luckily, several guys from the Kanban-Dev mailing list showed up to turn a scene from Modern Times into an unique exercise in Lean production.

I won't explain much about the "Pull" system or queuing theory backing Lean production; rather, I'll just explain what we did.

We had about 1500 bags to pack with more than 25 items each: a lot of flyers, several books (including past volunteer Ahmed Sidky's Becoming Agile), and even some agile hand lotion (wtf, right? But it beats the face creme I got at a triathlon called, I kid you not, "every manjack"). Anyway, it all needed to be bagged, carted, and trolleyed to the reception area. Uff da.

The group split into two teams. Our goal was obviously to get the bags packed as quickly as possible. The Kanban experiment was used to create a system of flow, in which each group had a steady stream of product through their production line. Bottlenecks meant the upstream production unit should slow down and not having work to do meant the upstream unit had to speed up. But it wasn't about working more or working less to achieve flow. It was about tweaking the process so that everyone working hard would result in the flow. The group had to self organize and evolve so that this steady state existed. Over two shifts of people this did all happen to a certain extent. We didn't have measurements to see who was fastest, but each process did improve over time. Here are some observations, along with how they might apply to software teams:

• Having no leader meant that every team member contributed new ideas to process improvement. Does the leader of your software team sometimes stifle innovation?
• Having two teams meant that competition fueled more frequent improvements. What external forces are driving your software team to evolve?
• Having no roles created a system where shouting "We're out of Agile Hand Lotion" meant that the person most capable of grabbing more lotion at that point in time immediately pitched in to do the job. Are the roles in your organization lightweight enough to allow the right person to contribute?
• Having one set of workers out-of-sight (running trolleys through elevators and hotels) meant that it was more difficult for the group to self correct their entire process. Finished bags did pile up and we were at a loss as to how to make the trolley's move faster. What parts of your SDLC are out-of-sight and out-of-mind?
• Not producing a Value Stream Map meant it was difficult to see the whole and fix the real problem, which was slow elevators. VSMs are much lower ceremony than most people realize, and we could have done one. Can your team truly see the whole?
• Many improvements were small and non-obvious in retrospect - "Why don't we pack the books last because they are heaviest?" and "Open the bags more quickly by pulling the handle like this." Does your company have a process group that focuses on the macro view to the exclusion of the micro view?
  

At the end of the day, pro facilitator Jean Tabaka of Collaboration Explained fame hosted our retrospective for us. The format was ORID:

• Objective – Focus on the facts, hard evidence data
• Reflective – Focus on how that made people feel or other associations
• Interpretive – Focus on the impact and significance
• Decisive – Focus on next steps
  

It was a typical retrospective in that we gathered data and created a shared understanding of the event in the Objective phase, talked about our feelings and personal experiences in the Reflective phase, generated insights in the Interpretive phase, and voted with dots in the Decisive phase to create a list of action items for next year. She and the rest of the team did a great job, and both Kanban and the retrospective were superb ways to kick off the volunteer sessions!

And just because I get a kick out of having foreign characters in my posts: 看板 is the symbol for Kanban. Whee!

30 Days Locked in a Team Room

Spent the last 30 days in a conference room converted into a shared work area for me and four of my (now) closest co-workers. We had asked to be moved to a shared space but none of us actually expected it to happen. After a month of it, all I can say is:

I do not want work in a cubicle ever again for as long as I live. Ever. Period.

One dude whistles. One dude crunches mini carrots all day long. One person is negotiating a house sale on the phone. And I pop my gum incessantly (if I don't I get an overwhelming urge for tobacco products). Yet it is the best work environment I've had in years.

Today I had to write up a summary of the team's past 8 retrospectives. Almost every single action item from the retrospectives over 4 months had to do with improving communication in some form, talking to each other more frequently, or getting better feedback. Until we got the team room. After moving to a shared space, the action items had nothing to do with communication. Empirically speaking, the team room unequivocally solved our project's biggest problems.

A team room has absolutely not lead to more interruptions. Side conversations are very easy to ignore. And any question you have is usually answered within seconds. Compare that to sending someone an IM seeing if they are available and then wandering over to talk. Speaking of, it's been wonderful not having to run some stupid instant messenger program in the background all day.

Cubicles are inhumane. Solitary confinement is punishment under most systems. Closing ourselves off from human contact and than holding a meeting to discuss ways to improve collaboration is laughable if we didn't actually hold those meetings every few months.

The insanity ended for me 30 days ago. I never, ever want to go back to working in a cubicle.