Looking Back on this Blog...

December 30, 2011

I started this blog in January of 2009. At the time, I wasn't quite sure of where I was going, only that I wanted to drive my professional development and get more involved in writing. I began posting once a week, and around the second quarter of 2010 I increased my posting to twice per week.

I'll confess that I was concerned if I could maintain a twice-per-week pace with my work schedule. I was also worried that I might run out of material. As it turns out, posting twice a week keeps the heat on me to continually learn and raise my game.

Product Development is Learning, not Predicting

December 27, 2011

New products—or new businesses—should not make predictions early on, like predicting what features customers will value or how much revenue will be generated from a new product or business. These are questions that need to be validated as quickly as possible by getting in front of actual customers, not by making projections using a crystal ball.

Even if you capture “data” in a spreadsheet, it’s still wishful thinking until proven otherwise. Everything has the illusion of being real when reduced to numbers that add up in a spreadsheet. But just because the math works doesn’t mean that reality is being represented.

That’s not to say that some thinking up front isn’t helpful. You need to have a clear articulation of the problem that you believe needs solving—based on keen observation and thinking on your part—coupled with an assessment on whether there are enough potential customers in the market who are willing to part with their hard-earned money to purchase your solution to make their lives easier or better. And you need to be able to offer a solution at an attractive price point that will also make you a profit.

This is all part of your homework, but it is only one step in the full learning process. You need to make informed decisions on what to pursue, but once you start down a path, the reality is that you are heading into uncharted territory. And the information that you collect along the way may cause you to alter your course.

Merry Christmas!

December 23, 2011

As we approach the Christmas holiday—and since some of us are doing some last-minute shopping—I wanted to take a moment to wish you a Merry Christmas! And thank you for reading!

Have a warm and happy holiday. -- Dave Moran

Image courtesy of: suphakit73 / FreeDigitalPhotos.net

Control Trumps Intent

December 20, 2011

In his book, Disciplined Dreaming (A Proven System to Drive Breakthrough Creativity), Josh Linkner describes how his company ePrize won the business of UPS—but managed to enrage this new customer by doing something stupid: they shipped the first package of sales materials related to their very first promotion via FedEx.

How did this happen? Well, the employee who had the responsibility to mail the materials responded with, “Our shipping contract is with FedEx.”

Linkner says he learned two important lessons from this experience. First, a lack of awareness has what he calls a “gravitational pull” that pulls people into a state of semi-sleepwalking. The second is “the incredible power of rules and bureaucratic processes.” Linkner observes that, “People are quick to ‘follow along,’ believing it is more important to obey than to do what is obviously the right thing to do for their company.”

Seek Growth, not Perfection

December 16, 2011

In my last post about goals, I noted that there needs to be a conversation between the employee and manager, discussing why a particular goal is important and how it will help the employee grow through a combination of experience and learning. Nurturing and growing people is definitely a good thing!

There is a difference, however, between growing people and perfecting people. I think that most of us would attest that most performance management systems in place today tend to lean in the wrong direction by spending too much time pointing out flaws that may or may not be important in the grand scheme of producing results.

After twenty or thirty years of performance reviews where individuals have had their imperfections pointed out to them repeatedly, you would think that many of us “seasoned” (yes, I’m in this category) employees would be damn near perfect by now. But we’re not. Well, I’m not anyway.

Do You Have Goals or Good Intentions?

December 13, 2011

It’s that time of the year when performance reviews and planning for the upcoming year are taking place, and this means that we need to talk about the goals we achieved this year (or failed to meet) and begin making commitments to new goals.

Goals are useful, they give us all something to strive for; a goal describes what we want to achieve in the future. Goals should challenge us, with the recognition that meeting these challenges won’t happen without effort on our part. Because goals are something that we agree to take on, they will not only be challenging, they will be motivating.

Goals energize us because they give us purpose; they provide meaning to what we’re doing now and they give us a sense of achievement and satisfaction when we accomplish a goal. They also inform us about how we should prioritize activities that we are performing today. If something isn’t moving us forward towards our goal, it should be a lower priority.

Have you ever had a conversation about your own performance goals that concludes something like this? “That sounds good, and I hope I have time to work on it.” If this sounds familiar, you aren’t making a commitment. You have good intentions.

People are Unique, not Interchangeable

December 9, 2011

The term full-time equivalent (FTE) is a unit of measure and is as generic as you can get when talking about people. The use of terminology like FTEs or project planning exercises that allocate resources to projects (still general, but better language), coupled with standardized approaches to performance management can create a mindset that people are more interchangeable than they really are.

I’ve had experiences in the past where an “available resource” was plugged into a project to fill a hole in a project plan without regard for the skills and abilities required to actually make the project successful. Close enough was regarded as good enough. Needless to say, this never works well for the project team or the person assigned to a project.

Management is definitely an art because people are unique. Each and every one of us possesses certain knowledge, skills, experiences, perspectives, and preferences that make us unique. We have our own strengths and weaknesses; the key for management is to help people turn all of this into actual performance.

What is the Role of Reports and Meetings in Your Organization?

December 6, 2011

If people are coming to work excited...if they're making mistakes freely and fearlessly...if they're having fun...if they're concentrating on doing things, rather than preparing reports and going to meetings...then somewhere you have a leader.” –- Robert Townsend

Meetings and reports are double-edged swords. Used wisely they can be effective instruments for planning and coordinating work. Unfortunately, it’s all too easy to cross the line and turn these very same things into onerous, time-consuming drains on productivity.

That line is invariably crossed when management takes the view that everyone is subject to their authority and control. This drives a demand for reports and status meetings that fills up countless hours per week.

This can be further exacerbated by the limited span of control concept because the constraint on the number of people that can be “controlled” (managed) by any one person ultimately introduces multiple layers of management into the equation that not only creates more meetings and reports. Worse, these extra layers don’t always mesh, further impeding the very cooperation and communication that organizations require to be productive.

Leadership Lessons from Two Boston Sports Legends

December 2, 2011

A title alone doesn’t make you a leader. Sports teams have coaches, and they are definitely (or should be) in charge. But sports teams have another type of leader that is driven by the recognition of one’s own peers: the title of team captain.

A captain’s job is to lead by example and to lead when the coaches aren’t around. To be effective, captains must have the respect from those they are leading. This goes beyond being genetically gifted with great athletic capabilities. You can be respected for your physical attributes, but leadership requires more.

Two examples of those who weren’t exactly known for being the most physically talented athletes in the world are Tom Brady and Larry Bird. This is not to say that they don’t have certain gifts, but neither of these two Boston sports legends have ever been regarded as being able to fun faster or jump higher than most others in their respective sports. However, they each posses leadership qualities that set them apart.

(Larry Bird is retired, but I’ll refrain from using the past tense to differentiate Larry versus Tom for the purposes of this post.)

How to Identify What Needs Improvement

November 29, 2011

Improving the efficiency and effectiveness of your organization is at the heart – and is the art – of management. Where do you start? What are the key areas that you should focus on?

A small set of general questions can reveal problem areas at all levels of your organization. You begin at the point most applicable to you—a line manager will use these questions at a departmental level whereas an executive will focus on a division, for example.

Are You Living on Past Glory?

November 25, 2011

While I’ve recently argued that revenue per employee is the ultimate productivity metric, I balanced this against over-using financials to run the company, urging that as leaders we must look beyond the spreadsheet. In a nutshell, my message was that you shouldn’t “cut your way to glory” today to the extent that you squeeze your company out of business tomorrow. If you are leading your organization as an ongoing, sustainable business, you need to be making investments in your future.

This implies that the revenue per employee metric can be deceiving because today’s revenue is the result of yesterday’s investment. If our goal is healthy, sustainable, long-term growth, we need to focus on innovation. What types of innovations and what levels of investment are important? Jane Stevenson and Bilal Kaafarani tell us in their book Breaking Away (How Great Leaders Create Innovation that Drives Sustainable Growth--and Why Others Fail) that we need to focus on four types of innovation.

Look Beyond the Spreadsheet!

November 22, 2011

In my last post, The Ultimate Productivity Metric, I stated that while revenue per employee is an excellent gauge for understanding how much you are generating from your people, it is an incomplete measure of how well the business as a whole is operating. Costs, for one, are not taken into account.

The implication is that you can be doing very well in terms of revenue generated per employee compared to your competition, but you may be losing money in the process. When it comes to controlling costs, the big trick is to find that sweet spot where you are producing more income for each dollar spent while avoiding cutting so deep in an effort to save money that you cut away activities that generate your income.

The Ultimate Productivity Metric

November 18, 2011

Agile leadership understands the advantage in maximizing the performance of a team as a whole, avoiding problems with sub-optimization:

“If each subsystem, regarded separately, is made to operate with maximum efficiency, the system as a whole will not operate with utmost efficiency.” - (Lars Skyttner) General Systems Theory

When dealing with complex knowledge work such as software development where there is a high degree of uniqueness and variability with each and every project—plus the need to leverage the functional skills and abilities of knowledge workers across multiple disciplines, we need to focus greater attention on outcomes, not functional outputs.

Results-Oriented Creativity: A Separation of Concerns

November 15, 2011

Do you consider yourself to be creative—or know someone that is highly creative? Creativity can surface in different ways, whether it is a novel idea for a new product or a unique approach to solving a difficult problem. Creativity is a differentiator for individuals and corporations, and we all know when we see it.

But what is goes into being productively creative? And by that, I mean coming up with ideas that have merit, ideas that work. Is it better to be creative or analytical? The answer is that you need both, but you need to cleanly separate your creative and analytical mindsets.

Do You Have a Prototype in Production?

November 11, 2011

The act of delivering software to the market is a continual learning process. My recent posts have been talking about bringing new products to market using fast, low-cost experiments to empirically learn about what really works—what customers will value and pay for.

If you have entrepreneurial types (and these can be intrepreneurs) driving your innovation, keep in mind that they are really experimenting and that they typically have a strong desire to get something in front of real customers to validate their learning. They also have a tendency to drive development teams for speed, and in response development teams start cutting corners on good design and technical practices that pay dividends later.

Other times, there is so much uncertainty about what really needs to be built that the entire development process can wind up being a giant learning exercise. Unfortunately, if that learning has been done under schedule pressure, you can still end up in the same place.

I call it the prototype in production problem.

Book Review: The Lean Startup

November 8, 2011

The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
With The Lean Startup, Eric Ries has produced a truly interesting, engaging book that is valuable for anyone seeking to drive innovation. In fact, given the intense scrutiny that venture capitalists purportedly have towards startups these days, this book might actually be more applicable to larger organizations and those who want to be better intrepreneurs.

The Lean Startup, as the title suggests, guides the reader in the application of Lean principles in a software startup. A startup, according to Ries, is “… a catalyst that transforms ideas into products.” And the products that a startup builds, “are really experiments; the learning about how to build a sustainable business is the outcome of those experiments.”

As part of this Ries advises us to avoid sub-optimizing individual functions, favoring working through what he calls the Build-Measure-Learn feedback loop in a specific way. Ries’ point is that, “… the goal is not to produce more stuff efficiently. It is to—as quickly as possible—learn how to build a sustainable business.” In the context of applying the principles of the Lean Startup, what matters is how quickly you can get through the entire Build-Measure-Learn loop.

Put Your Product Assumptions to the Test!

November 4, 2011

In the latter half of my last post I began to pull from Eric Ries’ book, The Lean Startup, discussing how minimal viable products (MVPs) are minimalist implementations that allow you to start the process of learning as quickly as possible, with the least amount of effort expended. There are times where what you learn may take you by surprise, as Ries recounts in his book.

At one point in his career, Eric Ries was a cofounder and chief technology officer at IMVU, an online social entertainment destination where members use 3D avatars to meet new people, chat, create and play games. IMVU’s first MVP shipped with avatars in virtual environments, but they were stationary.

Of course, customer feedback was that they wanted the ability to move their avatars around…

How to Fire a Business Bullet

November 1, 2011

One piece of advice offered by Jim Collins and Morten T. Hansen in Great by Choice is to avoid making a big bet on one innovation that ends up wasting your energy and your resources. Collins and Hansen observed that great companies fire bullets first, then cannonballs.

The analogy at work here is that if you are on a warship at sea fighting another ship – and you have limited gunpowder – it is better to fire a few bullets first to calibrate your shot. This way, you can determine the correct firing range and increase the odds of success with your larger cannonball shot.

The business research conducted for Great by Choice demonstrates that great companies obtained a 69 percent calibration rate on their “cannonballs” versus 22 percent for the comparison companies. Would you like to increase your odds by a 47 percent margin? What does a bullet look like in a business context?

Zooming In and Out

October 28, 2011

In my last post, Change the Right Things, not Everything, I highlighted how Intel shifted away from the memory business and into the microprocessor business full time. Andy Grove and Gordon Moore concluded that this was the correct decision when Grove zoomed out – as Jim Collins and Morten T. Hansen in Great by Choice call it – by posing his question about what a new CEO would do in their place.

Collins and Hansen adopted the terms zoom out and zoom in to capture a duality they observed in “10X” leaders. These leaders have the capability of remaining “obsessively focused on their objectives and hypervigilant about changes in their environment.”

Zooming out in a leadership context is about sensing changes in business conditions, the time frame involved, and the risk – ultimately leading to an assessment as to whether new conditions will call for disrupting existing plans. Zooming in, on the other hand, is all about “supreme execution of plans and objectives.” But there is another flavor of zooming in and out.

Change the Right Things, not Everything

October 25, 2011

As Andy Grove: The Life and Times of an American Business Icon relates, at one point in mid-1985 Andy Grove and Gordon Moore determined that Intel should get out of the memory chip business after Grove asked, “If we got kicked out and the board brought in a new CEO, what do you think he would do?”

Moore immediately replied, “He would get out of memories!”

The decision wasn’t easy to come by until Grove posed his question. The memory market was Intel’s historical bread and butter, whereas up until 1984, the microprocessor (logic) business wasn’t particularly good for Intel. Making the decision even more drastic for Intel was the fact that this change was a change in identity. “Our priorities,” Grove said, “were formed by our identity; after all, memories were us.”

Book Review: Great by Choice

October 21, 2011

Great by Choice: Uncertainty, Chaos, and Luck--Why Some Thrive Despite Them All

Why do some companies thrive in uncertainty, even chaos, and others do not?

This is the key question that Great by Choice seeks to answer. I’ll state up front that if you are looking for a how-to cookbook on success, this book isn’t for you! Instead, Great by Choice leverages solid research, analysis, and examples to clearly illustrate the principles used by seven companies to significantly outperform comparison companies in the same industry during turbulent times by an order of magnitude – generating 10 times the performance – to become what Collins and Hansen call “10Xers” (pronounced “ten-EX-ers”). But it’s still up to you to figure out how to apply those principles to your situation.

The Elevator Story: Guiding Behavior Changes with Scrum

October 18, 2011

Scrum is a great framework for self-organizing teams to manage their work, but it lacks any real guidance or techniques for teams to use when they encounter problems. All too often the default answer is either get a coach or let the team work it out.

Both options can work, but there will be times when neither is an option. As Agile adoptions increase, problems will emerge on too many fronts. Coaches won’t be available when we need them, and there will be times when the teams themselves will be ill-equipped to deal with problems on their own.

Changing behavior is the most difficult aspect of change, particularly one that involves conflict. Consider the following hypothetical scenario.

Software Developers Should be More like Writers

October 14, 2011

As I’ve noted in my last couple of posts, hard work is the backbone of success, but the best don’t just work hard for the sake of working hard. The best work hard at understanding what it takes to be better, to learn and train themselves in new techniques to raise their game.

A vast majority of the software developers that I’ve ever worked with are hard workers, without question. They’ll toil for countless hours at solving difficult problems; they enjoy spending their time writing code. For many, I feel that there is too much time being spent writing code and not enough time reading code.

Committing to Being Our Best

October 11, 2011

Towards the end of my last post I commented that we need to be committed to doing our best. To work harder at being smarter. It’s all about committing to and living up to the United States Army’s recruiting slogan (1980-2001), “Be All You Can Be.”

Doing our best doesn't require a competition to sort out the winners and losers. In business and in life, what is more important is your drive and mindset. Winning a contest is about who is the best on a given day. A winner’s mindset is about improving, about making a realistic assessment of where you are right now and what you need to improve – and to work at getting a little better every day.

What are you committing to?

October 7, 2011

As a result of Sprint Planning, your Scrum team has made a commitment to completing a certain set of Product Backlog features. This act is a public commitment, with the team’s Task Board visible to all. The ScrumMaster even sent out an email to all stakeholders outlining what the team committed to in this Sprint. However, during the course of the Sprint unforeseen problems emerge…

The team is faced with a quandary. The team cannot meet its Sprint feature commitment while supporting its other commitments to high-quality, well-designed code (related to the definition of “done”) and sustainable development. The ScrumMaster takes action on behalf of the team and removes features from the bottom of the Task Board, reminding the team that, “A commitment is not a guarantee!”

As a team member, how does that make you feel? How do you think the Product Owner or other stakeholders feel?

The Versatility of Velocity

October 4, 2011

Scrum teams understand that velocity is an indicator of how much work a team can accomplish in a sprint. Velocity can also be used to forecast completion dates, using an estimated backlog and the team’s velocity to project how deeply into the product backlog a team will be at a given point in time.

Scrum estimation works because it avoids making time-based estimates, and for good reason. People are poor at estimating task-completion times; we tend to focus more on what we want to achieve, underestimating or overlooking potential impediments.

Documentation is a Communications Vehicle

September 30, 2011

I’ve seen very large product requirements documents in my day, and I’ve even joked about the size of some of these documents, holding them in one hand and stating, “These must be great, they weigh a lot!” Heavyweight documentation doesn’t imply thoroughness. In fact, it can mean that you may have a couple of problems:
  1. The scope of the project is too large.
  2. The person writing a large volume may not be an effective communicator, at least not in written form.

Leading is Communicating

September 27, 2011

Leaders spend their time communicating. Stephen Denning, in his book, The Leader's Guide to Storytelling, referenced Henry Mintzberg's The Nature of Managerial Work(that I haven’t read) noting that talking comprises 78 percent of what managers actually do with their time.

Of course, talking isn’t necessarily communicating. As a leader, people need to hear and understand your message. It needs to ring true with them, to inspire them to action. Great leaders are great communicators. Abraham Lincoln and Ronald Reagan come to mind. As we all know, Reagan became known as The Great Communicator. He earned this reputation for a number of reasons:
  • He was optimistic about the future – particularly at a time when the country needed it.
  • He had a strong sense of purpose. He believed in our country and that it and the people in it deserved greatness.
  • His speeches used anecdotes and his messages were designed to distill complex issues into basic terms that everyone could understand and relate to. (Along with providing great sound bites!)
  • He paid attention to his speeches and his audiences’ reaction to his words.
  • His speeches had an emotional appeal that moved people.

Book Review: Toyota Kata

September 23, 2011

Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results

A few months ago I exchanged a few tweets with Alan Shalloway about Agile retrospectives and how they can become stale, and he was kind enough to point me to this book as a way to drive learning. He couldn’t have been more right! Alan has written about The Difference Between "Inspect and Adapt" and Plan-Do-Check-Act (PDCA), but this book really brought the point home for me.

The real secret of Toyota’s success, as author Mike Rother points out in Toyota Kata,is that Toyota is dedicated to continuous improvement. Toyota Katais a very practical guide in systems thinking applied to organizational learning and continuous improvement, and Mike reveals how Toyota lives and breathes continuous improvement in its management practices. And as Mike Rother explores Toyota's management practices, it is revealed that Toyota's approach to management is very different than accepted management practices in use in most organizations today.

Respect the Boundaries in Scrum!

September 20, 2011

We’re Scrum shop, and Scrum definitely has its share of “good fences” that are designed to make Scrum work. In fact, looking for how the boundaries of these fences are being violated can help you identify problem areas in your Scrum implementation.

There are three roles in Scrum: Product Owner, ScrumMaster, and Team Member. While lacking an officially acknowledged role, management plays an important supporting role and can be a significant factor in the success or failure of a Scrum team by either violating the boundaries or failing to support the team.

Organizational Fences Aren't Always Evil

September 16, 2011

As I pointed out in my previous post, fences stifle initiative; but that is not a universal rule. In business, fences are constraints, and some of these "organizational fences" are good constraints. Like those designed to prevent discrimination, sexual harassment, or injuries. These constraints need to be both visible and clear, and there shouldn't be room left for negotiation or interpretation.

Other types of constraints, however, need to provide people some maneuvering room. Operational constraints fall into this category. Operational constraints help to define and frame the problem at hand for people. They inform people about what the business needs from them in order to be successful – or to measure the degree in which a business succeeds.

Fences Stifle Initiative

September 13, 2011

William L. McKnight is a former 3M CEO who saved 3M from near bankruptcy and turned it into a large, successful, multinational organization. In doing so, he created a corporate culture that encouraged employee initiative and innovation. His belief that people required freedom in order to kindle their creative spirit is captured in his famous quote: “If you put fences around people, you get sheep.”

You might also get children. Consider the words of Tony Schwartz from his book, The Way We’re Working Isn’t Working:

“The all-too-common dynamic in today’s workplace is parent-child. Most employers tell employees when to come to work, when to leave, and how they’re expected to work when they’re at the office. Treated like children, many employees unconsciously adopt the role to which they’ve been consigned. Feeling disempowered and vulnerable, they lose the will and confidence to take real initiative or to think independently. Doing what they’re expected to do often becomes more important than doing what make most sense, what’s most efficient, or even what might create the highest value. “

Managing in Real Time

September 9, 2011

As I was talking to a fellow manager last year at the Give Thanks for Scrum event organized by the Agile Boston user group, we both noted how Agile management was about management in real time. What did we mean by that?

As teams get comfortable and productive with Scrum (that's what we use), they start decreasing their sprint lengths. If a team is working with one week sprints, everyone needs to be crisp, focused, and productive – every day. This means that those providing external support to the teams – such as removing impediments that are outside of the team’s control – must have that same crisp, focused, and productive mode of operation. If you take too long in removing an impediment, an entire sprint can go down the tubes.

Book Review: The CIO Edge

September 6, 2011

The CIO Edge: Seven Leadership Skills You Need to Drive Results The CIO Edge Seven Leadership Skills You Need to Drive Results

What gets a CIO fired?

Based on the research of the authors (Graham Waller, Karen Rubenstrunk and George Hallenbeck), it isn’t due to a lack of technology chops on the part of the CIO. According to The CIO Edge, CIOs get fired because they fail to build effective peer relationships. The authors state that, “Despite knowing how important horizontal relationships are, many CIOs we observed still gave them insufficient time and attention (typically being all consumed by management activities and by knocking off all the things on their to-do list) and consequently found themselves swept out of a job by this powerful force.”

Delight Your Customers through Focus

September 2, 2011

Great vision and mission statements are geared towards defining and communicating how an organization intends to succeed. When crafting these, an organization’s values come into play. A strong component of those values needs to focus on delighting the customer. However, this doesn’t mean at all costs.

Google’s Mission: Right or Wrong?

August 30, 2011

In my last post, Are People Buying What You’re Selling? I discussed mission statements and vision statements. The act of creating these statements – good ones – forces you to think deeply about your business, capturing the essence of why people should do business with you and why they should come to work for you.

These should be crafted with a long-term view, but are there times when that view should be trashed, or at least modified? Let’s look at a high-profile, public company: Google.

Google’s mission is to organize the world‘s information and make it universally accessible and useful.

As the world’s leading search engine, I would say that they’ve certainly succeeded on this front. But Google has a problem. Steve Denning recently wrote about this in a two-part article urging: Google: Rethink Your Mission! (And Part 2: Google+)

Are People Buying What You’re Selling?

August 26, 2011

As a leader, that is. Does your strategic vision sound something like this?

“Our strategy is to develop products that truly fulfill customer needs by exploiting our skills and abilities to the maximum level in order to provide a maximum profit to our shareholders. We will do this with high-quality products that provide a substantial competitive advantage. And while achieving this, we will be supportive of our community and our employees.” (Product Strategy for High-Tech Companies, created from the Dilbert Mission Statement Generator that is sadly no longer available.)

Granted, the example above isn’t from a real company, but elements of these generic statements find their way into a lot of real vision or mission statements. If any of these sound similar to your company, ask yourself this: What do your customers or employees really understand about your company? What is it all about? In other words: What do you stand for, and why aren’t you clearly communicating it?

Expect Mistakes in Business

August 23, 2011

Great professional sports teams are intolerant of mistakes – during a game. They’d much rather make their mistakes during practice. And if they do make a mistake during a game, they want to learn from it and avoid making it in the future.

Various professions have moments when mistakes aren’t tolerated, either. Doctors, for example, strive to be mistake-free during activities like surgery or delivering babies. While I’m not a doctor, I’m sure that the demands of the moment do plenty to increase concentration. Between that and years of training, mistakes are kept down to a rare occurrence. I’m equally sure that in other aspects of their job, doctors can and do make mistakes. The level of concentration required during surgery or delivering babies is not sustainable hour-by-hour, day-by-day.

In business, the “game” is continuous; we don’t have the luxury of practicing more than we play like sports teams; quite the opposite, in fact. And while we all have our peak moments of high concentration and involvement, we can’t sustain that pace indefinitely any more than doctors can.

Book Review: The 42 Rules of Product Management

August 19, 2011

42 Rules of Product Management: Learn the Rules of Product Management from Leading Experts "from" Around the World The 42 Rules of Product Management is a collection of “over five centuries” of product management wisdom from a variety of product management experts. Each chapter – from a different contributor – is consequently a fresh perspective provided in a short, concise chapter.

As a new product manager, I enjoyed gleaning insights from a variety of perspectives (the contributors include executives, consultants, authors/bloggers, and trainers as well as product managers). I appreciated reading what each contributor felt was important about product management, and why. It gave me a broad perspective in a short amount of time, and I found myself plowing through the book very quickly.

In this post, I'll share some nuggets that I came away with.

Fifty!

August 16, 2011

I’m celebrating my 50th birthday today! It doesn’t seem possible, but I’ve lived a half a century already...

I was a kid when the original Star Trek series aired on TV. My parents took me and my brother to the Cinerama airing of 2001: A Space Odyssey – but I wasn’t quite old enough to appreciate it. I also remember my parents waking me up to watch Neil Armstrong step out onto the lunar surface.

Define the Problem, then Resolve It

August 12, 2011

When you or your organization encounters a problem, does everyone start generating solutions? How do you evaluate which one to choose?

Choosing can be difficult, particularly in software development where problems are inherently complex and dynamic – involving both people and technology. But there is way around this.

Albert Einstein is attributed to providing an interesting answer to the following question: “You have one hour to solve a problem; how do you proceed?” His answer was reportedly, “I would spend fifty-five minutes defining the problem, and five minutes finding the solution.”

Make Improvement Continuous, not Periodic

August 9, 2011

“At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.”

Agile development seeks to change the working world of development teams for the better, and it does. When it comes to making improvements, the retrospective approach used by a framework such as Scrum is a great start, but it still smacks of being a periodic improvement tactic versus one of continuous improvement.

You Can’t Cut and Paste Your Way to Improvement

August 5, 2011

Jeff Atwood recently wrote about how Nobody's Going to Help You, and That's Awesome, differentiating between self-help and self-improvement. As Jeff says, “Reading books, blogs, and newsletters by people who have accomplished great things is a fine way to research your own path in life. But these people, however famous and important they may be, are not going to help you.

He’s right, you have to help yourself. Just like cutting and pasting text isn’t writing, “cutting and pasting” advice from a book into your life or organization won’t provide magical benefits. There is change involved, and lasting change requires time and effort. You have to work at it.

Iterating is Costly

August 2, 2011

Agile development’s iterative philosophy sounds great: deliver working software in short periods of time (weeks), allowing the users and/or stakeholders to review the work and suggest changes. These changes get prioritized and incorporated into the team’s product backlog. If the changes are important enough, they get worked on in the next sprint (iteration).

So you iterate. The problem is, iterating is a rework strategy. If you are iterating, you are increasing the number of increments required to deliver the forecasted feature set.

As a new product manager, I’m in the process of recommending a change to one of our products under development. I found what everyone agrees to be a serious limitation, one that is going to cost us several weeks of rework to correct. A change like this introduces a certain amount of organizational anxiety, and it certainly torpedoes the timing of other go-to-market planning already in progress. People are grateful that I uncovered this issue, but no one likes making the payment.

How do you avoid this problem?

Trust is Essential for Honesty

July 29, 2011

I recently read and commented on Pawel Brodzinski’s post, Give Honesty a Try. It is commendable that Pawel doesn’t have problems with people being critical of him because he is looking at the upside of knowing the truth. I agree with him –honesty helps us to do the right thing from an organizational perspective and honesty enables us to change and grow personally.

I asked Pawel a question that in all fairness was a tough question (as Pawel pointed out): ”I’d be interested in your take on building an environment where people feel secure enough to talk candidly. Personally, I feel that management has a role in building trust that goes hand-in-hand with honesty…”

As a writer on leadership topics – it occurred to me that I attempt to answer the question myself.

A Product Manager is an Agile Leader

July 26, 2011

As I’ve been gaining some very early experience in product management, I’ve noted some interesting parallels between the skills of a good product manager and a good manger, especially an Agile manger.

For example, one common refrain that I’ve picked up on from other product managers is that product managers need to lead people that do not report to them. They typically cite the challenge of being responsible for a product and counting on the cooperation and efforts of others that they don’t have direct authority over. Product managers, you’re not alone in this!

Diving Into Product Management

July 22, 2011

My transition from development manager to product manager was swift, and I’d sum up my first official month in a product management role as very active. I’ve been designated as the product manager of three products, one of which is a very technical, security-related initiative that is a BIG DEAL for our company. A product that will be a shared platform,involving integration of other products across our company...

My first order of business was to write a Product Requirements Document (PRD) for that very same security product (since we didn't have one). There has been various documents and artifacts produced to support release planning and development, so it wasn't like I was starting from scratch. Since we're a Scrum shop, the team has had a Product Owner in place along with a product backlog (the architect has been operating as the Product Owner until recently) and regular sprint reviews.

Did you notice a couple of warning signs? How about an important, new product under development with a part-time product owner? The absence of a PRD isn't necessarily a bad thing given that there is a product backlog, but in this case it turns out that we did have another problem that surfaced during my writing of the PRD.

Book Review: The Elements of Scrum

July 19, 2011

The Elements of ScrumIf you want to understand the essentials of Agile development and Scrum, The Elements of Scrum by Chris Sims and Hillary Louise Johnson is a must read. Chris Sims has worked with our company on a couple of occasions, providing “experiential training” in Agile development using exercises designed to demonstrate aspects of Agile development and why they work. His excellent training was for this reason that I felt this book would be a worthwhile read, and I wasn’t disappointed.

The book itself doesn’t talk about Agile development in pure theoretical terms, it provides insight on how Scrum teams function by using examples and clear explanations. The first chapter starts with, A Week in the Life of a Scrum Team, providing a short overview of what it is like to be a part of a Scrum team.

Phone Courtesy Isn’t Just for Cell Phones

July 15, 2011

July is National (U.S.) Cell Phone Courtesy Month!

Jacqueline Whitmore founded National Cell Phone Courtesy Month in July 2002, with “…the intent of making cell phone users more respectful of their surroundings.” I guess it’s taken me a while to realize that we had a cell phone courtesy month! This is the first year that I’ve become aware of it. How did I miss that?

The popularity of cell phones, texting, Twitter, Facebook, LinkedIN, etc. all reflect the innate desire we humans have to be connected. Oddly enough, the very devices that enable us to be connected are demonstrating that they can adversely affect our personal connections.

Where Do Unused Features Come From?

July 12, 2011

My last post discussed why Cramming Features into a Product is Bad Business. Coincidently, a related issue popped up in the LinkedIN Agile group discussion, Do you agree or disagree that Scrum is not Agile? – as the discussion found its way to the topic of requirements.

Horia Slușanschi referenced the oft-quoted Standish Group’s statistic that over 40 percent of a systems features are never used. The exact figures from the Standish Group are depicted in pie-chart form below:


How do these unused features find their way into the system in the first place? And what can we do to prevent what is clearly a huge waste?

Cramming Features into a Product is Bad Business

July 8, 2011

“Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’” – Marty Cagan in his book, Inspired: How To Create Products Customers Love.

Hitting this wall is definitely a BAD thing. And it sneaks up on you. Bob Martin discusses this in his book, Clean Code: “Teams that were moving very fast at the beginning of a project can find themselves moving at a snail’s pace. Every change they make to the code breaks two or three other parts of the code. No change is trivial. Have you ever waded through a mess so grave that it took weeks to do what should have taken hours?“

Managing the Agile Way

July 5, 2011

When I step back and consider our implementation of Agile development and what it takes to achieve a truly beneficial Agile adoption, I feel that ultimately, management is THE significant factor as to whether the organization will reap many of the benefits the Agile offers.

Agile isn’t just something “for the development teams.” Management needs to look beyond a specific framework and understand the operational and behavioral changes that should accompany an Agile adoption. Failure to do so will severely limit the organization’s potential for improvement.

Frameworks, not Processes!

July 1, 2011

I used to cringe whenever I heard someone say, “The process is the thing.” It was what came next that was the problem: a codified, rigid process that eliminated thinking and discouraged adaptation – at least not without a fight. For right or wrong, the PROCESS had to be followed, and this was with a company that said it valued continuous improvement!

Ever try implementing a change to a process – even one for the better – in an organization wedded to its processes? You need passion and persistence, which means that those small, incremental changes are likely never to see the light of day. The cost/benefit on an individual level is too high. Worse, you run the risk of getting dinged on your performance review for devoting too much time and attention on low-impact initiatives.

This is a shame, because the cumulative effects of many small changes can equate to a significant benefit.

Two Steps = Better Project Forecasts

June 28, 2011

In my prior post, I noted that there appears to be a 30 percent rule involving software projects: You’re going to spend 30 percent of your time figuring out what you’ve gotten yourself into. This places implications on the planning and estimation process that in my experience are best solved by Agile planning and estimation.

There is a tremendous amount of time and effort expended up front with traditional project planning, and one area in particular that is problematic is the tasking out of all of the work and guesstimating a duration associated with each and every task. There are two flaws with this:
  1. Software projects are the most unpredictable in the early stages of a project. A team needs to perform actual work to get their arms around the project.
  2. As I pointed out in Optimism Isn’t Just for Developers, people generally underestimate task-completion times.

Leverage Evidence in Software Estimation

June 24, 2011

Agile development and business users/sponsors are at two opposite ends of a spectrum in one respect. Developers want the business to be entirely flexible on scope or dates in reaction to death-march projects (and these are extremely painful) and the seemingly continual expectation that developers spend their days, nights, and weekends writing software – with no life whatsoever – to “satisfy the business.” The business side, naturally, wants what it wants, for a set price and delivered by a specific date.

Business people don’t care to invest their time in understanding why software projects are complex and uncertain, either. At least not in any great detail. What is one approach that you can take?

When Incremental Funding Works

June 21, 2011

Incremental funding – funding one iteration at a time – is an attractive concept. It goes hand-in-hand with Agile development's “getting right to work” philosophy where complete, detailed planning is not done up front, but spread through a project. However, I don’t believe that most projects can be tackled using a blind “fund as you go” approach. Projections have to be built into the equation, otherwise the business won’t buy into it.

Those who hold the purse strings like to understand how much money they are going to be asked to dole out and what the potential return of that investment is. The uncertainties of business means that they’re effectively placing a bet, and they sure as heck want to understand if they’re making a small bet or a big bet.

Go MAD with Agile!

June 17, 2011

Scrum, Extreme Programming, and Kanban are Agile’s Big Three, but which is better?

All have been demonstrated to work, yet all can fail.

The reality is that all of the challenges of today aren’t going to be solved by any one approach. There is no single, silver bullet that is going to work for everyone, everywhere, in every situation.

Failures will occur, despite the fact that the foundation of Agile is strong, built upon the knowledge and experience of others: Joint Application Development, Complexity Theory, Lean production, and many years of hard experience in the field of software development, to name a few. The approaches of Scrum, Extreme Programming, and Kanban reflect tremendous insight and each provide a solid framework to work from.

Early adoptions of Agile have proven to be successful, but there have been Agile project failures. There are too many variables in play – existing skill sets and knowledge, the amount of time and budget available for training, management support, the willingness of the workers to accept working in new ways, etc. – that influence success.

Book Review: Inspired How To Create Products Customers Love

June 14, 2011

Inspired: How To Create Products Customers LoveI’ve recently transitioned from being a Development Manager to a Product Manager, a move that is not a surprise to many since I’ve been dividing my time between both roles for a while now. This has prompted me to seek out books on product management, and Inspired: How to Create Products Customers Love by Marty Cagan provided me with a lot of terrific insight.

Early on, Marty Cagan defines the product management role nicely: “The product manager is responsible for defining—in detail—the product to be built, and validating that product with real customers and users.”

He also discusses the need to have a good relationship with engineering – otherwise you are “… in for some very long and frustrating days.” (True enough!) Marty points out one key to making the relationship work is that the product management/engineering relationship is a peer relationship; “As product manager, you are responsible for defining the right product, and your engineering counterpart is responsible for building the product right.”

It is clear the Marty Cagan has plenty of real-world experience, and he does talk about something that I’ve seen become an unfortunate reality: “Few words are more dreaded by product managers than being told by engineering: ‘No more new features! We need to stop and rewrite! Our code base is a mess, it can’t keep up with the number of users, it’s a house of cards, we can no longer maintain it or keep it running!’”

The Benefits of Limits

June 10, 2011

I can see it coming. As I walk by the open area with white-board paint on the walls and desks designed for pairing, I see everyone concentrating intently at their desks, some with headphones on. People are working hard, yet there is something wrong.

The sprint ends with far less than expected velocity.

A common way that teams get into trouble is that they try to put too much work in flight at any one time and the task board morphs into “swim lanes” where people are working feverishly, but independently. The result is a race to see if the “team” will accomplish its work by the end of the sprint. This can lead to a BIG disappointment, with a lot started, but little to nothing completed.

Yet Another Agile Elevator Pitch

June 7, 2011

Let’s say that you are talking with a couple of people whose organization hasn’t adopted Agile development yet, but wants to understand why they should. They want to understand what is behind the hype. They want a good elevator pitch.

What would you use as an elevator pitch for Agile development?

We all know the history of Agile development and how it seeks to overcome some common problems with software development, but an elevator pitch needs to be something more than just quoting the Agile Manifesto and telling people that they’ve what they’re doing all along is completely wrong. Why should people change their development approach? What will they gain as a result?

Source Code: Asset or Liability?

June 3, 2011

For those who feel that source code is a liability, my immediate reaction is this: Are you nuts?

Then again, I’m an optimist. With me, the glass is always half-full. I’ll bet that those who view source code as a liability are the half-empty crowd. Or experienced developers who have shoe-horned just one more feature into code that seemed to be actively fighting back.

Actually, I agree with the reasoning behind the assertion that code is a liability. However, classifying all code as a liability – psychologically speaking – isn’t exactly rewarding. It also isn’t accurate and frankly, telling programmers and the business folks that all the time, effort and money invested in creating software nets out to owning a liability paints software development in a very bad light.

Delight Your Customer Today, Enjoy Profits Tomorrow

May 31, 2011

I enjoy Steve Denning’s writing, and my personal opinion is that he makes astute observations and provides clear, solid advice. Like pointing out in his presentation, Making the Entire Organization Agile that we need to shift from producing outputs to delighting the customer.

He’s right, delighted customers will not only bring their business back to you, they will tell others, and in this Internet age of social media there’s real value in having a larger percentage of promoters versus detractors. This is why many companies are paying greater attention to their Net Promoter Score® metric.

Agile Brings Changes to Key Roles and Responsibilities

May 27, 2011

Agile development is – or should be – a driver of change. And when change is in the air, everyone wants to understand, “How does this affect me?” This post is by no means comprehensive, but I’ll take a quick look at some key changes, and I’ll tackle one that is particularly sensitive territory: the project management role.

Developers and testers feel the impact of change because the nature of their roles changes with Agile development. For example, team members are expected to work together interchangeably and to hold each other mutually accountable for the team’s results, something that they might not be used to. And then there is the question of specialists versus generalists. I gave my opinion in a recent post, Agile Development: Specialists versus Generalists as well as discussing what I see to be problems with specialists on Agile teams in another post.

The Real Divide between Agile Development and Project Management

May 24, 2011

There are a number of polarized views on this subject, but I don't believe that the real argument should be about traditional project management versus Agile development. The PMBOK doesn’t contain evil things, and Agile development doesn’t ignore as much as many traditional project managers might believe that it does. Agile fools you because certain things are implicit.

Common Ground with PMI Agile Certification?

May 20, 2011

When you are young, you are more welcoming to change because you haven’t built a career around a certain way of doing things. Change is more difficult to contend with as you get older, particularly when you have a spouse and house along with some kids, pets, and in-laws that demand your attention, let alone how additional responsibilities pile into your work day as your career progresses. Time becomes a scarce commodity, limiting your ability to develop an understanding – let alone adapt – to change on any front.

Despite understanding that it’s a bad idea to resist change in today’s fast-paced, competitive world, people do get comfortable with established ways of working, and it can be costly.

Business Agility is More Important than Agile Development

May 17, 2011

I recall reading an article many years ago that gave advice to CIOs that annoyed the crap out of me. The article was about CIOs needing to be change agents, suggesting that in order to generate a sense of urgency in the organization – and to get people to willingly and quickly adapt to change – CIOs should create a crisis.

This advice sounded lame to me then, and my view hasn’t changed over the years. If you want to drive change, there needs to be transparency and sincerity about the nature of change, and it must be grounded in reality. If you are a leader driving artificial change, people will see through it and write you off, riding out the fire drill and returning to the same way of operating once the drill is over.

Book Review: The Talent Masters: Why Smart Leaders Put People Before Numbers

May 13, 2011

The Talent Masters: Why Smart Leaders Put People Before NumbersThe goal of The Talent Masters, as the authors Ram Charan and Bill Conaty put it, “is to light a path for all companies to build a better, more secure future for employees, shareholders, customers, and partners by developing robust talent pipelines and same-day succession plans.” They immediately point out a common problem with this in the opening:

“If businesses managed their money as carelessly as they manage their people, most would be bankrupt.”

Meaningful Measurements

May 10, 2011

Measuring progress is important, as is assessing how well you are performing. The two are distinctly different, however. I wrote about assessing – or diagnosing – to determine where your pain points are (and where there are noteworthy strengths) in my post, Don’t Measure. Diagnose!

While performing well improves the rate of progress, the goal of measuring progress should be about the contribution that is being made toward the success of a larger entity. Individuals must make meaningful contributions to their team, and teams must make meaningful contributions towards a larger business goal.

Functional Managers or General Managers?

May 6, 2011

In a recent post, Agile Development: Specialists versus Generalists, I discussed the trade-offs between generalists and specialists within Agile teams, agreeing with Scott Ambler that organizations should be staffed with generalizing specialists and recommending that specialists should be in the minority relative to the generalists in an Agile organization.

What about Agile management? Should there be functional managers and direct reports organized around specialties such as database administration, software development, quality assurance, documentation, etc. in an Agile organization?

Yes, but…

Do We Need Product Owners?

May 3, 2011

David Anderson recently wrote a blog post Banish “Priority” and “Prioritization” noting that he found the words “priority” and “prioritization” no longer required with Kanban systems because, “They encourage roles/positions for people who do mostly non-value-added coordination work, and they add to the transaction costs of flowing work through the system.”

Jurgen Appelo followed up with a blog post of his own: Wasteful ProductOwners? In his post, Jurgen counters this thinking with the observation that “Managing stakeholders in a complex environment is a complex task. If we can replace the PO with a set of policies, then why not the ScrumMaster and Software Testers too? It is the ‘machine-thinking fallacy’ all over again. No wonder that some old-fashioned managers find the rhetorics of Lean thinkers appealing.”

Are Product Owners providing value, or are they unnecessary middle-men/women?

Agile Insights From a Couple of Combat Pilots...

April 29, 2011

The Inspiration for the Burndown Chart
Believe it or not, the inspiration for the Burndown Chart originated from Jeff Sutherland’s experience as a pilot in Vietnam. The corollary to software projects is that, as Jeff says, “Bad things are always happening. Things are breaking. People get sick. Software doesn’t do what you think it would do. There are issues with the hardware. There’s always something every day that’s trying to take your project down.”

Book Review: Agile Product Management with Scrum

April 26, 2011

Agile Product Management with Scrum: Creating Products that Customers Love (Addison-Wesley Signature Series (Cohn))The Foreword by Brett Queener, Senior Vice President, Products of Salesforce.com, articulates the advantages of Agile/Scrum development using product owners:

“As the chief product owner at Salesforce.com, I needed a way for my product managers to effectively connect the wants and needs of our customers and the business directly to the development teams in a highly dynamic and responsive way. Using Scrum allows us to put the product managers firmly in charge of delivering customer value. It enables them to direct the team to build the most business-critical feature first and to get them into the hands of our customers as soon as possible.”

Agile Product Management with Scrum: Creating Products that Customers Love by Roman Pichler provides a solid picture of being a product owner working in an agile context, which is definitely a collaborative affair! Early on, Pichler builds the case for teamwork, with teams being close to the customer:

“To create a winning product, the product owner, ScrumMaster, and team must develop an intimate understanding of customer and user needs, and how these needs can best be met. The best way to do this is to involve customers and users early and continuously in the development process.”

Making an Agile Adoption Stick

April 22, 2011

Studies are demonstrating that the most significant barriers to further Agile adoption are:
  • The ability to change organizational culture
  • General resistance to change within an organization
  • Management
(VersionOne State of Agile Surveys, 2008, 2009 and 2010)

My last post discussed the need for educating and garnering management support as key ingredients to improving the odds of success of an Agile adoption. In this post I’ll cover a few techniques that can help to smooth the Agile transition and make it stick (with a Scrum bias, since that is what we use). And if Agile is going to take, people have to truly understand what it is, agree to changing behaviors, and continually apply themselves to learning, inspecting, and adapting.

How to Improve the Odds of Success in Your Agile Adoption

April 19, 2011

Studies are demonstrating that the most significant barriers to further Agile adoption are:
  • The ability to change organizational culture
  • General resistance to change within an organization
  • Management
(VersionOne State of Agile Surveys, 2008, 2009 and 2010)

How can you improve the odds of success with your Agile adoption and overcome some of that organizational inertia?

Agile Development is More Than a Framework

April 15, 2011

In my last post I talked about Bruce Lee’s Jeet Kune Do (JDK) system and how it challenged the thinking of other martial artists when Lee introduced it, noting that Bruce Lee’s situation is analogous to Agile development today. Examining what occurred with Lee’s JDK can also serve as a beacon for what we in the Agile community need to watch out for in the future.

For example, during the 1980s Lee’s original chiseling away of the inessentials gave way to the excessive adding of techniques to JKD, the goal being that JKD would always have the correct counter for any given attack. JKD began evolving into less of a system to guide others in their martial arts journey, morphing into a grab-bag of techniques.

Spreading Agile: Let’s Open Minds, Not Close Them!

April 12, 2011

As a past student of the martial arts, I’ve noticed that there are some interesting parallels between Bruce Lee’s Jeet Kune Do –The Way of the Intercepting Fist – and Agile software development.

As I pointed out in a prior post, Bruce Lee on Software Development, Bruce Lee introduced a new system that was highly controversial because Lee challenged the thinking of his peers. Lee was advocating change, but this did not resonate with everyone – for more than one reason.

TDD Training!

April 8, 2011

We’ve had yet another busy week, but at least this week involved a few days of learning something new... I’m very grateful to Steve Ropa of VersionOne, who spent three long days with us providing Test Driven Development training as well as speaking at our TechMaine Agile Users Group one evening. The training was excellent, and everyone came away with a solid understanding of Test Driven Development, refactoring, and a renewed appreciation for software craftsmanship.

The Essentials of a High-Performing Organization

April 5, 2011

Do you conduct employee satisfaction surveys? Employee satisfaction is important, but it is just one building block towards becoming a high-performing organization. Being a satisfied employee is a component to being an engaged employee, which leads to greater individual performance.

The performance of engaged employees is superior because engaged employees take full responsibility for their work and go the extra mile. They are motivated and willing to apply discretionary effort towards achieving organizational success.

There isn’t, however, a single driver of engagement. People place premiums on different things, but consider how important some of these drivers of engagement are to a high-performing organization:
  • A bold vision of the future
  • Recognition of achievement
  • Being a part of a great team
  • Having control over your work
  • The opportunity to grow and improve

How to Make Recognition Meaningful

April 1, 2011

I spent most of this past week on the other side of the United States at our corporate headquarters. A majority of my time was spent in management meetings that are designed to get all of us development managers together to collaborate and learn from one another as well as become more informed about how we are doing on a variety of fronts, such as product/financial results, employee survey results, and to talk about what we need to do to improve the performance of our organization.

One area that we are focusing on is employee engagement. Since I’m an avid – and fast – reader, I loaded up my Kindle with a few books that I managed to work my way through during my flights. One of them was, We: How to Increase Performance and Profits through Full Engagement by Rudy Karsan and Kevin Kruse.

Should You Measure Teams or Individuals?

March 29, 2011

How do you measure performance? Should you be measuring performance at the team level or the individual level?

The use of autonomous teams in Agile development leads many to conclude that team is the only concern. The case being made is this: If you focus on individual goals and individual incentives, you will cause individuals to operate in ways that are counter to the collaborative teamwork that you seek.

Likewise, there are times when individuals resent having their performance strictly assessed at the team level. Sometimes people are assigned to teams late in the game, or are temporarily taken off the team to deal with a critical issue that limited their involvement with the team. Fair enough.

Resentment can surface in another way, as pointed out by Morten Hansen in his book, Collaboration: How Leaders Avoid the Traps, Create Unity, and Reap Big Results: “People working in teams can shirk and get by because individual output is not being measured, only team output.”

Morten notes that when people can hide, they often do. It’s called social loafing. People on the teams, however, know how much everyone is contributing, which is where the resentment comes into play. (The daily standup with crisp answers to the 3 questions combined with the collaborative nature of Agile teams definitely helps to address this issue.)