Mar 042014
Agility 2008 May 04

Agility 2008 May 04 (Photo credit: Cynthia Blue)

Mere days ago, Mike Cottmeyer wrote an article called “Managing Risk and Uncertainty in Agile.”  I think the main ideology is captured in the following quote:

I think [treating software as inestimable] is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing [sic] credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll [sic] can talk about how to move these folks, but for now we have to figure out how to commit. (Emphasis mine)

In other words, since most organizations aren’t ready to be agile, we need to ditch agile presuppositions and practices that would make them scared or uncomfortable and treat software development like deterministic work.  He also explains how the metaphor of building a house should inform our understanding of agile software development and what an impact that metaphor has had on his own understanding and practice.  Ultimately, what he wants agile teams to do is give up-front project commitments and estimates.  He (rightly) anticipates that people will say this is not agile, but answers this objection with something along the lines of, “Yeah, so?”

I certainly agree with Mike that just because something doesn’t line up with Ye Olde Agyle Orthodoxye, that’s not a reason to reject it out of hand.  “That’s not agile” is actually not a valid criticism of anything – you have to go on to explain how the idea or practice would hamper agility or has some other harmful impact.  But my interest here is not to refute the practice of up-front project estimates, commitments, or explain the dozens of ways in which developing software is completely unlike a house and why that is a very wrong-headed and misleading metaphor for software development.

My interest is in those emphasized statements: the idea that we have to learn to cater to an organization’s established, outdated worldview and practices until they change into an agile organization – somehow.  This kills me, and it’s disappointing to see it coming from a company that purports to train people in agility and transform their organizations (who’s transforming whom, exactly?).

It’s like that John Mayer song, “Waiting for the World to Change.”  That song has the worst message, which is, basically, “There’s a lot of institutionalized power opposing good social change, so I’m just gonna quit trying until something changes that situation – somehow.”  When you try to shape agility into the old processes and expectations, that’s basically what you’re saying.

Agility is a challenging and transformative force.  It’s meant to create pain points.  It’s meant to challenge processes and how we think about creating value.  This is what’s supposed to happen.  If greater agility is difficult to manage with an existing budgeting process, guess what’s supposed to happen!  The budgeting process needs to be examined.  If greater agility is difficult to manage with your established project management practices, then you need to look at how your PM processes should change.  Agility is something that affects an entire system.  You can’t just agile up a development team, leave everything else intact, and call it good.

So, I call upon agile coaches, consultants, advocates, and well-wishers to challenge rather than accommodate.  Don’t look for ways to make agility more palatable.  That doesn’t mean everything needs to be uprooted all at once, but it does mean that greater agility should be pushing outward to change existing structures, not the other way around.

If you make agility work in the ways an organization is used to, then you’ve made it irrelevant.  You are an enabler.  You are part of the problem.  They have cancer, and you’re trying to get them to smoke a nicer brand of cigarettes.

If you think you won’t be able to get clients if you rock their boat too much, then do us all a favor and let the market naturally select you out of it so people who can actually help your clients can pick them up.  Nobody needs you to institute daily standups and a backlog and allow them to think they’re ready for unbridled productivity.  Some of you are CONSULTANTS for Thor’s sake.  CONSULT!

All of you who, even now, are thinking of how to change your practices around to fit better with older presuppositions forged in an older business environment – all of you who think agility needs to learn to deliver what project managers expect in order to be viable – all of you who think scaling agile needs more command and control – all of you who have never stood up to a client because it’s in their best interests – I call you to courage.  I call you to challenge those presuppositions instead of accommodating them.  I call you to war against high-risk delivery, false and harmful metrics, misanthropic management philosophies, and waste rather than collaborating with the enemy.

As you work with your organizations, ask yourselves, “Am I doing this because it improves the value delivery process, or am I doing this because it’ll work more easily with the way things are?”  In most organizations, if it isn’t subversive, it probably isn’t agile.

Enhanced by Zemanta
Nov 062013

Local staffing firm and winner of the Most Non-Ironically Orwellian-Sounding Twitter Handle Award tweeted this the other day:

All successful change initiatives start here


That’s a pretty bold statement for a company that’s never done a change initiative.  All successful change initiatives start at the top.

This idea is actually not unheard of.  You hear it other places, mostly as the result of disillusionment.  You can’t be an agile consultant very long without having the surreal experience of a company hiring you to help them change, then deciding they don’t really want to change all that much.  As agility begins to cascade upward and outward threatening all extant presuppositions and practices, they stand, Gandalf-like, bellowing that YOU SHALL NOT PASS and breaking the bridge before all that hubbub you’re creating in their developer teams gets to accounting or whatever.  There was one organization in particular where I felt they were paying me a very good amount of money for the privilege of ignoring me altogether.  Like I said, it’s a very surreal feeling, especially when people can and do ignore me for free.

However, the truth is that change that begins at the worker level can and does work.  In fact, my most successful “agile transformation” started with a development team, and once people saw the points being put on the scoreboard, the changes cascaded throughout the organization, changing their culture, levels of trust, rate of delivery – all kinds of good stuff.  I’ve also seen change initiatives start at the top and fail miserably because, even though management was behind it, none of the workers were.  It was something forced down on them, and they could get with the program or get out.  People were resentful at worst and apathetic at best, confident in the knowledge that this was management’s new fad, and next year it would be something different.  Change initiatives that start at the top without the full buy-in and participation of the ground up have a high risk for failure, and I speak from experience.

So, is it the case that all successful change initiatives start from the ground up?  That’s also incorrect.  Nobody can destroy a company’s agility like their leadership, and I’m going to go along with Deming here and say that the vast, vast majority of a company’s performance problems rest with leadership (ironically, vast amounts of time and money are spent on structures trying to pinpoint failures in the work force – “We need to hold our people accountable” is usually followed by an unspoken “because the problem sure isn’t me”).  Your pilot project can outperform everything in company history, and management can still shut you down.  It would be nice if good results were the final word in these kinds of decisions, but anyone who thinks data is the final word in an argument has never been in a long-term relationship.  So, change initiatives that begin at the roots level without the full buy-in and participation of management also carry a high risk of failure.

If change initiatives that start at the top are prone to failure, and change initiatives that start at the bottom are prone to failure, then what are you supposed to do?  Start in the middle?

The first part of the solution is, as Deming says, “The transformation is everyone’s job.”  You have to be willing to address the organization as a whole.  Agility has ramifications for everyone, and can actually be harmful if you only optimize a particular segment.  Can you imagine what would happen if you could make the front driver-side tire on your car go 50mph faster than the other wheels?  A similar thing happens to organizations where agility is only increasing in one place.  If you want to transform an organization, everybody has to know that what you are doing is going to affect everyone from the CEO to the night janitor.  Naturally, this can cause concern, and this leads me to my second part of the solution.

The second part of the solution is that organizations are resistant to change because of the way we try to make them change.  When we blame an organization’s agile adoption difficulties on their industry, culture, or people, we haven’t gotten to the root cause.  The root cause is that your way of changing the organization is setting it off the way a cold virus sets off your body.  “What the hell is this thing?” says your body, and the fever goes up to try to boil it out of you, the snot spigots unload to try to flush it out of you, and sometimes other unpleasant things that tend to happen at inopportune moments.  This is what organizations do to alien matter introduced into their system.  And believe me, brothers and sisters, I am preaching to myself as much as anyone on this point, as I can cite instances in my career when I was happy to blame the transformational difficulties on the company instead of the way I was going about things.

Yosemite Sam

Yosemite Sam (Photo credit: Wikipedia)

Change initiatives have to be done with a respect for people and in a manner that drives out all fear of losing their job (Deming, again).  This is the genius of Kanban: the changes are incremental, evolutionary, and the ideas and decisions come from the people doing the work instead of something imposed on them from the outside.  You can’t just go in like Yosemite Sam hootin’ and hollerin’ with pistols blazing.  When people start responding with resentment or fear, that’s your cue that you have done something wrong; it is not a cue that something is wrong with them.  What kind of misanthrope would you have to be to start thinking about getting rid of people who are actually doing you a huge favor by reacting negatively to what you’re doing?

When you start with where workers are at, and you give them the tools to visualize their work, and you help them define what they’re doing, and you help them measure how efficiently that work is being done, and you ask them, “So, what do you think we should do?” you are on the road to people being valued, giving you buy-in, and coming up with better solutions than you could.  Do you sometimes need to bring in ideas from the outside to get people started?  Sure, sometimes – but even then, it’s something you want them to own, not something they have to comply with.

Change initiatives from the top can work; change initiatives from the bottom can work, but both are risky.  Successful change initiatives start with everyone, and they are done by listening and building up your people instead of forcing it on them or getting rid of them.

Enhanced by Zemanta
Nov 042013
W. Edwards Deming--statistician...saint

W. Edwards Deming–statistician…saint (Photo credit: Kazanjy)

In Chapter 2 of Out of the Crisis, Deming presents his 14 key principles for transforming an organization’s management, and by “management,” I mean “the way things are done,” not just specifically a certain organizational layer.  As Principle 14 tells us, “The transformation is everybody’s job.”

This was a fascinating chapter, not just because of the principles themselves, but because I could mentally compare and contrast them with how organizations I’ve worked with have been run as well as what business/agile consultants talk about when they speak of transforming an organization.  A lot of things consultants talk about a lot are not in that list, and vice-versa.  It was also interesting to see the points Deming chose to really hammer on.  Pages and pages are spent on the single-vendor principle (Principle 4), for example.  I didn’t count, but that one point may have more ink dedicated to it (in this chapter) than any of the others.  When leading a software development team, our “vendors” are not just equipment and software vendors, but they are also the people who give us our requirements, so I had to do some uncharacteristically intense cogitification to think through how that principle might apply to that area.

But those details aside, I wondered why his principles seemed so alien to American business.  I mean, the man almost singlehandedly rebuilt Japan’s economy and brought them from being a nation shattered by war into a lead contender in the world economy.  When you think about it, that doesn’t leave the rest of us with very many excuses, does it?

“I’d love to take the time to focus on quality, but our sales were lagging last quarter, and we really need to just get some things out there to meet some marketing deadlines.  We’ll track back around and improve things, later.”

“Yeah, I know what you mean.  Times are tough.  Last quarter, someone dropped atomic bombs on our major cities.  So, you know, that’s similar.”

If Deming’s principles can bring your business to roaring prosperity after that, it seems like more people would be doing these things, or at least talking about them, right?  He had worked with organization after organization, employee after employee, manager after manager, country after country.  He wasn’t infallible by any stretch, and his thought came out of a particular context, but still – why does it seem so different than what people are on about, today?

I think one reason for this is that Deming had a different end-game for businesses than most of us.  In Deming’s eyes, businesses existed to build a nation’s wealth and increase the prosperity of her people.  It’s really been interwoven through everything in the first couple of chapters.  Businesses that follow his principles prosper in the market, which enables them to provide more and more better-paying jobs to more people for years and years to come.  The idea that a business exists primarily to make a lot of money for an individual (or small group of individuals) to be discarded when it has served that purposes seems kind of alien to his way of thinking.

In Deming’s mind, if I start a business, it should be so that I can increase the prosperity of as many people as I can for as long as I can.  This is business eschatology.  This is the telos of your organization: to keep as many people employed as possible, paid well, happy and gratified, and improve your country and ultimately the world in this way.  Of course, as a by-product, you’ll be increasing your own prosperity, too, but you increase your own prosperity by focusing on helping first.

Perhaps this is way his notions of focusing on quality, building long-term vendor relationships, continuous improvement, ditching evaluations, and building systems that bring out the best in your people seem so out of place in the current business consulting climate.  In American business, today, the goals of many business owners are to make as much money as they possibly can in as short a time as they possibly can.  The goal drives your current behavior, which is why many of the discussions en-vogue today revolve around working faster, getting rid of people, getting lean by way of cost cutting, etc.  A lot of businesses are just trying to make as much profit as they possibly can as quickly as they can.  Everything else is driven by that.  Quality is only interesting if it becomes a factor in how much money they can make.  Improving their system is only important if it helps hit a certain profit target by a certain timeline.

I don’t have any statistics on this – it’s purely a personal hunch based on conversations, so don’t take it to the bank – but I’ll bet if you asked a group of startup owners what their long term goals were, a fair amount of them would say they’d want to get the business up to a certain value and sell it.  I’m not condoning nor condemning that.  It’s a perfectly legitimate choice.  It is, however, very different from Deming’s idea of the role a business plays in the economy and in the lives of the people involved, and so the values are going to be different.

As for me, reflecting on things like high unemployment, the reputation for shoddy workmanship certain American products tend to have, the disparity of wealth distribution, an ever-growing class of “unhirables,” businesses that are here today and gone in three years, I don’t know.  You almost get the impression the man was on to something.  The crisis he wants us to get out of isn’t a crisis of bad business; it’s a crisis of national and worldwide economic proportion.

Enhanced by Zemanta
Oct 282013
Different speed limits apply for day and night...

Different speed limits apply for day and night time on this stretch of the U.S. Highway 1 on the Florida Keys (in a Key Deer habitat). Note the nonreflective backing of the day speed limit number. At night only the number on the lower sign is visible in the headlights. (Photo credit: Wikipedia)

A little less than a year ago, Ben Barreth and I were racing at Sadlers, and he asked one of the attendants what the secret was to a low time.  The attendant told him: “Slow is smooth, and smooth is fast.”

See, if you go tearing around the track at top speed all the time, you’ll end up doing things like drifting around corners, brushing up against walls, and having to do massive changes of direction.  You feel this when you race; if you take a sharp corner at top speed, your wheels lock up against the track making that terrible screeching noise, and it takes all the speed out of you.  You have to start building up speed all over again.

Although it might seem counter-intuitive, the fastest way to get all the way through the system is not to crank up to your top speed the whole time; there are key times when you need to slow down to navigate difficult areas and, in the process, you end up going faster as a whole.

I’ve been getting back into my W. Edwards Deming reading (a man who was very clear that problems in American management are process problems, not people problems), and in the opening chapter of Out of the Crisis, he makes the main point that low quality is what’s holding many organizations back.  Low quality necessitates rework.  It makes customers unhappy.  And it isn’t free – someone gets paid good money to put those product defects in, and then someone gets paid to take them out.  He captures the “quality chain reaction” in a diagram that looks like this:

Improve quality -> Costs decrease because of less rework, fewer mistakes, fewer delays, snags; better use of machine-time and materials -> Productivity improves -> Capture the market with better quality and lower price -> Stay in business -> Provide jobs and more jobs

(Deming, Out of the Crisis, Chapter 1)

As one of many illustrations of various facets of quality, he brings up an example of a superintendent he was advising.  The first thing they did was measure the amount of defects produced over time, and they found that although the rate was variable, it was also fairly predictable (average 11% defective products over 30 days).  So, they had a nice, predictable system for producing bad stuff.

How do you get this number down?  Well, in this case, the people defined what counted as acceptable work and unacceptable work with examples of each, and made sure everyone understood.  This one act alone brought that 11% down to 5%.  That’s at least a 6% gain in productivity.  Then you start thinking about that remaining 5%.

The point is, a huge gain in speed was made when the group made a firm decision on what work would and would not be acceptable, and everyone knew what that meant.  Does that mean that it might have taken a little extra time to ensure what you were working on met the acceptable standards of quality?  Probably in some cases.  Would taking the extra time to meet quality standards take longer than finding the deficiencies later and fixing them?  Probably not.

Lowering your amount of rework is the cheapest, least disruptive way to move faster.

And there are many other benefits as well, especially when it comes to customers.  Defects take a toll on the customers who receive them.  It wears down trust, goodwill, and can ultimately drive them to look for someone else.  Driving your workers to produce faster at the expense of quality denies them the ability to feel pride in their work and a sense of craftsmanship and accomplishment.

Focusing on the quality of your work helps you get more high-quality product into the market faster, is more appealing to your customers, and is more enjoyable to your professionals.

Do you know empirically how much re-work accounts for your total workload and costs?  Do you have clear definitions of what’s acceptable quality and what isn’t?  Does everyone agree on those and agree what should happen when work is unacceptable?

Everyone wants to go faster, but just remember that productivity isn’t an open straightaway; it’s a system with sharp curves, critical decisions, and a dependency on a support structure that can only take so much wear and tear.  Slow is smooth, and smooth is fast.

Enhanced by Zemanta
Oct 082013
organizational culture

organizational culture (Photo credit: nchenga)

In survey after survey, the #1 reason agile practitioners cite for the failure of an agile effort is that the company culture didn’t support it.

That’s probably true, but I think we might be letting ourselves off the hook, here.  For an agile consultant to say the failure of the initiative was due to the company culture is sort of like saying that a patient’s cancer treatments would have been effective if it weren’t for that cancer.  Or making a PSA to announce that death is the #1 killer in America and we should all take steps to avoid it.

In the interest of transparency, I have been guilty of this more than once.  I’d go to a place, get an uncharacteristic amount of resistance (it’s a weird phenomenon that organizations will sometimes pay for consultants and then ignore them), and after a certain period of time, decide that agile just wouldn’t work there because of the culture.  If I’d been really honest with myself, the truth would have probably been closer to, “I’m not wise and experienced enough to know how to handle this situation,” or maybe even, “I don’t want to put in the amount of effort and longsuffering it will take to weather this situation.”

A dysfunctional culture is exactly one of the things greater agility is supposed to challenge and gradually alleviate.  The kinds of things you do to empower people to turn from victims to self-improvers are the kinds of things that begin to dissolve cultural problems.  Command and control cultures begin to thaw when they see the gains that a high level of self-direction gives.  Trust and cooperation begin to build among traditionally hostile departments when teams become more dependable and transparent.  On and on.  This isn’t just me waxing hypothetical, either.  I have personally seen this cultural transformation several times at the hands of a burgeoning agility.

Only trying agile initiatives at companies who have the culture for it is like testing your hangover remedy with teetotalers.  A company culture that’s ideal for agile is inevitably going to be agile all by themselves.  You might still add value in helping them optimize here and there, but you won’t have substantially improved that organization.

It is the entrenched waterfall, hierarchy out the wazoo, big planning up front, command and control, whirlwind priorities, siloed organizations that need the gentle erosion of improvement, agility, and optimization the most.

Enhanced by Zemanta
Oct 032013

Think (Photo credits:

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 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
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
Mar 272013
English: Picture taken from the Liberty Memori...

English: Picture taken from the Liberty Memorial in Kansas City, MO. High Resolution. (Photo credit: Wikipedia)

The flip side of the education coin are the employers.

Regardless of the causes or who thinks what about how we got here, the fact is that employers in Kansas City are having a hard time finding and retaining talented IT people.

It’s very easy to say that there aren’t that many talented developers out there or look to some cause external to yourself.  Obviously, per yesterday’s blog, I think there are things that training institutions could be thinking about differently to try to address this shortfall.

However, like I tell my teams, spending your time complaining about external causes has very low value.  Whether you’re right or wrong is irrelevant – you can’t control external causes.  The economy is what it is.  The market is what it is.  Kansas City is what it is.  You’ve been dealt a deck of cards, and that’s the cards you have to play.

The high value activity is looking at yourself – doing the hard, painful work of being self-critical.

Why should I come work for you?

There is no New Economy.  It’s now officially just The Economy.  You probably don’t have the funds to golden handcuff a squad of dream employees to your organization.  You may want Brett Favre, but you have the money for Matt Cassel.

If you do have those funds, then don’t hold back.  Don’t be “competitive” with your salary.  Blow everyone else out of the water.  Be disruptive with your compensation.  You compete in every other area; why not compete in this one?  But, honestly, it’s not usually about vast differences in salary.

It’s usually about what life will be like for your employees.  Do you put your developers in fabric-lined jail cells and saddle them with meaningless deadlines, tedious processes, and a culture that is basically designed around the idea that your employees are lazy and can’t be trusted?  Do you have unclear priorities?  Do you align your development projects and your developers with your company’s objectives?  Are they a part of something bigger than themselves?  Or are they a machine where requests come in and product comes out?  What are employees getting into?

If you have a scenario where no one would want to live in it for more than a year, don’t expect to attract and retain top talent.  Don’t dehumanize your developers and then complain about how hard it is to find people.  Kansas City has lots of exciting things happening, but in terms of its ecosystem, it has a small town dynamic to it.  Everyone knows everyone else.  Every developer has six degrees of separation from Kevin Bacon and someone who left your company.  What stories do they have to tell?

But here’s the other big one.

Are you giving new folks a chance?

Just for the sake of argument (I’m not necessarily granting this point), let’s say that Kansas City’s available hiring pool is light on the experienced hotshots who have mastered a wide array of technologies, and let’s say it’s heavy on recent grads, career-changers, and junior level devs.  Let’s say the perception is reality.  Let’s say, for every twenty resumes you get, only one or two seem really shiny.

What are you going to do about it?  These are your cards.  You can’t change them.  What’s your play?

Well, you can poach heavily, and while you might attract some high-end talent that way, why would you think those same people couldn’t be poached by someone else offering a 10% increase in salary?

Or you can deal with reality.  Instead of trying to fight the trend, why aren’t you harnessing the trend?

  • Do you have an actual plan to turn junior developers into senior developers over time?
  • Do you pair up your superstars with your newbies on projects so they can work on each other’s code and have a true mentoring / apprenticeship relationship?  Or do you silo your developers and just give the junior levels the “easy stuff” or maintenance tasks?
  • Why aren’t you giving new devs a chance, knowing that, sure, it won’t work out for some of them, but some of them will be gold?  Some of them will be the backbone of your efforts for years to come.
  • Why isn’t hiring new grads or career changers part of your strategy to get ahead of your competition instead of something you are trying to avoid at all costs?
  • Why don’t you give recruiters a list of personal characteristics that you want to shape your teams and your culture and draw your line in the sand there instead of pre-packaged technical knowledge or an arbitrary number of years of experience?
  • Why aren’t you open to hiring someone who works outside of your technology stack to see if they can bring innovative ideas or problem solving abilities that your current stack might not foster?  I’d hire a passionate, thoughtful Java developer for a .NET shop over a “this is just my job and I’ve coded the same way for ten years” C# developer any day of the week.
  • When you hire a senior level developer, are you asking about their mentoring abilities?  Are they someone who can help the more junior level developers grow?  Will they build your team into a high performance nightmare for your competition, or will they just crank out your code and take their paycheck?

Now, I’m not suggesting you just randomly hire a pack of people with no experience and no knowledge of your development base, but what I’m saying is this: instead of whining about the lack of experienced developers, why not proactively work with the reality on the ground?  Why not intentionally plan to hire junior level people with a very deliberate plan to grow them into your future team leaders?  Can you imagine how attractive that would be to job seekers?

As a long time developer myself, I’m going to let you in on a little secret.  Being a good or a bad developer has virtually nothing to do with experience, education, or anything else you’d find on a typical resume.  It has everything to do with passion, drive, and a self-generated commitment to learning and continuous improvement.  Isn’t that what you want your company to look like?  Wouldn’t you love a team of people spurring each other on to greater and greater performance?  Hire for that.

If you can plan for that – if you can design your hiring process that way – you might find that it’s not as hard to hire good developers as you thought, and you’ll find yourself looking at a crop of eager new hires ready to show you what they can do and having a vested loyalty in the companies that believed in them.  While your competitors are still behind looking for the next superstar or trying to steal her, you’ll be getting your projects done and growing your own superstars.

Enhanced by Zemanta
Mar 262013
The Careers Day poster they rejected

The Careers Day poster they rejected (Photo credit: Alun Salt)

DISCLAIMER: I will use specific examples throughout this post without naming any names.  I want to make it clear that this is not picking on any one particular institution or form of IT training.  I have been a trainer for one of Kansas City’s largest IT training firms.  I have taught college classes.  I have made training DVDs.  I have subcontracted to teach with other training companies who span the globe.  These issues are in lots of places, so please don’t take any specific example and assume I’m trying to come down on a particular institution or practice or favor one over the other.

In doing the research for this post, I started going through the websites of various “career changer” programs.  You know, the programs where someone wants to make a big change and get into an IT career, but they have no real background or experience, so they sign up for a multi-week program to teach them foundational skills that, ideally, is enough to get them an entry-level job to start them down a new career path (incidentally, I totally believe in this model if done well).  I was looking for success stories.

What I discovered was that most success stories were several years old.  In fact, one institution led with a great success story in their marketing materials for their program.  That story was five years old.

Think about that for a second.  All the students that pass into and out of this program, month after month, year after year, and the best results they’ve gotten so far were five years ago.

Despite the current fad of people with no real knowledge of the field inventing statistics to try and prove there’s a developer shortage in Kansas City, the reality is far more complicated.  If there’s any shortage, it’s a shortage of highly qualified developers in Kansas City.  If you post a job opening in IT right now, you’ll have no shortage of applicants.  You’ll still have a hard time finding someone.  In fact, just a couple of months ago, a friend of mine who is responsible for hiring for a very large organization here in Kansas City told me point blank, “We’re getting lots of applicants, but most of them are graduates from Institution X and don’t know s***.”

There’s a disconnect.  Four-year institutions, two-year institutions, and training companies continue to churn people out into the market, but the market doesn’t seem to be buying.

On the other side of the fence are the pundits who just flat out say that colleges and/or career-change programs just don’t work.  This doesn’t seem right either, because there are successes and, quite frankly, it’s hard to think of another model that can accommodate the quantities and speed of the market right now along with the depth of knowledge required to write good software.  If you don’t have organizations dedicated to making this happen, the odds are good it won’t happen at all.

My premise, which of course may be wrong, is this:

Organizations who train IT careers, specifically development, need to ditch their current models and adopt ones that are market-responsive and student-first.


Most IT training organizations are not matching their curriculum to demand.  This is a known issue with two and four year institutions, but it is a staggeringly huge issue with IT training companies and career-change programs in specific, and it has been this way for a very long time.  I’m not talking about the specific manuals they use or whatever; I’m talking about the actual topics covered.

Every so often, I’ll see an update somewhere that looks something like this, “Getting ready to learn design-time data binding to datagrids.  Whole new world!” or “Finally creating DataSets.  This stuff is awesome!” and I die a little inside, because these are the functional equivalents of someone training for the medical field and tweeting about leeches and hacksaws.

Nobody wants that stuff because nobody is doing that stuff.  No company is trying to hire someone for web technologies and methodologies that are now 12 years old (NOTE: Ok, obviously, occasionally people do hire for very old technologies because they need to support old products or simply refuse to change, but I’d say that’s not where most of the technical demand is).

In researching this post, I pored over job openings in Kansas City for .NET web development, and they were asking for MVC, HTML 5 and JavaScript, NoSQL, ORMs, TDD, MVVM, and design patterns.  I found two that asked for ADO.NET (along with the other things on this list).  If the whole purpose of your company is to release people into the field who can perform a trade, why isn’t the taught curriculum aligned with what people are asking for?

Teaching Methodology

PowerPoint slide.  Explanation.  Demo.  Lab.  Not.  Ideal.  For.  Career.  Building.

That way is ok-ish for getting across a specific technical topic to a specific kind of audience and background: namely, the kind of audience who already knows how to build applications and practically apply their knowledge in the field.

But if you want to teach someone how to build applications, then you build applications and instill the requisite knowledge as you go.  And when I say “build applications,” I don’t mean labs that have been specifically designed around a particular concept.  Those are notoriously unrealistic and often actively teach bad practices and bad ways of solving problems, because the focus is on that specific concept and not the other parts of development around that concept.

“But if I’m trying to teach someone data access, I don’t have time to teach things like proper separation of concerns in the class layers or HTML 5.”

Exactly.  That’s exactly the problem right there.  You’re trying to teach someone data access instead of teaching someone how to build an application and talking about data access in the context of building that application.  People leave your training (even if it’s a four year program) knowing a ton of isolated, bad examples of various technologies, but they do not understand how to solve problems with these tools, how these tools interconnect, or when these tools are bad decisions.  And because you are so focused on teaching them a technology, they probably have never even seen a realistic example of it.

This dovetails with another issue, that most IT instructors/professors in Kansas City are not developers or haven’t been for a long, long time.  They are just as incapable of teaching a class driven by actual development as their students, and their knowledge and experience is just as limited by the curriculum as the students.  It’s not impossible, but it’s very hard to learn a trade from someone other than a tradesman.

Economics and Risk

Most IT training programs require the student to pay regardless of the result.  Some companies are thankfully breaking away from this model, but it’s still the most common model.  Students pay tuition to the training institution no matter what.

Two problems here.

On the student side, it puts them at enormous risk.  They have to pony up (or taxpayers have to pony up, in some cases) several thousands of dollars that may ultimately result in nothing.  Although I’m way more concerned about the students than the institutions who train them, this is actually not the biggest problem.

The biggest problem is that, on the institution’s side, their primary motivational force now becomes getting people into their program.  Not preparing them for jobs.  Not getting them jobs.  Getting them in the door.

When the training company I worked for started doing career change programs around late 2000, they made all prospective students take a short test.  It was things like pattern recognition, etc.  Nothing heavy duty, but it did look at their ability to spot patterns, think symbolically, etc.  At the time, a student had to score a 90% or above to be admitted to the program.

Over time, it got lowered to 80%.

Then 9/11 happened and the training market tanked big time.  60%.

Eventually, the test was completely done away with.  We got people in our program who were great people, smart people, and very gifted in many ways, but coding at an in-depth, professional level was just not something well-suited to their way of thinking and gifts.  But we took their money, gave them their diplomas, and sent them out the door.  And I quit.

The thing is, the success of our students only indirectly affected our prosperity (by way of marketing).

How would it transform things if institutions only got paid if and when their students got their first IT job?

Holy crap, right?  Now, I have an interest in helping students find their proper niche here or elsewhere.  I’m only interested in putting the student in a web development program if I think the student has the chops to be a professional web developer instead of the chops to secure a $12000 loan.

I’m motivated to make sure my curriculum reflects what business owners want and need.  I’m motivated to make sure all my students are solid.  I’m motivated to make sure anyone who learns how to develop from me can go into a team of experienced developers and play at or above their level, because if they can’t, I don’t make my money.

Before I close, I just want to say that deep within the chocolatey-good depths of my cynical heart, I am warmed to see some amount of rising to the occasion.  The Disruption Institute, for example, shows a real initiative in looking not only at what the market needs today, but will need in the very near future, and organizes their curriculum around that – curriculum that has been put together by actual developers in the field.

I believe in training companies.  I believe in two year and four year computer science programs.  They all have their place for different people and different goals, and it’s a poorly thought through plan that would advocate getting rid of any of them.  But you have got to step it up.  If you align yourselves with market needs and commit yourselves to the students’ welfare first, the money will follow.

Enhanced by Zemanta