1. Training focuses on the present — Development focuses on the future.
2. Training focuses on technique — Development focuses on talent.
3. Training adheres to standards — Development focuses on maximizing potential.
4. Training focuses on maintenance — Development focuses on growth.
5. Training focuses on the role — Development focuses on the person.
6. Training indoctrinates — Development educates.
7. Training maintains status quo — Development catalyzes innovation.
8. Training stifles culture — Development enriches culture.
9. Training encourages compliance — Development emphasizes performance.
10. Training focuses on efficiency — Development focuses on effectiveness.
11. Training focuses on problems — Development focuses on solutions.
12. Training focuses on reporting lines — Development expands influence.
13. Training is mechanical — Development is intellectual.
14. Training focuses on the knowns — Development explores the unknowns.
15. Training is finite — Development is infinite.

I couldn’t agree more. When it comes to leadership development, you can’t “train the leader.” Training on technical, procedural topics is of course highly effective, but leadership requires too much contextual differentiation, too much innovation, and frankly relies much more on innate skills that can only be developed over time, not absorbed from a short training course.

Related posts:

1. Tackling the global project problem
2. Why heroes are bad
3. Boomers at the exit gates

Recap: Face up to communication problems

Last month I pointed out that we have to deal with a lot more than language barriers with global projects. For example, in some cultures, speaking openly is not to be expected, in any setting. Furthermore, communication is often strongly augmented with non-verbal cues that simply don’t come across the telephone or email channels. The very method someone uses to communicate often carries an important message in and of itself — “reading between the lines” and picking up on the myriad of non-English, non-verbal hints is critical. It takes time and often a great deal of experience on an individual level.

Doing everything we can to remove ambiguity from project communications can be a huge help. One of the first things I generally want to take a close look at are the techniques and processes used to manage a project. Most of the time, they are not adequate for one reason: They weren’t designed to support a global, multi-cultural organization.

Tools do help

Let’s consider some of the common problems stemming from communications issues:

1. Assignments don’t get handled correctly
2. Nobody seems to know what’s going on
3. There is no single place to go to find out how well (or how poorly) things are going
4. Sometimes people don’t seem to be working effectively
5. Things that aren’t important get attention, while things that are, don’t

These are problems that almost every organization has dealt with at some stage in its life. The typical global project almost always faces them, and often, fails to address the root cause, and then keeps right on stumbling over the problem. Making a few strategic changes to your process, and your tool set, can help dramatically.

Use the right tool for the job

I’ve seen many organizations use email inappropriately. Email is easy to fall back on as the main communication avenue when everyone isn’t in the same office building. For example, I’ve seen engineers jump in response to a new product idea from the CEO. This leads to circumventing the project management effort, often misdirects the lead engineer, and easily puts a project off-track. After all, what’s an engineer going to do — tell the CEO to go through channels and keep working on today’s mundane task, or jump on a new, exciting idea straight from the top?

Equally damaging is responding to every customer “fire drill” that comes up. Email invariably leads to rapid-fire emergency drills, often at a very high cost. Customer service sends an email to engineering, and engineering jumps to respond — in the process, putting current tasks on hold and upsetting schedules (not to mention the engineers themselves).

Stop using email for project communications, requirements, design and, above all, assignment of work. Email is a fantastic communication tool — but it’s not the right job for communicating work items on a project. It has a poor audit trail, as you never know who did or did not read it, emailed tasks cannot be prioritized or captured in a work management system, and at the end of the day, they’re just unreliable.

Instead of trying to stay on top of a dynamic, changing organization with email, use an appropriate work management system. There’s great news here: In today’s market there are fantastic systems available to handle requirements management, task management, project planning, customer communications, resources and more. In fact, probably the most daunting challenge is simply getting enough information to make an informed decision and choose the right tool. Cost is always a concern, but make sure adequate due diligence goes into analysis of the tools. Picking the wrong product can easily create problems. For instance, some tools may work well with your project management process, whereas others may not fit smoothly. In this latter case, people end up working outside the system — and that usually means sending emails to each other.

Use the right estimation methods

Also critically important in a global project context is taking a long, hard look at the techniques you follow for project estimation. Make sure that your estimation methods take into account the complexities of a global team — this means accounting for inefficient communication and dramatically variant resource cost.

Be wary of estimation methods that focus only on the short term. “Burndown” estimates that provide visibility into the next thirty days are a leading source of project overrun and schedule slippage. An appropriately planned global project needs to communicate the goals of the project throughout the team. This includes setting very real objectives and milestones. If the milestones are variable and tend only to establish goals in the short term these become the only measures of success for the team — in other words, hitting the thirty day goal means success, because other yardsticks have not been established.

Wildly variant resource costs must also be accounted for. It’s one thing when every engineer gets paid more-or-less the same salary. When facing a dynamic, global team where costs can vary by a factor of ten, cost overruns become a very real threat. Simple estimation methods such as burndown estimates neglect these issues on two fronts. First, they don’t establish an adequate project baseline, and second, they don’t measure resource cost and progress against the baseline.

Make sure that the estimation methodology you use is adequate to the project at hand. Keep “burndown” estimates confined to projects that are either free of cost constraints, or at least operating on reasonably small budgets — so that cost overruns won’t hurt the organization.

Pay close attention to metrics — and metrics tools

Metrics tend to be a sore point with many teams. Mostly, at least in my experience, this comes from the assumption that measuring and keeping on top of project status requires a lot of work, and requires capturing a lot of data that nobody wants to capture. This is just plain wrong.

The fact is, almost every organization I’ve worked with is already capturing the data they need. It just isn’t being used right. The basic information needed to estimate tasks and monitor progress of the project as a whole is usually already in the system — it’s just a matter of getting at the data and building the right kind of reports. For example, most popular project management tools that tout themselves as being “agile” tend not to bundle reports for EVM metrics, baseline comparison, and project cost overruns. This is certainly the case with Atlassian’s JIRA, an excellent product that I’ve frequently put to use on large scale projects. Fortunately, the data recorded by systems such as JIRA gives us everything we need to perform more advanced metrics analysis. We know the original task goals, it’s planned schedule and it’s actual schedule, and can derive planned cost. That’s all we need.

Staying on top of the metrics and measuring against original project baselines translates into a very tangible return: You know your project health at any point in time. You know if you are slipping the schedule, if project cost is increasing, if too many changes are being made, or if too many defects are being discovered. If you can’t answer these questions you aren’t on top of your project.

Prioritize and balance dynamically

Finally a note about traditional, static project planning. Project plans are out of date before the ink is dry. Make sure that your project management process and your tools take this into account. Whatever tool you are using, it needs to generate the supporting project artifacts for you — not the other way around. In other words, if you find yourself wondering “how can I keep this Microsoft Project file in-sync with the project,” you’re looking at the wrong end of the equation. Instead, your project tools should be constantly in-sync with the actual state of the project — and if you’re favorite view of the project happens to be a Gantt chart, then your project tool should spit out an accurate one at the click of a button. Let the computer do the number crunching and formatting. You need to concentrate on managing the project, the people, and the global organization challenges that your team faces on a daily basis.

Creating a truly collaborative, communicating team cannot be accomplished with tools alone. While the tips I’ve offered above are sure to help, they won’t address all of the challenges a global project team faces — but they will give you a starting point.

Related posts:

1. Tackling the global project problem
2. Managing risk in global projects
3. Fix your boss (or, reduce risk to quality using a matrix approach)

Each project reveals something new, sometimes subtle, sometimes much more obvious. While writing Outsourcing in the BRIC: Being successful in global projects with Brazil, Russia, India and China, understanding each situation and turning it into a tangible, applicable lesson was often a complicated exercise.

In this article, the first of several, I’ll present a few of the lessons learned — not necessarily the most prevalent or the most important, but lessons that I think most teams will run into pretty quickly and could derail you from the start.

Face up to communication problems

By far the most common, most glaring misstep U.S. employers make in foreign markets is to assume that people, by and large, aren’t that much different. It’s a mistake I’ve seen in almost every situation, whether the global team is Russian, Indian, Asian, or South American.

In the U.S. we have become very insular, expecting behavior from our workforce that simply doesn’t exist in other cultures. For example, we take for granted that employees will be outspoken and even downright vocal about anything they aren’t happy with. “The squeaky wheel gets the oil,” as the saying goes. But as it turns out, that saying doesn’t apply to many cultures. In fact, the global project manager needs to recognize that in some cultures, speaking out is not to be expected, in any setting. This has come up with almost every outsourcing effort I’ve managed throughout Asia: People will contribute extensively or not at all, depending on the culture.

One strategy to begin overcoming this problem is to initiate collaboration up-front. This can be a particularly effective tool for establishing peer relationships early in the game. While speaking out is not a given, it’s almost universally true that people open up to their peers before opening up to managers. Initiate your project with a two-day collaborative session to drive interactivity. Be sure to stage the session appropriately. It has to be at one location, the entire team should be present, and the environment should be tailored to create effective, collaborative conversations. Remember, it’s more about building the team than about making real progress on the project.

Be sure to continue facilitating collaboration once the exercise is over. If you don’t work to break down barriers constantly, they’ll crop up again — probably the day after your exercise ends. Make sure the team has the right tools to establish effective communication. Try to arrange team schedules that facilitate frequent communication. Develop an on-going staff rotation plan to make sure the team is constantly getting “refreshed,” and working together on a regular basis.

Beware differences in business fundamentals

Just as varied as individuals are the business environments. Consider, for example, the complexity of developing a product in a foreign market, with most of the team speaking a foreign language, with common business knowledge rooted in a foreign business environment. Many of the assumptions that we take for granted are simply missing, or interpreted differently in other countries.

Often a good starting point is to look for regulatory and risk management profiles that will identify potential differences of understanding. Compliance requirements are often taken for granted in one market and completely missing in another (think of COPPA, the Children’s Online Privacy Protection Act, a U.S. law that dictates certain standards for any system storing information related to a minor). Many such standards, laws, and policies exist and are well documented — particularly in Western nations — but are never explicitly communicated to foreign teams where such laws do not exist.

Another common problem: People who understand the technical aspects of a project, but not the application of the product itself, often work “blind” to project quality goals. For example, I once worked with a client developing a legal work product in the United States, but most of the work was performed in India. None of the Indian team members had a solid business or legal background, and even if they had, it would have been based on Indian business law. As a result, most of the team had only a vague idea of what the product would be used for, and none of them understand the target customer.

Be ready to reset perceptions

Depending on your market, your product, and your overall goals, don’t be surprised if there are a few false starts. Engaging a global partner is not something that will succeed or fail in less than 90 days. Having a short-term perspective and focusing on the tactical, rather than the strategic, will doom the effort to failure. Because of the multitude of barriers — from culture, to language, to geography — expect to take time to develop a lasting, successful relationship.

Likewise, when developing a product in the global marketplace, don’t be surprised if it’s necessary to restart the project once your client or partner really begins to articulate what they need. If the project was initiated in the U.S., its inception was probably isolated, initially developed in a silo. Assumptions regarding foreign markets, realistic business objectives, and misconceptions about global performance are likely to be re-examined.

Monitoring a global project is clearly much more complicated than a domestic project or one that runs entirely out of a single building. Make sure the right key performance indicators are being measured, and stay on top of them. Keep a careful eye on communication throughout it all. Once the gaps have been closed and a collaborative environment built, successful, frequent communication will drive creativity and results from foreign markets — while failing to have good communication will create isolated, poorly performing teams. Even though you operate as a global business, try to remember what it felt like when everyone was in the same building, and keep that feeling alive as much as possible.

Related posts:

1. Tackling the global project problem, part 2
2. Managing risk in global projects
3. Successfully applying lessons learned

Having created a methodology that tightly integrates Scrum concepts, I tend to be a strong proponent of Scrum. But being a strong proponent doesn’t extend so far as to promote all the hype — I’m also a very strong believer in the value of formal education and the need for experience. After seeing the negative consequences of Scrum Master Certification, I’m hard pressed to see any benefits to it.

I’m not challenging the value of Scrum as a practice. I’m challenging the value of Scrum Master Certification. In fact, I’ll go so far as to suggest the certification program is hurting our industry by attributing competency where there often is none.

For example, the Scrum Alliance web site proclaims that Scrum gives you the tools you need to “manage complex projects.” This week I met someone that just joined an established technology company. She’s well spoken, bright, and just got her Scrum Master Certificate. She also just graduated college — and with both of those glowing credentials in-hand, landed her first job: As a Project Manager.

She has no experience. Yet, her employer has hired her to manage a group of people, executing a technical project, largely on the basis that her Scrum Master certification gives her that qualification.

What’s the value in a certification program if it inaccurately represents the capability of the people it certifies? Most Scrum Master certificates are earned after attending a two day seminar, sometimes with interactive exercises. There is no examination, although there is an “assessment” of about 25 questions — but without a pass-fail score, you get certified regardless of how poorly you do. There is no review of relevant experience. There are no requirements of past performance. You can get a Scrum Master Certificate without relevant professional experience or training.

Let’s compare this program with PMI’s PMP certification process. The PMP requires at least — even for an experienced project manager — years of experience and education, and weeks, if not months, of preparation:

1. The application requires detailed validation of years of project management experience, and even more experience and exposure to relevant work.
2. While PMI doesn’t audit every student they do audit, and experience must be vetted and verified.
3. The examination is 200 questions and typically requires weeks of study (most PMP preparatory courses are 13 weeks in duration, as an average).
4. The examination is administered in a secure environment, with no supporting materials. If you don’t know it, you won’t pass.

Even more stringent requirements exist for PMI’s Program Management credential: Included in the vetting process is a 360 degree review by 12 of your peers. As with the PMP certification process, if you fail any one part, you don’t get certified.

PMI requires that certified practitioners maintain their credentials with ongoing education annually. If you don’t demonstrate an effort to stay current, you lose your credential.

All of this earns you the right to put “PMP” (or “PgMP”) after your name. But if you don’t have the past experience (or if that’s too much trouble), you can drop in on a local Scrum Master course and walk out certified tomorrow. But certified to do what?

Scrum is not a project management methodology. It’s a process control structure that only works when combined with a methodology, such as PMP. It says so right on the first page of Ken Schwaber’s Scrum textbook. In that context, Scrum shines because it brings efficiency to a potentially bulky project management methodology. Scrum can be wonderfully useful, when used right.

So, here I sit, inwardly aghast as I meet Ms. Project Manager, with her freshly minted college degree, a Scrum Master Certificate, and no experience to her name, and I wonder: Is the Scrum Master certification program misleading an already beleaguered industry? According to KPMG and Standish, our success rate over the past 10 years was only 30%. Maybe this is part of the reason.

Does a two-day seminar and mandatory certification in a professional-sounding credential hurt, more than it helps?

Taking a seminar on Scrum is definitely a useful exercise. I think the Scrum Alliance needs to stop misrepresenting what Scrum certification really means to its practitioners, and the business world at large. I’d like to see Scrum professionals coming out of the seminar saying, “Wow! I sure learned what a long way I have to go before I’m ready to manage a project on my own!”

Related posts:

1. The case for certification
2. Making Scrum work: Common failings in adopting Scrum
3. Scrum is not an agile methodology

In some cases the departure of these senior employees will allow younger managers to step up to the plate to fill the void, but not everyone is ready, or even wants the next rung on the corporate ladder. So the question becomes:  After all you’ve gone through during this recession, can your organization survive the holes these departures will create? Do you have a well developed Succession Plan with Knowledge Transfer processes in place?

Many managers faced with a looming shortage of employees have reconsidered their business model; to find alternative ways to serve the client, build their products, distribute the materials, but a reinvention of their strategy simply brings new challenges to the fore.

Take the case of one of our clients who decided to outsource some aspects of their work to deal with looming labour shortages. They were in for a nasty surprise. A few months ago we conducted a risk assessment and  they found to their horror that not only were their boomers poised to flee, so were some of their specialists — the “go to” people others rely upon to do their work.  The newly outsourced work was what these ‘specialists’ enjoyed, so instead of taking on new responsibilities, which were less appealing, they were seriously considering offers of work at the outsourcing company! Clearly a game plan was required to stall a potentially disastrous situation.

Traditional succession planning identifies high potential employees and implements long range plans to develop those people so they are well equipped to lead in the future. The focus is on core competencies, business knowledge, technical skills and sound judgement that will lead to solid business decisions. Mentors are enlisted from the senior ranks to pass on savvy business knowledge to new incumbents. Short term overlaps are permitted so a veteran of the job can coach a neophyte.

But what can a company do when the mentor has retired or the specialist now works elsewhere?

How can crucial knowledge be retained for organizational health and continuity?

Knowledge Transfer has become the latest ‘buzz’ as leaders, faced with the loss of people and corporate knowledge, struggle to retain information that is vital and which has contributed to their present success.

New people to the company don’t know what they don’t know, so important questions are not asked. The soon-to-retire employees who have been operating smoothly for years; often don’t know what is vital — what to keep or toss — and the clock is ticking ever closer to their departure. Some, on the other hand, know exactly what to hang on to for that lucrative consulting job they envisage after their retirement and guard it jealously from their colleagues for fear of losing their distinct advantage.

So, getting vital knowledge from individuals and passing it to the right people, in a way that can be understood and assimilated quickly and accurately, is the challenge that will be facing most business leaders for the next two to three years.

We suggest you implement a few simple things to protect your company from a major risk.

1. Pinpoint how many people will be leaving within the next three years and develop a strategy to capture their knowledge now before it’s too late.
2. Identify who your Subject Matter Experts (SME’s) are and determine their unique advantage — what makes them so valuable to your organization?
3. Consider doing some serious cross training to reduce your vulnerability, build capacity and engage employees in building a better workplace.
4. Develop a data base with SME’s, lesson’s learned and past practices so people can source information as and when they need it.
5. Start a community of practice so people are encouraged and supported to share information freely with colleagues.
6. Reward people for building your internal capacity when they mentor, coach or lead information sessions.

If you pondered for a minute when you might get around to this — stop thinking — start taking action now, the days, months and years are slipping past very, very quickly. Is your organization going to be a risk?

Heather Hughes, CMC is a Certified Management Consultant with a 30 year international track record. She specializes in building vibrant organizations through Leadership Coaching, Succession Planning, Knowledge Transfer and Employee Engagement.

Related posts:

1. Bad employees rarely quit and good ones are hard to find
2. Fix your boss (or, reduce risk to quality using a matrix approach)
3. Tackling the global project problem

Good employees are really hard to find — A solid worker isn’t just difficult to find, he or she is really difficult to find. And they’re the first ones to leave. The truth is that 10 percent of the world is competent – and you’re looking for that 10 percent in every hire.

It’s hard to do consistently. And that’s why organizations that do it with frequency have such strong reputations. If you want to build a business predicated largely on finding, getting and keeping quality employees to succeed, you should understand that premise will be your greatest risk. Finding a market and profitably selling to it (usually the greatest risks) will take a back seat. Better yet, pursue a business that needs some reasonable percentage of employees to be really good.

But if that news isn’t bad enough, consider the other side of the coin — if you don’t have really great employees filling your ranks, then what do you have?

Your bad employees rarely quit — For one thing, poor performers aren’t really all that motivated to look, as that might involve actual performance. For another, no one else is likely to recruit them. Your marginal and weak employees are with you for life unless you move proactively. In many years of running businesses, the only time this wasn’t true was during the dot-com bubble. At that time, every idiot could get a 15 percent to 20 percent raise here in Northern Virginia by changing jobs. And they did. Aside from that blessed time, weak employees are your most “loyal.”

Don makes a good point, among several others (his article is 8 things I wish I knew before starting a business): Having, and holding on to, great employees is very, very hard work.

It’s also quite possibly the one sure-fire factor that’s going to push your company toward success. Consider a few of the leaders in the technology industry, such as Apple and Google. Both have stringent hiring processes and focus on the quality of the hire first, and growth second.

Let’s put it another way: Does it make sense to focus on growth if what you are growing is mediocre (or worse)?

Related posts:

1. Hiring for the culture
2. It’s never a good time for training
3. Articulating the value of training

This translates into preparation, more than anything else: Preparing by understanding your options, preparing the organization for change, and preparing to measure your success.

Be thorough during evaluation

The most common oversight in preparing to adopt a new methodology is simply not evaluating all of the available options. It’s an easy pitfall to succumb to: There are so many processes, so many methodologies, so many choices, how can someone possibly make the right choice? Surely all of these published techniques are mature and “real,” does it even matter which methodology we choose? Yes. It matters a great deal. Each methodology has its strengths and weaknesses and very few methodologies can be applied to every development project.

The wide variety of methodologies is a reflection of the complexity of the software development industry. We have many choices in executing any strategic operation, whether a military incursion, a football game or planning for building a house. Likewise, the software industry has evolved a wide variety of processes, each one suitable for different scenarios. While it is certainly true that many methodologies can be successfully applied to many different projects we can’t make the assumption that any one methodology will work equally well in every situation. Adopting a heavy process in a project involving a small team and a short-term schedule is almost always a poor idea, as it leads to extending the project timeline to support unnecessary project artifacts. But less obvious is the impact of pairing a lightweight process with a medium-sized project. How many people is “too many” for an Extreme Programming (“XP”) project? At what point does the lack of formal project controls start to make the project unpredictable? Will the business stakeholders feel the project is not adequately managed? These questions, and many more, emphasize how important it is to prepare thoroughly before choosing a methodology.

Given the plethora of potential methodologies, it’s easy to just pick one and get started. The temptation to simply choose a well-regarded methodology, buy a well-reviewed book on the subject, and forge ahead can be strong. But this “textbook approach” can prove deadly. Without studying the methodology beforehand it’s easy to choose the wrong methodology — and even if a mistake of this magnitude becomes clear over time, it’s usually too late to change course. And much like reading instructions too quickly, it’s easy to realize too late that the process is wrong: Incorrectly implemented, or not the right fit for the situation.

Another pitfall to the “textbook approach:” It leads to following a process blindly and over-adopting, particularly with more comprehensive methodologies that have more to offer. The fallout from this: Teams come to think that comprehensive methodology is a “bad thing,” heavily weighted and full of red tape, unnecessary work and overhead. Using the textbook as an instruction manual makes it impossible to have a complete view of processes and artifacts offered by the methodology and, therefore, the value and appropriateness of each.

Prepare the team and the organization

Just as evaluating and selecting new methodology can be a mine field, so can the actual adoption process. A common oversight when preparing to adopt a new methodology is not planning for the upheaval it will cause: Training and learning curves, changes in operational behavior and metrics, and impact the schedules. Changing the way a business works means everyone has to relearn what they do on a daily basis. This means considering what it will take to implement the methodology within an organization as a whole, and achieving a level of investment in the effort by all the stakeholders.

Team members need to be trained, business units need to be integrated into the process, schedules adjusted to accommodate the new methodology and in most situations a significant learning curve will translate into a slow, steady adoption — as opposed to a sudden, rapid adoption. The former approach provides an opportunity for participants to learn the usefulness of different aspects of the methodology and to gauge its success. The latter approach — attempting to make a complete, rapid transition — often leads to failure during adoption. Too many interdependent processes that are not well-understood by the team leads to poor execution. This can lead to missteps during a pilot project, a time at which such mistakes are highly visible. Not having a steady, progressive and measurable improvement against existing techniques means criticism will come easily.

Measure your success

Creating positive, measurable metrics that demonstrate the benefit of a new methodology is critical. Part of the process is making sure training costs and the cost of adoption is tied directly to business goals. By coupling the business to the methodology, all stakeholders have a vested interested in success. Good metrics demonstrate that progress is being made — both providing a positive measure of success, and avoiding the need for a “big bang” success right out the gates. And, if you aren’t already tracking metrics and measuring success, this is an ideal time to find a management methodology that will.

Related posts:

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

Steve Muench, PhD, asserts that “Training is one of the chief methods of maintaining and improving intellection capital. Because of this, an organization’s training can affect its value.” (Tech Transfer Newsletter, 2004). In fact, the market-to-book value of companies significantly correlates with training as a percentage of payroll according to Bassi and Van Buren (1999). Furthermore, numerous studies have found that the organizational benefits of training are extensive. According to one, by Loewenstein and Spletzer (1998), “the effect of an hour of training on productivity growth is about five times as large as the effect on wage growth.” Research by Bartel (2000) also finds that employers, not employees, ”reap almost all the returns to company training,” going on to conclude that return on investment generally ranges from 100 to 200 percent ROI.

So, the evidence is out there — yet, why are companies cutting back when they should be investing?

One possible reason is a lack of good communication regarding the value of training itself. This is particularly true in small and mid-sized companies. The large ones seem to have it figured out: They do the analysis and understand how important “sharpening the saw” is. When asked if Amgen had made any cuts to training given the economy, CEO Kevin Sharer said, “We haven’t cut back on that at all. Developing people is the future of the company.” (Fortune, 2009).

But smaller organizations don’t have the maturity to understand the importance of training.

Training is investing in the future. Unfortunately, it’s not enough to simply ask the powers-that-be whether they want to make that investment or whether they’d rather remain stagnant while the competition passes them by. In a numbers-driven world, it comes down to dollars and cents more often than not. This means getting out the trusty spreadsheet and doing some math to show its value.

It’s not hard. The key is keeping your eye on the “line of sight” from training to profitability. More than anything, this means making sure that training is directly applicable to the bottom line. Training must become a resource, just like any other cost-oriented tool or expense. There’s no problem buying new software if it leads to profitability. There’s no problem hiring new staff when it means more revenue down the road. So, make the case for training: Demonstrate the return on investment (ROI) that a training purchase will generate, in terms of revenue to the business.

ROI analysis can easily be applied to training expenditures. It’s the same process as any other expense: Does the investment make sense and is it necessary to meet the organizational goals? Sometimes it’s an easy analysis to make. For example, if your company is currently losing money because of a poor process or incorrect practice, compare the current loss to the cost of correcting the problem (that is, the training that will fix the situation). Is the cost of training less than the ongoing loss (keep in mind that the loss is cumulative, continuing to accrue every year until it’s fixed)?

More complicated ROI analysis needs to focus on the financial value of your organization’s goals, and break that value down along the “line of sight” to the training investment. For example, let’s say your product launch is valued at $1 million, but half of that valuation is on the assumption you deliver a specific, key feature. That means your direct key performance indicator (KPI) for that feature is $500,000. Let’s further say that your team can only deliver two-thirds of the desired functionality without training. This means that the training program’s relevance to the KPI is about $166,000. Will the training itself cost less than $166,000? If so, you’ve got a business case to do the training. (You can round out the case with your ROI figure: If the training costs $20,000 then your ROI would be about 830%, which is a pretty darned incredible return on investment!)

If you’d like a more scientific, in-depth study of ROI methods, take a look at my article Should Training be an Integral Part of a Project Budget to Increase Project Profitability?, featured on the leading PM site My Project Management Expert.com. There’s a lot more research and some discussion of current ROI methods, as well as a couple of good examples.

Related posts:

1. Should Training be an Integral Part of a Project Budget to Increase Project Profitability?
2. It’s never a good time for training
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. Training versus development
2. Tackling the global project problem
3. Fix your boss (or, reduce risk to quality using a matrix approach)

Scrum can be remarkably beneficial in many kinds of software projects. But, as with any process, methodology or management technique, when used inappropriately it can cause more problems that it solves.

In this article I’ll discuss some of the common misconceptions and “lessons learned” as related to Scrum.

You don’t need training to use Scrum

This is the most important one in my mind: Training is just as necessary with Scrum as it is with any other process. I’ve run into many teams that eschew formal training in favor of simply “reading the book” or sending one lead engineer to a quick Scrum certification program.

Let’s look at it another way: For upwards of 30 years, the software development industry has followed a largely industrial process (sometimes called “waterfall” or “spiral,” depending on your particular experience). Across that time, many professionals have struggled with the complexity of software development, striving to create a process that is simple, reliable and repeatable. More often than not, to varying degrees, the industry has met with failure: Nobody has turned software development into a wholly reliable, repeatable procedure that always hits its goals dead-on.

Scrum is a process that has evolved out of this 30 year history. While the process itself focuses on simplicity and emphasizes a set of easy to follow practices, this does not make it inherently intuitive or trivial. In some regards Scrum is so contrary to established process that many team members just “won’t get it” unless they experience it in a learning-enabled setting. Training is critical, and I highly advocate sending your entire team to a Scrum workshop — or, better yet, bring the workshop to your team. Good programs exist that will turn your training session into a guided working session, which means your productivity will not be hurt by sending people off-site for training. Just the contrary — your productivity will leap ahead in just a week or two as training, learning absorption, experience and actual hands-on work all combine to create a Ken Schwaber’s original goal for Scrum: A hyperproductive team.

Scrum is all we need

Often sung to a Beatles inspired tune, I’m afraid it’s not true: Scrum is not all you need, and any idyllic fantasies otherwise will be met with dashed and broken hopes on the rocks of failure. Scrum is not a complete methodology, it’s a management control process — and that implies that you still need methodology. Don’t take my word for it, take Ken Schwaber’s, the creator of Scrum: “Scrum is superimposed on top of and wraps existing engineering practices, development methodologies and standards.” (Schwaber & Beedle, 2002; Agile Development with Scrum, p. 2).

Scrum is an excellent control process that helps us cut through the red tape of more traditional, bulkier control processes. It helps us to focus in on what’s important. It enables accountability to an extreme degree and, through accountability, achieves greater productivity. Its empirically driven measurement technique is well suited to the often experimental development environment of new products, such as inventing new software.

Nowhere in the Scrum process itself do we discuss development methodology. This means we must bring our own methodology to the table and wrap Scrum around it, enhancing processes that have not been hyperproductive and increasing their productivity. In other words: Software quality assurance, formal testing, configuration management, risk analysis, budget planning and project scope planning, verification, requirements management and specific methodologies such as the Rational Unified Process, Extreme Programming or Spiral programming must also be part of the equation.

The backlog replaces the Project Design Document

Here I’m essentially belaboring the point that Scrum is not all you need. Different development methodologies employ different kinds of design strategies and documentation strategies, but one thing is common across almost every single methodology: There is always a Project Design Document (PDD) in one form or another. The project backlog is not a complete design document. A well-implemented project backlog is going to provide enormous technical detail and will probably fulfill all the requirements for a technical specification — but this is only part of the PDD. Team collaboration is not a substitute for someone putting the product design specification in writing.

The Project Design Document addresses a host of project objectives and requirements that simply won’t show up in the project backlog, at least not in an easily interpreted, cohesive fashion. Some of these include: Overall project scope; market objectives; user interface models; business models; user acceptance criteria; original customer requirement statements or vision statements; a project baseline; key risks and mitigation strategies; user interface style guides; software architecture and software integration procedures; and the list goes on. Many of these artifacts will, in time, turn into very specific project backlog items, but many will not. It’s important to document not only the specific, day-to-day deliverables of the project, but also the overall goals, architecture, and design guidelines.

One of my favorite product suites for managing both the product backlog and project documentation is Atlassian’s JIRA and Confluence. Combined, the tools provide fantastic support for managing tasks and deliverables (the project backlog) and a collaborative documentation environment. The ability to seamlessly create links between the JIRA tickets and more in-depth, collaborative Confluence documentation is an excellent tool. It allows the team to expand on technical detail and cross reference extended documentation, all within the context of the product backlog.

The 15 minute daily scrum is unnecessary

I’ve run into a lot of resistance to the daily scrum, especially very early in the process of introducing Scrum to a new team. Nevertheless, within a matter of a month or two, the value of the daily scrum has been realized and wholly adopted by all of the teams I’ve led.

One of the worst situations you can get into is a “fuzzy scrum,” one that doesn’t start on time or that exceeds the boundaries of the meeting on a regular basis. If the Scrum Master shows up five minutes late, then politely waits ten minutes for everyone to gather, a focused 15 minute briefing turns into a 30 or 40 minute distraction that everyone resents. Stay focused on the daily scrum rules of conduct — specifically, start on-time every day, in the same meeting place. The Scrum Master must arrive early and be ready to kick off precisely on time. If someone is late, don’t hold up the meeting. Use a timer to casually ensure that everyone gets a turn, and nobody goes significantly over their time limit.

A well-structured 15 minute daily scrum will benefit the team enormously. It keeps the entire team apprised of progress and current goals. It helps to focus the team, avoiding situations where one person gets derailed, instead giving them support from the team. Remote workers and partner-vendors will stay in-touch with current goals.

I can’t count the number of times something has popped up in a daily scrum that resulted in days, potentially even weeks of gained productivity. I’ve seen team leaders that sit next to their developers react with surprise when they hear what an individual is actually working on. In situations like this, enormous effort has been saved when the team leader corrects the objective right then and there.

I’m not allowed to work outside of the sprint goals

Another very frequent misconception is that Scrum introduces artificial roadblocks; for example, forcing the team to work on current sprint goals and nothing else. This is only partially true: It is correct that Scrum focuses the team on the current sprint. The objective is to complete the sprint and then move ahead to the next set of objectives. This means that an individual team member must finish their sprint goals and, ideally, try to help out other team members with other goals, if possible.

However, once the team member is done with their sprint goals they are free to “look ahead.” There is nothing that says a team member can’t start working on the next sprint ahead of schedule or — if the next sprint doesn’t have enough definition yet — even draw directly from the product backlog.

Scrum is about productivity. It will never require the team to stop work because of an arbitrary set of procedures or policies. Quite the opposite: Well implemented, Scrum enables the team to become far more productive than previously possible.

We don’t have to adopt all of Scrum

This issue has come up with every single client and, I fully expect, will continue to do so. Technically, it’s true — but not initially.

As with any process or methodology, it’s critical to understand how the process works properly before customizing it. Scrum should be followed entirely and rigorously for at least the first month or two of a project. Ken Schwaber’s recommendation is to do so until “several sprints” have been successfully delivered and the goals of achieving a hyperproductive team are met. As Clara Ko writes in Jeff Sutherland Talks Shock Therapy For Scrum, “Perhaps there are good reasons for excluding some parts of Scrum, but without truly understanding the reason behind a Scrum practice or the implications of skipping it, agile teams struggle to become hyperproductive, or mistakenly, struggle with Scrum itself.”

In other words, before changing Scrum, become an expert in it. Once the Scrum process has become second-nature it becomes much easier to begin customizing it or cutting pieces of it out. It will also become clear why something stopped working smoothly. Past experience will give the team the awareness to know the process broke because it was changed, and the motivation to move back to a working process.

With proper training and guidance, teams uniformly experience incredible productivity gains with the Scrum process. They key is adopting Scrum correctly, and that means doing it with the right level of training and commitment, especially early on. Process change is never easy, and while Scrum may appear to be a simple process it is not an intuitive one.

Related posts:

1. Why Agile isn’t enough (and why it doesn’t work)
2. Scrum is not an agile methodology
3. Common oversights in choosing methodology