I was re-watching Star Trek II: The Wrath of Khan the other night and I was reminded – once again – about how Lean management can be poorly implemented. That may not be readily apparent, so walk with me for a bit.
Lean Software Management came from Toyota’s manufacturing practices and their hyper-focus on eliminating waste in all processes. One of the ways in which they accomplish this is the use of a Kanban board, which visually represents all upcoming, ongoing, and recently completed work.
In the Kanban process, every discrete task or piece of work is represented by a card (kan) which is placed on a board (ban). The Kanban board has various columns, which can be tailored to meet the project’s demands. And the card moves across the Kanban board from left to right as it is processed by the team.
A card needs some definition before it can be pulled into the process: its priority, what it means for the task to be complete, and a general estimate as to the relative complexity or size of the task before it can be “Ready.” Ready cards are then pulled into the all-important “In Progress” column by the team.
After completion, the card flows across some minimal verification, deployment, or post-processing columns until it finally moved to “Done”. The flow of the card through the columns is always to the right. So, it is vital that any subsequent activity does not cause a task or card to travel backward.
Lean Software Management came from Toyota’s manufacturing practices and their hyper-focus on eliminating waste in all processes. One of the ways in which they accomplish this is the use of a Kanban board, which visually represents all upcoming, ongoing, and recently completed work.
It’s the “In Progress” column that gets the most attention. A team member can only have one element of work in progress (WIP) at a time, focusing on it until completion. This way, the wasted time and effort in setting up and switching between environments while multi-tasking is eliminated.
It is also important that a card not linger too long “In Progress,” as that is an indication that the task was improperly defined or that your system has blockages. Management is all about minimizing the WIP and maximizing throughput across the board to increase project value.
A common implementation of this practice places a prioritized list of the most important cards in the “Ready” column so that the next available team member automatically pulls the highest priority card. This maximizes the project value, as every developer is always working on the most important tasks at any given time.
All of this hinges on having and cultivating “T-shaped” team members with a broad range of skills, that master one or two. (Wouldn’t that make them 𝜋-shaped?) This way team members are more-or-less interchangeable cogs that can complete any task that arises. Very efficient, but it brings me to the other night.
* Spoiler Alert (for a famous movie from 1982) *
In the Wrath of Khan, James Tiberius Kirk was promoted to the rank of Admiral but was having issues adapting to life behind a desk at Starfleet. Kirk’s skills and temperament were more aligned with captaining a starship than supervising cadets at Starfleet Academy. And as Spock noted, anything else was a waste of material. As an Admiral, Kirk feels old, but in the end, after re-assuming command of the Enterprise, Kirk realizes he feels young again.
There are additional aspects to the movie that make this the best in the Star Trek franchise … maybe tied with IV … but this element encapsulates my issues with poorly implemented Lean management. A team member who finishes a task may not be the best fit for the next highest priority card.
That can be due to skills, interests, career goals, or temperament. But like Kirk, team members are more fulfilled when they are able to learn and express mastery over those skills. (See my article on Continuous Fun.) And managing team members should be just as important as managing optimal workflow.
A common implementation of this practice places a prioritized list of the most important cards in the “Ready” column so that the next available team member automatically pulls the highest priority card. This maximizes the project value, as every developer is always working on the most important tasks at any given time.
This condition also raises my concerns from a long-term, waste elimination point of view. If the next highest priority task is security-related, I would not want to entrust that task to someone who has minimal security expertise. That would create waste in a slow progression across the current board and probably generate many future tasks unnecessarily to repair and enhance the original effort.
It may be controversial, but I think the “T-shaped” person is a myth. I have never met a person with an acceptable experience level in all skills, from graphic front-end design to database optimization to penetration testing and management skills. And have deep expertise in one or more of those skills. And who would be equally happy doing any task from mundane to complex! Most especially myself.
So how do we resolve this no-win scenario?
Kanban!
I propose that teams using Kanban implement skill tracking for all tasks and team members for better alignment and happier teams.
During the task definition phase, document the assumed level of experience for each skill needed to complete the task along with its relative task size. Likewise, each team member can be assessed, or self-assess, their relative skill levels in each pertinent area needed by the project. And since we’re assessing, let’s find out what each team member is actually interested in doing for their professional career. Radical, I know.
If the skills don’t line up, they get a new training card that will help them complete the activities properly when they get a similar card again. Or they get to shadow or paired program on the card with someone who can train while completing the task appropriately.
Then when a team member is ready to pull the next card, we can make sure that the person’s skills meet the minimum requirements for the task. If the task falls within the skill set range of the team member, great, off they go!
If the skills don’t line up, they get a new training card that will help them complete the activities properly when they get a similar card again. Or they get to shadow or paired program on the card with someone who can train while completing the task appropriately. Or if they’re overqualified, then can pull a junior member to shadow them, giving them a chance to work on training skills. Or maybe they can pick a slightly less important card that aligns with their interests, sacrificing a bit of optimal project value to maximize employee fulfillment and retention.
It’s important and fun to learn new skills, but not when the team is counting on actions beyond your skillset. Likewise, it is important and fun to be able to express mastery over skills you know, but not when it’s repetitious to the point of boredom. As good developers are hard to find and retain, keeping them engaged and learning is just as important as managing workloads. Don’t waste team member abilities and don’t waste project resources and time with employee attrition.
In the spirit of agility, I urge you to try it, measure, and assess for yourselves. Let skill tracking be the genesis for your renewed effort in eliminating long-term waste and helping your team feel young again. It will be a far, far better thing than you have ever done before. A far better resting place.
