Let’s start at the beginning and reiterate this original statement from Schwaber and Beedle, the creators of Scrum:

Scrum is a management and control process that cuts through complexity to focus on building software that meets business needs. Scrum is superimposed on top of and wraps existing engineering practices, development methodologies, or standards.

Scrum is a process. One process, that must be taken and combined with other practices, methodologies and standards. A process does not, in and of itself, create a methodology and for this reason I say that “Scrum is not an agile methodology.” I might even go so far as to say “Scrum is not Agile,” but that’s misleading — because as a process, Scrum is compatible with and enhances agility, either taken as an “Agile methodology” or a general practice of being agile.

As Scrum has become more of a buzzword it runs into this dichotomy more often. I experience this frequently with my clients, where the dialogue goes something this this:

Me: “So, what methodologies do you follow?”

Client: “We use Scrum.”

At this point, I feel as if, say, I’d asked for a bowl of fruit and being given a bit of jam.

Me: “Yes, but that doesn’t answer my question since Scrum is a management process, not a methodology — do you use any development methodologies?”

This last is often poorly received. It’s at this point that I typically remind my client the reason I’m here is because they’re having trouble, and the reason is likely because of poor internal processes.

Methodology is a body of practices, procedures, and rules used by those who work in a discipline or engage in an inquiry. In the context of software and systems engineering, it specifically addresses how we manage the conceptualization, specification and delivery of the software. Scrum does not cover any of this. Scrum is just a management process that can be applied to pretty much any business situation.

A good methodology is going to provide a framework in which requirements capture and management is specified. Project parameters and management criteria, such as reporting structure, authority and responsibility, status management and progress management will be specified. Program assessment goals and objectives will be specified. Assessing organizational capability and planning growth or acquisition may be needed. How requirements are stated, what depth they must go to and what standards must be met, and how to manage change in requirements will be specified. Likewise, quality assurance processes will be set forth (for example, audits and controls will be put in place to ensure requirements meet agreed upon standards). Testing of the product will be standardized as well: What techniques will be used, what are the goals of the test program, and what will the output of the test program be? User acceptance standards should be specified and usability testing programs implemented. Transitional phase operations, often overlooked until “after we’re done,” need to be planned and prepared for — and then executed. Scheduling, resource planning and budget management are of course a key component of any well-run program. And through it all, meaningful measurement criteria must be established and communicated to stakeholders.

Scrum touches only the tip of the iceberg in regard to much of this. This is intentional: Since it’s designed to work compatibly with just about any methodology, Scrum explicitly avoids putting too many constraints in place. More than anything it’s intended to refine an existing methodology and process, improving its productivity through streamlining.

Of course, sometimes Scrum is all you need. A sufficiently senior team, comfortable with the problem domain, combined with a project of reasonable size and a business that’s willing to launch without a clear end-point can work. But more often than not, one of these four essential elements is missing. Perhaps the business isn’t comfortable with an undefined, vague end-point (they may want to know what the budget is, or have a hard launch date). Perhaps the team is new, hence the necessity for more structure and measurement. It’s a rare situation that we can dive into a project with no methodology, only the Scrum process, and come out the other side in a favorable position. Sometimes it will work, but it’s a gamble — and often a gamble that the business isn’t willing to bet on.

I’d like to stop hearing “we use Scrum” in response to the question “what’s your methodology?” It’s great to say, “Rational Unified Process with Scrum to streamline it” or perhaps “XP with a Scrum wrapper so we have better visibility,” but please don’t try to deliver software with “just Scrum.”

Related posts:

1. Making Scrum work: Common failings in adopting Scrum
2. Why Agile isn’t enough (and why it doesn’t work)
3. Common oversights in choosing methodology

Indeed, a good question: What would we do without the hero?

Let’s flash forward a little ways. The hero has grown tired of the project and leaves. Fears abound that the project is doomed; there’s no way the team will survive without him. Concerns run deep, until the hero tells us he’ll stay on-board as a part-time consultant. Of course, he’s pretty busy these days — but, well, he’ll give us a “preferred” rate and show up at least a few days each week. He’ll keep the project afloat, no worries… in between getting his new company off the ground, of course. The one we’re funding with expensive consulting dollars. Either that, or the hero feels the project isn’t challenging enough, and leaves to greener pastures and more exciting projects, still promising to provide part-time support to keep the project afloat.

Either situation is dismal. Both demonstrate a project and a team that’s being held hostage to the whims of the “hero.”

The truth of the matter is simply this: Heroes are bad for the team, bad for the project and bad for the company.

Heroes are motivated by making themselves indispensable to the project by becoming irreplaceable. Most often this takes the form of information hoarding. The hero understands quite well that the established culture supports his role only while he and he alone can solve the project’s problems. One of the most effective ways to make sure this happens is to keep critical information away from the team. He’s the only expert in a few critical areas, and refuses to share his knowledge because it would be inefficient or too difficult to convey to someone else.

This leads to situations where the hero is subtly motivated to make sure there are instances in which only he can save the project. By ensuring the hero is the only one with the answers, the only one who can solve the problem at hand, he becomes indispensable — and, also, a tremendous project risk. Not only is everyone on the team constantly put in second-place to the hero, they also suffer as a whole when the hero is at his best. In times when the hero “shines,” the team is struggling to overcome roadblocks they haven’t been prepared to deal with. The project falls into jeopardy because the team cannot focus on a solution as a whole. Instead, the team churns in vain trying to contribute to the solution that only the indispensable hero can tackle.

Consequently, team morale is often a casualty of the hero culture. The continued failure of the team to exceed project goals, instead running into roadblock after roadblock, is tiring. Compound this with the fact that only one person, the hero, is enough of an over-achiever to solve the problems of a seemingly over-ambitious project and the team begins to become demoralized. Nobody likes to come face to face with failure repeatedly. Doing so in an environment that doesn’t provide the tools to better oneself is futile, and the hero team leader is certainly not motivated to fix the situation. In point of fact, most heroes tend to be pretty lousy team mentors, as being a hero implies putting oneself above everyone else. This means that while the hero has holed up inventing the next great solution, the team is left to its own devices. This vacuum of leadership provides a poor environment for anyone interested in advancing their skills and career, let alone seeking out a workplace that provides opportunity to learn.

Environments that support the hero become detrimental to the team. With the team leader focused on fulfilling the role of hero, collaboration suffers. Without a truly open, collaborative, information-sharing environment projects function at low efficiency (or, in some cases, fail to function completely as information is silo’d and isolated). In contrast, a healthy team elevates everyone, sharing information and skills, making the hero obsolete and making the entire team indispensable. A collaborative team rapidly turns into a formidable force when its collective attention turns to any problem — such teams turn out productive results faster and more efficiently. Each individual’s growth becomes a focal point, and the positive experience and knowledge gained from such a working environment becomes a lesson that each team member can share. In an open, collaborative, delegating environment the team lead will mentor the team; constantly challenging each person to take on more responsibility and grow into new opportunities. The best team leads are not information hoarders but information sharers, almost trying to engineer themselves out of the equation by teaching everything they know. In fact, this kind of leadership becomes truly indispensable because so few people are able to teach, motivate, mentor and unify a group of people toward a single purpose effectively. It’s not the information hoarded in the team lead’s head that makes him invaluable, it’s his ability to create a hyper-productive team and get things done.

As a project leader it’s important to confront the hero mentality head-on, making it clear that a hero is known for what it is: A detriment and risk to the project. Heroes are a liability. They are a bottleneck to progress, introduce the risk of “hostage projects,” generally make poor mentors and leaders, and always create specific situations that are harmful or dangerous to the project.

Unfortunately, putting an end to hero culture is often not an easy task. Many workplaces that embody hero culture don’t understand the problem — they think everything is “just fine,” and look to the hero as a critical resource, someone that has saved the project or the company time and again. Especially in young or inexperienced organizations, the difference between a supportive environment and a destructive one is unclear. The hero continues to operate above and apart from the team, often disregarding what little authority or direction he disagrees with. Inexperienced team members don’t know they should have a team lead that is mentor, guide and teacher. Organizations can be set up in such a way that the hero figure is empowered beyond reasonable boundaries, as often happens when clear structure and accountability is not in place. Combined, these problems can create the environment where a hero-mentality, embodied in someone who is ill-suited to create unity, lead, and mentor, ends up holding the project hostage. Most often, the evidence will point to the root problem: The team will constantly run into problems only one person can solve; team members will disagree with the hero and often not achieve consensus; much of the team will be “out of the loop,” particularly where the hero is involved; overall, the team will operate either apart from the hero or as individuals, not a cohesive group. Perhaps most indicative: The hero has sole authority over the project, yet little accountability. This is common in so-called “flat” organizations. I tend to avoid organizations that strive to be “flat,” as it’s really just a way of saying “we don’t want to deal with the fact that someone has to be in charge.” The simple truth is that leaders and managers need to have the authority to implement policy. Good leaders and managers will find ways to do it without using their authority unless necessary.

The easiest way to fight hero culture is from a position of authority, such as the project sponsor or project manager role. Given the advantage of authority, the hero can be given a choice: Either become a collaborative leader, or face what amounts to demotion as a new leader steps in. Some heroes won’t be able to make the right decision and will end up leaving the project — but others will embrace the idea of transforming themselves into a positive influence. I’ve seen this happen in a few cases and can honestly say the results were extraordinary. It could be that your hero’s spirit is willing but he doesn’t recognize there’s a problem. Likewise, it could be that your hero is struggling to move into a management role and needs guidance himself. Sometimes you’ll find out the hero was thrust into a leadership role without wanting it, and will happily step aside.

Whether tackling the problem from a position of authority, or from the inside, there are a few strategies that will help to ease the process. Developing a collaborative environment is a first step at ending the hero culture. This means putting in place tools and processes to share information, including an open information environment. Get information out of everyone’s head and into a tool that facilitates group review and commentary, such as a wiki or document repository. This can begin by emphasizing brainstorming sessions, collaborative documentation and group exercises to design and implement solutions. Often group development can be a productive tool, as well (some environments, such as Extreme Programming, push pair programming as one example — I don’t believe pair programming should always be put in practice, but this is a good example of when it makes sense). Project deliverables should also be managed in an open, collaborative environment. Use a project or task tracking system that lets everyone see what’s going on, what’s being delivered and how it’s being done, and most important: Focus on shared responsibility and avoid having unique specialties in favor of collaboration.

The team should also push for opportunities to advance skills and individual knowledge. Avoid “information silos,” or individuals who hold all the answers to a specific problem. It’s healthy for teams to have more than one expert in an area. Not only does it reduce risk, it also affords a more collaborative environment where two or more people can openly discuss a solution and work together on implementation. Any time you hear “only one of us knows how to do that,” immediately think in terms of how you can turn one into two or three people.

Demand a leader that is a good mentor. If the team hero isn’t up to the job, find someone who is — and be vocal about wanting an environment that supports growth. A healthy work environment includes ample opportunity to take on more responsibility. Any project manager that hears you want the responsibility will start casting about for a means to give it to you — and that usually means making sure the team leader can advance his team.

Ultimately, your work environment is in your hands. If you’re aware of the problem, identify it and and surface it — but do so in a constructive way. Have ideas and solutions ready to solve the problem, and emphasize the value it will bring to the team or organization. Focus on the facts as much as possible, like productivity gains the team will experience when it has greater bandwidth, and how getting to market more rapidly (and probably with a better, more robust product) will boost return on investment.

Related posts:

1. Hiring for the culture
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Whole teams

“The problem is that, especially in a small shop, we:

a) Don’t have comparable projects that can be used to provide historical data, especially for partner projects that are often more one-off than core product development. I can say with some confidence how long it takes to add a new Struts 2 action and mapping – that part is easy, but what about the elements on the page? What about the logic?

b) Don’t have the infrastructure in place to really record time spent on any one task, and often find that if we did, it would be inaccurate because we wear so many hats, each hat being taken on and off randomly throughout the day/week.

c) Can’t afford just yet to spend a lot of time making exhaustive estimates, because that’s time that won’t be spent in construction and testing.”

This is probably the most common problem facing software teams today and, quite simply, the root cause of most project failures. Even projects that are regarded as ultimately successful suffer from this issue, as evidenced by frequent project overruns, software delays and adjusted delivery goals. And yet, we have the tools at hand to solve the problem: Function Point Analysis, Proxy-Based Estimating, Evidence-Based Scheduling, and similar tools offer the basic software estimation processes needed to accurately predict the overall cost of a project.

The problem is not with lack of process: It’s with lack of proper adoption. As Kirk points out, in his own situation a host of pressures prevent dedicating the necessary effort, time and resources to do the job right. Put bluntly, relatively unseasoned teams often lack the experience and wherewithal to set up the right processes and make the right investments. These “investments” typically translate into very real costs to the business, longer development schedules being among the most obvious. The pressure applied by a business to set a delivery date now, before enough data has been gathered, can be daunting. It often takes a combination of two things to successfully pull off software cost estimation: First, a team that has the ability to make accurate statements regarding a software project, and second, a business that is willing to listen to that team.

An experienced team

During my years performing project auditing I’ve noticed a trend throughout Silicon Valley, particularly among startup companies. This trend involves creating teams from remarkably bright individuals that have very little formal training or experience in software development. Other sectors, including large scale enterprise and the military, take a different approach: Assembling teams that have the senior leadership necessary to create an effective team. This means a formal understanding of development process as well as experience — because, quite simply, technical knowledge without experience generally results in missteps. Those experienced, senior dinosaurs are actually quite valuable in providing guidance and mentoring to the development team as a whole. But, again being quite blunt, these senior experts (SME’s or Subject Matter Experts) support their teams in a very effective way by providing the voice of experience and authority to the business. This is the bit about “standing up to the business,” and is critical when the business tries to step in and force decisions that just shouldn’t be made yet.

A listening business

Perhaps equally important as building a team with experienced, authoritative leadership is having a business that recognizes the value — and expertise — of its team. That has to extend to a willingness to listen to the team, and take the team’s recommendations at face value. I’ve personally walked away from more jobs than I’ve taken where it was apparent that the business believed in a purely “top down” management style, not giving the team the resources or time it needed to make the right decisions to deliver a quality software product.

Let’s make this concrete: What does “listening to the team” mean? More than anything it means listening to the needs of the team and addressing them. Kirk points out that they have a lack of expertise in software cost estimation: Hire a consultant to work with the team for three to six months to address this need. He points out a lack of infrastructure: Buy the right tools and give the team time to put them in place (they aren’t that expensive). Most appalling to me, he points out a lack of time to invest in estimation because that means the team isn’t coding: Give them the time to do their job right. The long term benefits will be realized ten-fold through accurate software estimation, greater reproducibility and improved software quality (you know how the software is always late or ships with too many bugs in it? This is the root cause).

Strategies for success

For projects that don’t have a body of work product to use for historical data, look outside the project. Unless the team consists of entirely junior programmers with no experience under their belt this won’t be hard to do (the formal nomenclature for this is wideband delphi, an easy-to-use and surprisingly accurate method for discovering historical data where none seemed to exist). The basic process is simple: A moderator and an estimation team with three to seven members is selected for two meetings run by the moderator. In the first meeting the estimation team creates a work breakdown structure (WBS) and discusses assumptions. After the meeting, each team member creates an effort estimate for each task. The second meeting is the estimation session, in which the team revises the estimates as a group and achieves consensus. I’ve had excellent success using this process as a basis for arriving at reasonably reliable estimates, but it’s important to add one more step: Make sure that the programmer that takes up the given task agrees with the estimate, and understands the task in full. Sometimes the group estimate will be more aggressive than an inexperienced programmer is willing to take on; likewise, sometimes an experienced programmer will know it can be done more quickly. Be conservative, and defer to the individual programmer when appropriate.

In regard to making time for the underlying effort in software cost estimation, one of the most common excuses I hear is “we don’t have the tools to record time, our team wouldn’t agree to it, and if we did, it would be inaccurate because we wear so many hats.” Frankly, this is just procrastination. First of all, read Joel Spolsky’s article on Evidence Based Scheduling. It’s an excellent introduction that clearly explains why wearing a lot of different hats, being distracted by unplanned tasks, and having a chaotic environment just doesn’t matter. A good system for measuring velocity is going to understand and accommodate those realities — in fact, the entire purpose for estimating velocity is because of all these unexpected, unplanned interruptions. If we had none, our estimates would be perfect, wouldn’t they? So, where does this excuse lead you but down the same, inevitable path: Lots of misunderstandings with the business, failed deliveries, slipped ship dates, poor software quality and an awful lot of late nights trying to get incomplete software out the door. Stop the addiction: Do the right thing and spend $200 on FogBugz or, if you want to go industrial choose my favorite, Atlassian JIRA (it’ll cost you a couple thousand dollars, but it’s probably the best investment your department will make, period). If you’re looking into JIRA, check out the Greenhopper plugin.

And finally, if you feel you just can’t take the time to estimate and manage your project, keep in mind this is the same as saying “we just can’t take the time to do it right — so we’ll hope for the best.” This is a classical problem for many Agile organizations that focus entirely on the short-term while sacrificing long-term strategy. It’s a situation that leads to a perpetual, self-feeding problem, and it gets worse not better. It’s time to break the pattern and make the decision to fix it.

Probably the most important piece of advice I offer team managers is simply this: “I don’t know” is OK. The worst thing you can do is commit too early. When the business challenges you for a timeline and presses for a hard and fast ship date, the best thing you can say is “I don’t know.” The natural follow on question is going to be “fine, what do you need to find the answer?” Stand firm and insist that you need the time, tools and resources to accurately estimate the job. Cite past performance — or past lack of performance, failed deliveries and customer service problems, if need be. Ask the business “do you want more of the same, or do you want to improve?” Ultimately, it’s up to you as the team lead, Scrum Master or project manager to make this happen.

No related posts.

Is this attitude regarding education part-and-parcel of the declining attitude toward education in the United States? More to the point, how will organizations continue to function if they curtail strategic learning initiatives? People don’t “just know” how to apply complicated concepts. They need training, particularly in areas such as software quality assurance, safety & reliability, validation & verification, and the basics of leadership, mentoring, and working as a team (including formal process education). And I haven’t even touched on morale issues, upward mobility and challenging our employees to aspire to improve their career path.

The fact of the matter is, in today’s economy we should be pressing for more education not less. This is called “recession proofing your organization.” Inevitable pressures to reduce staffing means fewer employees will need to do more, do it more effectively and take on new challenges they’ve never faced before. How about preparing them for it?

So, in an environment that doesn’t support training, how can organizations find educational funding?

Recognizing that training is not a wasted expense is probably number one. This needs to happen with management, but it doesn’t need to begin there. Training programs that are relevant to your work and beneficial to your employer are clear wins. Document the benefit of offering greater cross-functional capability within your team, of improving your efficiency, and reducing mistakes. Put together a training plan that demonstrates how the organization will benefit before you take a training request to your manager.

Consolidating training is also a huge win in most cases. For example, if you send five people to training courses around the country you’ll likely spend at least $15,000 (assuming the course costs $2,000 and then factoring in reasonable travel costs for each person). Consider bringing training on-site instead. Most programs that are available in public classes can also be delivered at your organization, and tailored to your specific needs. You get better, more relevant training and comparative costs are low. (An on-site workshop costs as little as $5,000-10,000 and becomes more cost-effective with more employees).

Use digital learning tools to reduce training costs as well. In particularly tight times, many web-based training programs exist. While not as effective as on-site, person-to-person training with an expert they can still provide a huge benefit to the student.

Focus on internal cost savings as well, and justify how the saved costs should at least in part be translated into better organization capability through training. For example, if you have more than one document repository (a problem many organizations suffer from) implement a single, consolidated document management system to improve efficiency and lower licensing costs.

One final idea that might find some traction: Audit your internal learning requirements and processes. Put together an analysis that demonstrates organization weaknesses and tie those weaknesses to actual issues the organization has experienced. Document the costs of handling those problems in retrospect and show how improved capability and efficiency would have avoided the problems—and will likely avoid future problems.

Related posts:

1. The case for certification
2. Articulating the value of training
3. It’s never a good time for training

1. Employers should not require certification.
2. Non-skill-based certification testing procedures have little value.
3. The Alliance is deeply concerned that uncertified, skilled workers will get locked out.

After considerable rumination I’m still feeling like the Alliance’s stated opinion here is fuzzy at best, misguided at worst.

I tend to agree that employers should not require certification for all things, but I disagree with the blanket statement that employers should never require certification. Wouldn’t you like to know that your management team is involved in current program management developments in the industry? Wouldn’t it be good to know that your Software Configuration Management lead didn’t pick up his knowledge entirely by the seat of his pants? Certification, just like earning a degree, demonstrates that a student has studied and understood specific subject matter. Particularly for team leaders this is valuable across the organization.

As for the value of different kinds of certification programs, I think this is a problem that will market correct. The market will tend to favor better certification programs. Certainly, I agree that skill-based certifications heavy on essay testing, problem solving and hands-on examination is the best way to go. But it’s neither here nor there. Education and certification is a good thing to support; if there are a few poor programs out there, they’ll eventually get weeded out.

On the Alliance’s next point, that skilled but uncertified workers might be “locked out,” I can’t help but feel the concern is misplaced. First of all, there are a number of industries where certification is required and sponsored by the employer as part of on-the-job training. But more to the point, I’m not at all concerned that the overly chaotic technology industry is on the verge of adopting uniform, required certification prerequisites. I can’t shake the feeling that the technology industry would benefit from looking harder at certification programs, much like the medical, scientific and even accounting industries do. Would you want an Uncertified Public Accountant working on your tax return, or a Certified one?

I’d love to see the Alliance restate their opinion, possibly stressing some of the benefits we could, as an industry and at the individual level, realize from good certification programs:

1. Keeping knowledge current. I don’t care how good a programmer you are. There is simply no way to stay on top of the best practices body of knowledge without looking to external sources. Picking up as much of that knowledge as possible through excellent training curriculum makes sense. The individual improves their skills; the organization motivates and energizes their employees and realizes benefits from best practices.
2. New discoveries in the field. There are new breakthroughs almost every day. The training and certification programs available today provide a venue for tapping into that knowledge, and in many cases the alumni associations create communities to share and develop ideas.
3. Demonstrating skill in established standards. Good certification testifies to two things, in my mind: First, that the individual is capable and competent enough in a field to pass an examination. That’s actually pretty darned valuable in the loosely defined technology field. Second, it tells me the individual cares about their continuing education and trying to be the best they can be in an area. Certification is optional. I’ve found that the people that get certified tend to be people that are more passionate, more enthusiastic, and want to be better at what they do.
4. Establishing a few standards. There are a lot of evolving standards in technology. Some are well established and many are brand-spanking-new. With this amount of technological turnover it’s hard to know what someone means when they say “I know Agile.” Having a common point of reference is not always a bad thing.
5. Assuring baseline knowledge in senior team. Without some common ground, how can we all talk about the same domain? By having at least the senior team go through with certification it helps bring all of the benefits of continuing education to the team using a common vernacular.

I’ve managed a lot of project teams over the past few decades. Almost every team that I’ve been asked to take direction of has had a wide range of skills, some barely adequate and some exceptional. Most of us have had similar experiences: Quality assurance groups where none of the staff have been formally trained in structured software testing, configuration management or even what quality assurance programs are all about, for instance.

I’m going to go out on a limb here and say we need certification. We need to know that the program manager knows how to manage across projects; that the quality assurance manager understands product life cycles; that the configuration team has a solid grounding in configuration identification and audits. It’s a natural evolution of this industry—an industry that is still very young, and showing it’s growing pains every time we look at it.

Related posts:

1. Finding strategic learning funds
2. What do you mean, SQA isn’t testing?

I respect goals more than most people — having founded or directed a number of innovative projects that’s probably a given. But I also respect a balanced strategy in developing those goals and the forethought to plan for changes.

I decided to take on a project reinventing a product that had over a decade of history behind it. Actually, I was more talked into taking the project by a friend and prior colleague. Over many months we went back and forth on the subject — but eventually I caved and decided to do it. In hindsight, my mistake was obvious. I had let my friend sway me, despite all the cynical bias I usually apply to potential projects.

When I started discussing taking the project on, the terms had already been set in stone. An early adopter client had signed up to foot most of the development cost, the project goals had been established, a target date was set and a contract signed. The project would be delivered for a fixed price. All of this was acceptable to senior management and even seemed reasonable at first. It was understood that the project dates and even the budget might not be “quite right,” but this was a long-term product. A little bit of overrun was to be expected.

As the project director I would be responsible for all technical execution. I would inherit the legacy system’s development team and have the ability to hire a couple of new people if need be. It was an attractive project, but riddled with potential problems. The irony is, I flagged all of these problems before taking the job — and I did it anyway. I was caught up in the persuasive, charismatic message the company President voiced — and two years later I’m reminding myself to keep those cynical biases near at hand.

“Remember that the worst reason to do it is for love.”

It’s important to love your work — in fact, personally I think it’s a requirement. It’s also important that you don’t do it solely for love. I’m a technologist through and through — and that makes my work dangerous. It’s easy to get wrapped up in the moment, to be one of those smart people defending bad ideas. What I need to be is a smart person defending a smart idea — an idea with all the right elements to evolve into a brilliant product, support a viable company, cross to the early majority market and achieve success.

Be objective in your analysis. Long ago someone gave me this advice: “Never invest in your own product.” In other words, if you can’t find other people that are willing to invest, you’d better challenge your assumptions. Maybe the idea isn’t well evolved.

“Look for the chasm.”

If you haven’t read Crossing The Chasm by Geoffrey A. Moore, it’s a worthy read, especially in the technology market. The company’s strategy was wrong. One of the most important aspects of product development is considering how the product will make it to market. That means developing a strategy around early adopters as well as the “early majority,” a group that represents the first half of your market research bell curve. The early majority is your cash cow. Make it into the early majority and you’ve got it made. The problem is getting there.

The root of the issue is crossing the perceived “chasm” from the early adopter to the majority. Early adopters are a rare breed of client. Typically they are actively seeking out new technology. They are often willing to take risks the majority avoids and may even fund development of early projects. Unfortunately, there are few early adopters — most companies can only attract a couple, if even that. And to make matters worse, early adopters make costly demands. Because of the concessions the early adopter makes — greater risks, higher costs, early funding to name a few — they demand greater returns. In a nutshell, they demand a custom project that meets their very specific — and yet often hard to define — requirements.

And there is the rub. If you are building a custom project tailored to the picky needs of your first — and perhaps only — customer, how can you evolve it into a product suitable to the majority? Such a product must be suitable to a wide audience “off the shelf,” robust, complete and easy to adopt. Custom solutions rarely meet these criteria.

To overcome the disparity between a hard to finish custom solution and a generic product of wide utility a company must budget time to “cross the chasm.” The transition from the custom, early adopter client to the early majority is often not an easy one. Products must be retooled, marketing messages revamped, new clients must enter into the pipeline (riding, hopefully, on the good recommendations of your first early adopter clientele). This is a critical time and often one that a company fails to plan for. The chasm was largely dismissed on the assumption that existing clients adopt the new product readily yet no transition plan from early adoption to majority adoption existed.

Even if the project goes without a hitch, there is necessarily a transition from the custom project to the generic product. This time must be budgeted, and funding must be allocated. Glossing over such a transition is a huge oversight — and probably the number one red flag for potential failure.

“Requirements are… required.”

Another concern surfaced very early in reviewing the project. The requirements that had been gathered were far from adequate. The entire work of requirements consisted of a tailored and very detailed request for proposals from the early adopter customer and the idea that the legacy software would serve as a blueprint.

These requirements, as an RFP, where actually very good, consisting of hundreds of pages of needs, desires and parameters from the customer. In many regards it was far more complete than most RFP’s — but it had very little to do with requirements per-se. The RFP was riddled with contradictions, incomplete statements and inaccuracies. The technical detail was simply not there but the business treated it like a finished set of requirements.

For example, round-trip integration between a 20-year-old Adabas court information system was summed up in a few sentences amounting to “there will be bidirectional communication with the court information system.” The effort was dismissed as trivial — yet the company ended up investing well over eight monthsof development time on this oversight alone.

“Don’t ignore unrealistic preconceptions.”

During my early discussions regarding this project a certain lack of grounding in the realities of software product development became clear. It’s important that the entire company is backing up a new project. That means aligning resources and setting goals in such a way that growth into a viable second-stage project is possible.

An early conversation I was a part of should have received more attention from me. “Once we finish the first release, we’ll be able to reduce staffing. Future versions of the product will require little or no additional development,” posited the company President. This attitude surfaced repeatedly, lending pressure to “finish” quality assurance efforts so that we would stop spending money on testing. My initial reaction was simply to dismiss these ideas, thinking that as feature requests, client demands and the realities of business growth became clear expectations would be corrected.

Unfortunately, pressures from the business alone are not enough to change deep-seeded misconceptions. This was a battle I ended up fighting repeatedly. Ultimately, the idea that the development effort should beshrinking rather than growing to accommodate a larger market contributed to the “chasm effect.”

“Avoid compromising on methodology.”

“We already have a contract, we know what we want to do, and really it’s OK if you go over budget. Let’s just get to work.” Sounds great doesn’t but? But it never really works that way. The realities of a business mean that your board of directors is watching the bottom line — unless you happen to work for Xerox Parc, stick to your methodology. Plan your project scope, development an lifecycle, and treat your business as “the customer.” Follow through on every aspect of iteration planning and delivery.

In retrospect I can say that a casual business attitude (such as evidenced by the statement above) is probably the most dangerous situation to get into. Customers will hold your feet to the fire. Investors want to see progress. Paying clients will demand quality and new features. But a seemingly casual business owner isn’t going to stay casual for long. Eventually the project schedule starts to matter. Follow your methodology, emphasize communication and frequent releases to keep the business in the loop, and don’t believe for an instant that it’s OK to take a shortcut. Inevitably, those shortcuts come back to bite you, quite often in the form of misunderstandings around schedules, features or capabilities.

“There is no substitute for a clear contract.”

Don’t buckle under pressure to get things rolling. I’d say at least half, if not more, of my projects have started with pressure to begin work with no contract in place. Clearly, starting work without a contract is in the client’s interest, or at least it seems to be. But what happens when the team is several months down the road and issues start to arise around responsibilities, client involvement, payment schedules and procedures to resolve these matters?

In the worst case you can end up with a poorly drafted contract that fails to lay out clear guidelines for all parties involvement. In this case, the contract was already in place — and unfortunately, none of these details were well incorporated. This can lead to poor client involvement, a very difficult situation with a demanding, early adopter client. Insist on a clear, well structured contract that makes it clear who is responsible for what activities. Incorporate these procedures into your methodology and risk mitigation strategies.

Technically, the project delivered some fantastic technology, but the cost on the team was high. Long hours and very hard work — and as of yet, no clear pay off as the company still struggles to get over the chasm and find a mainstream market. In the long run, I can’t help but think everyone would have been better served had I stuck to my guns. My instincts were to walk away from the project — and in so doing, provide a clear and concise message that the project could not succeed as it was set up.

Entrepreneurs, particularly those with a strong vested interest and long history with a product, can be terribly persuasive. Years of tuning the message and creating an infectiously exciting atmosphere makes them skilled at converting skeptics. Becoming excited about a product is wonderful, but don’t let the euphoria of the moment overshadow the concrete facts.

Related posts:

1. Common oversights in choosing methodology

Scott Berkun brings up some good points that are all too often at the root of an organization’s problems. Why do so many companies today pursue wildly optimistic or even pipe dream plans? Why is so much effort invested in seemingly random direction? And perhaps most important, how can these out of control organizations see the light and get back on track?

Most of the time I believe the problem — and its solution — comes down to understanding the people in the organization. Not long ago I had the pleasure of experiencing an organization of nearly 850 people with a development group of close to 300 people that used XP (Extreme Programming) as a top-down mandate throughout the company. The amazing thing is, it worked — there was chaos, there was limited visibility into the long term future and a host of other problems. Yet at the same time everyone in the organization was so empowered to get the job done that it created a huge sense of ownership. It worked because the people were brilliant on the whole — it was the right mix. In contrast and more recently I’ve seen a largely XP approach completely fail in an organization of about 100 people with a 20 person development group. Why the disparity?

I don’t believe it’s because one company had smarter or intrinsically better employees. Both companies have very talented individuals. It’s not as simple as choosing “smart” people. A “smart person” is an over generalization. For example, in Why Smart People Can Be So Stupid David N. Perkins writes “a strong sense involves recurrent foolishness that seems, in principle, within the intellectual reach of the person to discern.” In other words, a person can be really smart but not know how to engage their smartness. In so much as this happens, that is “stupidity,” and it can happen with smart people just as much as anyone else.

The conditions and environment greatly affect the ability of a person to function well. In one environment an individual may be able to channel and focus their energies — while another leaves that same person flailing about trying to find a purpose.

Perkins lists a number of attributes that often lead to poor decision making in smart people. Some of them you will likely recognize as traits that occasionally show up around the work place. Impulsiveness, neglect, procrastination, vacillation (dithering), backsliding (succumbing to old habits), indulgence, overdoing (obsessiveness), and walking the edge. These are the danger signs, the red flags that warn us that something isn’t right.

In working with different organizations it quickly becomes clear that the environment is created by the people within in. Certainly, management has a stronger influence on environment — and, consequently, can easily create negative influences that cause complete failure to deliver. More often, there is a slight disparity between management and team. More than anything this stems from an inadequate understanding of all the parts — and in this case, the “parts” are the people that make up the organization.

There are simple tools for combating these negative influences and ultimately eradicating “stupid” decisions. The near-term goal of these strategies is simple: To create a collaborative, unified environment where the organization executes as a whole. At the root of this lies empowerment and ownership. Individuals that take ownership in their efforts demonstrate interest in achieving a positive outcome. Likewise, the ability to achieve this outcome is mandatory if we are to avoid a sense of apathy and the opposite of the desired affect.

Empowerment of the individual means creating a holistic environment. Avoiding “siloing” within an organization in favor of collaboration is critical. Creating an environment that fosters mentorship and cross-team collaboration generates creative thinking. Creative thinking leads to ownership and a vested interest in the outcome of a problem — and this, of course, leads to involvement and an underlying desire to meet attainable goals. It also opens the door to accepting challenge — an open, collaborative environment is one where individuals are open to seek new challenges. Challenge leads to ambition to learn and grow, another benefit of an overall, holistic environment.

Of course setting lofty goals to achieve this kind of organization is one thing and executing it is another. Identifying the problem is the first step. Look for warning signs, and don’t let them run rampant in an organization. Fix the problem — we spend a third of our lives at work. It should be an enjoyable experience.

ed: Seth Godin’s blog had an interesting post recently, highlighting the difference between vertical and horizontal knowledge. This seems to be closely related to siloing and collaboration, respectively.

Related posts:

1. Finding strategic learning funds
2. Why heroes are bad
3. Whole teams