I'm Moving

I'm joining the Wordpress bandwagon. Please follow me to my new blog: www.agilist.net

When Coaching an Underdog Team

In a perfect world, members of a newly formed Agile team are highly skilled, and the role of the coach is to overlay Agile so the skills are employed in the right way, in the right place, and at the right time. But many of us don’t live in a perfect world.

As a coach, I have often been challenged with team members who lack fundamental software development skills. This can distract efforts to be successful with Agile…and when core skills are missing, there is risk that the organization will peg Agile as the culprit for poor results.

I have met a number of people who told me that Agile was abandoned at their company and dubbed a failure. Agile cannot ‘heal’ poor software development skills, rather, it helps teams that possess skills experience an order of magnitude improvement in results.

When tasked with coaching a team of underdogs, the first order of business is to assess the presence (or lack) of core software skills. If an underdog team is what it is, a successful coach recognizes the obligation to clearly separate Agile coaching efforts from those of teaching/mentoring fundamental skills. This will help a company balance it’s needs: To emphasize skills development, or to place more emphasis on successful delivery. If the latter is the emphasis, it may not choose to pursue that particular project with a team of underdogs.

Cards Don't Build Software, People Build Software

I've been reading/listening to a lot of chatter lately about where the tactical elements of SCRUM stop, and something additional is needed. I've seen and heard a lot of feedback indicating that the (purportedly) prescriptive components of SCRUM (story cards, SCRUM meeting procedures, backlogs, burndowns, etc.) are all replacements for things the PM used to do.

So if SCRUM is biased toward the (former) PM community, what about the rest? Even the best-written user story does not build software by itself. I still see a lot of churn and disagreement regarding how to effectively convert verbage on a card into quality working software. Some believe that a developer grabs a card and starts coding, while others believe that architecture, analysis, and design are all still essential activities needed to fulfill a requirement represented by a user story.

From observing behavior of new SCRUMers, if Story Cards are analogous to shouting, the subordinate/supporting tasks and deliverables are barely a whisper. Is this because it's assumed that traditional Project Management is broken, but Development is fine as long as we leave the developers alone and just let them code?

Just because I'm Agile, doesn't mean that I need to abandon the multitude of communication tools that help ensure that we build the right thing. I still like storyboards, data element definitions, domain models, use cases, state chart diagrams, business process models, communication diagrams, sequence diagrams, data models, etc. A lot of software requires a great deal of precision - If I don't write down or draw models of the software I need, I'm bound to forget. What tends to be lost on a lot of new Agile adopters is: It's okay to write things down, just don't try to write down absolutely everything before you start building.

Go Ahead and Eavesdrop

A few years ago I managed a team of learning content developers for an international consulting firm. One of my many trips brought me to Paris, France to check on the progress of a course being developed there. One of my friends and colleages, Thierry, honored my visit by organizing a dinner for some of the employees and their spouses.

We went to a hotel at Versailles and were seated at a large round table on the back patio - I think there were 12 of us. It was a beautiful summer night, and everything was perfect. The food was great, and everyone was chatting up a storm, so all seemed to be having a good time. In the midst of the chatter, Thierry shouted, "Hey everyone, you're all speaking in French. Ken doesn't speak French, so please speak in English." I was a bit embarrassed, and I can imagine that some of the wives may have been thinking, "The lazy American comes to our country and he can't even speak our language."

One of the wives said out loud, "But why? We're not even talking to him?" Although everyone laughed, she made an interesting point which begs the question, "What would have been the point of me hearing all those conversations that I wasn't intended to be a part of?" I believe that in an informal setting like this, people are expected to eavesdrop a bit and jump in and out of conversations at will.

Recalling this story caused me to think about all the collateral and indirect communication that occurs in a team room. At times, the dynamics in the team room involve any number of impromptu conversations. Often times, others could contribute to (or learn from) those conversations, even though they didn't receive an engraved invitation to participate.

The informality of impromptu conversations includes an implicit invitation to tune out, listen, or jump in fully and contribute. I contend that much of the high value communication that moves a project forward occurs this way.

Now Hear This!

For those of you (like me) who didn't make it to Agile 2008, I found the next best thing. There are some great podcasts of interviews with folks from the conference, as well as from the prior two "Agile 200n" conferences. These podcasts are professionally produced and well done. Last night driving home I listened to a discussion with John Stahl about gimmics they use in the team room to keep the mood fun. For example, they got a gong that gets gonged during the SCRUM meeting every time somebody reports completion of a task. Even if you're not so much into gimmics, I'm sure you'll find some other useful nuggets on these podcasts. Click here for the RSS feed with links to all of the Agile Toolkit podcasts.

I subscribed to the Podcast on iTunes so I can keep up with all of them up on my iPod automatically. I don't know how to link you to the iTunes subscription, but if you go to the iTunes store and search for "Agile Toolkit Podcast" you should find it. If you don't know how to do that, give me shout and I'll try to help.

Hoarding Tasks

They finally restocked the Splenda in the break room this morning. I have an unquenchable sweet tooth, and usually put a couple packets in my tea. The bin has been empty all week, so when I saw it fully stocked this morning I was half tempted to grab several of them to keep in my desk to use the next time they run out. It dawned on me that if each of the 400 employees in this office grabbed just 20 packs, there would be 16 cases – or 8000 packets sitting unused throughout the building.

The same thing happens when we hoard work. If I grab a handful of tasks and only work on one or two at a time, I could be blocking others from pitching in to help with the ones that are just sitting there. Granted, everyone else on a project team may likely be working on some of the tasks they nabbed…but what if their time would be better spent on the pending tasks in my queue?

This gets to the heart of the reasoning behind meeting as a team daily and pulling work from the backlog that is doable that day and only that day. For tasks that multiple team members are qualified to complete, it allows the highest priority tasks to get continuously burned down. If tasks requiring specialized skills possessed by few team members start stacking up, it provides an opportunity to pull in additional help to eliminate the bottleneck. Ain’t it sweet?

Balancing Mechanization, Psychology, Sociology and Business on Agile Projects

I'm not frustrated by Brett's comments about assertions in my Blogs. I'm actually flattered, and happy that he's reading them. Tenure doesn't necessarily earn me any more credibility than smart successful people with fewer years of experience.

My eclectic undergraduate training (Mgmt Science/Operations Research + Psychology minor) augmented later by an MBA illustrate where my interests lie. I've always been a fan of Franklin and Lillian Gilbreth's time motion work in the early 1900's, and later of Goldratt's Theory of Constraints. On the other hand, my interest in Psychology and Sociology tends to clash with the concept of applying a pure process optimization approach to software development. I'm further fascinated that software developers took so darned long to pay any attention at all to those old proven methods. It's all these things that I find so fascinating.

When it comes to human behavior in a social environment, there are few wrong answers. There are far too many uncontrollable variables to be able to treat human processes as a science. I am fairly certain that most humans don't want to be cogs in a machine. Even those who are willing to be cogs will probably dislike it after a while. (Then again, I'm sure you can't say that about everyone.)

I do agree with Khan that lag time is the primary cause of delays on projects. (btw - per your comment, I updated my blog with a link to the referenced work.) The Ops Research bug in me says to attack the lag time to compress the duration of work. The Psychology bug in me tells me to evaluate the personal motivations and interactions that cause people to do (or not do) things that waste time. And the MBA bug in me causes me to look at projects from a purely P&L and ROI perspective. I believe that proper balance of all three perspectives will lead to true optimization.

Is Agile Too Noisy?

A common complaint from folks new to Agile has to do with all the noise and interruptions when working in a team room environment. Are the noise and all the interruptions causing your tasks to take longer than you'd like? Don't worry.

In Rashid Khan's book Business Process Management: A Practical Guide he references a 2001 study which showed that 90% of the time spent on a task is “lag time”, and the remaining 10% represents actual task time. The 90% represents the time that work is spent waiting in someone’s inbox, in transit, or blocked by other tasks. If an efficiency expert were to drive workers to crank through a task in half the time, they may be disappointed to see only a marginal impact to the overall productivity of the project. If a 10 hour task is completed in 5 hours, and nothing is done to reduce the 90 hours of lag time, the 5 hour savings is hardly noticeable.

To compound the lag time issue, a 2002 study by Safari found that technology workers spend an average of 31 hours per month looking for answers, researching issues and solutions for problems, and helping colleagues do the same. This constitutes 20% of their time spent seeking out information.

Tactics employed on Agile projects can attack these barriers to productivity. When a team is brought together in a team room, some will complain that the noise and dynamics interfere with concentration, negatively affecting productivity. Even if these factors cause a 10 hour task to take 15 hours, the project still benefits when lag time is slashed from 90 hours to 20 hours. Additionally, imagine the additional time saved when a missing knowledge item is announced in the team room, and (because all information experts are present) the knowledge gap can be filled immediately.

Are We Ready for the Guitar Hero Employee?

I have been trying to learn how to play the piano for almost 30 years, and on my best day, I’m a poor piano player. Although I know how to read music, and I know which keys correspond to each note, I usually resign myself to pounding chords with my left hand and tapping out the melody with my right hand.

Two of my sons were home for Thanksgiving weekend, and each sat at the piano and played beautifully. I’m talking full two hands on the piano, hitting every note - harmony, melody, arpeggios, style, the whole nine yards. I was in awe of the music each of them was able to eek out of the piano. And here’s the surprising thing - neither of them has looked at the sheet music, and if they did, it would likely just be a distraction.

So what’s the explanation? Music prodigies? I think it has more to do with the fact that they are in touch with how they best learn. The same skills that allow them to excel at Guitar Hero and Wii Bowling can apply to other real world skills. They are kinesthetic learners – they learn by seeing, touching, and emulating behavior. They each learn tunes on the piano by watching YouTube videos with close-ups of talented players fingering the keys. The interesting thing is that this is not an isolated phenomenon – there's a multitude of these learn piano videos on YouTube that are getting tens of thousands of views.

To the other business folks out there, this phenomena is representative of our incoming generation of workers. The video game culture has created a generation of kinesthetic learners. My wife commented, “Wouldn’t be great if school subjects were available as video games?” Imagine Playstation Physics, X-Box Calculus, and Wii History…

And if we resist? What will happen when these kinesthetic learners enter the workforce and struggle to integrate them into a business world littered with dazzling white papers, PowerPoint slides, and weekly status meetings? I believe there is a change coming that is going be fun and interesting. Stay tuned…