Business Processes » The Cutting Ledge

How Do You Know if Agile is Effective?

Agile, Business Processes, Kanban No Responses »

May 242013

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.

IT Employers Need to Step it Up in Kansas City

Business Processes, Hard Core Miscellany 2 Responses »

Mar 272013

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.

IT Training Needs to Step it Up in Kansas City

IT Training Needs to Step it Up in Kansas City

Business Processes, Hard Core Miscellany 11 Responses »

Mar 262013

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.

Curriculum

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.

How to Make a Team Out of Your Company

Business Processes 2 Responses »

Mar 252013

Simplified scheme of an organization (Photo credit: Wikipedia)

One of the more misused terms in business is “team” (with “disruption” and “culture” being close). Every business talks about their teams or describes themselves as a team, but I’ve worked with many organizations both inside and outside the Kansas City area, and I’ve seen few teams even on a small scale, much less an entire organization that worked as a team. I see groups of people with common job functions. I see people employed by the same company. I don’t see a lot of teams.

I wrote The Five Second Team Test to smoke this out for teams within an organization, but what about the organization itself? Is there a way for an entire company to work as one team? That’s probably a book unto itself, but here’s my Slightly Longer Than Five Seconds Test To See If Your Organization Works As A Team.

Org Level	Examples	Deliverable	Examples
Captains	CEOs, Partners, Engaged Owners	Strategic Goals	200 new subscribers by the end of next quarter
Lieutenants	Other C-Levels, Department Heads	Projects that will best achieve strategic goals	Print marketing campaign, new feature launch
NCOs	Managers	Prioritized items that need to be done to achieve project	Redo photography for ads, make 3d holographic interface for website
Enlisted	Developers, Janitors, Implementers of any kind	Actualized project	New print ads, new website features

Now, obviously, you can’t reduce the complexity of organizational interactions to a five row HTML table, so let’s remember this is a quick and dirty smoke test and not a doctoral thesis on the many aspects of organizational dysfunction. You could have the most streamlined corporate structure in the world, but people are people after all, for better and worse.

But what I want to highlight is that the chart above describes an organization that at least has the infrastructure in place to behave as a unified team. Each responsibility is ultimately tied to a company’s strategic goal and can be traced there. Each level has to make decisions about priorities, using input from the levels below, but ultimately is responsible for giving the next level the “what,” while leaving each level to determine the “how.”

The main point is this: everything everyone is doing is traceable to and subservient to the company’s currently prioritized strategic goal or goals, whether you are the CEO or the janitor.

You might be thinking to yourself, “Don’t most companies already operate that way?”

You’d think so, but they don’t. In fact, I’ve only seen one that comes close. Here’s what usually happens:

Captains: Serve as authority figures and public relations. Do not decide on any strategic goals, sometimes because of the possibility of failure. That responsibility is delegated to…

Lieutenants: Interested in their own bailiwick and view the welfare of the company primarily through that lens. Come up with projects they think are good ideas and lobby them to the Captains and other Lieutenants, hoping they will be more persuasive, powerful, or political. Reluctant to take a perceived “hit” for the welfare of another Lieutenant or even share information with them. The Captain serves no particular purpose in this process except to say, “Ok, sounds good.”

NCOs: Victims. The latest round of Project Proposal Shark Tank has dropped something into their laps that may or may not be realistic, a good idea, or may uproot priorities and direction, but it needs to be done and it needs to be done, yesterday. The justification for the project involves some loose understanding of vaguely defined benefits along with, “Bob really wants this.” Failure is not an option, leading to some high control practices.

Enlisted: Micromanaged, highly controlled group of people responsible for creating realized chaos. They don’t know why they’re doing what they’re doing except maybe they know who’s yelling for it. They don’t understand why their manager changes their workload and priorities every week.

As you can see, the process and the cultural issues are tightly coupled. I hope you can also see the bad position this puts everyone in. Nobody knows why they should be doing what they’re doing, but everyone knows they’ll be crucified if it doesn’t happen. A lot of developer teams I work with remind me more of my time in SERE than anything else.

Now, your organization may not be as bad as what I described. It might be worse; it might be better. But sometime, waltz on down to your software developers, find a developer, ask her about the feature she’s working on and say, “Which of our company’s goals is this feature meant to help accomplish?” If they don’t know, it might be your company isn’t a team at all.

You Can’t Change Company Culture

Business Processes No Responses »

Mar 082013

2012 Behaviour Matrix copy (Photo credit: Robin Hutton)

An organization’s culture rightly gets a lot of attention when talking about how to improve the organization. It’s the culture that makes certain changes easier or more difficult to accept. Even the amenability to any change at all is heavily influenced by the culture. When you look at various surveys on why agile projects and initiatives fail, “culture” usually tops the list. Culture is the primordial soup of a host of workplace ills and the mother of all dysfunctions.

In light of this, it may be tempting to put process improvement on the back burner to “work on” culture, but here’s the problem: You can’t change culture. At least, you can’t change it directly.

Think about it like this.

You’ve decided to make a personal culture change. You want to be a happier, more optimistic person instead of the roiling squall of negativity that you have become. Ok, great. How are you going to do that?

You can’t just become a happier, more positive person just by wanting to or just by visualizing yourself as being more positive. You have to identify the behaviors you want to change and start changing your personal culture that way. You might budget time to read inspiring biographies. You might snap a rubber band on your wrist every time you cut down a co-worker’s ideas. You might stop watching Fox News. You might start watching the YouTube video of that Japanese 4 year old playing the xylophone. You’re going to identify behaviors that contribute to being negative and unhappy and replace those with behaviors that enhance your happiness and positivity.

If you want to start eating healthier, you don’t just magically start eating healthier by identifying the problem and wanting to do better. You’re going to dismantle the pneumatic tube that connects your desk with Krispy Kreme. You’re going to order salads at burger joints. You’re going to pick the changes you want to make in your processes to create the culture you desire.

Organizations are no different. It’s insanity to say, “Let’s not work on your processes until we improve your culture,” because working on processes is the only way to improve culture. How else are you going to do it? Long speeches on how much your culture sucks? Exhortations to be different? “You guys really have a problem with trust. So, start trusting each other. Everybody done, yet?”

If your organization suffers from a lack of trust, then create processes that demand trust (collaboration, lack of unnecessary rules) rather than processes that shield you from the need to trust (heavily governed silos). You don’t say that collaboration won’t work here because we have a trust problem; you fix trust problems by making collaboration easy, valuable, and essential. How else would you possibly fix that? Make everyone fall backwards and have the person behind them catch them every day for a month?

Although it’s kind of a fad right now to disdain process improvement in favor of culture improvement, it is a deeply misguided one. You can’t work on one apart from the other. The relationship is too reciprocal, too tightly-coupled, too systemic to be able to deal with organizations that way.

When you spend time engineering your processes, then you’re engineering your culture as well. Culture isn’t an abstraction or an ideal; it’s what you actually do.

Marissa Mayer Got It Right – You Can’t Fix A Broken Culture When People Aren’t In The Office

How to Hire and Poach-Proof Good Developers

Business Processes No Responses »

Feb 252013

Software Developers working at Magenic in San Francisco, California, USA (Photo credit: Wonderlane)

Cute and hilarious introductions take too long.

1. Remove “market average” from your vocabulary.

Seriously, screw the market average. I can tell you that there is no salary figure screwier than Kansas City’s market average for software developers. I have seen developers who could barely write the “Hello World” program being paid six figures, and I have seen developers who could have built Facebook by themselves making $70k, and these are not rare circumstances but are very, very common. There is almost no connection between our market average and the quality of developer you’re looking for, so offering a salary 20% above market average does not mean you’ll attract developers who are 20% better than average.

Even if the market average were a meaningful figure, do you know who else thinks that if they offer a little bit above market average, they’ll get the good people? Everyone thinks that. All the companies. By skimming above market average, you’re doing what everyone else is doing right now.

Here’s a crazy thought. Before you start hiring, why not think of how much value that hire will bring to your business, then decide how much that value is worth to you, then offer that? How about instead of saying, “We’ve got a ton of work, we need four more developers,” you say, “If we get X amount of work done, that’ll net us about Y amount of dollars. I’m willing to pay Z amount to secure that Y.”

I really, really hate to use this analogy, but this is how factories make decisions about buying machines. They think, “If we buy this machine, that will enable us to deliver X more product, which will net us Y more dollars,” and that drives their decision about the quality and price of the machine they’re targeting, as well as when to buy. The operating expense is linked to the value produced by that expense. If spending $100k a year brought you $250k a year, wouldn’t you spend that money? No? Is something wrong with your brain? It’s still a good decision if you had to spend $200k.

Likewise, if you spent $100k bringing in an asset that would only bring you $80k of value, that’s a terrible decision. Don’t hire. Focus on more valuable work to put you in a position where hiring would bring you more money.

Don’t make the decision based on cutting cost; make the decision based on acquiring value.

2. Strategically align your employees.

If I went to any of your developers right now and asked one, “Tell me what the company’s major strategic goals are for the next year and how what you’re doing right this second impacts that goal,” could they tell me? If they can’t, they are eminently poachable. They have no stake in achieving the company’s goals. It’s just work to them, so the next person who comes along with more money or better benefits can take them. What’s the difference in building a widget for you versus building a widget for Richie Rich Richardson Industries?

“Company loyalty!” you say. Well, this is 2013. Employee Loyalty to the Company left on the same boat with Company Loyalty to the Employee round about the 80s.

“But they’re a part of the team!” you say. But how can you say that when they have no idea how their work impacts anyone else? To them, it’s a very basic transaction. You ask them for software, and you give them money, and they give you the software. That transaction looks exactly the same everywhere you go.

I agree that a big key to poach-proofing your developers is making them part of the team – something larger than themselves. But you have to understand that unless they have actual equity in the company, this sense is almost completely non-existent by default. They have to feel that what they are doing right now is a key to accomplishing the company’s current goals, and in a way that’s way more specific than, “Hey, bud, you’re key to accomplishing our goals.”

Incidentally, this requires your actual development projects being driven out of your company’s goals, which almost nobody does, but that’s another blog post.

3. Design your processes around the ability of the employee to deliver value.

80% of business processes have a single point of origin: We think this is what real businesses do. 19% have another point of origin: Someone did something that screwed us up, so now we have to have a policy to make sure it never happens again.

On rare occasions, these might be valid justifications for a process, but the vast majority of the time, these are terrible reasons for processes. Ignorance and self-defense.

Companies that succeed deliver value. You need to have processes that help your employees deliver value rather than hinder them. Now, sometimes you have no choice in the matter (compliance issues, etc.), but it is very common for a developer to walk into a scenario where they are buried under a ton of rules and regulations that serve no purpose other than to communicate to them that the company does not trust you and executives know how to do your jobs better than you do.

Nerf footballs, pinball machines in the break room, Beer Tuesday – all these things are nice, but they are not competitive edges in the hiring market. Employees spend more time working than anything else – family, hobbies, worship, entertainment – anything else. That work needs to be fulfilling and as frustration-free as you can make it. Make processes that allow workers to deliver value quickly. Make process that facilitate cooperation and collaboration – the essence of what it means to be a REAL team. Remove obstacles so they don’t have to spend their time doing it. Get rid of rules that serve no purpose other than to assert your authority or control miscreants (seriously, just fire miscreants, someone else will take them).

No developer ever made a job change for free pizza on Fridays, but plenty have made job changes because they were frustrated with how they got their work and how they were expected to perform it. So make it easy for them.

4. Give new guys a chance.

Just remember, nobody ever started as a senior developer.

Do You Need Teams to Be Agile?

Agile, Business Processes No Responses »

Jan 312013

Look! It’s paired programming! (Photo credit: Wikipedia)

One of the earlier moves most organizations perform to become more agile is to form teams, usually of the cross-functional and self-organizing variety. As the Elder God Scrum awakens from its slumber and draws more cultists into its tentacled maw, this has become such a common feature of agility that it’s hard to imagine any kind of serious agile effort without them. But are they actually necessary?

I’ve thought about this question a lot the past few days, and my current answer is: they shouldn’t be.

Self-organized, cross-functional teams are structures that address certain issues that dampen agility in an organization – issues like silos, communication, project visibility, and the granddaddy of work dysfunctions: too much work in progress.

Many organizations suffer terribly from these afflictions, and teams are a way to begin to reduce those issues. If you give a project to a team and they have an agile mindset, then they will swarm around a few issues at a time rather than break off and do different things, and this key shift in workflow cures a lot of the ills listed above. If I have a team with the same backlog, same priorities, same resources, and we are committed to delivering value as quickly as possible, then we will pour as much effort as we can into the most important thing, which requires us to collaborate regularly and give everyone visibility into everyone else’s work. The common purpose, shared knowledge, and self-organized tactical workflow will produce greater speed and quality, especially as the team learns to work together.

In that sense, teams may be necessary in the same sense that surgery to remove a steel beam from your head may be necessary – you have a critical condition, and it’s hard to see how to get from Point A to Point B without addressing it in a specific and immediate way.

However, we need to keep in mind that teams are a means to an end. Ideally, an organization functions as one team – every facet is strategically aligned, working on the most important thing, limiting their work in progress, making their work and information visible, and doing the activities necessary to breed continuous self-improvement. In this scenario, “team” would just be an arbitrary designation to refer to a number of people very closely related in delivering something, sort of like “project” would be an arbitrary designation to group related items of value to deliver. The entire organization would be a box where requests for value would come in and actualized value would go out, focused on a united, rapid, high-quality value delivery flow.

As awesome as that sounds, it is incalculably distant from where most organizations are at, and trying to drop them directly into that state would probably kill them.

So, yes, form teams and use them. I’ll certainly continue to do so. But recognize that they are tools to enable principles and reach a goal; they aren’t ends unto themselves. I’d argue that, in the higher planes of agility, an organization would have no formal teams at all.

What’s Wrong with the Project Approach?

Agile, Business Processes, Kanban No Responses »

Jan 282013

English: It shows that agile methods are focused on different aspects of the software development life-cycle. (Photo credit: Wikipedia)

I haven’t had much time to write, lately, but I thought I’d assist the pithy Bob Marshall in preserving the following paper by Grant Rule. It’s a paper that’s like pretty much completely right. You can quote me on that.

What’s wrong with the project approach to software development?

January 11th, 2011 Author: pg_rule

Pretty much since “software” was first invented (60 years ago?), numerous folk have been promoting an ‘engineering-led’ approach to ‘software projects’. Yet this advice goes largely unheeded, with the result that the relative success of IT projects is poor, and has improved very little during all my years in IT (38 and counting). Given that such admonishments seemed to have had such little effect in all that time, I also find myself asking, “Do I think it likely that further exhortations to those involved in ‘software projects’ to change their project practices is likely to achieve improved value delivery to stakeholders?”

And I have to conclude that the answer is “No”.

Following Albert Einstein’s adage that, “The definition of insanity is doing the same thing over and over again and expecting different results”, it seems to me that we need an entirely new approach. A new approach which goes to the root causes of what actually goes wrong in the end-to-end process. Why are the honest endeavours of software developers often so disconnected from the delivery of customer and stakeholder value?

Observation of what actually happens in organisations suggests there are two root conditions to the problem:

Those responsible for business strategy are disengaged from, and know relatively little about, software- intensive systems and technology. So they structure their organisations so that software & technology people are segregated into silos. In those silos, the inmates talk amongst themselves in whatever arcane language they choose. But importantly, they don’t communicate (or interfere) with the ‘real business’.
Everyone conspires to pretend that software-related activities should be managed as ‘projects’. That is, as chunks of work that start and end (on more or less clear and agreed dates), that have more or less well- defined goals, that contain a list of activities (tasks) that are assigned by a ‘project manager’ to a project team to which ‘resources’ are assigned for a limited period.

The results of studies too numerous to mention shows that most software projects are ‘challenged’ or ‘fail’. One study suggested that the majority of experienced project managers (and I am sure, folk playing other roles) expect at least 1 in 3 of the projects they lead to fail! As systems become more complex, and larger, they employ more teams combining projects into programmes… which further reduces the likelihood of successful achievement of the overall goals.

My conclusion is that we need a complete change of mindset. We need to move away from the inherently batch & queue concept of the ‘project life-cycle’ (as promoted by organisations including BCS, APM, PMI, OGC, SEI, NCC, ISO, IEEE, IET, etc. etc.) to a different approach.

I suggest that the required new mindset will accommodate the ideas of flow production and lean systems thinking that first began to be developed systematically (in e.g. automotive engineering) around 100 years ago. (Of course, one can trace elements of flow production & lean at least back to Carthage c.300-200 BC, but let’s ignore the history for now.)

I posit that Tom Gilb’s Evo method, and other agile methods such as XP, Scrum, Flowchain, and software Kanban, etc., begin to achieve ‘better’ results compared to ‘traditional’ big-design-up-front, wholly batch & queue methods, precisely because they encourage workers to focus on smaller batches of stakeholder value. In other words, value in terms the software developer can get to grips with.

Agile methods are one or more steps nearer to the ideal of ‘single piece continuous flow’. BUT… they are inherently limited because they continue to create & disband teams, to establish & abandon value streams, to create & throw away know-how, at – it seems – every opportunity. And crucially, they allow the C- suite and ‘business-side’ managers to ignore their responsibilities for the system of work and for the desired outcome.

Flow production (toward which Evo, Flowchain and Kanban currently make the nearest approaches IMO) would:

A) Make the entire end-to-end, whole-life, ‘concept to consumption & retirement’ process of defining, deciding, acquiring, designing, developing, operating, supporting, maintaining & replacing software- intensive systems a visible, inherent part of normal business operations… forcing issues onto the management horizon so they can be addressed as business issues – and not just something technologists worry about.

B) Because it would be apparent that software & IT issues were causing interruption to (or even cessation of) the flow of value, C-suite executives would have to recognise the pressing need to engage with software & IT related issues just as much as they do with other kinds of business issue. Conversely, the engagement of the ‘systems and software engineers’ with ‘the business’ would also be stimulated, the role of each and the communication between them finally becoming acknowledged as a main artery of the organisation’s lifeblood.

Flow production can only work effectively with the active engagement of all involved. For this reason it is a far more sustainable business model than other, perhaps more familiar, approaches. It embeds the ability to flex and respond to market forces deeply into the organisational culture. The focus on ‘the unforgiving minute’ forces constraints and problems out into the open where everyone can see them. It won’t allow problems to be swept under the carpet, or passed from one department to another like the proverbial buck. Hidden problems will always result in debts in one or more of the five kinds of capital. And such hidden debts, whether financial, technical, intellectual, social or environmental, all too often bite you when you least expect it. They will injure or kill the project – and destroy stakeholder value. Even if the project avoids repaying its hidden debts, this usually means that the debt has been passed-off onto one or another unsuspecting stakeholder group (sometimes, the end-customer or taxpayer). Which must be judged as unethical behaviour.

Unfortunately, not only have most people in the software industry been taught to sit in their silos and focus largely on coding, they and their masters have developed a cultural love affair with the project concept. To the extent that everyone assumes that all work has to be compartmentalised into projects, the very epitome of batch & queue thinking. Tell me what you think. Has the software project had its day, or is there another way of revolutionising workpatterns in the software industry?

Cult of the Startup

Business Processes, Hard Core Miscellany 2 Responses »

Nov 192012

Web startups (Photo credit: Wikipedia)

I already know I’m going to be misunderstood, so right out of the gates, I want to make something clear.

I believe in startups. I believe startups are good for the economy. I believe many larger companies could enjoy better market performance if they went back to valuing some of the things that startups value. I believe people like the Kauffman Foundation, Michael Gelphman, Ben Barreth, and everyone putting things on the line to help tech startups in big and small ways in Kansas City are doing great things for both our profession and our city and I cannot wait to see what these kinds of initiatives have in store in the next few years.

What I want to talk about is a growing cultural trend I see in the tech field in the country as a whole – that trend being the belief that startups are something of a messiah in both the technical field and the marketplace as a whole.

It isn’t hard to see where this comes from. Prospering in the economy, now, involves a very different playbook than the 1960s, and some have been quicker to see this than others. Large companies with their enormous infrastructures have proven, generally, to be too slow to change to evolve mutations that favor them in the current environment. They are too slow to market. Too slow to respond to changing marketing trends, customer expectations, and ways of interacting with and delivering to their customers. Their entrenched fortifications have made them risk-averse. Secure is slow, and slow is dead. The giant whales find themselves eaten away, bit by bit, by hordes of tiny sharks.

The sheer operating expenses of a large company have bred an unhealthy connection to cost accounting and managing by the numbers. Problems with the financials lead these companies to decide to do what they’ve always been doing, but just do it better, as if the world has not changed radically around them and is only changing faster. Hemorrhaging profits are solved tourniquet style: cut costs, move less, play defensively, and as any gamer can tell you, playing defensively means you’re losing.

Forget about benefiting the economy at large. Historically, we’ve proven that giving tax incentives to large corporations is about as effective as communism in stimulating the economy. Large corporations do not use tax breaks to hire, we’ve seen. They use them to pay larger shareholder dividends. Many large corps have frozen hiring to weather out economic troubles and, if the recent actions of some companies in the wake of Obama’s re-election are any indicator, this trend has no sign of significant reversal.

No, we know that jobs are being created in the small and mid-size areas of the market. We know that the companies that are growing are the ones who have quit trying to fight and control change and, instead, have learned to work with it. This is something of a guiding principle in current, agile software development practices, and we’ve seen this way of thinking reflected in business as a whole. Small, dedicated teams. Collaboration. Shifting to what the customer wants even if it means jettisoning the plan. Only doing planning when it adds value and is the most accurate. Cutting extraneous activity and minimizing time spent on decaying value. Find your failures early rather than right before you’re done. Get your product out in an early and light version and get feedback rather than trying to make everything perfect. These things are par for the course for the startup and the rules of survival in the new economy.

But as with most trends, my perception is that the love affair with the startup in our communities is swinging the pendulum too far the other way. Rather than the startup mentality providing a useful corrective to the market, they are taking on a life and identity of their own that isn’t being critically examined. I mean, one big thing you’d think people would pay attention to is:

Most Startups Fail in Five Years or Less

I have, in the past couple of years, attended several startup-oriented conferences, startup weekends, and hack-a-thons, and only one time have I ever heard a presentation given by a startup that failed. This is very unfortunate because, if we cared about startups, then we should be falling all over ourselves to warn them of the pitfalls and how to avoid them. Learn from the mistakes of those who have failed before us.

In this study by the University of Tennessee, a whopping 99% of startup failures were due to incompetence or lack of experience. Only 1% failed due to some external force beyond their control. 25% of startups failed their first year, and by the 10 year mark, 71% of them had failed.

But no one talks about this. Go to any community’s Startup Weekend or conference and all you hear is, “Wooo! Startup! More startups! Time to market! Bro, pass me those nachos! Woooooo!”

Is this really healthy for our communities and businesses? Is having a weekend for people to come up with a startup idea and get funding really the best thing for them, or are we just enabling failure and disappointment with greater expediency? 99% of startups fail for some reason along the “We don’t know what the hell we’re doing” line. How much are we correcting that? How much are we helping people take an honest look at the risks and what they need to do to succeed? Where are the Thoughtful Evaluation of Your Abilities and Plans Weekends?

We seem to be laboring under the idea that startups are inherently good, which leads me to my next question:

Why Do We Want to Encourage Startups?

Presumably for the reasons I stated at the beginning, but what I mean is, why does your community specifically want to encourage and attract startups?

Is it so your community can have a reputation as a startup hub? Why? All that will do is just attract more startups. It perpetuates itself, but why? Why is it any more useful to be known as a startup hub than as a… I don’t know… coffee house hub? So you have a lot of startups in your area. So what? If this is as far as your vision goes, all you’re really doing is making your community a failed business aggregator.

Is it because of the economic benefits? Your community would probably economically benefit more by seducing a large swath of a big company to relocate to your area, ironically. Many startups would have to enjoy tremendous degrees of success over a long span of time to match even one large company setting up shop and hiring hundreds or thousands of people. Please note, I’m not advocating that. I’m just trying to get us to think critically about what our endgame is, here.

To me, the value of encouraging a startup community is twofold:

One, it equips individuals with the mindset and skills they need to survive in today’s economy. Even if their startup fails and they go to work for someone else, they will take those skills, those views, and the knowledge from their mistakes and bring that to their future endeavors. I am of the belief that, in today’s economy, every single person needs to consider themselves a startup and manage their careers accordingly. Whether you run your own business or are a cog in an enormous company, you need to think of yourself as a startup , run your career that way, and influence your operations that way as much as you can. This is pretty much its own blog post topic, but my point is that – succeed or fail – “starting up” is a great way to get people thinking that way and getting hands on experience thinking that way, regardless of the final outcome of their startup.

Two, it creates knowledge quickly. You don’t have one or two companies trying new things and testing the markets – you have hundreds and hundreds. You don’t have one or two management models, but you have almost as many management models as there are individuals. Large companies have a lot to learn from startups, if they’d listen. And startups have a lot to learn from companies that have survived for decades, if they’d also listen. The rate of knowledge creation in startup success and failure is immense and useful – like thousands of tiny market experiments.

There are certainly other reasons to want to encourage startups in your community, and there are other issues to be wary of as well, such as the overwhelming emphasis of speed over quality and time to market as an overriding value consideration. But my main point is this:

In all the startup hype, do you know why you’re hyping it, are you helping startups by spending a proportionate amount of time dealing with their survival, and are you telling the truth, the whole truth, and nothing but the truth? When it comes to the new economy, there are no magic bullets.

My Tribe is in Stage Fad

Agile, Business Processes No Responses »

Oct 302012

English: Logo of General Motors Corporation. Source: 2007_business_choice_bro_en.pdf (on GM website). (Photo credit: Wikipedia)

The year is 1937.

You are reading a book on management. This book is the result of studies over the most profitable and growing companies over the past ten years with General Motors as the flagship. The book chronicles success stories, failure stories, and companies that experienced much greater success by making various cultural and procedural changes. Companies that follow this book’s advice experience much more efficiency and profitability.

Sounds like a good book, doesn’t it?

In this book, there are three, main recommendations:

Companies must see themselves in the business of turning a profit and, as such, decisions should be made based on ROI.
The best way to optimize the whole is by optimizing individual pieces.
Companies should value results, not methodologies. Therefore, companies are best managed by a centralized hub that makes decisions based on the bottom-line data that comes in from the various departments.

How does that book sound, now?

Interesting, isn’t it, that the cultural and procedural changes that would have made you a ton of money in the economy of the 1920s – 1940s would send you on a spiral of self-destruction in today’s economy?

The economic chaos following 9/11 and the bursting of the housing bubble have caused organizations to look more closely at their strategies and tactics than they have in years. Everyone is looking for the right paradigm, the right recipe, the magic formula that will keep their company afloat and turn their economic hemorrhaging into consistent profitability. Books are flooding the market like nobody’s business promising lights at the end of tunnels, and businesses are desperate for their saviors.

You can make a reasonably good living just by challenging a business’ current practice. You don’t even have to have a better idea; just ask incisive questions. You could write a book called Manage Like an Emu full of mostly blank pages and the occasional sketch of Godzilla destroying a city, and someone would buy it. You could probably certify people in it. You could give Emuization seminars around the country and authorize Emu Coaches to make sure companies fully absorb and implement the Emu Paradigm. Emu.

I’m not trying to say that all these books, seminars, coaches, etc. are all worthless. On the contrary, many of them are very valuable. Obviously, as a consultant myself, I believe that Lean thinking, Agile values, and the various thoughts, practices, and paradigms that orbit in those systems are extremely valuable insights and bring demonstrable improvement and prosperity to organizations that embrace them. Surviving and thriving companies are full of and led by readers and learners.

But it’s also important to note that the best guarantee these things can offer is that they are effective today in today’s economy. Perhaps they will continue to be effective for decades or even centuries; I have no idea, but neither does anyone else. Seventy years ago, centralized management by spreadsheet would have catapulted your company way ahead of your competition. This year, it’ll drive your company straight into a lake.

Learn what works now. You’d be an idiot not to. Change and adapt to deal with the current situation on the ground. Just be aware that the battlefield is always shifting. Your competition is changing. Market forces are changing. Technology is changing. Perhaps the very ways of looking at things that move your company ahead, today, will be the recipe for death, tomorrow.

The only principle that seems to have stood the test of time is that the organisms that survive adapt to their environment by developing advantages suited for survival in that environment. Organizations that cannot do that or do it too slowly go extinct. Commit your organization to continuous improvement, constant change, and constant learning, and all the current hyped up management tactics and cultural recommendations will serve you far better, now and in the future.

Older Entries

Related articles

Why should I come work for you?

Are you giving new folks a chance?

Related articles

Curriculum

Teaching Methodology

Economics and Risk

Related articles

Related articles

Related articles

What’s wrong with the project approach to software development?

Most Startups Fail in Five Years or Less

Why Do We Want to Encourage Startups?