Measurement is hard

I was going to title this post "ISO 15939", but then many of you would not be reading this. However, this last week I was introduced to a measurement world I am still trying to figure out. It looks compelling, and it is related to this standard.

One of our challenges is convincing people that they should expend the effort to measure something. One of the books on this subject I like is entitled "Practical Software Metrics for Project Management and Process Improvement", by Robert B Grady. In the book he describes how you use the "Goal, Question, Metric" paradigm to choose what to measure. Using this method you first state what it is you are trying to accomplish, then what questions you would ask to see if you are accomplishing that goal, and then decide how you would measure the answers. Very simple, in fact, practical. The book is full of lots of examples too, and it's dense, and to the point.

Fast forward to this week. I had the pleasure of listening to Rick Hefner, PhD, Director of Process Management at Northrup Grumman, talk about measurement and CMMI. He referred me to http://www.psmsc.com, which I'm still trying to wade through. It seems based on similar principles. PSM is a web site for Practical Software Metrics. The book by a similar title was written in 1992, and this organization has been meeting on a large scale since 1996; yet I had never heard of it; hopefully that's just me and this is old news to you guys. The book was written based on experience at Hewlett Packard. The PSM web site and group was sponsored from DOD and the Army (this may be why I haven't heard of it). But ... bear with me, it looks flexible, not DOD-ish.

I'm sure a number of you will react that we just need to use agile practices, work hard, and hire good people and forget measurement. I'm sorry, but I won't ever agree. You can't improve strategically without measurement, because you don't know what to improve, or if you actually did improve. If your product and work life is perfect, your customers are always happy, you never miss deadlines, you have more revenue and earnings than you can count, and you have fantastic work/life balance.. then fine, maybe you don't need measurement. If you have that environment, call me - I'll work for you. Otherwise I think you should check this out, just to know what it is and see if there are tools here for you. And by the way, eXtreme Programming advocates metrics - you have to measure the number of stories built in an iteration. So please don't tell me I don't get it.

There are a number of extensive white papers on the site, dealing with subjects such as how to measure your process improvement efforts, and measurement of security properties of systems.

They have a piece of free software (PSM Insight) that will help you with measurement that conforms to iso15939. I haven't run it yet, but was viewing their online demo and it looks useful. One could argue it's simply a graphical tool for your data, but it seems to also get you to conform your data in a way that uses industry standard metrics and indicators, so that others can understand you better. I would be interested in any comments from people who've used this tool.

Bottom line: check out http://www.psmsc.com

Praise is getting harder

The Wall Street Journal yesterday did an article on younger workers' need for praise. (You'll need an online subscription to read the article).

The article claims that popular self-esteem-building parenting and coaching techniques have created a generation for whom a lack of continuous feedback feels like rebuke. The abundance of praise may have led to the formation of a cadre of narcissists. Moreover, in the race to provide such praise, praise words get inflated - "nice" and "smart" are no longer complements. What you think may be praise might not have the desired effect.

The article mentions communication that many of us are probably more familiar with - if nobody is yelling at you, that's a proxy for communication of satisfaction with your performance. That strategy will fail with many 20-somethings and you will be burdened with filling a vacancy. On the other hand, inflated praise may seem disingenuous, even to the receiver. Bottom line, praise is getting harder.

The article talks about how to give feedback in such cases; a lot of younger people may completely ignore candid feedback, because they are used to being told they can do anything if they believe they can. Steve Smolinsky advocated using language like "It's not as good as you can do", a compromise with some lack of directness.

All of this language is counter to a lot of how I have been coached and treated in my career. I'm certainly not advocating being mean, but if you are disappointed, the discussion has to happen; you may not understand all the factors, and very likely your employee doesn't. Clouding this discussion with praise may fail to get the point across. With practice, you can give someone feedback and show that you want them to be successful at the same time, without confusing it with ego-boosting messages. What this article says though, is that may not be enough. Perhaps you can use another technique they mention for relationships - give five times as much positive as negative feedback (but do it at different times).

Bottom line, this probably isn't new - you should already be thinking about how different people react to different forms of praise and feedback. What is new, to me at least, is thinking about it as a assumption based on age; it will require observation to see if the theory matches your reality.

Develop, Support or Punt?

As a leader, having identified an individual's lack of skill in a particular area, how do you decide whether to try to develop the skill, simply provide support from someone else in the weak area, or move the person out of the role or team? After all, it's the leader's job to remove roadblocks and provide support, right? When does support stop being a good thing and start being a problem?

I don't think this situation has a general answer. The only sound bite I have is that if the lack of skill could demotivate the team, then unless it can be remedied quickly, the person lacking needs to be removed. For example, if a person simply can't tolerate their design being reviewed, maybe they shouldn't be doing design; that in turn might have significant consequences for the individual, but the leader must consider the health of the team first. This is hard to do if the person has some other skill that is very helpful to the team; but it's not enough if it could take the team down.

Another class of skills are those that are required to perform the minimum requirement for the job. In such cases, supporting the person rather than developing the skill will be demotivating for the team. So for example, if the person cannot write clear documentation on their interfaces, but that is a requirement for the job, then allowing the person to be weak in this area by assigning it to someone else is not supporting them - it's enabling them to evade responsibility. The person may be a superstar in some limited ways, but if they can't do all the required steps in the job, they need to be fixed or removed.

After that it gets a little fuzzy. What if your superstar designer and implementer just can't negotiate? She gets nervous and clams up when she should be discussing who should do what... and she really hates negotiating. Should you overlook the shortcoming, try to fix it, or let her go? (Assume that this is not an essential part of her job, so letting her go isn't the right solution). She might quit if you push her too hard, but you know she could be so much more if she had this skill. I advocate you tell her that; your opinion on how much more capable she could be might be enough to overcome the fear. If she's really not interested in fixing it, it isn't likely that she will be successful in developing the skill. So first create the motivation for her to try; it is amazing what people can do when they want to. Failing that, assign her some support.

Eco-Capitalism

This twelve minute video talks about how some large companies have made environmental progress and money at the same time. Not only is this a fabulous trend for business and the planet, but it shows that if you look for win-win strategies, you might find them. Conversely, if your model of the world believes that something can't be done, your bias may inhibit or prevent it.

Intuition

I love this quote attributed to Jack Welch (and I've probably got it wrong, sorry Jack):

If we are going to make this decision based on opinion, I prefer mine.

I like it because it is straight up - facts and analysis are credible scientific truth-seeking mechanisms. Opinions are based on all kinds of human biases.

I attended a meeting recently regarding a paper to be published soon, about studies regarding expert's ability to predict future success of startups based on business data presented by entrepreneurs. The study group was able to use neural nets and Bayesian analysis to "code" the startup team's properties such that it predicted success better than VCs. It's not published yet, so I don't want to spoil their thunder, but it looks fascinating.

What this says is that your "gut" reaction is undoubtedly worse than careful analysis. It might be really good for those life-and-death split-second decisions using that small part of your brain wired for preservation. The allure of the intuitive decision is strong; but there is no evidence that it chooses the correct direction, and there is some compelling evidence to the contrary.

A May 2003 HBR article called "Don't trust your gut" reported that in 2002 45% of surveyed executives relied more on instinct than facts and figures. That's a staggering and scary number. It's so much easier to go by gut reaction, but the article makes the case that we are such effective pattern recognition engines that we see patterns where none exist. The pattern recognition skills built into your most basic brain functions are fast but not particularly good at sorting through risk. It's biased for survival; I read somewhere recently where a man had been next to a window which blew in during a windstorm, and now he gets nervous whenever he hears wind... totally illogical, but the pattern is burned in his brain.

My dog is a great pattern recognition engine. She notices subtle movements, sounds and behaviors and can interpret with surprising accuracy what will happen next. Yet I wouldn't ask her to choose my stocks for me.

Bottom line? Do the math.

Focus and Innovation

In my experience, a major impediment to innovation is lack of focus. If your organization isn't clear on what it is trying to accomplish and why, you are likely to consume your resources on a myriad of time consuming projects that contribute little to the effectiveness of the current product, and leave no room for innovation.

So if you want to innovate, get control of your portfolio. It will take time for this to trickle through the organization so that engineers feel comfortable saying "no" to things they used to agree to. It is hardest when those things are also things they enjoyed doing. I've seen a dysfunction where there seemed to be a gleeful satisfaction in avoiding accountability because the system wouldn't let engineers work on what they know they are supposed to work on. You have to observe this and stop it. But in order to do that, you need a clear mechanism for establishing and communicating focus.

Steven C. Wheelwright and Kim B. Clark advocate for an "Aggregate Project Plan" which decides on the fate of projects before they begin:

Simply adding projects to the active list—a common practice at many companies—endangers the long-term health of the development process. Management needs to create a set of projects that is consistent with the company’s development strategies rather than selecting individual projects from a long list of ad hoc proposals.

Wheelwright and Clark used change in product and change in (manufacturing) process as a means to define different types of developments: Derivative (little change in either), Breakthrough (change in product and process) and Platform (the middle). They also added a bucket for R&D and another for Alliances. They then plotted circles in the boxes to represent the resources required for various projects - larger diameter circles represent more resources. Using this system they were able to get management to remove projects that weren't clearly aligned with the company strategy, and in just a few years improved productivity at a particular company by a factor of three. The graphs started as a mess and ended up being clear and compelling.

Fewer projects meant more work got done.

Bottom line: don't let the busywork prevent you from doing the important work. We all know this is good advice, but it can be hard to make it happen. Wheelwright and Clark provide a tool to help you manage up and out to hold capacity back for what it is needed for.

Acid test for secure development

The March 1, 2007 issue of CIO magazine lays out questions for customers to ask you about your software development environment, and how to evaluate the answers. The first 5 questions are in print:

1. Do you review security at each phase of the software development life cycle?
2. What methodologies do you use for security testing your products?
3. Do third parties conduct security assessments on your products?
4. Do you have security squads that attack your products prior to release?
5. Do you use automated tools for security testing or code review?

and they have another ten questions in the full online article here. I can tell you that most of the places I have worked would provide really poor answers to these questions even today.

For those of you out there with products products which have access to your customer's networks and data: get yourself a roadmap for developing the skills in your organization so that you can credibly answer these questions well. Educate your management to get the funding and time required. We've gotten away with some amazingly casual attitudes towards protecting our customers, but those days are rapidly vanishing.

Innovation Test

I'm not sure if this is ridiculous or interesting, but I stumbled over a tool, put together by IBM Global Services, which portends to assess your organization's innovation strategy and benchmark it against 750 other companies. I rated a former employer and ... surprise... we didn't score really well. The assessment tool raises more questions than it answers, in my mind; and no doubt this is a tool to get you to hire IBM consultants to help raise your innovation. Well... let me rephrase that... to create an innovation strategy.

The tool is here:
http://www-935.ibm.com/services/us/gbs/bus/html/gbs_ceo_iat.html?re=schome

but I'm going to make a broad claim here and see if it sticks. Innovation is less about a strategy and more about a culture. You have to look beyond the short term, make sure people are not overwhelmed with the day-to-day things, so they have enough time to think about making long term things better. And of course reward the behaviors that support innovating. Now that I've said that, maybe I'm doing the same thing as the survey. I'm just as trite... and I didn't have to survey 750 CEOs to get there.

Cool Change Management predictive metric

The October 2005 issue of HBR has an article called "the hard side of change management". They introduce a new metric called DICE, which stands for "Duration", "Integrity of Performance, "Commitment", and "Effort". In their study they found that by applying simple subjective scores to each of these areas, and then a simple formula to roll up a total score, they have a number which can be used to predict success or failure. They did the study on over 1000 projects and found correlation between these four factors and were unable to add additional factors to produce a better predictor.

Amgen used the tool in 2001 when they made a series of changes. At one point they used this metric on 300 initiatives (yikes!) and reconfigured resources on 200 of them based on the DICE framework.

The authors suggest that it be used in one of three ways: track projects, manage portfolios of projects, and force conversations. All three are really helping the organization decide where to focus time and energy.

The article gives specific guidance on how to evaluate a score for each factor. You can pay for and download the article here from hbr.com.

Root Cause (or, punishing the innocent)

An article in the Wall Street Journal yesterday reminded me of how easy it is to fire people up to solve the wrong problem. For those of you with an online WSJ account, you can view the story here. There is also this article in Information Week which anyone can read. The articles talk about a bill that republican Michael A Costello is sponsoring, Massachusetts House Bill 213, which would punish retailers for leaking personal data. Now, don't get me wrong, we do want to provide incentives for protecting personal data. But the issue here is stolen credit cards. The root of the problem isn't security practices at retailers. It is not possible to completely secure a complex system from hackers. There will always be ways to get such data. Holding the retailer accountable is just wrong. Similarly, holding the software, system, and database vendors accountable is also fundamentally flawed.

What is the core problem here? The main problem is that credit cards are embarrassingly insecure. The banks don't deal with the problem because it has been less expensive for them to pay the price of failure than it is to fix the problem. What this bill would do, if passed, is completely let the credit card companies off the hook. That is just so wrong it is offensive, and I hope people see this for what it really is: an attempt to remove the increasing risk of credit card theft away from the group who is really responsible, by taking advantage of the current emotional response to recent TJ Maxx theft headlines.

The credit card companies can solve this. If you've used a SecurID card from RSA, you know that a credit card sized object can provide a unique temporary number based on a secret PIN you provide. You must have the card and supply the secret to get a one-time authentication. Instead of the inane little three digit code credit card companies have us copy from the back of the card, you could use a dynamic generated code which is based on at least two factor authentication.

Using such a system, it does a thief no good to have the card in their possession unless they have also obtained the magic number. If that did happen, the person who lost the card simply reports it stolen and it is disabled. No break in to any system would divulge the personal secret, and the TJ Maxx problem would simply go away. Not only does this virtually eradicate the most prevalent forms of theft, but it provides the bank with non-repudiation and replay protection. In other words, customers can't claim the charge was made without their authorization, and someone can't later use the numbers to create another charge. This means the consumer and the retailer win, at some cost to the credit card companies relative to the current system; but how much more expensive is it, if most of the theft goes away?

There are other ways to do this as well, probably equally effective, and some which are easier to use (hosted on a cell phone for example). But the banks don't want to invest in the infrastructure, and now they are trying to legislate passing the buck to the retailer, which ultimately will end up being paid by either the consumer or the systems providers, while the credit card companies continue to make record profits with inferior technology.

So let's quit punishing the innocent and solve the right problem. The retailer and the consumer pay the 3% transaction fee - shouldn't we demand that they earn their money and fix this abomination?

Do the same in your business. When someone is pushing costs around, take a look at what the real problem could be. It's probably the one that saves the most cost for most stakeholders, and in particular respects your customer's costs.

A change tool: ADKAR

I was considering a potential assignment and rummaging through my toolbox, when I recalled an acronym: ADKAR. I don't recall where I originally learned it. It is a diagnostic tool to help you figure out how far along a change an organization is, and what remains to be done.

(A)wareness is present if people are aware that a change needs to be made.

(D)esire is present if people want to change the status quo.

(K)nowledge is present if the people know how to change it and get to the new state.

(A)bility is present if the people are actually able to work on making the change -- including but not limited to (for example) being given enough time to do so.

(R)einforcement is present if there are positively reinforcing reasons to keep the new state.

It's compellingly simple on the surface. The hard part is really who are the "people"? An organization generally will have some people with each of these attributes at any given time. A stakeholder analysis will help here, but I think there is a momentum factor as well. As you progress down ADKAR, you have to line the influencers up and gain momentum with everyone involved.

The requirements factory

I was speaking to some offshore development managers last week, where we were discussing what a challenge it is to get good requirements. This is not a new phenomenon, it has just gotten so much harder with increasing levels of technical complexity and the cultural and distance diversity of our current development landscape.

The May 1995 issue of Communications of the ACM included several articles about requirements for software products. One of them involves how Digital Equipment Corp redesigned their requirements process. Their challenges and learnings are still relevant today.

They first described a fairly traditional nine-step process that one might find at any major software development organization. It isn't "waterfall" since many of the steps overlap. Nonetheless they mention that many product development personnel expect that creative, knowledge-driven processes are similar in execution to deterministic, manufacturing style processes, and that it was that view that was correlated to dissatisfaction with the requirements management process.

[they] expected the process to do the creative work of contextualized data collection, interpretive data analysis and responsive design

The teams that were more successful allowed themselves more flexibility on the process. In other words they adjusted the process to the problem. This supports the idea that a process should not be over-prescribed; the team needs the ability to be creative not only in how to implement the solution, but in how to figure out what the solution is.

Then they did something very innovative and interesting. They incorporated creation of marketing deliverables into the requirements management process. Specifically the marketing and advertising messages, user information, pricing and competitive positioning and sales and support information. I haven't worked or consulted anywhere where that was done up front, but it strikes me as a brilliant way to engage the cross functional teams to work through the entire problem set and ensure that they understand all aspects of what the proposed product is and needs to do. It provides the right framework to help answer the questions which will inevitably need to be solved, and gets them resolved earlier. The result is lower requirements churn.

The challenge for most organizations is going to be the change in behavior required to get the marketing department to work in a fundamentally different way. That means you'll need a compelling vision or a painful execution failure, and support from the top.

A well written product quality article

I was part of an effort where we had a tremendous impact on quality in just a couple of years. We principally did it by turning the organization around from its earlier behaviors, and simply making it clear that quality is the developer's job, not the QA department's. QA's job is to measure and prove that the developers did what they were supposed to (or that they didn't). Development's job is to design and build a high quality product. A lot of development groups don't run that way; we got fantastic results by making the change. I found this writeup, by Karl Wiegers, which talks about how to specifically implement systems which support that goal. It is fantastically well written. Karl is also the author of a book I have used to set up review systems, called Peer Reviews in Software.

Effective Communication

I found this on Ronny DeWinter's Software Quality blog:

Communication levels:
Not everything that is said is heard.
Not everything that is heard is understood.
Not everything that is understood is agreed.
Not everything that is agreed is applied.
Not everything that is applied is retained.

That is a fantastic short synopsis of why communication is so difficult. It shows that just getting someone to understand you is not enough. Of course, getting further down this list is not always required. But if it is, you should test every step so that if a breakdown occurs, you know where it happened and how to fix it.

You may not need agreement in every case, but it is nice to know when you don't have it, and if you have trust, agreement is testable simply by asking. If you don't have trust you may have to test downstream.

One of the places I worked would appear to have agreement but often fail to actually practice what was agreed. Application or practice should be easily testable, you can build it into the original communication. For example, "When you complete this, send me a copy".

Whether something is retained or not may or may not matter. If it is important to you that it is retained, put a follow up action in your favorite planning tool to test future retention.

Who's schedule is it anyway?

Delivering new products on schedule is always difficult. At a recent Agile Software seminar, someone asked the crowd if they had ever had any home remodeling done. A lot of people raised their hands. Then she asked if it went according to plan; very few people raised their hands. The point she was making was: if something as well understood as remodeling can't go according to plan, what makes us think that we can do something that has never been done before, and predict the future outcome?

What can you do if your schedule is dictated? This happens in many or perhaps most organizations, and it's not going to change anytime soon. But you can manage it.

I remember an executive who once told me: once your organization gets to a certain size, you are expected to just figure out how to make the dictated schedules work. Whether this is successful or not depends on what percentage of your responsibilities has this attribute. If schedule is the number one requirement for 10% of your work, indeed, you should be able to manage it. Somewhere between that ideal and 100%, you will hit a wall unless you have a method to deal with the unsolvable problem.

I advocate for a highly transparent system to communicate the decisions you are going to have to make. Specifically, you really only have a couple of variables to play with to meet the schedule: resources and function (some people will say quality too is a variable -- depends on your environment). You may need to decrease function or adjust schedule in another area to free up resources to meet the schedule on a higher priority project. The transparency depends on your ability to rank the projects in a way that meets the corporate strategy. You will need to articulate and defend the priority of each; depending on the number of items, you may need a spreadsheet and a numerical method for ranking that can easily be explained. Once you have the ranking, you can justify hurting the lowest priority projects in function or time in order to fund the highest priority projects.

This seems self evident as I write this, but in practice it can be really hard to do when the project you are hurting is going to affect someone else's bonus. Once ranked, socialize the ranking before adjustments need to be made, so that your decision criteria has been vetted before you need to hurt someone's favorite project. To be really transparent, make sure the stakeholders of those lowest priority projects understand the risk involved.

Software Product Lines

I decided to cover this subject since the December issue of Communications of the ACM is dedicated to the subject matter. I first got introduced to the terminology last year when I was talking to a San Diego employer, who was looking for management talent with this skill set. I didn't find much information on it then, but bought a (largely boring) book on it.

If you haven't heard of it, it's kind of the holy grail of software development. What if we could stop re-implementing stuff, and use the stuff we have already invested huge money and effort into making correct? People talk about re-use all the time, but it really doesn't happen significantly in real life. So we pay our employees to solve similar problems over and over again. Extremely inefficient. I've long been a proponent of solving this problem... imagine what it could do for your quality alone. Can SPL really solve this problem?

I don't yet know the answer to that question. A significant amount of information comes from the SEI at CMU. In particular, check this out. Google of "software product line methodology" turns up a bunch of references. Maybe I didn't do it right last year, but it appears that the methods have a lot more traction now. CMU is even offering a certificate program in it.

The articles in the December Communications of the ACM were mostly written in academia. One was written by a leader at Nokia. I mentioned that a San Diego employer is changing their organization and development practices to embrace SPL. It must have enough evidence of success to be worth it, or maybe it's just another management fad. The challenge is that it takes additional work to break your products into product lines; different practices, organizations, processes, roles, etc. The initial change will be hard, and even after that there is an investment hurdle to get over when determining new product lines.

What the methods still seem to need in my mind, is a good grasp on the future. I am dubious about the abilities of the average organization to do a good job at that. I suppose applying it to the cash cows makes sense, except that by definition they already exist, are stable, and making money. So to change it you have to believe you need to make significant additional change, or maybe your current software inventory is too hard to change (either in development effort or product stability).

I believe this method is applicable to larger organizations with good Voice-of-Customer (VOC) data. If you really know where you have to go, you may be able to make the right investment decisions to create software product lines.

Sustainable Advantage

Because I am such a fan of innovation, one of my former bosses once chided me, saying: "The only sustainable competitive advantage is execution". The context of the discussion was about Apple Computer's innovations, and whether they were innovating or simply producing ... well .. art. This quote from fastcompany.com inspired the conversation:

If your cool new thing doesn't generate enough money to cover costs and make a profit, it isn't innovation. It's art.

That article, written in January 2004, may have to eat its words because Apple has proven to be an impressive execution engine. Two incredible examples in my opinion are completely switching over to Intel ahead of schedule, with great quality, and changing the way music is distributed and sold. These are really hard things to do, and they executed amazingly well. It didn't hurt that the products are world-class cool, but what gets lost is how those great ideas could have been simply ideas. The difference is they set audacious goals and then they executed.

That's a long introduction to what I want to talk about, which is taking a fresh look at your business from the standpoint of execution. We complain about how offshoring is making things so difficult, how technology and open source and infrastructure has enabled a lot of competition. Yet we rarely take a disciplined, open, introspective look at our value chain and ask "why" at each step. If we did so regularly, as part of strategic reviews, we could deliver better products faster to customers, increasing customer satisfaction and our brand's reputation. In the process we can literally crush the competition, and then we get to call the shots instead of constantly reacting.

You can use tools from six sigma and lean, to evaluate what you are doing today, where your value is created, where effort is expended for little or no value, and where inventory queues (not necessarily physical inventory) prevent faster flow of value creation. The objective is to get objects through the value creating engine faster, spending enough administrative oversight to ensure the process is working in terms of quality. To do this, you have to start measuring, and that might be difficult if your organization doesn't want to do that extra work. I advocate you start by creating a value chain map so that at least you know what you want to measure and have enough information to make a compelling case for why the organization should do the work to collect the data.

I want to mention, you don't have to fear six sigma. You can use the tools without making the whole organization embrace it as a normal part of their operations.

If you can get that far, and can ensure the integrity of the data, the rest should go a lot easier. You'll still need to involve stakeholders every step of the way, who may feel threatened if something they currently do is no longer necessary. In the end though, you should be able to bring everyone together if the improvements fit into your overall strategy. Using the data, the tools, strategy, communication, and change management, your company too can be a world class value producer.

Innovation and middle management power

Rosabeth Moss Kanter wrote an article for Harvard Business Review in 1982 that was reprinted in 2004, entitled "The Middle Manager as Innovator". She points out that middle management drives changes that increase organization capacity.

Among the many things she says that I agree with, she talks about how lack of power in these ranks can interfere with the innovative process, because it inhibits collaboration. When power is unclear, unfocused, or unevenly distributed, managers are more concerned about protecting their turf than collaborating for the greater good. The successful middle manager in these environments uses their power to persuade their peers to support their cause. This is the good side of politics, influencing others to accomplish the greater good. In order to be successful at doing things out of band, almost surely these managers will need extra resources, and that will likely come from the manager's peers, and he or she must have a little support from higher up to prevent a veto from stopping the project.

One of my coaches pointed out that in order to make things happen, you have to have the right combination of Power, Influence and Authority. The required mix depends on the particular objective. I think in Ms Kanter's article, some times she is talking about influence and authority rather than power. Influence is the ability to change someone else's direction based on a number of skills including communication, persuasion, trust, vision, etc. Authority is that property which is granted to you by someone who has higher authority - it is what the manager is officially allowed or expected to do. Power is the ability to inflict consequences, good or bad, on others.

I have worked for companies where collaboration was really difficult, and I think that it was the lack of power anywhere in the organization that was a key cause (when this is the case, authority and influence must play a larger role, leaving things unbalanced). Some of my peers an I analyzed what it was we were actually empowered to decide. It was almost nothing, limited to who gets promoted and how much to compensate them. This was an intentional part of the culture, Darwinism. One influential leader told a group of new managers, "If you want to get something done, don't ask for approval, just do it". This was felt to foster an innovative environment, and in older times it worked. But when power is fleeting and temporary, and everyone is trying to make their own project successful, you will see very little collaboration.

Collaboration is key, in my opinion, to long term success and market leadership with innovation that improves not only what is delivered, but how. To accomplish that, make sure your middle management is empowered.

Entrepreneurship and Insubordination

Robert Nardelli is quoted as saying "there's only a fine line between entrepreneurship and insubordination". I found this gem in the Oct 2006 issue of Harvard Business Review, in an article by David Garvin and Lynne Levesque. I'll leave the details to your reading pleasure, but there were a few key points that resonate with me, regarding how to innovate within a corporation.

First, quite a bit of innovation is going to lack data, and what you do have is likely to be ambiguous. Another quote: "it's hard to find marketplace insights for markets that don't exist"; this is the innovator's dilemma. You need "Mavericks" that can cope with that ambiguity and drive the organization forward anyway. You'll need to attach them to seasoned operational experts to help them design experiments that validate or negate hypotheses, and change course accordingly. This totally makes sense and seems to bypass a lot of risk and leverages the strengths of the umbrella corporation.

A perhaps counter-intuitive recommendation in the article is to "learn from small samples" rather than statistically significant large focus group learning. Highly successful examples include Intuit's "Follow Me Home" program, where employees actually watch customers use Intuit's products in their natural environment. Nokia, P&G, and Starbucks have similar programs which are leading to new sights.

The article also talks about skills acquisition and building. This is a variant of the build or buy decision, in this case whether you build the team internally or borrow or acquire a team with the right skills already in place. This is a critical decision but generally can be made by evaluating whether you have the competence to grow the needed skills, how critical it is to have the skills on board, and how long it will take to develop those skills.

Sirens' call: Agile

I consider myself an early adopter; I am usually the first to try new things. When it comes to Agile software development, however, I have pretty much waited until it entered the mainstream. We are there now. Large, respectable companies are moving to some form of Agile. They had to. It is clear that what we have been doing hasn't led, in general, to higher quality, predictability, efficiency and effectiveness. The systems are too complex and the world is changing too quickly.

One of the reasons I didn't adopt right away, is that Agile seemed like a step in the wrong direction, for the wrong reasons. If you haven't seen the Agile Manifesto, check it out at http://www.agilemanifesto.org/principles.html.

The first principle I struggle with is "The most efficient and effective method of conveying information to and within a development team is face-to-face conversation." The statement is true, and frankly, is the reason developers love Agile. Many developers I have worked with view documentation as a non-value-add activity. My aversion to this principle is that it ignores a huge problem in software development, which is keeping maintenance costs and quality under control. One of my clients had over 5 million lines of code and no idea how it worked. The people who created it had left the organization. The reasons why things had been done certain ways were lost. Adding anything which required change to the base code was a recipe for unquantifiable risk to the entire release, and many hours debugging under stressful conditions. I'm sure you developers out there will say that documentation is best buried in the code. The problem with that argument is that only developers will read it; and if I may say so, despite their technical prowess, I have seen some incredible oversights committed by developers (including myself).

The second principle I struggle with is that we should "welcome changing requirements, even late in development". It is clear that requirements do change and will change and we must adapt. But I fear that without attention to detail in requirements, people will be lazy about thinking things through, and any organization which behaves that way will waste inordinate amounts of energy refactoring.

Now that I've shown my negativity towards the principles, let me state that I think Agile brings a lot to the table. The number one thing it brings in my opinion has nothing to do with efficiency; it is risk management. In an out-of-control Agile environment, you may have the artist's problem - "it will be done when it's done, and I can't tell you when that is". Assuming you don't have that environment, then you have planned what you need and when you need it to meet your customer's requirements. Using Agile, you define mini-releases along the way to get there. Each mini release could actually solve the customer's challenge in some useful way. Now, if something ends up harder than you planned, and it will, you still have something to ship. You still have goals, you still have a sense of urgency.

My point is this: if you approach this as a potential efficiency drain to create the extra releases, but know that in return you have a ship date that you have confidence in, as well as feedback along the way about how "done" you really are, then delivering "working software frequently" is totally worth it.