Oct 072013
 
He rents furniture, but he knows the truth about the space program.

Marvin discusses credibility issues

In America, we have regulated and unregulated professions.  Regulated professions are the ones where you have to be verified in some way by the government before you can legally practice.  I can’t legally set up a neurosurgery clinic in my basement, for example, and it’s not for lack of trying!

Most professions in America are unregulated.  In other words, the government feels comfortable enough letting the market sort out the frauds from the genuine article.  I guess the consequences are lower or perhaps the market is more effective in some respects at this task.  I admit I’m not sure what the deciding factor is, because sometimes you get some professions that are unregulated that seem to be strong edge cases.

For example, did you know martial arts instruction is an unregulated profession?  It’s true.  You could open up your own martial arts school, today.  You could even invent your own martial art, make yourself the grandmaster (which I guess you’d be by definition), and set up shop, and it’s all entirely legal.  Being a martial artist, myself, I’ve seen this result in all kinds of interesting things, ranging from dubious lineage claims and fighting credentials to an individual who claimed Martians taught him his martial art.  Oh, wow – Martians, martial… I just got that.  Anyway….

The reason martial arts are a strong edge case is because the people who learn from a martial arts instructor usually have a reasonable expectation that they’ll be able to defend themselves with it.  The students, by nature of the case, don’t usually have the expertise to tell a true fighter from a fraud, so they could earnestly be learning a martial art that guarantees they’ll get their tails kicked in a fight (or worse).  Martial arts schools are a great place to be a fraud, because you’re sparring with other people learning the same thing (if you spar at all), you’ve got a built in cult of personality around the instructor, and if a student gets pounded on the street, it’s easy to chalk it up to their lack of skill.  In other words, it’s almost completely impossible to verify a martial arts instructor is a fraud unless they make empirically verifiable claims or you are/have seen the genuine article, yourself.

Even in those cases, the cult of personality is so strong that there are teachers who make ridiculous claims about being able to do things like knock someone out with one touch (or not touching them at all), and despite third parties demonstrating this is not the case, their schools are still swelled with students, and inside the walls of their dojo, they wave their hands around, conditioned students fall over, and the credibility structures remain intact.

Another unregulated profession is business consulting / agile coaching.  There is nothing stopping anyone from claiming they are an agile consultant and marketing themselves this way.  Since this is a field where there’s quite a bit of money to be made, charlatans abound.

This is sort of analogous to the martial arts problem.  There’s nothing stopping someone from setting themselves up as an expert of their own way of thinking, surrounding themselves with people who’ll drink their Kool-Aid, and taking you down a path of “mastery” that’ll end up with the economic equivalent of you getting beat up in a parking lot.

Just like a fake martial artist can “look” like a fighter to the untrained eye, a fake agile consultant can sound like a real one, surrounding themselves with buzzwords, aphorisms, and passionate criticisms of things they don’t understand and have no real experience with.  To organizations that need genuine help in these areas, a well-marketed fake is almost indistinguishable from the genuine article.  The person sitting across the table talking about systems thinking and the pitfalls of various agile methodologies could be some former mainframe guy who hasn’t developed any software in a decade and hasn’t led a single agile effort at any company ever.  He’s a total fraud, but how would you ever know, because he’s read some stuff and heard some stuff and sounds like he knows what he’s talking about?

In the martial arts world, people ask things like, “What’s your MMA record?  Are there any videos of you fighting?  How many fights have you been in?  Can I spar with you right now?”  In other words, they look for some kind of external verification that this person can actually teach them how to fight (or how to compete in tournaments or find enlightenment or whatever a person’s goals are for studying a martial art).

In the consulting world, try throwing this out there, “Tell me about the companies you have specifically led in becoming more agile.  What did you actually do, what were the empirically verifiable results, and who can I contact over there to corroborate your story?”  I mean, this is basically what we ask prospective employees to do when applying for a job.  I don’t think that’s an unreasonable thing to ask of someone who’s going to be advising you strategically.  Do you have multiple consultants in your area to choose from?  Sit them down in a room together (or separately) and ask them about your real business problems and see what they have to say and where that answer comes from.  When you hold up a fake next to the genuine article, the differences begin to emerge.

This is where you begin to separate the salespeople from the consultants.  This is where you separate the people who have a rich well of theory and experience from the people who have just spent a lot of time around “agile stuff” and say quirky things.  This is where you separate the individuals who have shepherded people through valley of the shadow of kaizen from the recruiters who picked up academic credentials.  This is where you separate the people who have made real strategic laterals with real, measurable impact from the people who just passed a Scrum Master certification course.  This is where you separate the people who have learned from their mistakes from the people who make nothing but mistakes or have made no mistakes because they’ve done nothing of impact.

Now, does this mean you should never bring on someone without experience?  No, because that’s logically impossible.  Everyone has to get experience to have experience, and they won’t get that without someone giving them a chance.  There’s also a lot to be said for solid theoretical knowledge, as that can help make sense of and bridge gaps in experiential knowledge.  Also, there’s a lot to be said for the insights of a newbie to help challenge the thinking of those who are more established.  But just know what you’re getting into.  Do it with your eyes wide open, and don’t just assume that because someone knows all the right buzzwords that they actually know what they’re talking about.

The number of consultants I’d actually trust to help an organization improve their agility in Kansas City, I could count on one hand.  There are a few others who will be great consultants with some seasoning.  There’s a lot of smoke blowing out there, folks.  Do your due diligence.  Don’t learn self-defense from someone who’s never defended anything.

Enhanced by Zemanta
Oct 032013
 
Think

Think (Photo credits: www.mysafetysign.com)

Back in August, Bob Maksimchuk wrote a brief article on what he calls “agile scorpions.”  The basic idea is that companies have these people who have no intention of changing, and it is intrinsically in their nature to… well, murder you, according to the story, but I think he was trying to get across the idea that there are people who are by nature a certain way (i.e. not agile and resistant to change), and these people will end up torpedoing your attempts to create organizational change.  His recommendation is to try and discover these scorpions as early as possible and get them off your team.

Some of us discussed this article over on LinkedIn.  LinkedIn discussions are valuable, because you usually end up with 90% of the masses on one side of an issue and 10% on the other side.  The 90% are usually the well-intentioned-but-inexperienced, the parrots, the inflated frauds, and a very small margin of thoughtful, experienced people who just happen to have that view.  The 10% tend to be the people who have been around the block a few times and have a very deep understanding of how agile efforts do and don’t work in organizations.  Needless to say, the 90% was firmly on the side of getting rid of the scorpions, which makes sense, considering 90% of Salem was on the side of the witch trials.

I mean, how is that not appealing?  The reason your team is struggling isn’t because of trying to apply a prepackaged solution that doesn’t fit, lack of systems thinking, militant adherence to a methodology, or overpaid consultants who don’t know their ass from a hole in the ground; it’s because somewhere, someone on your team doesn’t have agile DNA, and they must be rooted out before they doom you all.

As attractive and simple as the theory might sound, that if you just get rid of the heretic everything will magically fall into place, I am here to tell you this is complete hogwash.

People are complex.

The personality test industry is a multi-billion dollar business right now.  Organizations like buying pre-packaged solutions.  They like the idea that they can pay someone, run everything through some tests, and come out the other side of the machine with a complete analysis.  It’s one of the reasons you can be a bad Scrum / SAFe consultant and still do so well in the market.  Here’s your company.  Here’s my solution.  Just execute it.  ???  Profit.

The idea that these tests are rigorously accurate has been scientifically debunked many times over, but that hasn’t stopped the money train.  Are these tests completely bogus?  Of course not, but at best they reveal generalities.  You can use them for general ideas about communicating together and whatnot, but the simple fact is that personality is complex.  It can’t be quantified the way people wish it could be.  Saying, “We need to hire an INFP, but this guy didn’t score as an INFP” is similar to saying, “We need to hire a Republican, but this guy drives a hybrid.”

You can’t put people in a box, formally or informally.  Sociological data, especially data that comes from the subjects themselves, is just not accurate or reliable enough to make concrete decisions on.  Why does someone seem like a “scorpion” to you?  How could you possibly determine that?  Is it because they argue with you?  Is it because they think your ideas are stupid?  Is it because they like the way things are now?  Is it because they got an 80% on your Scorpion Detection Test?  None of those things tell you that a team member is actually a saboteur.

Getting rid of someone is a last resort.

If someones first response to a “scorpion” is to get rid of them, they probably need to learn a few things about management, people, organizational health, and courage.

About ten years ago, I was leading up an agile team at a worldwide bank, and there was a guy on my team who just fought me on every little thing.  I swear, if I said that the sky were blue in a meeting, he’d spend half an hour explaining how it was actually maroon.  Every new thing I tried to introduce, every point of view expressed, this guy was right there to explain why the old way was better and this new way was more complicated and pointless.  He showed all the Grade A signs of being a “scorpion,” and he wasn’t secret or subtle about it at all.

According to the 90%, I should have started looking for a way to get this guy off my team.

About eight months of this went by, and after some conversations with the bank, we determined we needed to make a shift in the application architecture to accomplish some new needs they were having.  I dreaded bringing this news to the team, because I knew I’d have a fight on my hands.  I especially dreaded having this guy in the meeting.  I decided to call him in advance – not out of some deep insight into his personality I’m sorry to say, but because I just wanted to get it over with.

So, I called this guy the day before, and I said, “Listen, I’m calling you because I got out of some meetings where the bank is going to need some things our architecture won’t support.  We’re going to need to change how we access our third party data, and I just know this is going to be a big disruption to the team.  I was wondering if you could help me figure out a way to explain it so that everyone will understand and see why it’s needed and not just get upset about it up front.”

It was like I flipped a switch.  This guy was suddenly full of ideas.  He wanted me to explain the change to him, and he told me that we could do this, and maybe roll this out incrementally, and maybe I could work through the infrastructure bits, and this and that.

I asked him if he thought this new way would be more complicated than the simple architecture we were currently using.  Oh, no, not at all.  It would be easy.  We’d just have to make sure this, that, and the other thing.

I asked him if he’d be willing to introduce this idea to the team and walk them through it.  Of course he would; he’d set something up for Thursday.  Three months later, and this guy would still pipe up in retrospectives about this change, talking about how much easier it made everything.

This guy didn’t hate change.  He didn’t hate me.  He hated not being a participant.  He hated not having a voice.  Rightly or wrongly, he felt he was not part of the effort, and he resisted this in the way he knew how.  What if I’d gotten rid of that guy?  I would have lost an ardent supporter and dedicated employee because I wasn’t willing to try and find what made this guy tick.

Sometimes, the heretic is right.

The quickest way a species goes extinct is to have something valuable humans want.  The second quickest way a species goes extinct is to weed out all variation.  Mutation is survivability.  In a world where species compete for resources and live in harsh environments, differences are inherently beneficial to survival.

The same goes for an organization.  The second quickest way to wipe yourself off the economic map is to eliminate everyone in your company who thinks differently than you want them to.  Why?  Because sometimes the heretics are right, and you have no heretics, you’ll never see it coming.

Sometimes, people resist your agile initiative because your initiative is stupid.  Sometimes, people resist it because you are trying to impose things that don’t organically fit.  Sometimes, people resist it because you are jettisoning or overlooking important, valued things that you may not value as much.  In my experience, people actually very rarely resist change simply because they are intrinsically change resistors, and frankly, I don’t even know how you’d go about proving something like that.

Even insane people have reasons for the things that they do.  When someone presents themselves as an obstacle, you have a fork in the road.  You can get rid of them (90%), or you can learn from their viewpoint (10%).  They probably have some very legitimate concerns.  Maybe for that specific organization, you have to approach things differently.  Maybe the nature of the business means you have to sacrifice some agility temporarily for longer term gains.  Maybe you just made the guy who’s been that team’s manager for 15 years look like an idiot in front of them.  Maybe someone else just has a better idea than you, even if it’s not in the textbook.

Your resistors and complainers are very often mirrors we don’t want to look into. They’re the people who take our pie in the sky ideas and say things like, “You know, pie can’t actually hang in the sky unsupported.”  You know what?  Kid’s got a point.  Listening to your heretics and using them to help give you new insights and modify and improve your course is healthy and wise.  Sure, they may be expressing their resistance inappropriately (a common thing when people feel they have no appropriate avenues open to them), but that’s hardly the main point.  When someone points out the hole in your armor, you can repair the hole and say thanks, or you can fire them for not being a team player and enjoy feeling like Donald Trump all the way up to the point some Norman shoves a lance up your nose.

Managing people, helping them improve, channeling their strengths and weaknesses, learning and growing as an organization of people – these things are hard work.  It’s in the trenches work.  You can’t print out the spreadsheet that tells you who to keep and who to let go.  You can’t manage by the numbers, here.  You can’t let the Bobs talk to all your employees and tell you who to keep.

I’m not saying no one should ever be fired, because that’s not true.  But I am saying that people are not born with or without the agile gene.  If you are willing to get to know your people and think about the organizational system with them in it instead of just getting rid of everyone who doesn’t fit your idea of the “right person,” you might find that the “wrong people” will surprise you, and not in a stingy-tail way.

Enhanced by Zemanta
Aug 272013
 
Retrospective 5 (Pinestone)

Retrospective 5 (Pinestone) (Photo credit: .:fotomaf:.)

Kanban does not prescribe any particular meetings.  It leaves it up to the workers to decide what meetings have value and how often to do them.

One meeting that I’ve found has value nearly everywhere I go is the good ol’ Retrospective made famous by good ol’ Scrum.  As long as we think of retrospectives more generally as a regular time for the team to talk about improving itself, you’ll find retrospectives many places you find Kanban and/or Lean practices, including Toyota.

Having extensive experience with the traditional Scrum retrospective, though, I think there are some things that can be changed to make it flow better with Kanban’s intent and, in fact, I think it even produces better retrospectives for Scrum teams as well.

The traditional Scrum retrospective basically follows the format of each team member stating what things went well (things to keep doing), what things did not go so well (things to stop doing), and what things could benefit from change (things that could benefit from change).  The Scrum Master records all these and, ideally, the team selects some to work on for the next sprint, and they talk about these items as part of the next retrospective.

You don’t have to be a Scrum Master very long before you watch these meetings devolve into a dry, useless mirror of the daily standup where no real value is added or degenerate into an unfocused whine-fest.  The value of the classic retrospective tends to drop so quickly that, if you head over to LinkedIn and start rummaging through the threads in the various agile and Scrum groups, you’ll see tons of threads asking how to do retrospectives differently.  In these threads, hilarity ensues because 90% of the consultants and coaches only learned the practice but never really understood the purpose, so you get surreal ideas like, “I use Legos in my retrospectives.  I buy everyone ice cream.  I dress up as Sailor Moon.  I have my retrospectives underwater in SCUBA gear.” and so on.  Ideas that try to make the meeting more engaging instead of changing the meeting to better accomplish its intended purpose.

I would like to share with you what I think is a good way to change the meeting to better accommodate the way Kanban effects organizational improvement.  It is not the objectively best way, nor is it a good thing to do in every organization, but here it is.

The first part of the meeting is to go over the metrics – specifically, we review the Cumulative Flow Diagram and the “Control” Chart.  Together, we discuss flow.

Did you catch that?  We don’t talk about making low numbers higher or high numbers lower.  We talk about the flow of our work.  What does the data imply about where things are not flowing smoothly, and why might that be?  Are there communication issues?  Too many handoffs?  Is there a small part that is affecting the whole?  Is the whole thing screwed up?  We are concerned about the areas where work is not flowing smoothly and taking cues from areas where it is.  We talk about where we would like to be and how our situation is different than that.

Notice this is very similar to talking about what is going well, what isn’t going well, and what are areas for change.  The main difference is that we are talking about an objective situation as a team as opposed to navel gazing into our personal feelings.

Once we have talked about these things, we discuss as a team what we believe the one area is that needs the most love.  Usually, the data strongly suggests an area, so there is little debate.  Then, we brainstorm ideas of how to improve that area.  We vote on one idea, enact that, and see if it made a difference when we get together next time.

Here are the key points:

  • The discussion stays about our work, not things or people outside our work that we can’t control.
  • The discussion stays objective.  The metrics are what they are, regardless of what our individual feelings might be.
  • The metrics are a catalyst for discussion and inquiry, not a substitute for it.
  • The focus is on improving our flow, not going faster.  Take the kinks out of your hose, and the throughput will increase.
  • The focus area and the solution both come from the team, not from the outside, creating instant buy-in.
  • One and only one change is introduced so it can be measured.

One might argue these are the basic intents of the Scrum retrospective, and that may be, but I would then counter-argue that the traditional format is not the most efficient way to accomplish those intents in many cases.

Enhanced by Zemanta
Aug 262013
 
gray wolf

gray wolf (Photo credit: U.S. Fish and Wildlife Service – Midwest Region)

When I was in school, I bought a wolf adoption packet.  I don’t even remember what it was called, but the idea was to prevent the extinction of a specific kind of wolf.  You bought one of these packets that had a photo of your wolf and such, and your money went to an organization preventing their extinction.

When I told one of my friends about it, she said, “I can’t believe you spent money to save a wolf when there are so many children dying of starvation out there.”

You’ve probably seen something similar in your own life, when one person assists a cause, and that effort is criticized by someone on the grounds that there are other, more important causes out there.  Usually this criticism comes from someone who is doing nothing about either situation.

Obviously, there is the fact that people can care about more than one thing.  Of course I care about children dying of starvation.  Caring about one thing doesn’t mean you think it’s the most important thing, nor does it mean you can’t care about anything else.  But people do something for causes for a lot of different reasons.  In my case, someone presented an opportunity to me to do something about it in a way that made it easy to help.  People have different backgrounds, gifts, and preferences that draw them to certain causes, but I’d say the common factor in all of them is that people feel like they can actually make a difference in that area through their efforts.  This is why the Peace Corps has many members and the Giant Asteroid Hitting the Earth Prevention Society has so few.

In the Agile and Lean communities, we tend to talk a lot about processes – the pros and cons of different processes, how to tweak them, how to analyze them – and it usually isn’t long in such discussions before some wag pipes up, “Hey, guys, remember.  Individuals and interactions over processes and tools!”  Usually this is someone who is contributing nothing in either category.

I actually find this sort of thing both offensive and stupid – chronically short-sighted at the very least.

If the Saw movies have taught us anything, it’s that you can’t change a person.  People have to change themselves, and it’s something that takes a long time apart from some traumatic experience.  I can’t consult someone into a more agile mindset.  I can’t consult an organization into trusting each other more.  I might be able to point out these needs, but ultimately, I am very limited into what I can do about it.  I can’t change people by making them fall backwards into their co-workers’ arms, and I am unwilling to set up an elaborate chain of deathtraps to help them all see that they’re valuing the wrong things.  I can inform them, but that’s really where my power to change stops, more or less.

So, placing all my efforts in the people/culture bucket is kind of like joining the Asteroid Prevention Society.  It’s an important issue that I can do relatively little about – at least, directly.

At the same time, we all know that individuals and interactions are more important than processes and tools.  Absolutely.  100% agreed.  By a long shot.  So the question is, as a consultant, how are you best serving the individuals and interactions as opposed to being a process or tool vendor?  I believe the answer is in focusing on the things that will enable the people and the organization to change themselves – most notably, educating them, changing their behaviors (or processes if you will), and letting the results of that be the levers for creating the true people and culture changes that are the core of what will benefit an organization long term.

I have seen this path work several times – culture and people changes that cascade from education and creating more enabling processes.  It’s like irrigating dry soil, making it ready for the seeds of true growth that would inevitably die otherwise.  I have never seen lasting cultural change come from an initiative specifically designed to change the culture.

So, the next time you hear someone seeming to focus on processes or tools, don’t automatically dismiss that interest as misplaced, especially if they aren’t selling said process or tool.  It may be that they care about individuals and interactions far more than you know.

Enhanced by Zemanta
Aug 142013
 
Kanban in miniature

Kanban in miniature (Photo credit: jhritz)

For some years, now, David Anderson has vocally separated Kanban from “agile” or “agile methodologies” like Scrum, XP, and so on.  I never really understood why this was.  Although obviously Lean is found in several industries as is the use of various elements we find in Kanban, easily the most common place to find Kanban in the wild is in software development, and specifically software development teams trying to become more agile.

Also, you have to understand that I came to Kanban as a progression of sorts from Scrum.  Scrum helped me achieve a lot of the things I was trying to get out of a more agile software development experience, and when I came across Kanban, I saw it as (in my opinion) a better way to get at those same things.  But I didn’t see it so much as a different kind of thing from Scrum; just something that did some of the same things better.  So, in my head, Scrum, DSDM, XP, Kanban – these were all the same kind of thing, just with varying approaches and doing some things better than others.

But now, after having engineered the use of Kanban in a few different organizations and observed its power and value, as well as doing research trying to accumulate something intelligent to say about its differences with SAFe as it bulldozes its way into the market like a hyperactive wrecking ball that just demolished a Pixy Stix factory, I think I’m beginning to see what David’s been on about.

Agile and agile-ish methodologies can link their spiritual heritage to the concepts that became embodied in the Agile Manifesto – the signatories of which are names that you’d recognize in the field, like Ron Jeffries of XP fame and Darth Sidious of Scrum.  This Manifesto articulated principles and concepts of what agility was looking like in software development (and specifically software development, I might add – it says right there in the preamble).  People began to create and collate practices and systems that, in their minds, did good jobs of expressing in practice and technique those agile principles.  You do these things, and you are getting closer to expressing those principles more fully and more comprehensively.

What I have been discovering over time, though, is that Kanban actually makes nothing more agile, nor does it improve anything.

Rather, Kanban is an efficient, effective way to show you where you can improve, the best places to improve, and what the impact will be.  In other words, Kanban gives you everything you need to improve quickly, efficiently, predictably, and get the most bang for your buck.

When I was a kid, dentists would sometimes give you these red tablets for you to swirl around in your mouth after you brushed your teeth.  They tasted like they were made from Hell’s own brimstone and the ground up bones of dentists that had passed on, and perhaps they were, but when you spit the stuff out, there would be red areas on the surfaces of your teeth that you missed while brushing.  They didn’t clean your teeth; you had to do that.  But the red tablets drew your focus immediately and visibly to the areas that needed your attention and the severity of your lack of attention.

Kanban is like that.

Making your work visible, limiting your work in progress, measuring the flow of your work, making policies explicit, and managing to flow are all designed to give you exactly what you need to apply your improvement brainpower.  Where do these improvements come from?  From you, of course.  Nobody knows how to do the work better than the people doing the work; not an agile coach, not a consulting company, not a manager of the people doing the work – the actual people doing the work are your best source of ideas for improvement.

Organizations usually don’t lack opinions about how to improve; what they lack are ways to get their work situation under control so they can meaningfully study it, ways to sift through the good ideas from the not-so-good ones, ways to know what their priorities should be, ways to project the impact on the work, and ways to measure the actual impact to see where adjustments to the good ideas need to be made.

So, why is Kanban not agile?  Because Kanban doesn’t increase your team’s agility one single iota.  What it does it create the conditions and foundations necessary and  provide you with all the intelligence you need for kaizen – an ongoing journey of improvement, driven by the people doing the work, but always viewing how it improves the system as a whole.

Enhanced by Zemanta
May 282013
 
Karma Chameleon

Karma Chameleon (Photo credit: Wikipedia)

The Capacity Chimera is in the same zoo as the Karma Chameleon.

Capacity Planning is the practice of a person or a group of people estimating how many available hours they have to work.  Then, they estimate how long each of their work items will take.  In theory, this tells them what they should have done by the end of the day or week or sprint or whatever time period they pulled the capacity from.

For example, let’s say I have a team of six, one of whom is only 50% dedicated to this project.  For a week of work, that’s 40 hrs. for 5 people and 20 hrs. for one person, giving my team a capacity of 220 hrs. for tasks.  Of course, we all know it’s unrealistic to assume everyone can put it a full 8 hours dedicated to task work.  There’s phone calls, emails, little delays, etc.  So, let’s say a “full day” is six productive hours in terms of completing tasks.  That gives me 30 hrs. for 5 people and 15 for the sixth.

Then, you take all the things that need to get done and estimate how many hours each one will take.  You assign them to people until you have “spent” each person’s capacity.  You should now feel confident that all those tasks are very likely to get done by the end of the week.  Or I should say, you do feel confident, but you probably shouldn’t.  While capacity planning is probably better than no work limits at all, it’s still very unreliable.

In the first place, it requires you to accurately predict your capacity.  So, you take out your PTO, your meetings, and some token amount for daily incidentals.  Well, meetings run over and they run short.  Incidentals are sometimes nothing, and sometimes they eat up your entire day.  Sometimes, that email exchange turns into an on the spot meeting.  Sometimes, kids get sick.  Sometimes, servers go down and all hands have to work to get them back up.  Sometimes, people get fired.  Or hired.

In fact, I’d venture to guess that a week where -nothing- unpredictable happens is far, far less common than a week where something does.  I’m not even sure I could definitively say what my work will look like for one day.  I can tell you what I intend to do, but who knows if it’ll actually fall out that way?  Much less a week.  Much less a team of six such people.  And that guy who has 50% capacity for my project?  Somehow, that 50% always ends up looking like 30%.

So, your pool of available hours per person is already unreliable, and possibly unreliable by a rather large margin.

In the second place, capacity planning requires you to accurately predict how long your tasks will take, down to the hour.  This probably isn’t happening, either.  Not only are people bad at estimating, but many tasks (especially in software development) have a measure of unpredictability to them.  I -think- adding a new database table will take an hour, but what if I accidentally add it to the wrong database and don’t realize it for a while?  What if someone else accidentally drops my table with a restore from a backup?  What if a persistent error on the database or in my SQL takes me two or three hours to chase down?  Or, what if it goes even more smoothly than I thought and takes thirty seconds?

One could argue that, while my estimate in hours could be off, it’ll rarely be off by a factor of days, and that’s probably true most of the time.  But you add up these little deviations – an hour here, a half hour there, two hours there – with each task, and eventually you’ve shaved off a whole day you planned to have available to get tasks done.

Much like estimates based on exhaustive requirements, capacity planning offers an illusion of security.  When the smoke clears, it’s still just guesses about unknowns.  It also tends to take a lot of time – a rather lot of time spent getting things wrong.

If you use capacity planning, and it never quite seems to pan out, you might consider ditching the whole guessing thing in favor of using your teams actual rate of getting things done to project what things will get done.

Enhanced by Zemanta
May 242013
 
English: Simon Cowell at the National Televisi...

English: Simon Cowell at the National Television Awards at the Royal Albert Hall, London, October 2006. (Photo credit: Wikipedia)

How do you know if your chosen agile initiatives are working?  How do you know if you’re agile consultant is actually helping or just telling cute stories and quoting books they’ve read?  How do you know if your agile teams are actually agile or just call themselves that?

This is a dicey question, and there are a fairly large number of agile consultants who will tell you that you can’t measure such things.

Like most falsehoods, this has a seed of truth to it.  When you are dealing with complex systems that are primarily people-powered, you can’t quantify everything, nor should you try.  This is one of the many reasons why managing by the numbers is so wrong-headed.  You have to be in the midst of your people.  You can’t quantify things like communication, collaboration, trust, habits, or many of the multifaceted aspects of the way people work with other people.

It is also true that any change in business as usual will actually create a dip in productivity (and possibly morale) as people have to leave the familiar and struggle to form new ways of working together.  Unfortunately, this stage (sometimes called the “storming” stage) is where most people abandon their agile initiative because things got worse, and they never reap the rewards of riding through that dip and coming out the other side into the new normal of greater productivity.

However, it is my view that some aspects of agile effectiveness can be measured, and it basically comes down to this: are you delivering more value more quickly?

Companies increase their agility to make more money.  Full stop.  For all our fancy mission statements and talk about disruption and whatnot, every for-profit organization has the overarching goal of making money.  Things that help companies make money, save money, or protect money from risk are seen as improvements, while things that cause companies to lose sales, lose money, or put their money at risk are seen as detriments.

Agility is not exempt from this.  In fact, if agility isn’t helping you in this department, what’s the point in doing it?

There is no inherent value in conforming to “agile rules” or even the Agile Manifesto, so trying to measure that is a waste.  There’s no inherent value in conforming to a plan, so trying to measure that is also a waste.  That alone sweeps a ton of possible metrics off the table.  There’s no point in assessing agile effectiveness by things like if you’re doing Agile Practice X, if you’re following the Scrum rules, or how well your estimates match up to actuality.  None of that truly matters.

There is inherent value in delivering items of value, not wasting time reworking those items, and removing obstacles to delivering those items.  Therefore, if you want a measurement of the effective agility of your team or organization, here are the metrics I think are not only most important, but are actually measurable.

1. How much value are you delivering over time? (Throughput, Lead time)

2. How much rework are you having to do? (Quality, Time spent on bugs)

3. How are work items flowing through your system? (Flow, Amount of work over time in each stage, Amount of work coming into and leaving the system)

The things that help you deliver more over time without increasing rework are enhancing your agility.  The things that impair this dampen your agility.  The whole reason to become agile is to deliver more, deliver faster, and deliver higher-quality.  It isn’t to become better people, hack our corporate culture, or make software development more pleasant.  All those things might very well happen and are probably desirable, but they are means to an end.  Ultimately, it’s all about the Benjamins or whatever the kids are calling money these days, and that is the final criterion by which initiatives can be measured.

If you aren’t measuring these things, I encourage you to do so.  A lot of people think their diets work, too, until they step on the scale.  A lot of people think they can sing until they do it in front of Simon Cowell.  Find out, and when you’ve found out, don’t use those measurements to beat yourself up (or anyone else for that matter), but use them as a catalyst for conversations about improvement.

Enhanced by Zemanta
May 072013
 
Me presenting at KCDC 2013

Me presenting at KCDC 2013

Thirty-six hours before the first KCDC precompiler session began, I got a call from Kansas City’s premiere Lean/Agile expert asking if I could fill in for him at the Agile and Lean Workshop precompiler due to an emergency.  Twelve hours before the session began, the United States’ premiere Lean/Agile expert was delayed by snow and told me he couldn’t make it to the session until lunch.  That left me and this guy, or in other words, George and Ringo, and Ringo had a conference to run.

And it went great!  We had a really good group who gave us good questions to work with.  We played some games.  We talked about Scrum.  We talked about Kanban.  We talked about all the hot button Agile topics like estimation, bidding, and ongoing maintenance.  It was a good, energizing talk that reminded me how much I enjoy that sort of thing.

P.S. If you were at that workshop, please take a second and leave a rating for me at SpeakerRate.  Much appreciated.

Friday morning, Dan “Kan-Man” Vacanti gave a terrific keynote about how we serve our customers better with pull systems for doing our software development as opposed to push systems.  He also gave my own session a quick shout-out for which I am grateful, because without context, most people don’t get too fired up about a talk called “Lean Metrics.”

Next, I gave a talk called “Lean Metrics.”  Standing-room only with some people sitting in the aisles.  It was a huge fire hazard and OSHA violation, but it charged me up.

We talked about why estimation fails us and how keeping metrics can overcome some of the weaknesses of estimation, providing a better foundation for our planning and projections.  Then, I demonstrated control charts and cumulative flow diagrams, explaining how each one can help us in not only estimating, but also continuous improvement as well as challenging elements in the organizational culture that dampen agility.

Here are the slides for that presentation, and if you were there, it’d be cool if you left me a rating for that talk at SpeakerRate.

After this was over and I was carried out on the shoulders of screaming fans, I spent a little bit of time catching up with contacts from KCDC’s various sponsors.  This was an especially good KCDC for sponsors.  We had 850ish people there, which meant that, even between sessions, there was a continuous flow of activity to the various booths, unlike previous years where booth visits were pretty bursty in between sessions.

I attended an eye-opening talk on UX from John Alexander, a talk on the enterprise use of HTML5 and various JavaScript libraries from the Keyhole team, and a truly thought-provoking talk on what other languages have to teach us about object-oriented programming by Jessica Kerr.

That night, dinner and drinks with a huge crowd of people I usually only see once a year.  Also, Sugar Ray gave a concert nearby.  Nobody noticed.

I did not get to attend on Saturday, but I hear good things.

I think the venue worked out great, the crowd was numerous and diverse, and the variety of speakers and topics made sure there was at least something for everyone.  It may have been our most valuable KCDC yet in terms of investment.  If you didn’t go this year, dude, go next year.

Enhanced by Zemanta
Apr 152013
 
Illustration of the event horizon (Schwarzschi...

Illustration of the event horizon (Schwarzschild radius) (Photo credit: Wikipedia)

The idea of an event horizon comes from general relativity, but if you’ve ever heard of an event horizon, you probably know it either from black holes or from that weird Laurence Fishburne movie.  With black holes, the event horizon is that boundary around a black hole that marks the transition from “you could conceivably still get away with enough force” to “you’d better tell your friends you’ll be late to the bar.”  Black holes are always pulling at the things around them, but the event horizon defines the difference between having to deal with a black hole and actually being inside one.  Interestingly, from the outside, objects that pass the event horizon seem to disappear completely.

Event horizons are the ultimate black box.  They are the universe’s embodiment of that fight or flight moment.  You can get in, or you can stay out, but you can’t stay there.  In fact, the force required to stay in an event horizon increases to infinity.  The longer you try to remain neutral, the harder it becomes until it’s impossible.

When an organization decides to increase their agility, this effort also has an event horizon.  Generally, these efforts either originate in management and spread out, or they originate in an implementation team and spread out.  The latter is far more common.  Management might mandate the agile effort, but the actual transformation begins in an implementation team.

Regardless of where it starts, this effort has a boundary that attempts to suck in everything else around it.  Agile transformation efforts are not static.  You can’t just take, say, a team of software developers, get them all agiled up, and expect this to have no ramifications for the rest of your organization.  What you have done is created a singularity that, given enough time, will draw in the entire organization.

This is actually what you want.  This is one of the benefits of truly agile efforts; they can’t stay in their little box.  That event horizon is defined by the boundaries of contact between your “agile teams” and the rest of the organization.

Does your project management have distinct, Waterfallish phases?  The event horizon will eventually touch that.  Do you budget your projects on a cost-based approach where you have to allocate all the money up front?  The event horizon will touch that.  Are you constantly changing priorities at the top?  The event horizon will touch that.  Do you have tons of processes solely designed to protect the company from itself?  The event horizon will touch that.

In ways you never even intended, the singularity will try to draw all aspects of your company into it, and the event horizon marks that boundary of change.  Objects pass into it, and that’s where you have the critical moment of decision: do you allow accounting, management, project management, the executive team, and sales to pass through the event horizon, or do you expend force to keep them outside of it?

The answer to that question says a lot about the ultimate success or failure of an organization trying to be agile.

Enhanced by Zemanta
Mar 192013
 
PhotonQ-Homer' s Evolution Theory

PhotonQ-Homer’ s Evolution Theory (Photo credit: PhOtOnQuAnTiQuE)

The Random Language Cloud (Confusicus Maximus)

Example Quote: “Does anyone Scrum the backlog issues into maximum value for the business process?  What are the risks and how do you number the point enhancement?”

Description: Maybe it’s because English isn’t their primary language.  Maybe it’s because the contributor has a very complex concept in their head and has trouble expressing it clearly.  Maybe it’s because someone wanted to spark a discussion and increase their influence for the week.  Whatever it is, the Random Language Cloud is commonly found starting discussions with questions that make no damn sense.  Sometimes, they will also interject into a discussion, but that is a much rarer sighting.

Natural Predators: None.  Virtually nobody interacts with an RLC, although I’d give someone five bucks if they’d just post a reply to one that said, “…what.”

The Guy You’re Not Even Sure How to Start Fixing (Falsus Presuppositionus)

Example Quote: “In agile, what is the best file format for the BA to give me the up front requirements document?  Or do you prefer an electronic tool?  I’d really like to minimize the amount of communication the team has to do.”

Description: Great care must be taken with the GYNESHSF, because some of the time, deep down, is someone who genuinely wants to learn and genuinely has no clue.  They are only difficult because there is obviously a long string of knots that need untying before you can even start to address the issue they raised, but in the long run, the effort is usually worthwhile for both parties.

There is another breed of GYNESHSF, however, that is bound and determined to cling to their original presuppositions and want you to say things that will fit it.  A common sign is the comment, “Well, X wouldn’t work here.”  This is actually a great way to troll agile discussions, but a very bad way to have a real one.

In either case, when this species moves from asking questions to offering advice, get ready to grab a mop and a bucket of napalm.

Natural Predators: Theoretical Agilists – these guys will spend all day with the second breed of GYNESHSF.  Experienced Agilists will spend all day with the first.

The Humble Noob (Genuinius Noobicus)

Example Quotes: “I’m just starting out trying to be more agile, and I’m having problems understanding how to do relative estimates.”

“I’m actually new to all this, but we tried Practice X, and it seemed to work all right.  I’m not sure if it’s the best way to do things or not.”

Description: A reasonably rare sighting, the Humble Noob is great. They genuinely want to learn and are aware that they don’t know very much.  They are careful with their questions, and the advice they offer is suitably qualified with the idea that they may not know the best answer, but they’re just trying to help.

Natural Predators: Theoretical Agilists love these guys because they can rattle off answers from The Textbook without any fear of challenge or contradiction.  It validates their credibility and releases endorphins.  Experienced Agilists, in their best moments, also have a bit of Humble Noob in them throughout their career.

The Theoretical Agilist (Armchairus Quarterbackus)

Example Quotes: “Kanban is no good for software development.”

“Apple is more or less an agile company because Steve Jobs was a Product Owner.”

“Do you have a Product Owner?  Why don’t you have a Product Owner?  You need a Product Owner.  Preferably a certified one.”

“This article by Ken Schwaber answers your question.  You should seriously read this book.”

“That’s Scrumbut.”

“Process is the enemy of Agile.”

“Agile coaches should never help with the team’s actual work.”

Description: The Theoretical Agilist has read books and perhaps has gotten certified.  They are, surprisingly, often Agile Coaches and Scrum Masters.  They may even be advising actual teams.  However, the common characteristic they share is that they really don’t know what they’re talking about because all they know is what they’ve heard or read.  They do not learn from their experience, if they even have any, but instead force their theoretical knowledge upon their experience to try to make it fit.  They are often very good at selling themselves and presenting themselves as subject matter experts, but very poor at articulating the foundations for their views or practical applications.  Professionally, they will happily charge you money to provide no real value except by accident.

Pantheon: Ken Schwaber (the one true inventor of Agile, which is usually a specific process), Mike Cohn (his greatest prophet), Steve Denning (the Real Business Expert)

Natural Predators: Me. Seriously, I lose my s whenever these people show up, and they become more numerous with every Scrum Master certification class.  I am trying to work on this because occasionally in these self-proclaimed experts is someone who really just wants to learn but is insecure expressing that, and I don’t want to turn those people away.  I also don’t want to be a jackass to anyone, but I so, so am when this happens. So, opportunities for personal growth there.  But if you ever want to troll me on LinkedIn, the best way is to jump into a discussion about agile and say that Kanban won’t work in software development and support this by quoting Steve Denning’s blog.

The Experienced Agilist (Mythicus Unicornus)

Example Quotes: “I’ve tried Practice X at four different companies and it worked really well.  It didn’t go so well for one company I tried it at, and I think it’s because it wasn’t a good fit, there, so I tried Practice Y and that worked.  But usually, I try to go with Practice X if I can.”

“Let me show you the change in delivery metrics of this team over the past six months.”

Description: These people have been forged in the fires of adversity.  They, like the Theoretical Agilists, have usually read a lot, are often certified, and sometimes work as full time Agile Coaches or Scrum Masters.  The key difference is they have been at this a long time and can articulate the differences between The Textbook and An Actual Business.  They can also tell you when The Texbook is dead on.  They can also tell you under what circumstances their favorite techniques don’t work well and what better measures are.  They can demonstrate their successes numerically and do not shy away from talking about their failures and what they’ve learned.  They don’t just know What To Think, they also know What To Do.  They know when to let an organization come to their own realizations, when to push them in the right direction, and when to go, “Look, guys, what you’re doing is just stupid.  Stop it immediately and do this other thing.  Just trust me on this.”

Natural Predators: Theoretical Agilists swarm these people like sharks, because 99.999% of the time, their advice varies to some degree from Holy Orthodoxy.  They are also both appreciative and critical of leaders in their field, which does not sit well.

Where do you fit?

 

Enhanced by Zemanta