Let's take a quick look at a scenario that happens all too often in the business world…

1.       Company has process/culture problem.

2.       Consultant brings in new process.

3.       Company loves new process.

4.       Process fixes problem.

5.       Consultant becomes hero.

6.       Company thinks Consultant IS the process.

7.       Company becomes dependent upon Consultant.

8.       Company doesn’t want to let Consultant go.

When it comes to software developers, we live in a town that gets attached to individuals.

Often we start as consultants and over time bleed into staffing models.

It’s somewhat revealing about what clients truly want.

And it’s cultural. It has to do with trust and execution. After being at a client for awhile, the Consultant's messages – and what their Company stands for – become replaced by the hero culture of the individual.

There is a portion of this that’s knowledge work and we fear that change of personality presents a loss of that knowledge. We worry that it will create uncertainty in our daily continuity. That’s understandable. We start to imagine that the daily operations of the new process can’t operate without the Consultant on hand to make it tick. But other individuals have knowledge too, so perhaps the real fear is that we might be losing someone who can save us in dire circumstances.

The fear of losing the hero as our "Ace in the hole".

The intention of having a consultant should be to help companies course correct and become self-sufficient with new approaches.

If you’ve had a rock-star IT consultant come in to help with your internal pictures, at some point he or she should be able to put themselves out of a job. But the opposite invariably happens and Dependency situations arise instead.

Companies lose sight of the original intention, and the consultant gets swallowed up in the process they’re attempting to correct and the message is lost. The Consultant becomes a daily grind "fix-it-all" super-hero – strapped to the process they’ve been hired to provide assistance with.  

We get tied up in the achievements of the individual, and not the philosophies they brought to the table. We start treating him or her as a great developer who can get more work done than their peers, and the Consultant turns into a “Butts in Seats” contractor. We lose sight of how they were able to achieve success. In fact, we don’t really care. Ultimately, we just want it done for us. We want the hero to arrive to save us from the very same poor decisions we were asking them to originally help us with.

We want the Consultant to save us from ourselves.

Focus instead on what the Consultant is telling you – the process improvement and self-sufficiency. Not the hero that made it happen. Listen to what he or she is telling you. Don’t just watch them execute and absolve yourself of the responsibility of learning what they are attempting to teach you.

Instead, up your own game. After all, that’s what the Consultant was originally brought in to do, right?

Every day I see more and more developers becoming agents of positive cultural change in their own organizations and IT communities. Either by nature or occupational hazard, we enjoy problem solving. It’s just how we tick.

Because software touches every aspect of a modern organization, our opinions are being sought to help solve larger systems pictures. As we do so, mentors and thought-leaders have become an indispensible part of that transformation to better practices.

Developers are in a constant learning culture and it can be an overwhelming experience for new developers to even know where to begin. Given the pace at which new technologies and practices arrive and the breadth (and depth) of knowledge we’re expected to retain, ours is an industry that benefits immensely from mentoring.

Mentoring assists with technology, practice and process learning curves, team cohesion, software delivery, stakeholder engagement and employee retention (something that all IT departments face).

Rather than tread ground that’s already been walked before, a mentor will show you solutions that have already been formed and help you avoid technical dead-ends that have already been taken. It can also help a company avoid Technical Debt born of rookie mistakes.

So what are the qualities you should seek in a mentor?

1. Seek out a subject matter expert (if one exists) in your area. Someone who has invested the time it takes to understand something deeply.

2. Seek out someone who actually practices what they preach and who can explain why alternate approaches might fail. But beware of a mentor claiming subject matter expert status in a technology that’s 10 years old… We call that archaeology.

3. Seek out developer mentors who are the communicators in your discipline. The ones who publically speak and blog are excellent choices because they’re brave enough to publically stand behind their facts and convictions.

4. Seek out developers who are trying to address larger industry dysfunctions like Agile, Lean, Kanban. These are your thought-leaders. They are the ones attempting to make this industry a better place to work in. They are the culture changers – the ones who can help with larger company pictures.

5. Seek out a mentor who is also focused on community. We’re fortunate in Kansas City that the developer community is so actively collaborative in nature.

Good developers love to learn and share it. Good mentors show up.

Here’s a quick list of groups and events that you might think about checking out. This list is not exhaustive, but a great starting point if you’re wanting to find a mentor or simply become more active in the community. 

Kansas City Developers Conference – A yearly event not to be missed. Mentors, MVP’s, speakers, bloggers, experts galore.

Limited WIP Society Kansas City - A monthly meet up for developers interested in the Lean and Kanban software development. A great roundtable on topics suggested and voted on by those who attend. Moderated by Troy Tuttle.

Kansas City IT Professionals – Run by community advocate Mike Gelphman. Mike also runs the most active IT LinkedIn group in Kansas City.

KCNext – Recently merged with SITAKS serving as a regional advocate for KC Tech companies.

8:00am:    Phone rings – You’re asked to help a new employee who doesn’t understand the system you were part of implementing a year ago. You take an hour and a half to help out because a departmental manager who believes training is “an IT thing,” has conveniently passed the buck and absolved himself/herself of the responsibility.

9:30am:    You get a coffee break and vent to a coworker that training was not part of why you signed up. Your manager has seen and condoned this 1.5 hours, but still expects you to commit to the "deadline".

10:00am: You get an email that a self-important departmental manager would like changes to an existing system. He has escalated it to all departmental heads because the competition is doing it and it’s the latest priority #1. He is a predictable squeaky wheel, but he generates fear so well that IT is forced to drop everything and respond.

10:01am: You check in with your boss, and indeed, find out that this has been deemed “an emergency.” You both question the need for a steering committee governing best business interests, but realize that the company should have the ability to change its mind… And they do – often.

10:15am: You both hurry to meet the departmental head to understand this dangerous threat to the stability of the company and experience a venting session about how your software is non-competitive. The specifics are short, but the emotions are high, and IT is to blame for a sudden marketplace inequity.

11:00am: You decompress with your boss and attempt a course correction to help out Mr. Needy and his attempts to sully the credibility of the IT department.

11:30am: You’re still in the dark as to what the specifics of marketplace advantage translates to, so you go to lunch and spend an entire personal hour discussing and interpreting his needs while two tables over, he has a relaxed meal with the competition.

12:30pm: You check email and find there’s another departmental head with an operational crisis. It turns out to be something that’s happened repeatedly before, but your past help hadn’t championed any advocates – it had only created a technology (help-desk) dependency situation. You help the user find the ALT key, resize a window and listen to them talk for an hour about their fear of pressing the wrong button.

1:30pm:   You try to redress where your day has gone and what project it started out being. You start getting back to the project that you’re meant to be working on. You view the code, attempt to assimilate it back into to your memory and get on track. The conflicting needs of departmental heads predominate your thoughts and concentration and effort seems a joke if your priorities are forced to change tomorrow.

2:00pm:   You start to question your priorities with your manager. Your manager attempts to run interference but is conflicted by whose political needs will help his own cause. Everything seems to be Priority #1. There seems to be no visibility to the department or company on your ever-changing work schedule.

2:30pm:    Things go quiet for a while as if the drama might pass and tomorrow might be a set of new priorities. You feel like a pawn in a game with an allegiance to a department rather than a company. Because no new priorities have actually been set, you go back to your scheduled development work with a tinge of guilt because you’ve not really received any true guidance and instead, feel like you should be providing some.

3:30pm:   You get back to the code you were meant to start at 8am this morning.

5:00pm    Your boss stops by to ask about the progress of “the project”. He reminds you of "the deadline" while your mind wanders more consciously where your subconcious has been all day…..thinking about finding a new job. 

At the end of your 8-hour day, you’ve lost 6.5 hours against that project “deadline” (not including your personal lunch time) and are still expected to deliver a miracle. You wonder how tomorrow will look. You know it’s not predictable, and you know that the work you did today will not be accounted  for against the project. It will become invisible to your boss, the department and the company.

All they will see is the looming mythical deadline…and a false perception of IT incompetence. 

We like to educate. In fact, we even have a board game we use frequently to help clients visualize workflow and facilitate collaborative systems thinking.

We recently introduced this game (created by a fellow New Zealander, Heaven forbid) to a selected group of cross-functional internal change agents.

They seemed extremely engaged and excited by the benefits of Kanban and receptive to the collaborative approach required by each other’s input.

It was a great session on software delivery, where the players identified bottlenecks in process from a full systems picture. Amongst other things, we discovered that optimizing one functional area did not ensure better throughput of software.

Important lessons and great stuff if you’re in to that sort of thing. We are, and so too was this group.

Here’s something interesting, however: In order to represent the productivity of a developer in this game, dice are rolled…

This is always an interesting conversation topic and uncovers a host of questions like the ones below. Take a look and let us know what you think: 

1. Is it realistic to portray developer productivity this way, on the randomness of a 1-6 scale?

2. Is the daily life of a developer really that unpredictable?

3. If it is, then what does that mean for project planning and estimations?

4. When you ask a developer how long something might take, how do you account for interruptions, daily “emergencies”, or the business demands for their knowledge? What’s your “padding” for those factors against that guesswork – surely padding itself is guesswork game too? Now your project planning is nothing more than a game of predicting padding on top of other guesswork.

5. Can you really keep a developer in a productivity bubble away from the demands of the daily operation of a company? Does that solve any problem, create more or just move the problem to others?

Deadline: Originally a Civil War term for a line that marked the distance a prisoner could go before being shot on sight. (source: http://www.thefreedictionary.com/deadline)

When I see an employee who is asked to guess on a timeframe, be held accountable for such random number theory, and then forcibly held accountable to that speculation – I become concerned.

When I hear an IT department say, "We need to identify these timeframes so we know how much overtime we'll have to put in to make our deadline"  -  I positively cringe.

Many companies still have an unhealthy "adrenalin-junkie" addiction to deadlines because they confuse them with results. The truth is, and what many companies repeatedly fail to understand, is that they are actually incurring larger costs in the form of waste, technical debt, staff turnover, disengaged employees, and eroded company culture.

As this self-induced erosion occurs, these companies get a reputation in the community as a place to avoid, both from consumers and job seekers.  

This tired practice of using wartime models for peacetime business practices is both misplaced and corrosive. Comparing workers to soldiers, projects to D-Day beach landings, and acceptable losses/collateral damage to the greater cause……all of this modern day nonsense eventually erodes the very business continuity and productivity gains they were trying to obtain in the first place!

If the goal is productivity – deadlines will guarantee the opposite. Forcing your staff to meet arbitrary timelines doesn’t build morale; instead it builds an unhealthy camaraderie of mutual hatred, resentment and distrust toward management.

Steady, predictable output, determined from actual metrics, gets you there – and more accurately. Agile principles, when applied correctly, have the ability to turn the tide of the deadline culture while simultaneously creating better work environments.

What company in their right mind WOULDN'T want that?

This year, why not change the way you've always done things? Let your employees enjoy the holidays without the threat of looming deadlines born out of someone’s need for their bonus or misplaced desire for a neatly packaged project completed at year end.

The deadline isn't what's most important.

Approaching things in an agile and lean manner is a philosophy, and as such it's not something you do only while at work or even during a certain project. Some people will always run and be comfortable with a waterfall project because that is their internal process. 

Planning

If you are an inherent 'planner' then being agile to you will feel very chaotic and out of control, however it is mearly about only planning as much as necessary and delaying decisions until the last possible responsible moment.

You might be a waterfall-ist if:

• When planning a family vacation are you the type that planned on Thursday 4 days from now at 1:15PM you will be stopping by the worlds largest Starship Enterprise?
• Instead of going to the grocery store every 2 or 3 days to food for what you feel like at the time or do you buy 10 lbs of beef at a time from Costco and commit yourself to eating it all that week even if you find out Wednesday that all beef was a bad choice?

Being agile is not making so many plans that you are heavly invested in them not changing, instead you should be able to switch directions quickly enough to respond to changes or unforeseen obstacles. As valiant as it seems sticking to your orginal plans no matter the developments along the way, it is actually not good decision making. Unless your filming National Lampoon's Business Vacation, then you can go crazy Clark.

Constraints

Another attribute is how do you handle failures or other undesired results. If you have seen huge process maps with seemingly endless hoops to jump through to get work done, its most likely the result of over compensation for failures. Everytime something has gone wrong in your process, it is not an immediate invitation for extra constraints, contstraints in a process should exist to provide benefits not to just stifle flow. Sometimes the cost of a failure is less than the cost of the constraint, in which case it makes more sense only to work on lessening the impact than to implement a prevention constraint. If you don't know the cost of the failure or the constraint then it's irresponsible to implement one.

To put this into everyday perspective… car wrecks happen everyday and people get seriously injured and even killed. This is obviously a very bad result that can be solved by constraining car speed to 5mph. While this will work the cost of this constraint is quite massive and not ultimately beneficial. A better solution than simply slowing traffic to a crawl would be to develop smarter and safer cars to make wrecks less dangerous.

So before you go out and try to do an agile implementation do you think you have the mindset for it?

I remember being asked once how shipping and handling was calculated in a client's system. I thought it was an odd question, but I was being asked by a Senior V.P of that company so I thought it best I cooperate. I’d been working there as a consultant for only about 2 months, but there was an expectation that I should know the answer “because it was in the code” and well, I was in the code too.

I think he could see the double-take on my face that said, “So how long have you worked here and been a Sr. VP? You don’t know how your own freight is calculated? Couldn’t you ask your CFO?”

But this sort of business-to-IT dialogue is common. After some research, I was able to look through the code and provide the somewhat convoluted calculation for him. He looked at the calculation and then…get this…he began to press ME as to WHY it was calculated the way it was. 

“Who made that decision?”, he proceeded to ask me as if the IT consultant that had been at the company for only 2 months could go back in time and be a fly on the wall when that decision was made. 

This scenario is an all-too-frequent and frustrating conversation between business and IT. But who else did he have to ask? Performing a witch hunt for an employee who no longer worked at the company was a worthless pursuit and, even worse, the inter-departmental politics were extremely ugly (Let's just say he didn’t want to ask Accounting.)

So why does this scenario keep happening between business and IT?

It’s inevitable that employees leave companies and that obviously includes IT staff as well. As new employees arrive, the software a company uses is often the only living record of all those historical decisions – both good and bad – and the business itself starts to look at those decisions (wrongly) as an IT responsibility. 

But then something even more dysfunctional starts to happen. Not only is IT held responsible for past decisions that were made when they weren't at the table, they are then asked to offer new ones. This continues the cycle of mystery accountability for business decisions as time goes on. Many times consulting, clients are expecting IT to help them not with technology decisions…but with business decisions. 

Soon, leadership begins to excuse themselves from the decision table. They start seeing business decisions as coding issues, and this is where a serious misalignment with IT and your business can occur.

In the absence of effective, engaged and decisive leadership, IT starts making business decisions. Which begs the question…..

Should IT be making your business decisions?

Would you call a communications professional and rely on them solely to “create” some pretty words for your website – relinquishing the responsibility of communicating the critical message of your company's culture, services and more?

Would you call a social media company for guidance and then sit back and hope that LinkedIn, Twitter and Facebook would require no effort or input while yielding magic results?

Would you send a sales rep into the field to just “go make me some sales…” without communicating the company message and positioning – hoping that along the way he or she is going to create a company brand for you?

These are all leadership responsibilities. And so too is IT. 

Some "leaders" believe that giving money away to IT means that they have paid for a solution and therefore are absolved of all responsibility and accountability going forward. In fact, quite the opposite is true. The more money you spend on something, the more involved you should be to ensure you’re getting what you want.

Creating good software requires close collaboration if you want it to accurately reflect your business needs and daily operation. This should not be performed in an information-vacuum followed by a grand  presentation of choices to be adjudicated by the business. If business doesn’t know what they want, or chooses to absolve their responsibility for the decision, you will have IT folks making "best guess" business decisions and your software (and business) will be negatively impacted for years to come.

The bottom line is this: Business leaders MUST come to the table. They MUST be engaged. They MUST be curious. They MUST evolve from their 20^th Century fear of technology.  

The role of IT in that disovery process should be PARTNER – not DRIVER.

Leaders need to lead. Your business depends on it.

There’s a wonderful old church across the road from me that is celebrating 100 years this year. It has a modest old world stone composition that I never tire of seeing, and a single bell that rings on irregular occasions with the sort of pure tone you might hear in a small Swiss village.

By contrast, just 2 blocks west, a bigger, gaudier institution has a mechanized bell that discharges a rapid, 10 minute series of randomly programmed electronic songs whenever they can.

Someone, somewhere, at sometime decided that this gimmick was so novel to them that they wanted to broadcast their love for it to a six block radius every Sunday at 9:15 a.m. followed by an "encore" performance at 11:15 a.m. To me, it’s right up there with the recently uninvited installation of a fire-hydrant that litters the edge of my property….a virtual "WELCOME" sign for neighborhood dogs.

It’s vain to presuppose that others will share your love of something. Like smoking, it’s arrogant to assume that others will derive your same pleasure while inflicting your exhalent upon them. It’s that solid line between sharing and imposing.

So why do I share some of my day-to-day observations with you and what does it have to do with business? 

There are countless entrepreneurs who make this same mistake – “If I build it, they will come.” There are programmers who do too – writing unnecessary code and features that only a mother could love. If I like it, surely others will too…

In fact, this sort of narcissism in the Entrepreneurial and Technology realms now has a name. Eric Reis, author of “The Lean Startup” calls it vanity metrics. Yes – business and IT both at times suffer this same cultural dysfunction which demands unapologetically, “Well if I like it, surely everyone else will too.” In social situations, the equivalent might be “Do you mind if I…?”

In business and IT, the question should be “I wonder if there is true value in what I’m doing? Perhaps I should test my idea out a little bit…on other people.”

But then what? Listen to the feedback. Don’t ignore it. Don’t believe that you and only you know best. Don’t impose your theory and expect positive acceptance biding time with denial. Act on that information sensibly and with honest humility. In business – as in life, the results obtained from listening are always better.

We get this one all of the time.

“Can you guarantee me the quality, the cost and the time it will take to create something that’s never been built before?”

Sales people love to offer such guarantees because they can quickly calculate their commissions and excuse themselves from the responsibility of execution. Software companies like to fabricate similar fantasies “to stay competitive.”

But you know who loses with this dysfunction? The client, the developers and the product because the first thing to become invisible is the quality.

The guarantee of both the client experience and the product is seriously cheapened when you guarantee the wrong thing. The developer team performs mad late-night dashes near the end of a project (and away from their families, by the way) and the client receives a product (perhaps delivered on time) with compromised quality that starts the technical debt ball rolling. The focus has moved from the product to “the deal.”

Antagonistic relationships form quickly around the adopted contractual practices of the construction industry (have they ever been on time/budget?) And while project dysfunction is even higher in that industry, entrepreneurs, business owners and managers still insist on using that model because they are familiar with how that game is played and oddly more comfortable with the waste it guarantees.

The game itself goes something like this…

Can you give me a fixed bid based on this vauge mound of paperwork I’m giving you?

It could range from a PowerPoint presentation sales pitch to a ton of paperwork that institutes painful change to all parties. Both assume that paperwork can explicitly describe an entire project and that no further learning or human contact need be established in order to deliver an estimate. And yet learning and human contact is at the very heart of creating software. Daily.

This need to treat software development as a pure engineering discipline is misguided, because the non-deterministic nature of both people and technology is involved. Nevertheless, we skirt that issue and demand time, cost and quality with the mantra “I have to know how much to budget.”

So invariably a Sales guy, Software Company or even IT department pulls some figure together from dubious metrics and incomplete information – sometimes without even consulting the developers. They double it, triple it, add the Salesman’s commission and present it to the client (who is also oddly enough aware of this game) and the incessant (and relationship damaging) haggling begins. 

At this point, software development has crossed the threshold into a task driven commodity. Clients seek multiple bids and the predictable age-old dysfunction of selecting the middle “guess” is used and we all imagine that a “sensible” decision has been made… We propagate the cycle, expecting different results without employing any feedback loop to measure the waste and maybe change our ways.

Do you engage your clients every step of the way? Do you incorporate daily communication and feedback so that all parties are on the same page of the process? Is the feedback loop continuous and does it work both ways? What guarantees do you think are realistic for clients to ask for?

And the most important question of all…….

Is the product you are generating something that EVERYONE can be proud of?