Happy Holidays!

December 26, 2012

It's the end of another year, and I sincerely hope that everyone is enjoying this holiday season...

As I take time off with my family, one thing that I always like to do in some of my spare time is take stock on what I've read throughout the year, to reflect on what I've read and how these books have influenced my thinking. A few of the books I read this year are actually re-reads, like The Goal (I read this a number of years ago, but it's still a great book and very applicable today).

It's always great to read books because you benefit from the experiences and perspectives of others. There isn't enough time in one lifetime to accumulate the information and wisdom that you can get from books. Granted, you need to supplement your own thinking and experience things for yourself, but I certainly like to be informed and have some things in my back pocket to try. It can save you a lot of wasted time and aggravation.

Initiate Change, but Don’t Drive It

December 19, 2012

I’ve recently been examining culture and how agile experiences can be very new experiences for many organizations. On a personal level it is all too easy to adopt the attitude that change is for “the other person” (or department, or division…). When it comes to organizational change, persistent effort over time coupled with consistency is required so that change is not viewed as another management “the flavor of the month.”

You can begin an agile adoption as “something the development teams do,” but as their understanding of agile deepens and their proficiency increases, there will be an increasing need for the rest of the organization to transform to agile. Without this transformation, your agile adoption will either be a watered down agile implementation (sorry, I couldn’t resist the bad pun) or continually at risk of being pulled back to old ways of thinking and working.

In order for lasting change to occur, we must be open to having new experiences, willing to reflect on how our current mental models just might be filled with assumptions rather than facts. We have to be willing to change what we believe. This is why I feel that it is important to initiate change instead of driving change.

Driving change is problematic because people tend to resist being changed by others. People don’t react well when change is imposed. They need to be invited into the conversation about the need for change, what the change looks like and why the change is beneficial. And they most likely will need to make changes slowly, a little at a time.

Simple Advice that Saves Time and Avoids Frustration

December 12, 2012

And it is pretty simple: Shut up and listen!

In my last post on Three Simple Questions That Foster Great Collaboration, I stated that immediately after asking one of those three questions, it was important to listen. The part about shutting up was implicit. However, I found a great TED Talk by Ernesto Sirolli titled,Want to help someone? Shut up and listen! that drives the point home.

Sirolli starts his talk with a humorous story on his well-intended, but misguided efforts he experienced in his youth to bring aid to Africa, teaching Zambian people how to grow food in what he and his compatriots found to be a very fertile valley. They were mystified that the local people had no interest in agriculture – to the point where they resorted to paying them. And even then the locals weren’t interested in showing up.

Why was such disinterest displayed by people for something that was clearly for their own good? The reason became abundantly clear one night – just as the crops had grown out perfectly and changing the, “Thank God we're here!” attitude of Sirolli and his group to one of surprise and leading them to ask, “Why didn’t you tell us?” (Watch the video to find out what happened.)

Three Simple Questions That Foster Great Collaboration

December 5, 2012

Agile development is a highly collaborative approach, both in terms of developing of the software and in reflecting on what is working and what needs improvement. And because software development also involves decision-making every step of the way (from the requirements and their prioritization to systems architecture to detailed implementation in code to tools to testing, and so on...), anyone involved with agile teams needs great interaction skills in order for teams to be great.

We need the ability to question and explore another person’s thinking, to raise issues or concerns about the team’s direction, and to constructively challenge each others’ thinking. We need the ability to have an open, honest dialog where people feel respected and safe.

Book Review:The Culture Game

November 28, 2012

The Culture Game: Tools for the Agile Manager

What is a Culture Game? How does this relate agile management?

Dan Mezick’s perspective is that every 1-on-1 interaction, every meeting, and even an organization’s corporate culture are structured as a game. There’s an important key word in that last sentence. Dan isn't focusing on the objective of winning in The Culture Game, instead he’s asking us to examine the structure.

Consider how your work environment is structured and reflect on Dan’s assessment that, “Some of these games are well-structured, fun to play, and actually stimulate the pleasure regions of your brain. Good games frequently generate feelings of control, progress, optimism, and persistence. Games that are poorly structured generate feelings of frustration, lack of control, lack of progress, isolation, and despair.”

Agile development targets these key issues, and experienced agile practitioners routinely point out that agile is a cultural change (I've been blogging about organizational culture in my recent posts). Since the ground rules change with agile, and it is best that everyone understands those rules and knows what the goal is so that everyone is playing the same game.

The Culture Game provides an excellent blend of theory and actionable tools for you to use as you transition to agile. Case in point, I discussed Dan’s expansion of the Results Pyramid in my last post, which is a critical piece of theory to understand when introducing change because, as Dan states, “All learning is change, and all change is belief-change. …People who are always learning are constantly changing their models. They have become adept at responding and adjusting to new information and knowledge as it becomes available to them.”

Adopting Agile: Seeing is Believing

November 21, 2012

As Wikipedia states, “change management is an approach to shifting/transitioning individuals, teams, and organizations from a current state to a desired future state.” The challenge is that at both a personal and organizational level, people have underlying beliefs about what it takes to be successful. For change to stick, people must be open to new experiences and new ways of looking at things, to use these new experiences to explore their beliefs and to change what they believe.

Our beliefs are shaped from past experience, and this is where we all need to be talking as agile is introduced into organizations. Resistance is encountered because agile is (in many cases) asking people to try something new that goes against what they believe is necessary to succeed in the first place. A couple of quotes come to mind (I’m paraphrasing a couple of common ones that I’ve frequently heard):

“We can’t deliver software without performing thorough, rigorous planning up front.”

“We can’t design [the user interface, the architecture, the database] without understanding the full requirements up front.”

I’m sure that you can think of many others!

A Cultural Recipe for Agile Organizations

November 14, 2012

Lately I’ve been examining the subject of organizational culture through the lens of William Schneider’s four cultures that are covered in his book The Reengineering Alternative: A Plan for Making Your Current Culture Work. The four cultures are shown in a quadrant below:

Drilling a little deeper, the horizontal and vertical axes represent dividing lines:
  • What an organization pays attention to. The content. There are two content elements: Actuality and Possibility.

  • How an organization makes decisions. The process. There are two process elements: Impersonal and Personal.

Competency and Control Cultures: A More Challenging Agile Transformation

November 7, 2012

In my last post I discussed William Schneider’s take on Collaboration and Cultivation Cultures from his book The Reengineering Alternative: A Plan for Making Your Current Culture Work and how these two cultures fit more readily in an agile culture.

This post is Part Two, covering the Competency and Control cultures.

Transforming to Agile – The “Easy Button” of Collaboration and Cultivation Cultures

October 31, 2012

As I explored in my last post, being agile is about transformation at an individual and organizational level, going deeper than simply adopting frameworks and practices. And depending upon your present organizational culture, agility will be a larger change for some organizations than it will be for others.

The reason for this is that organizational culture is defined by what the organization believes it needs to do in order to succeed, which translates into a specific mindset and a preferred way of operating. And while there usually is a dominant culture, keep in mind that traits of other cultures will most likely be present.

In this post, I’ll look at two culture types that more readily support agility than the other two – as those cultures are defined by William Schneider in his book The Reengineering Alternative: A Plan for Making Your Current Culture Work.

The two cultures covered in this post are the Collaboration and Cultivation cultures.

Assess Your Current Organizational Culture to Gauge Your Agile Adoption Effort

October 24, 2012

According to the most recent State of Agile Development Survey by VersionOne, the largest barrier to further agile adoption is the ability to change organizational culture. I believe the real question of the day centers on adoption versus transformation and how transformation can be a large cultural shift.

Mike Cottmeyer explored the issue of adoption versus transformation in a 2011 post, Untangling Adoption and Transformation. Mike’s epiphany was that adoption is focused on doing agile, concentrating on the practices that we put in place, whereas transforming is about being agile, which is all about leadership, understanding yourself and undergoing a personal transformation as a “precursor to agile software development.”

I agree with Mike, there is definitely a difference between adopting agile and being agile. That’s not to say that you won’t improve your current situation by adopting agile practices. Pair programming and Test-Driven Development are examples of technical practices that you can benefit from. Adopting Scrum as a product development framework gives control of the workday back to the employees, which should improve morale as a result.

However, Scrum and technical practices support agility, but they don’t make you agile. Practices get you started, but they only scratch the surface. Being agile is about going deeper, about viewing and approaching work that is a transformation change at a personal and organizational level.

Don’t Push Yourself

October 17, 2012

A fundamental change with lean and agile thinking is the concept of pulling work versus pushing it through a work system, whether that system is that system of you or a work environment comprised of many individuals. All too often we subscribe to notion that we must “push ourselves” to produce, to hit a pre-defined target. This sets us up for failure, particularly with complex knowledge work.

Problem #1 in using a push mindset is that we make a commitment to an up-front guess (estimate). We should be committing to the work that needs to be performed, not the estimate. The estimate is simply a gauge to inform us about the approximate size of an effort, but it doesn’t anticipate the inevitable extra work that inevitably shows up. A common countermeasure is to anticipate by buffering the estimate, which can lead to the next problem.

Problem #2 occurs when managers review the estimates. All too often they start assessing the size of the work should be – based on what is known – balancing that work with the perceived capacity and what they feel a good utilization rate should be (which tends to be on the high, optimistic side). After some “negotiation,” estimates are trimmed and the team is asked to commit to “their” estimates and the target date. (You can do this to yourself if you misjudge your own capacity and plan for too high of a personal utilization rate.)

Problem #3 is that extra, unanticipated work will find its way into those predefined tasks. This will cause tasks to go long, and the schedule will become challenged. Capacity problems are revealed! Work piles up, and managers (or yourself as the manager of you) typically counter by demanding overtime, effectively punishing the team for not meeting their “commitments.” Overtime and the negative connotations about the team failing to meet its commitments builds a contentious , us versus them relationship that can in turn lead to other undesirable behaviors, such as cutting corners so that the team can get a project “back on schedule,” despite the fact that these actions will have serious, long-term repercussions.

Leverage Personal Kanban to Introduce Lean and Agile to Your Organization

October 10, 2012

In my last post I described how I’ve recently implemented Personal Kanban to help me be more productive. I created my personal backlog, identified recurring tasks, and mapped out my value stream (the flow of work from beginning to completion) on my Personal Kanban board, following the advice I found through some quick research.

I find the term Value Stream to be particularly important; if you are undertaking some task, the underlying assumption is that there is value in your doing it. The question is: What provides you with the greatest value?

Personal Kanban helps you to assess your actual work, to visualize your own investment of time to help you determine where you are wasting energy, such as expending too much time and effort on urgent needs while those important, high-value tasks remain starved for attention.

There is another way that Personal Kanban can help you. Long-term goals take time to achieve. And because they are long-term in nature, we need to break them down into a series of small tasks – small wins – to keep up moving and motivated. As Peter Sims relates in his book Little Bets: How Breakthrough Ideas Emerge from Small Discoveries, cofounder and the former chief creative officer of Electronic Arts Bing Gordon calls this smallifying.

Meaningful Work/Life Balance through Kanban

October 3, 2012

Like a lot of people, I face plenty of urgent demands each day – both personal and professional. And like everyone else, I feel overwhelmed at times by the continual onslaught of demands and requests for my time. Lately I’ve felt that I’ve been extremely busy, but not anywhere near as effective as I should be. I was feeling unsatisfied at the end of the each day (and week).

I wanted to do more than simply suck it up; to work endless hours to finally – which never happens – catch up. What I really needed to do was to get a grip. And this meant more than checking off tasks on a to-do list. I wanted to be both efficient and effective, addressing both the urgent and the important, to make sure that I gave myself those meaningful accomplishments – whether they are of a personal or professional nature – that provide us with that satisfied, rewarding life and career.

So what’s an agile practitioner to do?

Product Review: SonicAgile

September 26, 2012

If you are looking for an online tool to manage your Scrum projects, a new tool called SonicAgile may be of interest to you. And you can try it for free for 30 days before you buy.

SonicAgile allows you to create projects and invite collaborators to that project via email. SonicAgile is designed to leverage email by notifying collaborators when a new story is added as well as posting any replies by one of those collaborators to the discussion tab of that story – a nice touch. Since we are all busy professionals, replying directly to an email to add our two cents is less disruptive than linking to another site.

The Best Invest in Their People

September 19, 2012

“The whole point of being alive is to evolve into the complete person you were intended to be.” – Oprah Winfrey
On a personal level, continuous improvement requires a growth mindset; people who believe that their qualities can be cultivated through effort over time. You will experience setbacks, but people with a growth mindset view these as indicators on where they can learn and improve, not a judgment about their capabilities. (Those with a fixed mindset view their capabilities as just that, fixed, either you have it or you don’t.)

The point is to stick with it, to continually learn and improve despite these setbacks – and in fact learn from those setbacks. As Mia Hamm once said, “After every game or practice, if you walk off the field knowing that you gave everything you had, you will always be a winner.”

At an organizational level continuous improvement is also a constant, gradual change. What leaders can’t do is reorganize a company into being a model of continuous improvement. Organizational structure doesn’t contribute to continuous learning, people do. Toyota didn’t succeed because of its organizational structures, and in fact it didn't succeed because it focused solely on improvement. Toyota succeeded because (as Mike Rother points out in the Toyota Kata) Toyota’s leaders focused on increasing the improvement capability of people.

Balanced, Disciplined and Coordinated Teamwork is Essential

September 12, 2012

In my last post I described a hypothetical situation where a startup company grew in size and created an organizational hierarchy. This is actually a common way that self-organizing systems deal with complexity. In an organizational context, work becomes organized by functional specialties, each designed to carry out specific tasks.

As the title stated, hierarchies themselves aren’t bad. From a systems perspective, hierarchies reduce the amount of information that any part of a subsystem has to keep track of. However, as part of growth and transition to a hierarchal organization, my hypothetical company lost its way. The purpose of the hierarchy shifted from supporting and helping to coordinate the work to controlling it.

Over-control constricts the subsystems – individuals and departments – from performing as well as they can. An analogy is a sports team where a coach is prescribing every action to such a degree that a player isn’t free to explore and develop his or her own strengths or unique abilities, let alone take informed, independent action on the field based on the fast-changing circumstances and realities of the game as it is unfolding – and losing the game as a result.

Organizational Hierarchies Usually Start Out Effectively

September 5, 2012

But they can transition to the “dark side,” even with the best of intentions…

Imagine that you own a small, growing company. As you grow, you hire additional staff to help you deal the work: those activities designed to delight customers and generate a profit. As you grow, the complexity of the business increases because you have more customers and more employees, so you hire people to organize things so that the majority of your employees can continue to serve the customer base.

Let’s say that your company becomes very successful and you receive an attractive offer to you sell your company. The new owners bring in professionals to manage the continually expanding enterprise, and you lose touch with the inner workings of the company because after a short transition period, you move on to “other things.” This turns out to be a small bakery, a business built around your spouse’s hobby and a desire the both of you have to own and operate a small, family-run business.

Then one day you receive a call from a long-time employee who has risen to an executive position at your former company. She tells you that the company is in trouble. She adds that she has approached the owners and they have agreed to pay you a tidy sum to have you consult with them, provided you are willing to do so.

Reflect and Celebrate this Labor Day

August 29, 2012

In America, we celebrate Labor Day on the first Monday in September – September 3rd this year. For you international readers, Labour Day might be celebrated at other times, depending upon where you live. May and October are popular alternatives.

Labor Day in America is intended to celebrate the contributions and achievements of our workers. (It also is a symbolic end of summer.) Over the years, American workers have built cities and a strong transportation infrastructure that includes highways, railways and air transportation. Workers have built tremendous companies, producing automobiles, planes, computer hardware and software. We put men on the moon and brought them back safely – an important piece of our acceptance criteria. The list is endless.

As we acknowledge the achievements of workers, we should also recognize that much as what we have accomplished in the past was done through significant effort. But sometimes we value the wrong things. Working long and hard may indicate commitment, but there are times when it can be counter-productive, like intense schedule pressure coupled with excessive overtime in software development.

Are Business Plans Obsolete?

August 22, 2012

Business planning is regarded as an important activity – as long as you don’t plan on everything working out according to plan… The objective is to think deeply about your target market, what it will take to serve them profitably along with the issues and obstacles that you may face. A business plan also serves as something that you can share with others so that they can provide you with their feedback.

Business plan templates that I was introduced to in college included things like a market analysis, an overview of the products or services that would be offered based on that market analysis, marketing and sales strategies, the organization and management of the company, and of course those rosy financial projections. But isn’t this really an attempt at predicting the future, unlikely to fit reality? And does building a business plan like this even make sense in today’s turbulent, hypercompetitive global economy?

The Real Reward of Corporate Freedom

August 15, 2012

This week I returned from a week off, and although I did respond to emails, updated a presentation, and participated on one conference call during that week off, I did manage to get some much-needed down time on my staycation.

Even though I only finished some of the home projects that I had in mind for myself, I had a good week. I managed to catch some of the Olympics on TV, I spent time reading, and – how could I forget – we added a second dog to the family so that our recently-acquired dog Sammy would have a playmate.

These days, we have a Paid Time Off (PTO) policy at my company, but it wasn’t like that when I first joined. It was a small, focused company that didn’t have any HR to speak of. We didn’t have a set vacation policy. People took whatever time off they felt they required. And depending upon your stage in life and/or whatever may be going on in your personal life, some people needed more time than others. And that was OK.

Take a Rest and Boost Your Productivity

August 8, 2012

That’s what I’m doing this week, taking some vacation time. I’m not traveling during this vacation, it’s a staycation. We have short summers in Maine, and there are plenty of outdoor activities and other attractions that can make a staycation in Maine quite enjoyable. Heck, thousands of people pay good money to come here every week for their vacations.

It’s my first real time off this year, and I find that disconnecting from the day-to-day grind to be a good thing. You need to recharge every now and then. You come back fresher and more productive. Americans are particularly bad at taking their vacation time, but it is detrimental to long-term performance and productivity.

I find this to be true in my own experience, and it is supported by a 2006 study of employees at Ernst & Young which found that for each ten hours of vacation employees took each month, their performance reviews were 8 percent higher the following year. (As reported in the book The Way We’re Working Isn’t Working.)

Support Your HEROes

August 1, 2012

“To succeed with empowered customers, you must empower your employees to solve customer problems. This is much harder than it sounds. It means your staff are going to be coming up with solutions on their own. The ideas don’t come from management; management’s new job is to support and empower employees.” – Josh Bernoff and Ted Schadler from their book Empowered.

These days, the Internet, social media and mobile technologies provide information and opinions about your products and services to consumers with tremendous ease and speed. Companies have responded to this by participating in social media and leveraging mobile tools and technologies to connect with and engage consumers.

This makes consumers are more empowered today than ever before. And while companies are doing a fine job of leveraging technology to become much more responsive to consumers, getting to the next level requires a fundamental change in how we run our businesses.

Being Agile Must Include Everyone

July 25, 2012

Agility in software development will only get you so far, particularly if an agile team exists in the midst of a non-agile organization. The surrounding system and the expectations of that system will exert a tremendous amount of pull back towards old ways of thinking and working, and even the best agile teams will be challenged to thrive under these conditions.

Most organizations today are systems-heavy, with a great deal of effort and focus on systems designed to direct and monitor activities in an effort to keep everything strictly planned and everyone “under control” and working towards the plan. Unfortunately, working the plan with the requisite reporting and approvals required in control-oriented systems negate that adaptability and rapid response to changing business conditions that organizations desire.

Are Your "Efficiencies" Creating Inefficiencies?

July 18, 2012

This week, I thought I would direct you towards an interesting post by Dan Cristo: How to Build a Company that Outlasts a City. Lesson 4 makes a great point that I would like to expand upon, and that is “Companies…tend to make employees less productive as they grow larger.”

As Dan points out, the drop in productivity is a result of organizational structures becoming too hierarchal. And he’s right. Many are. Dan observes that when we encounter structures that are too hierarchal, “Creativity and innovation are slowed down by risk assessments and business justifications. Information has trouble passing between different departments which creates confusion and rework.”

Even if you didn’t take the time to read his post, the title gives away his solution. “The key is to build your company like a city. Groups should function like little shops on the street where an employee can visit one group, then walk across the aisle to stop by another group.”

But doesn’t this create inefficiencies?

An Example of Winning Through Commitment vs Planning

July 11, 2012

Imagine that you have been asked to join a company as the CEO, a company that is losing customers to a rival firm. And it is your job to turn the tide. What would you do?

Dr. Jan Wallander found himself in this very position with Swedish bank Svenska Handelsbanken. He was invited to become CEO of the bank because he was the one running the smaller, rival bank that was winning customers from Svenska Handelsbanken. Wallander did in fact turn the bank around, and it managed to outperform its competition on a number of key measures including customer satisfaction and earnings per share.

Wallander achieved this by discarding the traditional management model that is designed for leaders to plan and control organizations from a corporate center. Wallander understood that front-line managers were more than capable of running the business – and in fact were more qualified to understand the needs of the customers and how to profitably meet those needs than those in more isolated corporate positions.

A Few Good Manifestos

July 4, 2012

Since this is the 4th of July – a holiday known as Independence Day for those of us in the United States – I thought it would be fun to look at a few manifestos other than the United States Declaration of Independence, which is a political manifesto…

According to Wikipedia, a manifesto is a public declaration of principles and intentions. The first few manifestos referenced in this post represent good intentions, with the goal of improving our present state. The last two represent what can go wrong, using satire to make a point.

Among the software community, the Manifesto for Agile Software Development (a.k.a., The Agile Manifesto) has gained significant prominence, and rightly so. Since I whole-heartedly support the manifestos I’m referencing, I took the time to do something that I’ve been remiss about, and that is to become a signatory of these manifestos. (Have you taken then time to do the same? If not, do so while you read!)

Do You Want to Engage Employees?

June 27, 2012

I recently read about an experiment where researches ran a lottery with a slight twist. (Beyond Performance: How Great Organizations Build Ultimate Competitive Advantage by Colin Price and Scott Keller.) Half of the participants were assigned a randomly numbered lottery ticket. The other half were asked to choose their own number. Just before drawing the winning number, the researches offered to buy back all of the tickets.

The researchers expected that everyone would value the lottery tickets equally, since a lottery is a game of chance. In fact, those who choose their own number had a greater potential of duplicating someone else’s number, so in reality the value of those tickets should have been less.

Unexpected things occur when people are involved, and as frustrating as this always was to Mr. Spock, emotion can trump logic. In this case those individuals who wrote their own number consistently demanded at least five times more for their ticket.

What drove people to ask substantially more for tickets where they chose the number versus those who had a randomly-selected number?

Bridging the Innovation-to-Business Gap

June 20, 2012

Many companies these days articulate (in one way or another) the desire for more creativity and innovation from their employees. What they really want are growth and profits realized from seizing new opportunities that their competitors missed or mismanaged in some way. If you take a closer look the problem, the challenge typically isn’t a lack of ideas – dig deeply enough and you’ll find people with plenty of ideas – but there is a problem with taking these innovative ideas and building them into a viable, profitable business.

What you really need is to create the conditions that not only cultivates ideas, but harnesses the entrepreneurial spirit and applies it for the benefit of your organization. Instead of following the traditional entrepreneurial route of leaving a company to launch a new venture, companies need “inside entrepreneurs” who takes the initiative to undertake something new while continuing to work for their existing organization.

Companies need intrapreneurs. Elizabeth and Gifford Pinchot coined the term intrapreneur in 1978 in an article, Intra-Corporate Entreprenuership, and their observations and recommendations made in 1978 remain solid to this day.

A Manifesto That You Don’t Want to Live By…

June 13, 2012

It’s easy to make a management misstep. The wrong look on your face at a meeting or a failure to thank someone for their efforts (yes, they were doing their job, but people like to feel appreciated) and you’ve committed a foul.

People will forgive occasional missteps and chalk them up to your being preoccupied or overwhelmed by other pressing problems, as long as you don’t establish a pattern of behavior that marks you as less than appreciative and supportive of those you are managing. If that happens, you will in turn lose the support and appreciation of those you manage, and that can put you on a downward spiral that limits everyone from reaching their true potential.

Management by Fear Isn’t an Effective Lever

June 6, 2012

In a recent post, Is Fear a motivator? I pointed out that while fear is may be considered a convenient motivational lever by some managers, “management by fear” seriously constrains organizational performance because the negative feelings and stress associated with it can cause people to literally freeze up. It can also mask problems and issues that you need to be aware of.

Bob Sutton referenced a study in his book The No Asshole Rule that was conducted by Amy Edmondson which illustrates how this can happen. Edmondson wanted to study how leadership and co-worker relationships influenced drug-treatment errors in eight nursing units. She and the Harvard Medical School physicians funding her research were at first puzzled when questionnaires demonstrated that units with the best leadership and co-worker relationships reported the most errors. Ten times as many errors, in fact!

How Do You Define Leadership?

May 30, 2012

Some people feel that because they have a title, this makes them a leader. However, the big test of leadership is in how you answer this question: Would you have any followers if you didn’t have a title?

Leaders have followers, and if you don’t have true followers, then what you really have with your title is positional authority. Following is a voluntary act. This means that leaders can exist within organizations even though they aren’t in formal positions of authority; informal lines of leadership exists where leadership is conferred on certain individuals by others, such as in recognition of knowledge and expertise in a given area.

When it comes to formal lines of leadership, people are placed in positions of authority – management roles – in order to get things done. Not just as individual contributors, but to orchestrate and leverage the collective talents of the people who make up an organization.

Changing Mindsets: One Key to Successful Organizational Change

May 23, 2012

In a recent post, Learning Organizations Require Certain Conditions, I talked about how – at a personal level – we need a growth mindset versus a fixed mindset. If your goal is to stretch yourself and expand your capabilities, you need to be willing to put yourself in new situations that a growth mindset welcomes.

At an organizational level, a significant challenge for leaders who are driving change is making that change stick. This means changing the mindsets of those in the organization, shifting thinking towards something new while overcoming that inevitable resistance. People need to accept and buy into it. Change must move past being “something new” to the “new norm.”

How do you get there?

Don’t Let Fear of Failure Prevent You from Starting

May 18, 2012

We all enjoy success and the desire to succeed over failing is definitely a motivator, but we shouldn’t let fear overwhelm us or limit our growth, either. If we are going to stretch ourselves and reach new heights, we need to push our limits -- without getting in over our heads.

There’s a balance that needs to be struck. We need to have far-reaching, motivational goals, but we shouldn’t be placing self-imposed limitations on our potential. We need to nurture our ambition to scale new mountains without reaching for too much, too soon, because being overwhelmed can cause us to give up.

You can’t make the cut from novice to expert in one leap. But you can develop expertise over a period of time through dedicated effort and coaching from others who have developed expertise. And yes, you’ll experience some failures – let’s call them setbacks – along the way. Some of those setbacks may be out of you control while others will reveal your current limitations. It is up to you to reflect and learn what you need to do to expand your capabilities to move past them. Success doesn’t happen by accident (most of the time); you need a game plan.

Is Fear a Motivator?

May 15, 2012

There are definitely some in management positions who think so. The rationale being that it keeps people focused on their jobs and doing the “right” things. If people fear the negative consequences for failing to perform, they’ll be motivated to give it their all, right?

Not from my experience. Fear may be a convenient motivational lever, but “management by fear” will seriously constrain organizational performance. Fear of failure in the workplace brings anxiety and stress that drains people of energy. It causes people to play it safe and avoid stretching themselves. Fear can contribute to failure because the negative feelings and related stress gets the better of people and causes them to freeze up.

Learning Organizations Require Certain Conditions

May 11, 2012

As I noted at the beginning of my last post, Principle 14 of the Toyota Way states that become a learning organization is achieved through relentless reflection (hansei) and continuous improvement (kaizen). What does it take to make reflection and continuous improvement work?

There are conditions related to personal and organizational dynamics that must be in place to foster learning. For a start, people and organizations have to want to improve, which means being able to take an honest, realistic look in the mirror.

At a personal level, people need a growth mindset versus a fixed mindset. People with a fixed mindset tend to believe that “you are who you are” and there isn’t much that can be done to change that, whereas those with a growth mindset believe that people can change – substantially, if they so desire. Another important distinction to understand is that people with a fixed mindset react to setbacks differently than those with a fixed mindset.

The Toyota Path to Competitiveness

May 8, 2012

Principle 14 of the Toyota Way states: Become a learning organization through relentless reflection (hansei) and continuous improvement (kaizen).

How much do you reflect as an individual? How about as an organization?

Time for reflection is definitely scarce in most organizations. In his book The Way We're Working Isn't Working, Tony Schwartz quotes Harvard psychologists Robert Kegan and Lisa Lahey, who observe that, “We are already the most overinformed, underreflective people in the history of civilization.” Schwartz argues that, “The relentless urgency that characterizes most corporate cultures undermines creativity, quality, engagement, thoughtful deliberation, and, ultimately, performance.”

He’s right. These days we’re continually pressed for time, with little to no time remaining to reflect. We’re doing more with less – and this at times this means more than just doing more with less people, it means that we’re doing more with less thinking about what we're doing now, let alone reflecting on what has already transpired or how we could approach what we're about to do differently. As the Toyota Way articulates, reflection is a key aspect of become a learning organization. The lack thereof will impact us individually as well as challenge the long-term viability of our company.

Book Review: Scaling Lean & Agile Development

May 4, 2012

Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum
If you are looking for a book that discusses why it is more important to be agile than to do agile, this book is for you! Scaling Lean & Agile Development covers both the theory that supports Lean and Agile thinking along with practical advice on what to “try…” and “avoid…”

It is difficult to justice to a comprehensive book in a short review, but Larman and Vodde did an excellent job of combining their experience with extensive research to provide a comprehensive look at why Lean and Agile works and what it takes to change.

For example, thinking that Lean and Agile is only for developers, “…leads to no real change and no real result, and the eventual predictable abandonment of lean principles or agile development because ‘that doesn’t work.’” In fact, “it is vital to appreciate that organizational agility cannot be achieved by a development team in isolation—it is a system challenge for organizational redesign.”

Larman and Vodde go on to explain: “If an engineering team has the technical capacity to adapt or change quickly, but requirements management, legal practices, product management, HR policies, site strategies, and deployment processes all emphasize rigidity, conformance to original plans, conformance to the status quo, and slow practices, then how can there be real agility?”

The Elegance of Scrum as Defined by BART Analysis

May 1, 2012

Not all adoptions begin with ideal staffing. At one point in time I was both a development manager and a Product Owner for one of our teams. Was this ideal? No. Does something like this happen in real life? Sure.

If you choose to operate where there is role overlap, make sure that you are clear about what role you are “playing” when dealing with questions or issues. For example, as a development manager it was fair game for me to discuss the design and implementation of the code with developers on the team who sought out my advice, but not so if I was operating as a Product Owner. I always called which hat I was wearing before diving in.

I made sure that I did because I didn’t want to cause confusion later, when we found a dedicated Product Owner for the team. I understood the boundaries, authorities, roles and tasks (BART) that should be respected for proper execution of the Scrum framework, and I wanted the team to understand them as well.

Agile Teams Need to Guard Against Self-Mismanagement

April 27, 2012

Scrum is an excellent framework that provides a team with the requisite structure to address the complexities and challenges of software development while remaining completely open in terms of defining what the product is and how it will be implemented. A key tenet with agile and Scrum is that the team is in control of their work, and a framework like Scrum provides the necessary guidance for teams to coordinate and manage their work without being directed by someone else.

As simple as a framework like Scrum sounds, execution is harder than it appears. One danger is that people start adapting Scrum to meet their current ways of working instead of changing the way that they work. For Scrum to be of value it is important to look beyond the mechanics of the framework and embrace the Lean and agile thinking and approach to work.

Improve the Flow, Don’t Interrupt It

April 24, 2012

Agile development teams exist for the most part in non-agile organizations, and all too often there are too few who understand the implications of this and how well-intended actions actually work against the mindset and techniques of agile development. This can lead to a watering-down of agile (Waterfall/Scrum hybrids come to mind) and a reduction in the benefits obtained as a result.

From a management perspective, agile development should not just about autonomous teams doing their “thing” independently. Those autonomous still need management support – but in a different way. Autonomous teams should be focusing on improving the flow of value to the customer and you as a manager should be supporting those who have direct responsibility for that delivery.

Agile development seeks to eliminate or reduce overhead while using tools and techniques that improve – or at least maintain – professional discipline to drive long-term productivity gains. Agile teams need to work be “in the flow” as much as possible to improve productivity, taking input from customers and internal stakeholders and converting that input into a valuable outcome for the least amount of effort expended. As a manager you must guard against doing two things: interrupting the flow and impeding the flow.

A Quick Example on How Going Slower is Faster

April 20, 2012

If you’ve ever been challenged to explain why you should consider adopting agile development, one good reason is that agile development – executed properly – focuses on all aspects of software development, from delivering value to technical excellence. This includes performing work that too often gets short-changed under intense schedule pressure: refactoring.

(This is an admittedly simple example, but it illustrates how focusing on feature delivery at the expense of looking at the big picture can hurt you in the long run.)

Let’s say that you are in a race. Both you and a competitor are vying to dominate a market with similar applications, and you are both starting from scratch. You are an agile development shop and your competitor isn’t; for them, cranking out the features is everything.

The picture below shows that your competitor establishes an early lead…

Don’t Hit the (Software) Wall!

April 17, 2012

Since the Boston Marathon was run yesterday, I thought this would be an appropriate metaphor.

Imagine running a 26.2 mile race… It’s a long race, but you’re prepared. You’ve run 20 miles every Sunday along with hill workouts and a variety of other distances during the rest of each week to be in the best shape possible. You start the race a little faster than you anticipated based on your split, but you shrug it off. You feel comfortable, so you keep going. You even ignore the early water stations. It’s a crisp, fall day, so heat is not a factor. Everything is in place for a great run.

Almost. The events described above were real. They happened do me. And I should have done things differently. I should have backed off my early pace when I got my split. I should have been taking in water. But when you are young and stupid (I was 20 years old at the time)…

I hit the wall. I started feeling odd at 18 miles, and by mile 20 I was done. The loss of energy and fatigue was sudden, and I had NOTHING left. I walked the remaining 6 miles, trying to find the strength to run every now and then, but I couldn’t. I finished in the middle of the pack, disappointed that I had run myself into the ground. I knew better, but in the moment of the race I thrust common sense aside and went for it.

Despite knowing better, organizations routinely run into the software wall all the time. We’re guilty of approaching work in the same way that has proven not work more often than it does, but expecting a different result.

Being Agile is Being Efficient and Disciplined

April 13, 2012

Is agile development chaotic and undisciplined, as some would assert? It shouldn’t be. However, using frameworks and practices don’t make you agile in and of themselves. They support agility, provided that you have the right mindset and approach to your work as you make use of them.

I’ll examine the following (briefly) in this post:
  • Scrum
  • Test-Driven Development
  • Pair Programming
A huge change with agile development is that teams are self-directed. Scrum is a great framework for teams to use to manage their work, provided that teams genuinely collaborate and actively manage their work. This means more than adopting the practices, vocabulary, and artifacts of Scrum. “Doing Scrum” without an agile mindset is also known as Cargo Cult Scrum, which is the mistaken notion that ritualistic actions and artifacts will provide magical benefits. Trust me, magic is not going to happen all by itself!

Software Development Workflow Shouldn't Mirror its Phases

April 11, 2012

(My apologies for posting a day late, but I’m in one of those cycles where I’m generating content just-in-time instead of having a good backlog ready. I paid for it this week, as I ended up very sick Monday evening and wasn’t able to make a Tuesday post.)

In the future, we won’t need to program computers. They will program themselves to perform whatever tasks we ask them to perform. Until that day arrives, we’re faced with doing things ourselves. So for now, we need to generate value by flowing through the standard development phases as quickly and easily as possible. With agile development we target delivering potentially shippable software at the end of every sprint, but NOT by working in a linear fashion:

It’s tempting to reduce work to its constituent parts and have specialists complete each phase in strict, gated phases where we sign off on the work before beginning on the next phase. We have evidence to support this approach, including studies that show how the relative cost to find and fix defects increases substantially at every phase.

Adapt and Improve Your Way Into Being a Competitive Force

April 6, 2012

As part of my Maine Agile User Group talk this week, I referenced a quote from management guru Peter Drucker that you don’t typically see or hear:

“Productivity means the balance between all factors of production that will give the greatest output for the smallest effort. This is quite a different thing from productivity per worker or per hour of work…”

This quote comes from his book, The Practice of Management, originally published in 1954. Unfortunately, another one of his quotes, “what gets measured gets managed,” is used and abused all too regularly.

As you can glean from the second sentence of Drucker’s productivity quote above, he was cautioning us about emphasizing the wrong things – and as the Principle of Suboptimization tells us – optimizing each part independently will not lead to an overall system optimization. In fact, it can worsen it. We need to be very careful about what we’re measuring and what behaviors we are driving with those measurements.

We’ve Been Approaching Things in the Wrong Way

April 3, 2012

Agile development is all about using multi-disciplinary teams to continuously deliver working software in the form of business features at the end of every sprint or iteration. This means prioritized features, not horizontal architectural layers. By that I mean that we don't build out all of the layers up front in one shot, speculating on what we might need to have in place to support future business features. We design and build what is required for the features that we are working on today.

Likewise, the merits of the empowerment model espoused by agile development have been known for some time in the business world, albeit largely ignored. Most organizations today strive for central control and compliance, whereas an effective empowerment-oriented management model assumes that those on the front line can not only call their own shots effectively, but are better able to respond more rapidly to changing competitive conditions.

The right management model requires that front-line teams have autonomy and critical information available to them to make effective decisions. There is a need to invert the organizational pyramid – or at least tip it on its side – so that business units who are focused on profitably serving and satisfying customers’ needs are being informed and supported by a leaner organization that is not imposing onerous reporting and control mechanisms on the rest of the organization.

Leadership Agility: Transforming Problems into Results

March 30, 2012

My last post discussed reflective action from the book, Leadership Agility by William B. Joiner and Stephen A. Josephs. Reflective action is a leadership agility skill that guides you towards making better decisions, engaging in action, and then evaluating – reflecting – on what you’ve learned so that you develop as a leader.

As the book points out, if you are leading in a rapidly changing, complex business environment, you will be facing ill-structured problems. A key challenge for leaders in these situations is that solutions to these problems aren’t predefined, nor will they have one right answer. You will be working with incomplete information and evaluating a number of plausible solutions that will require what the authors called creative agility.

Creative agility is a combination of critical thinking skills and breakthrough thinking that generate “uniquely appropriate responses that transform these ill-structured problems into desired results.” Your creative agility is supported by two capacities:

CONNECTIVE AWARENESS: The ability to hold various ideas and experiences in mind, compare and contrast them, and make meaningful connections between them.

REFLECTIVE JUDGMENT. This capacity refers to the way you determine what’s true and what is the best course of action for solving ill-structured problems – and to the way you justify these views to yourself and to others.

Develop Your Agile Leadership Skills with Reflective Action

March 27, 2012

In today’s turbulent business climate, leaders are facing complex problems. A leader’s ability to successfully navigate continually changing, uncertain waters requires continual reflection and improvement. A great resource for developing your leadership capability can be found in the book, Leadership Agility by William B. Joiner and Stephen A. Josephs.

In their book, Joiner and Josephs state that, “At its core, leadership agility is a process of stepping back from your current focus in a way that allows you to make wiser decisions and then fully engage in what needs to be done next. We call this core process reflective action. Reflective action is both the essence of leadership agility and the best way to develop it.”

Being Agile: Preparing a User Group Talk

March 23, 2012

I’m preparing for a talk for our next Maine Agile User Group meeting on April 3rd, and I’ve decided that my topic will be: Being Agile versus Doing Agile. My goal is to convey an understanding of what it means to be truly agile. Early on, one of my slides asks:
  • Is Scrum agile?
  • Is TDD agile?
Friend and colleague Paul Corriveau recently answered this question in a blog post, Scrum Is Not Agile. I’ve had many conversations with Paul about agile, and we’re always looking to learn more and apply that learning, so it is no surprise to me that his post is consistent with my thinking. As Paul points out, building good software takes more than “process magic.” It takes effort and discipline to change your thinking and your approach to work in order to improve from where you are today.

Are You a True Servant Leader?

March 20, 2012

As a leader, are you adding value to your people? Without being a burden, that is?

In this age of autonomous, collaborative teams, true servant leaders need to ask themselves just that. At least as a starting point. I submit that the real answer to this question needs to come from those that you are serving, and not from within.

This question is important because the problem with the traditional, command-and-control model of management is that employees have to contend with overhead to provide a flow of information about what they are doing – and knowledge workers are the ones who know most about what they are dong – to others in management so that these managers can “direct” the employees more effectively.

And the overhead changes every time there is new leadership. Employees are continually contending with providing reports and information tailored to the preferred format of whoever is requiring the information. The unfortunate part about this is that too many management decisions are made with distorted information from offices or conference rooms that are at least once-removed from where the real action and day-to-day decisions are being made.

Is the Scrum Framework Lacking?

March 16, 2012

What does it take to succeed with agile? When we first started with agile development, we a sent a couple of people to an agile conference, and they returned with advice from others that we should expect to take about “two years to get it right.” We shook our heads and wondered why. After all, we had selected Scrum as our framework, and it seemed simple enough.

As we discovered, there is some real change lurking beneath that simplicity. The current Scrum Guide states that Scrum is:
  • Lightweight
  • Simple to understand
  • Extremely difficult to master
Adopting agile means more than adopting a simple framework, it means adopting a different way of working and interacting that involves some very real change. It is the change that is difficult to master, not the framework.

If You Are Afraid of Losing Control, Try This Experiment…

March 13, 2012

As VersionOne’s State of Agile Development Survey reveals, a couple of the greater concerns about agile development are expressed as management concerns. Management opposition being one and a loss of management control the other concern.

Management that lacks prior experience with agile won’t be familiar with, nor comfortable with, the autonomy and the inherent trust that comes with autonomy. Unfortunately, both autonomy and trust are required to be truly agile. The challenge for management is that most companies recognize that they need greater engagement from their employees; they need people who will think and act with a greater understanding and ownership of their work.

The dilemma is that while adopting agile and its use of autonomous teams can help to create the very conditions that result in having more engaged employees, there is concern that, “It won’t work for us.” Is there a way to test the waters without making a leap of faith? One that allows you to directly witness the power of autonomy unleashed to its fullest potential, in the context of your own environment and people? You bet there is.

It’s Not About Efficiency, It’s About Resiliency

March 9, 2012

“Most white-collar workers wear white collars, but they’re still working in the factory. They push a pencil or process an application or type on a keyboard instead of operating a drill press. The work is planned, controlled, and measured. It’s factory work because you can optimize for productivity.” – Seth Godin, in Linchpin

Seth Godin is urging us to become indispensable, original thinkers; those who are difference-makers and not commoditized, low-paid workers who are easily replaced. A great many organizations deliberately plan for efficiency and reliability by breaking work into distinct, specialized pieces that can be performed routinely, but there is a downside to “optimizing for productivity” in this way.

For today’s post, I’ll point you towards my guest posts on VersionOne’s Agile Management Blog, where I discuss a significant benefit of being agile: Organizational resilience.

The Agile Resiliency Factor: Part 1 of 2
The Agile Resiliency Factor: Part 2 of 2

“In Agile We Trust”

March 6, 2012

Being an agile organization is a major cultural shift from the way many organizations manage today, which can be broadly summed up as being plan-driven by a centralized, command-and-control structure that relies on a heavy dose of reporting. And while this model works, it is proving cumbersome, costly, and unable to adapt quickly enough in today’s turbulent business climate.

It’s not uncommon to hear senior executives express deep concern about the lack of employee engagement (which collectively costs U.S. companies hundreds of billions annually in terms of lost productivity) and the need for commitment and results from people because “they are our greatest asset.” Yet companies continue to manage in ways that say, “I don’t trust you” to the very people on the front line who are responsible for – and should be trusted – to conduct business with and for a company’s customers.

While there are many who will assert that they are using a “trust, but verify” model, companies expend a great deal of time and effort in reporting and oversight that is geared towards compliance – along with imposing serious constraints on what those on the front line can and can’t do without centralized approval. Even with information systems designed to facilitate the approval process, it’s still a cumbersome, inflexible and slow system that siphons time and attention away from delighting the customer and maximizing the value that the entire organization brings to the customer.

Worse, some companies manage solely “by the numbers,” creating a “management by fear” climate in the name of driving accountability. Don’t make your numbers and you’re history…

Strive for Excellence, not Perfection

March 2, 2012

Our mental models can get us into trouble. For example, managing very dynamic, highly variable efforts like software development though a series of crisp, well-defined, sequential phases seems to be very – to quote Mr. Spock – “logical.” Yet as many of us can attest, more often than not this logic breaks down rather quickly in actual practice.

The arguments for a sequential approach are sound, at least on the surface. You define your requirements, do your design, implement that design (code), and then verify (test) that everything is correct. Everything is in a nice neat, orderly, logical sequence of events.

What makes everything work well is the perfection of the outputs from each phase. The better execution you have in one phase leads to greater efficiency and effectiveness in downstream phases. In fact, studies have proven that finding and correcting problems (defects) increases significantly the deeper into the development phases you go:

What breaks down, and what can we do about it?

You Don’t “Do Agile”

February 28, 2012

Sometimes we get into right things for the wrong reasons. Like Agile development. I bet there is more than one organization out there that adopted Agile development expecting certain benefits, like delivering software faster, and with fewer defects; or having more engaged – and productive – employees through the use of autonomous teams.

It’s not that these benefits aren’t possible – they are. But they aren’t what it means to be agile. A framework like Scrum or practices such as Test-Driven Development and pair programming can be classified as just that, agile practices, but the practices themselves aren’t agile. It is more accurate to state that they support agility…

How Game Companies Deliver with Agile

February 24, 2012

Not getting everything you expected from agile development? Do you feel that creativity and collaboration are problems? Perhaps some tips of the trade from game development companies will help.

If you haven’t seen it already, I highly recommend that you read a recent SD Times article, What games can teach enterprise developers, by Alex Handy.

In the article Handy quotes Randall Ward (cofounder of Appfire Technologies), who says that he can tell a lot about a development shop by looking at the offices. “…making your environment fun to work in is something enterprises can learn from game companies,” he says.

What is Productivity?

February 21, 2012

In a great article, Management Myth #1: The Myth of 100% Utilization, Johanna Rothman asserts that, “Too many managers believe in the myth of 100% utilization--the belief that every single technical person must be fully utilized every single minute of every single day.”

She’s right. As Johanna points out in the article, utilizing people is a very different thing from utilizing computing resources. People are supposed to be thinking, which leads to better outcomes, new ideas, and a more successful organization. This begs the question: What is productivity?

The State of Agile Development

February 17, 2012

I’m always interested in State of Agile Development Survey by VersionOne, particularly in the contrasts between the reasons for adopting agile and the actual benefits obtained. According to the survey, the top 3 reasons for adopting agile were:
  • Accelerate time to market
  • Manage changing priorities
  • Increase productivity
The top 3 benefits obtained from implementing agile were:
  • Ability to manage changing priorities
  • Improved project visibility
  • Increased productivity
Close, but the #1 benefit of accelerated time to market didn’t make it into the top 3. Improving project visibility is a good thing, but the ability to accelerate time to market was actually #5 on the list of benefits achieved, falling short of the hoped-for #1 reason to adopt agile. Why?

Set Your Sights on More than Raving Fans…

February 14, 2012

Customers are great to have, but as Ken Blanchard points out in his book Raving Fans, "If you really want to 'own' a customer, if you want a booming business, you have to go beyond satisfied customers and create Raving Fans." In the globally-connected, social media world of today, raving fans are a tremendous asset.

The Internet, mobile technology and social media combine to create a fast, easy, global reach for your ravings fans as they rave about your products or services. And they do so in ways that traditional marketing can’t touch! There’s nothing like delighted customers promoting your products and services to potential prospects and turning them into actual customers.

But you can do more.

Sprint Zero: Don’t Waste Your Time

February 10, 2012

Is there such a thing as a Sprint Zero in Scrum? Should there be? After all, don’t teams need to decide on the tools that they’re going to use and set up important things like version control, build machines and app servers so that they can be productive during sprint work? One thing is for sure, we don’t have a shortage of opinions on the subject!

Ken Schawber flatly declares that “There is no such thing.” Ron Jefferies provides a balanced perspective at Scrumdevelopment@yahoogroups.com:
It's probably a good idea to get your computers set up before trying to write software, for example. It's probably a good idea to have at least a fair vision of what you are trying to build. It is probably not a good idea to define a lot of architecture and IMO it is almost certainly not a good idea to install your database and schema.

I do, however, object to calling those activities Sprint Zero. Here is my reason:

It is a core principle of Scrum that every Sprint must produce an increment of potentially shippable software.

Therefore, an interval of time which does not produce an increment of potentially shippable software is not a Sprint.

Therefore such a time interval should not be called a Sprint. It doesn't do what a Sprint does.

The Ultimate Brand Metric

February 7, 2012

The American Marketing Association defines a brand as a "Name, term, design, symbol, or any other feature that identifies one seller's good or service as distinct from those of other sellers." When a brand becomes well known, it is said that a company has achieved brand recognition.

A brand is distinctive, and when you do something really well your brand communicates your essence, your purpose. For many years when mainframe computers the only computing option and involved large expense and risk, there was an old saying that, “No one ever got fired by buying IBM.”

There was an underlying message about the IBM brand that IBM would stand behind its customers in ways that other companies would not or could not. This wasn’t just marketing hype, either. It was a very real, cultural belief in IBM that customers mattered and that those customers could in turn count on IBM. IBM delivered on the promise of its brand.

Genius is in the Fundamentals

February 3, 2012

I don’t know how this year’s Super Bowl will turn out, but being from New England I’m naturally rooting for the Patriots. And I’ll admit that the New York Giants certainly give me reason to worry… However, it should be a great game!

This will be Tom Brady’s fifth Super Bowl appearance, an indicator that he’s been playing at an elite level for quite some time now. What does it take to be one of the best? Apart from his incredible work ethic and constant study of the game, Tom Brady focuses on a superb execution of the basics.

In his article Tom Brady still listens to QB whisperer, Tim Graham talks about how Brady recognizes the need for solid mechanics and works on them constantly. Interestingly enough, Brady still relies on Tom Martinez, his personal throwing coach since before he ever made his first junior varsity start.

You Don’t Have to be First to Market…

January 31, 2012

As long as you are the best.

For example, MySpace was first to market, generating an incredible following and was by all standards a huge success – THE player in what we now know and love as social media. MySpace was purchased by News Corporation and had all the advantages of professional management and financial backing to guide and fuel its continued growth. In effect, the social media market was MySpace’s to lose. And lose it did. To a company called Facebook launched by some college undergrads.

Why? Because while MySpace was an innovator, it wasn’t a leader. MySpace captured a sizeable market share by being first with a great idea – validating the existence of a market – but it failed to capitalize on its first-mover advantage. Instead, Facebook took the lead in truly learning about what customers wanted and adapting its offering, eventually taking the lead in market share.

The Many Faces of Innovation

January 27, 2012

In my recent post Charting a Course for Corporate Success, I outlined three, broad categories of innovation:
  • Disruptive, Breakthrough Innovations.
  • Sustaining, High-Value Change.
  • Everyday Creativity and Emergent Innovation.
When it comes to leading businesses, it is important that we don’t just come up with new things; we need to innovate in ways that create value for our customers. As research by Robert Wolcott and Mohanbir Sawhney demonstrates, there are many different ways that business can innovate to achieve this outcome. They came up with twelve dimensions of innovation that we can consider:

The Value of Business Focus

January 24, 2012

The essential, underlying aspect of your company’s strategy is its distinctive competence and the perceived value of this competence by your customers. You need to articulate your purpose, and this requires a strong focus.

A great example of exquisite focus is found in the book, Good Strategy/Bad Strategy by Richard Rumelt. While I personally lack experience in manufacturing, I can certainly appreciate the example of Crown Cork & Seal and its brilliant strategy crafted by John F. Connelly in the 1960s.

Charting a Course for Corporate Success

January 20, 2012

At a time when corporate survival rates are declining, what do companies – and leaders in particular – need to do to chart a course when maps aren’t readily available? You can’t “cut your way to glory” – at some point businesses need to innovate and grow. But how do you evaluate what the right direction is for your company? Where should you focus?

This is a difficult challenge, and unfortunately, there isn’t a step-by-step cookbook available to solve this problem. I’ve culled together advice from several sources to aid in charting your own course to success. Fair warning: This isn’t a process, just a framework for thinking that provides a little orientation. I’ll admit that is a lot easier pulling this information together than applying it; the hard part is involves thinking deeply about your own situation.

Book Review: Steve Jobs

January 17, 2012

I have to say that this book had me believing that I would dislike Steve Jobs because he came across as a spoiled (crying when he didn’t get his own way), arrogant tyrant to work for, a harsh and insensitive individual to be friends with, and a man who was distant and neglectful towards his family. However, Walter Isaacson balanced this view of Steve Jobs with a detailed treatment of the qualities that made Steve Jobs great.

3 Sets of Agile Questions

January 13, 2012

With Scrum, there are three questions that each team member answers in the daily standup meeting:
  1. What did I do yesterday?
  2. What am I planning to do today?
  3. Do I have any impediments?
These questions target the day-to-day work, but are there questions that can and should be asked as teams conduct a sprint review or a retrospective? Yes. And the right questions are a different set of questions that should explore the value that teams provide their company and the customer.

Overcoming Monkey Business

January 10, 2012

In the self-managed environment of Agile development, managers can come away feeling like they have a lot less to do. After all, management no longer directly assigns and monitors the work, right? A natural follow-up question might be: with autonomous teams, why do we even need managers?

Autonomy should never mean hands-off. Even autonomous teams need a helping hand every now and then. Remember the old saying reminding us that someone, “Can’t see the forest for the trees”? We all can get so involved with the details that we lose sight of the bigger picture. Managers happen to be in a great position to provide a broader perspective to teams that can contribute to more effective day-to-day decision making of the team.

I came across another piece of information to consider in Mike Rother's book, Toyota Kata. In it, Rother cited a research paper on continuous improvement at Toyota written by Professor Koichi Shimizu of Okayama University, which contrasted improvements carried out by production operators (via quality circles, suggestion systems, etc.) and improvements carried out by team leaders or supervisory staff.

Leadership, Management, and Self-Management

January 6, 2012

I view the basic distinction between leadership (“doing the right things”) and management (“doing things right”) as being fundamentally correct, albeit oversimplified. Various forums have raised the question of management versus leadership, with differing opinions on whether one person can be both a manager and a leader. Does this question change in an Agile context?

I believe so. With Agile, traditional lines between leadership, management, and working professionals are blurred. This is not a bad thing, but it is a different thing.

Agility is the New Standard

January 3, 2012

Agile development has been increasing in popularity in recent years, and depending upon who you listen to, the following scenarios are possible in the near future:
  • The foothold Agile has obtained in many organizations will spread beyond software and IT, gaining acceptance in other areas of the business.
  • There will be an increase in failed implementations, with a subsequent backlash against Agile.
  • The term Agile will cease to be used to identify any set of practices; it will simply be THE way that we operate.
I think all of the scenarios are possible; the first two are really about the expansion and growth of enterprise agility and in 2012 I believe that we will see a heightened interest and activity with the rest of the business incorporating Agile practices, mostly out of necessity.