Reflections on 2010

December 31, 2010

Like every year, nothing went completely as planned. This blog is part of my own professional development exercise, and during 2010 I doubled the frequency of my posting from once per week to twice per week. (I’m NOT planning on doubling again in 2011!) I’m continually examining my writing style and thinking about software leadership, and I’m continuing to take new information in by reading other blogs, articles and books.

Scrum Isn't a Spectator Sport! Part Two

December 28, 2010

This is my second post about the need for active participation in order for Scrum to be successful. Part One discussed some the changes involved with managers and how managers can support Scrum teams. This post discusses the changes that individual contributors need to make as participants on a Scrum team.

Merry Christmas!

December 24, 2010

Scrum Isn't a Spectator Sport! Part One

December 21, 2010

Scrum is a motivating work environment that improves productivity, but…

Scrum needs active participation and involvement! As a manager, this participation is about taking the time to learn about what Scrum is really all about and changing how you operate.

Some managers have a hard time resisting the urge to assign tasks and direct the team; it takes effort, discipline and a willingness to let go and even allow others to call you on your command-and-control behavior. Instead of changing, some managers continue to direct and assign work to individuals, disrupting teams and causing the process to fail.

Other managers go through the exercise of empowering a team and stepping completely back. But they do this with their fingers crossed. They wave goodbye to the ship (team) from the dock and hope that they return with a hold full of treasure – with the plan of “holding them accountable” if they don’t and reverting back to their comfort zone of highly directed teams.

I'm sure other scenarios come mind.

What these scenarios miss is the part in the middle: the part about management changing into a collaborative, supportive management model. The team needs to get the work done, and it’s your job as a manager to help the team reach its goals.

Book Review The Leader’s Guide to Radical Management

December 17, 2010

The Leader's Guide to Radical Management: Reinventing the Workplace for the 21st CenturyAs an Agile practitioner, I was interested in Stephen Denning’s new book, The Leader’s Guide to Radical Management. Denning discussed his objective as being one to discover workplaces “… where work is highly productive, new ideas are embraced, and jobs are deeply satisfying.” Denning admitted surprise when he noticed that an unusually high proportion of these experiences came from software organizations.

Is Delegation Obsolete with Autonomous Teams?

December 14, 2010

Agile development makes use of autonomous teams. We use Scrum, and this means that work should be negotiated between the team and the Product Owner. This also means that managers shouldn't be assigning tasks to individuals. As far as autonomous teams are concerned, is delegation obsolete?


The Art of Delegating

December 10, 2010

There is one thing that becomes painfully obvious to anyone once they spend a short amount of time in a management role: you cannot do everything yourself. Your universe expands and you quickly realize that you can’t do all of the work. You need to delegate.

And whatever you do, don’t micromanage! If you do, you own the work, not the employee. And you will own it for all time. Anything related to that work will come back to you.

Are You Overcommitted?

December 7, 2010

Do you feel stretched thin, with too many requests and too little time? If so, you may need a “yes diet,” or at least some re-direction of your "yeses."

Saying “yes” to every request is a sure-fire way to clutter up your day. Sometimes, people say “yes” to avoid a difficult conversation, or because they are already strapped for time to complete some other task that they said “yes” as a quick and easy way to out of a conversation so that they can get back to their other task(s)…

What are your options?

Critical Thinking Applied: Crap Detection

December 3, 2010

We're all faced with decisions each and every day. We are being sold, persuaded, or pressed into making a call. In these situations, critical thinking helps to shape your understanding of the arguments being presented, functioning as crap detection.

Crap doesn’t require detection when it is out in the open, all by itself. It’s far less obvious when it is packaged in some way. Naturally, some people are much better at packaging than others.

Software Construction is Fast and Easy

November 30, 2010

Do you consider design and development to be different activities? If your thought process is along the lines of, “Our design is complete, now it’s time to start construction!” – with construction meaning programming – you’re being trapped by the construction metaphor. Here’s why.

Giving Thanks for Scrum

November 26, 2010

The Leader’s Guide to Radical Management by Stephen Denning, is an excellent, well-written book that I found particularly interesting because Stephen talked about his objective being one to discover workplaces “… where work is highly productive, new ideas are embraced, and jobs are deeply satisfying.” Stephen admitted surprise when he noticed that an unusually high proportion of these experiences came from software organizations.

As Stephen looked deeper, he “…discovered a way of managing that was much more productive than traditional management and where the people doing the work were having serious fun.” His results were documented in his book.

And what is the secret? In a word: Scrum.

A Manager’s-Eye View of TDD

November 23, 2010

Although we haven’t tried Test-Driven Development (TDD) at my company yet, I expect that sooner or later, one of our teams will want to. This post is about head-checking my current understanding of TDD with you, and asking those of you experienced with TDD some questions along the way.

Just to be clear: My goal is not to understand Test-Driven Development so that I can mandate it. I want to be prepared so that I can have intelligent conversations with my staff about it as well as have reasonable expectations about what it will take to adopt it.

An Agile Story: Progress versus Success

November 19, 2010

Mitch Lacey has an interesting presentation from Tech-Ed Europe, Working Software is Not Enough! that is long (about 60 minutes), but well-worth your time.

One of the twelve Agile principles is that working software is the primary measure of progress, but Mitch asserts that he and his team were wrong in believing this. After viewing the presentation and listening to Mitch, my take is slightly different.

The Benefits of Pair Programming

November 16, 2010

In my last post, Results through Pair Programming, I took a quick look at what pair programming is, and noted that there are two flavors:
  1. Collaboration with driver/navigator roles, splitting responsibility for the tactical coding and strategic aspects.
  2. Collaboration by sharing and dealing with the tactical coding and the strategic issues together.
Purposeful collaboration is the common component in both cases; pair programming is not about someone looking over your shoulder and making comments like, “Oh, you missed a semi-colon!” The compiler can do that job, and quite frankly, that would drive me nuts.

Results through Pair Programming

November 12, 2010

When you hear the term Pair Programming, what thoughts come to mind?

Let’s talk about the elephant in the room: As a manager, does pair programming conjure up thoughts of paying two people to do the job of one?

Why Processes Ultimately Fail

November 9, 2010

“Just follow our ABC process, we guarantee success!”

How many times have we heard that one? In a world where there is relentless pressure to deliver, the hope of a guarantee is attractive. And to be fair, the various software development methodologies out there certainly aren’t snake oil; they have every intent of helping organizations to be successful. Yet things still go wrong.

Do You Value Innovative Risk-Takers?

November 5, 2010

“Pearls don’t lie on the seashore. If you want one, you must dive for it.” – Old Chinese Proverb

Once upon a time, I worked for a company whose message to us employees was, “We value risk-takers.” It was clear from this oft-repeated message that our senior management team understood that achieving greater growth meant that playing it safe – always seeking to avoid failure – equates to missing opportunities.

I was a couple of years out of college at the time, and it was exciting to be working for a profitable company that wanted to continue its successful streak. I was intrigued to see how this valuing of risk-takers would play out.

Catalysts, Inhibitors, and High-Performing Teams

November 2, 2010

As a manager in an Agile development shop, I find that an important consideration when staffing our self-organizing teams is to answer the question, “Who is the catalyst on this team?”

Accountability in Action with Self-Organizing Teams

October 29, 2010

My last post discussed Accountability and Self-Organizing (Scrum) Teams. In our years of Scrum development, we’ve managed to get some things right and some things wrong. Our biggest problem area seems to be drift – we start out fine but gradually drift back into old habits.

Daily stand-ups are a common area that I’ve noticed issues with accountability. Our organization stresses respect and courtesy, but at times we’re almost too nice. I’m a frequent attendee at many daily stand-ups (a.k.a., daily scrum), and I always (well, almost always) wait until invited to speak, respecting the boundary between management and the self-organizing team.

Consider the following scenarios involving the daily stand-up and answering the “three questions”:

Scenario #1: An individual responds to the What will you do today? question with, “… and I’m available for work” (or to help anyone). And the meeting concludes without this individual actually committing to any work or pairing with someone who could use a hand, despite the fact that there are task cards in the “not started” column of the team’s board and/or scenario #2 surfaces.

Scenario #2: An individual has been working on a task estimated to take two days, and its day three of the sprint. This individual reports, “I’ve been working on task XYZ for 2 days, but it is more complicated than we thought and it looks like I’ll need two more days to get it completed; and I have no impediments.” The remainder of the team nods, reports on their progress, and the team breaks and goes back to work.

What’s going on? What should you do as a manager?

In the first place, the ScrumMaster is someone who has authority to speak at the stand-up, and the ScrumMaster is responsible for guiding the team in its implementation of Scrum. In Scenario #1, the ScrumMaster could have asked the individual, “And what are you committing to today?” before allowing someone else to begin. In Scenario #2, the ScrumMaster could have asked, “It sounds like this is much more involved as we thought; would it be advantageous for someone to pair with you?”

Either scenario should be discussed during a retrospective, along with team modifying its working agreement as an improvement. For experienced Scrum teams, I expect more from everyone involved. I’ve been having conversations about accountability with my direct reports, talking in terms of these scenarios and how people should be holding each other accountable – in depersonalized ways. (Discussing accountability in terms of behavior and action, not as a threat.)

During one-on-ones, I’m encouraging people to speak up when they need help – especially when things appear to be more involved than initially thought. As a member of a Scrum team, it should be considered perfectly acceptable to ask for help and not be a personal reflection on your inability to get something done. Perhaps another set of eyes is all that you need to simplify a task, or to work on something extra because something truly is more involved than anyone thought.

The key to remember with Scrum is that stand-ups are not supposed to be simple status updates. Stand-ups are a mechanism for the team to manage its work. And while it’s honest to report that you need two more days for a particular task, is that being completely responsible in context with a team that is supposed to be getting high-priority tasks into the done column?

Transparency is another component of this. Give people insight into your work by being specific. This will allow the rest of the team to understand exactly where you are and what you are struggling with. This can trigger someone else to say, “I’ve worked on something similar to that in the past, I think I can help you,” whereas being vague and general about your work will cause people to simply nod and not be engaged about your task because they can’t relate to it.

I’m also reminding people that they should be asking others if they need help in situations where it is observed that a task is taking longer than planned. We’ve had situations where teams have let someone grind out a higher-priority task while others move on to the next task in the queue. This creates trouble because there too many tasks in flight at one time.

When many tasks are being worked concurrently the emphasis shifts back to individualized work with little to no collaboration and shared ownership of the work, negating the benefits of teamwork. The consequence of this will be instances where sprints end with very little completed, with carry-over of work into the next sprint. Limiting the work in process forces teams to consider how they can collaborate and get the highest-priority tasks into the done column quicker. Try it!

I’ve also tested people on something else, given the instances where I’ve seen little recognition of tasks going long during stand-ups. I’ve asked people if they know what they are going to say prior to the stand-up or if they are preparing their elevator pitch during the stand-up, which distracts them from paying attention to listening to others and managing the team’s work. I’ve gotten a couple of guilty grins when I’ve asked this question. I trust my people and they recognize the problem with this, so I’m sure that we’ll see improvement.

As you can see, the reasons for so-called “failures” aren’t deliberate acts of sabotage. People intend to do a good job, but highly collaborate teamwork is foreign to the years of very individualized focus that many organizations have. Consider the “failure” of accountability as outlined in Scenario #2; Could it simply be a consequence of a strong sense of personal responsibility and commitment, where someone wants to deliver on what they said they would? It can, and if that is the situation, I classify this as a good problem. A problem in a team context, but it’s better than someone who is simply not focused or uncaring about the team’s commitments.

As a manager seeking to overcome the individualized focus that is programmed into so many of today’s workforce, you need to continually point out that the objective of teamwork (and Scrum) is to maximize the output of the team, and that there are advantages to shared work and collaboration. And you need to support the teamwork first, individual second concept with performance expectations and reviews.

Accountability and Self-Organizing Teams

October 26, 2010

We’ve made the transition to being a Scrum development shop, and this means that we have self-organizing teams. Product Owners determine product priorities (with input from some of us stakeholders) and articulate what needs to be done; each team determines how they will go about meeting those priorities, right down to how much work the team feels that it can deliver with quality.

This means that managers and project managers do not assign tasks or otherwise direct individuals and teams; the team makes its own determination about who will perform the work and how that work will be performed. Are we in a situation that if everyone is accountable, is no one accountable?

Not at all! As a manager, you do have one limitation: Because tasks aren’t being assigned, you can’t have the “I’m holding you accountable for completing this task” discussion, something that I wrote about being a bad idea in my previous post.

This doesn’t mean that accountability is absent, quite the contrary, in fact. Scrum – and Agile development in general – supports individuals and teams who are trusted, competent professionals who have a goal of continuous improvement. If you are in doubt, reflect on those attributes as you re-read the Principles behind the Agile Manifesto.

Scrum defines the job roles and protocols of team interaction and decision-making along with the boundaries that must be respected in order to support true team ownership and accountability. Honoring the principles of the Agile Manifesto and the practice of Scrum, teams should be autonomous, self-organizing, self-improving entities that are working to deliver value to the business through satisfying the priorities established by the Product Owner.

This is the basis for accountability with Agile teams. One key portion of accountability rests with management: Managers staff project teams, and must keep in mind the objectives and needs of the project so that the skill sets of those on the team are adequate.

Competency is relative:
  • Relative to the needs of the project.
  • Relative to the amount of money that you are willing to pay for specific competencies.
As such, competency-oriented components are a business decision and accountability is on management’s shoulders. Individuals and teams have a responsibility to improve their competencies as agreed upon with management, who in turn have a responsibility to maintain the desired levels of competency within the organization – and taking action to build or acquire talent to meet the demands of the business.

Other aspects of accountability are part and parcel of Scrum development. Since teams discuss and negotiate the work – and how much of it the team will absorb in a sprint – there is complete understanding of the work, automatic buy-in, and realistic expectations established. Teams have full authority to determine how to carry out their responsibilities. Daily stand-ups are a mechanism to managing and monitor the work that has been committed to by the team. And teams reflect on their work at the end of every sprint, conducting retrospectives and determining how they can improve.

Interestingly enough, while Scrum defines the ground rules for managing and monitoring the work as well as guiding the team towards self-improvement, teams can make mistakes that cast doubt on their accountability. It takes training, time, practice, monitoring, and reminding to get it right. Next post, I’ll discuss some of ways that we’ve been challenged.

Avoid the Word: Accountability

October 22, 2010

“… and I’m holding you accountable.”

Quick, how does this phrase make you feel? Apprehensive? Uncomfortable?

For too many, the word accountable conjures up negative connotations. Why?

Accountability as a concept should simply be an “accounting” for reaching some goal, nothing more. But as a manager, it’s my own policy to stay away from uttering anything that sounds like “I’m holding you accountable.”

My rationale is simple: It comes across as a threat. There is nothing about that phrase that creates a positive outlook about the work or conveys trust in the individual who is about to carry out the work. In the software business, we need all the positive, can-do, creative energy that we can muster. I try to find ways to encourage and work with those who report to me, challenging them and guiding them by partnering with them as much as possible.

We don’t “hold people accountable” for being successful, do we? We recognize achievement through things like awards, bonuses, and promotions. Accountability only surfaces when there has been a failure to reach a goal or to accomplish some task. Used in advance of the work it becomes a threat, instilling fear of consequences and retribution for failure.

Yes, we all have goals and objectives. We need to exhibit certain behaviors and have specific competencies to be successful. Instead of accountability, I talk about expectations with my staff. We talk about what interests them, what will challenge them, and how they will go about the work –including acquiring any new knowledge or skills required to make them successful. Expectations create that positive, partnering context that I’m looking for.

Lyssa Adkins talked about setting expectations and holding people to those expectations in her book, Coaching Agile Teams: “Expecting high performance does not mean that you demand it. It means that you simply know achieving it is more than possible; it is normal. Expecting high performance means that you believe the team can attain it, so you hold them, compassionately and firmly, to that expectation.”

While Lyssa was talking about Agile teams, I believe that the approach holds true for individuals as well.

Once we’ve established and agreed upon expectations, I don’t cast people adrift, waiting to see how they fare and “holding them accountable” for any failure. I try to catch failure before it happens. I hold bi-weekly one-on-one conversations to talk to each person directly about what they are doing, what challenges and obstacles they face, and what we can do to help them be successful. I attend as many of the daily team stand-ups that my schedule allows so that I can learn first-hand how work is progressing at the team level in real-time. And our management team meets weekly with our Product Owners and ScrumMasters to discuss how various projects/releases are progressing, and we’re always prepared to remove obstacles or provide assistance to any team that needs it.

In business, there is an accounting process. My company is a for-profit entity, and we need to “make our numbers.” There is a final accounting at the end of every year, and our business uses quarterly measurements to check our progress along the way. We do the same with our staff. Accountability exists, and it will always (and should be) present. It just doesn’t have to be a threat.

Book Review: Coaching Agile Teams

October 19, 2010

Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition (Addison-Wesley Signature Series (Cohn))I’m always on the lookout for a book that will help us raise our understanding of Agile development and improve our ability to execute. If you have the same objective, I recommend Coaching Agile Teams: A Companion for ScrumMasters, Agile Coaches, and Project Managers in Transition by Lyssa Adkins.

High Expectations
Lyssa references Dan Pink and his take on what motivates knowledge workers: autonomy, mastery, and purpose. Lyssa’s point is that, “Setting high performance as your baseline expectation and giving teams a way to achieve it play directly into these powerful emotions.”

Lyssa immediately sets us straight on what she means by this, lest we get the wrong impression: “Expecting high performance does not mean that you demand it. It means that you simply know achieving it is more than possible; it is normal. Expecting high performance means that you believe the team can attain it, so you hold them, compassionately and firmly, to that expectation.”

But how do you achieve high performance? Lyssa uses the power of metaphor with her High Performance Tree.

The High Performance Tree
The High Performance Tree guides teams towards high performance:

Lyssa instructs us to draw the tree from the roots up, teaching the meaning of Scrum values while you list the characteristics of high performance. I won’t delve into the details here, but the entire chapter from the book is available here if you are interested.

Building a high-performing team requires that people understand one another, and Lyssa outlines various activities that teams can use to learn about one another. I like Lyssa’s take on these activities as they focus specifically on what is important to know from a business context; As Lyssa says, “No fluffy stuff.”

A couple of quick examples:

Market of skills: Imagine that each team member owns a booth at a market. Within 20 minutes, each person makes a poster that answers the following questions:
  • Which competencies, skills, and abilities related to the team are available at your booth?
  • What is available under the counter of your booth? (What competencies, skills, and abilities do you possess that may not be relevant to the goal of the team?)
  • Which competencies, skills, and abilities would you like to achieve or learn from of the other team members?
Each person then presents their poster, and everyone learns what others have and are excited about, what skills could be available to the team, and how they can help someone gain the competencies, skills, or abilities the person wants.

Constellation: This starts in an open space with any object in the center of the floor, representing the center of the constellation. Team members stand around the object, and as each statement is read, individuals should gravitate toward the center or away as if it were a scale. The closer to the center object, the more true the statement is for them, and the further away, the less true.

Some warm up statements:
  • I enjoy time alone.
  • My happiest times are when I’m in nature.
  • I like to make things with my hands.
  • I thrive being around people.
Once the warm-up is done, you can move on to using statements designed to raise work preferences:
  • I like speaking in front of people.
  • I avoid conflict with people who have more seniority than me.
  • I like surprises.
  • I do not like uncomfortable silence and work to fill it in.
  • I enjoy public recognition.
  • I get quite in uncomfortable situations.
  • I am a perfectionist.
  • I enjoy debates.
  • I like to facilitate meetings.
Coaching Advice
Coaching teams that are self-organizing places some practical constraints on coaches: When is it appropriate to be involved? Should I work at the team or individual level? Coaching Agile Teams has the answers.

You must coach at both individual and team levels. It’s a question of when.

Coaching at the team level will have the strongest effect at the beginning and end of a sprint or project. During the middle of a sprint, it is best for the coach to help keep the team moving by assisting in things like removing impediments that are outside of their control. The golden rule with Agile teams is that, “it’s the team’s commitment, not yours.”

This means that as a coach, you don’t solve problems for the team. When there are problems that need to be taken on, take the problem to the team. As Lyssa points out, some decisions may be management calls, but even these decisions should not be made without consulting the people how have to live with the result.

And when you do address a problem with the team, Lyssa’s advice is that you “ensure that you balance problem-solving with their ability to sprint. Raise only those problems mid-sprint that must be attended to immediately. Let the others wait until the retrospective.”

This places you as a coach in the position of staying at the process level; Lyssa asserts that, “Most problems on agile teams can be solved by strengthening or reaffirming an agile practice.” As a coach, stay away from the details of the team’s every decision and plan.

Coaching styles will vary. For example, with new teams new to agile, Lyssa recommends invoking the Teaching style of coaching. And if you observe the team violating a rule of agile and you feel strongly that they should “do it by the book,” Lyssa is direct in her advice: “Put your foot down.”

While Lyssa likes to be direct, she does so in a way that engages the team to solve its own problems:

“State what the symptoms you see, float your hypothesis, and ask the team what they want to do about it. When you float your hypothesis, make it light and open. If you present it in too much detail or with too much ferocity, then they won’t be invited to challenge it and tell you what’s really happening. You might say, ‘Hey everyone, I see a couple of things: The burndown chart looks a bit flat, and the storyboard looks like a lot of work is happening at once. Hmmmm… I could guess that we have too much going on simultaneously. What do you think?’”

Agile development is all about inspecting and adapting. Some key questions to keep in mind during a retrospective that Lyssa recommends:
  • Is the team using the structures of agile to stay coordinated?
  • What is the team tolerating?
  • How well does the work flow?
  • Where are the breakdowns in communication, coordination, attendance, attention to one another, and collaboration?
  • Where are the brilliant moments?
  • Where does it feel slow, like molasses on a cold day?
  • How does the team’s level of anxiety change throughout the sprint?
  • Are people present physically, mentally, and emotionally?
  • When and how does the level of excitement change?
Collaboration or Cooperation?
Coaching Agile Teams discusses the topic of collaboration, contrasting it against cooperation.

Collaboration yields a whole that is greater than the sum of the individual parts.

Cooperation yields the sum of the individual parts.

Why is this important? Lyssa states, “If the work the team has been charged with does not require innovation and they are content to use agile practices mechanically, you may choose to stop at cooperation. Cooperation features the smooth flow of work-in-progress from one team to another and between the team and the wider organization.

“Collaboration needs cooperation as its base, but it adds the essential ingredient for yielding innovative, breakthrough, and astonishing results.

“When collaborating, team members build on top of one another’s ideas, each person giving away from their cherished vision of what it “should be” so that something better, something that no one of them could have imagined alone, emerges from the ash of their burned and forgotten personal visions.”

Coaching Agile Teams provides plenty of insight and advice that we as coaches, managers, and agile practitioners will find valuable. The book is well written, and explains each topic clearly. I highly recommend this book, and I’m sure that you will find it a useful addition to your Agile library.

Book Review: Good Boss, Bad Boss

October 15, 2010

Good Boss, Bad Boss: How to Be the Best... and Learn from the WorstWhat does it take to be a good boss? What are the behaviors and actions that you should strive to eliminate from your repertoire? The answers to these questions are in Bob Sutton’s latest book, Good Boss, Bad Boss: How to Be the Best… and Learn from the Worst.

I had exchanged a couple of quick e-mails with Bob about getting a galley (advance copy) to do a review a little earlier than this, but alas, it didn’t arrive in the mail. This didn’t prevent me from reading the book, it only delayed me. I was motivated enough to read this book that I made it the FIRST book to purchase and read on my newly acquired Kindle.

I wasn’t disappointed. This book is a GREAT read! There is a wealth of research put forth that is pertinent to us managers, and there are even some nuggets that non-managers can appreciate.

Being a Jerk...
Bob Sutton notes early on that, “The best bosses balance performance and humanity, getting things done in ways that enhance rather than destroy dignity and pride.”

Not that bosses are deliberately seeking to be jerks. As Bob says, “I’ve never met a boss who wants to leave people feeling demeaned, disrespected, and de-energized.” So, if no sets out to be jerk, how does it happen?

Here’s one way: Bob cites surveys by Christine Pearson and Christine Porath reveal that almost 50 percent of workers claim they don’t have enough time to be civil on their jobs. (A consequence of doing a lot more with a lot less, no doubt.)

Bob reinforces this by relating a classic experiment that demonstrates how time pressure undermines sensitivity and humanity with what he calls “splendid irony.”

“In 1973, psychologists John Darley and Daniel Batson recruited students at the Princeton Theological Seminary to give a brief talk on the Good Samaritan, a parable from the New Testament about the virtues of helping those in need. After getting the assignment, the seminary students walked outside through an alley to get to the building where their talk was scheduled. In the alley, they encountered a person (a shill planted by the researchers) sitting slumped with his head down and eyes shut, who was coughing and groaning. To top it off, it was freezing, as the research was done during an unusually cold December in New Jersey. The researchers told some of the seminary students they didn’t need to hurry, some to hurry, and some to rush over immediately because they were already late. These differences in time pressure had a huge impact: 63 percent of those in no hurry stopped to help, 45 percent in a bit of a hurry helped, and only 10 percent of those in a big hurry helped – passing just inches from someone apparently in dire need as they rushed to talk about the virtues of Good Samaritans.”

Time pressure isn’t the only driver. Bob notes that performance pressure can be intense, and that many bosses “…work in extremely competitive industries and face one tight deadline after another. Most bosses are praised, feel proud, and enjoy handsome incentives when their teams and organizations succeed – and many are blamed, feel shame, and lose income, and sometimes are canned when their followers fail.”

Tying all of this together, Bob makes a valid point about the nature of the job: “As I’ve said, it is almost as if the job was designed to turn occupants into assholes. It is difficult, arguably impossible, to be a boss (or any human being) without being a temporary asshole now and then.”

Agreed! And hopefully I’ve been viewed as temporary asshole having a bad day now and then and not a full-time one…

What does Bob recommend so that you avoid these problems? First, whenever the heat is on, keep reminding yourself and others of the big picture, to take a long-term time perspective. And if you can’t do it, turn to someone that you can trust to remind you when the pressure is intensifying and/or when you have what appears to be a blind spot.

Rigorously prioritizing your work is another mechanism. As Bob points out, “Most bosses are expected to do so many things that it is often impossible to perform each chore perfectly – or even very well. Good bosses focus their attention, and their people’s efforts, on the small number of things that matter most. The best bosses learn when they can and should ignore the least important demands from others.”

And before everyone starts thinking that THEIR boss is clearly a full-time jerk, let me quote an interesting observation Bob has in the book: “…just as there is strong evidence that power turns people into insensitive jerks who are oblivious to subordinates’ needs and actions, there is also convincing evidence that subordinates are hypervigilant about superiors’ moves and often assume the worst about their intentions.”

A manager’s job is a perilous one. One missed “good morning” or a wrong look on your face at the wrong time can become a major let-down for someone. Please, don’t assume worst! As Bob says, “Every boss is prone to bouts of cluelessness and forgetting how closely followers track every little things they do.”

His advice – on the surface – clashes with traditional advice: “You’ve got to think and act as if it is all about you. Your success depends on being fixated on yourself.” Meaning that we should all pay attention to people’s reactions and how they perceive us and not being self-absorbed.

These days, we all have a lot going on, and as good bosses we need to protect our people from distractions – including management-introduced distractions Bob calls Participation Traps.

The first trap is creating unnecessary interference and distractions. Bosses who ask for too much input and assistance make it tough for people to concentrate. The second trap is that just because people can perform a job well doesn’t mean they ought to help manage it. Asking employees to help bosses with their management chores is misguided when employees lack skill, interest, or time.

“The third trap is most aggravating. I call it sham participation. It happens when the boss asks people to devote massive effort to help with some decision – serving on time-consuming committees, interviewing experts, preparing reports, and so on. But the boss knows from the outset that underlings will have no influence.

“The best bosses let the workers do their work. They protect people from red tape, meddlesome executives, nosy visitors, unnecessary meetings, and a host of other insults, intrusions and time wasters. The main test here is whether or not followers believe their boss has got their backs.”

Another trap deals with bosses who don’t pay attention to the team dynamics and reward people who actually drag the organization down. Bob observes, “Unfortunately, too many bosses have such blind faith in solo superstars and unbridled competition that they hire huge egomaniacs and install pay and promotion systems that reward selfish creeps who don’t give a damn about their colleagues. Or, even worse, they shower kudos and cash on credit hogs and backstabbers who get ahead by knocking others down.

“When I looked more closely at places where people were cooperative and unselfish, I saw that although their reward systems varied wildly, they all applied something like the GE definition of a superstar, promoting innovation and effectiveness through ‘the power of two performances’: individual contributions on their own jobs and collaboration on and across teams.”

Dealing with Failure
Things don’t always go according to plan, do they? We are all faced with failure, and sometimes even “failing” can be a question of degree. Bob Sutton and Jeff Pfeffer argue there are three kinds of reactions to failure:
  1. Blame, humiliate, and perhaps expel the culprit. This is the “do it right the first time or don’t do it” mentality.
  2. “Forgive and forget,” which is what benevolent but incompetent bosses do.
  3. “Forgive and remember,” which use failure as an opportunity for learning rather than finger pointing.
The best, naturally, use option #3 and move forward, keeping a positive, forward-thinking demeanor.

The Power of Positive Thinking
Bob cites research on how expressing confidence that good things will happen to your people can become a self-fulfilling prophecy, talking about a study of drill instructors at an Army boot camp. Five drill instructors were tricked by researchers into believing that ten of the thirty soldiers that each would lead for the next fifteen weeks was nearly certain to achieve superior performance.

“Those randomly anointed soldiers were treated differently by instructors and came to believe they had special talents. During the course, there were huge differences between the anointed soldiers and everyone else. They displayed superior performance on many tasks, including firing weapons and reading maps. This study shows how the self-fulfilling prophecy works: the drill instructors believed something that was, as first, untrue, but believing it caused them to transform those lies into truths.”

Conversely, Bob warns us that the self-fulfilling prophecy doesn’t always work. ”You can bring in people who seem like talented stars, devote massive attention to them, and give them every chance to succeed. Yet their performance may still suck. The challenge for bosses – as for all human beings – is that they see what they believe. Psychologists call this confirmation bias: selective thinking where ‘one tends to notice and look for what confirms one’s beliefs, and to ignore, not look for, or undervalue the relevance of what contradicts one’s beliefs.’”

There is far more in this book than what I’ve outlined above. I found this book to be a fun, well-researched book that made for an entertaining read. (Of course, I enjoy business books to begin with.) If you want insight on how to be a better boss, this book is definitely for you!

How to Avoid a Self-Organizing Train Wreck

October 12, 2010

In my last post, I noted that most businesses have a heavy bias towards planning and execution, and that learning isn’t really a part of the business psyche. I also stated that it is poor execution on management’s part to stand idly by while watching a team as it runs straight into a brick wall and fail miserably.

As a manager involved with Agile teams that are supposed to be autonomous and self-organizing, is there a single, RIGHT way to manage? Is there a checklist that we can use?

The answer to both questions is: No. My rationale centers around optimal (not flawless) execution. And optimal execution for one team will look completely different for another team because the mix of engagement, skills, strengths, and preferences of the individuals involved vary.

The first step is on management. Make sure that you understand where your people and teams are at, and adjust your leadership style accordingly.

The book Great Business Teams recommends selecting a leadership style based on the level of engagement and skill set:

ENAGAGEMENT: An individual’s commitment to being a team player, his or her willingness to take ownership of and be held accountable for the team’s success; his or her intention to embrace the attributes of high-performing teams.

SKILLS: The knowledge and skills an individual brings to a goal or task; education, experience, and/or ability; the individual’s appropriate utilization of his or her technical leadership, interpersonal, and strategic skills in the context of meeting performance goals.

Engagement and Skill Set Stage
Recommended Leader Behavior
Low level of engagement and/or skill set
Moderately low level of engagement and/or skill set
Moderately high level of engagement and/or skill set
High level of engagement and/or skill set

Where the leader behaviors are defined as:

Prescribing/Directing: Telling players the what, where, when, and how of an issue.
Coaching/Instructing: De-emphasizing the how in favor of the why.
Coordinating/Partnering: Working alongside the players.
Inspiring/Empowering: Allowing team members to run with the ball.

The next step is on the individuals who are on the teams.

The notion of “blaming the people instead of the process” when things go wrong certainly raises blood pressures in many of us (rightly so when blame is being placed), but there are times when people and teams bypass critical learning steps. So don't take it as indictment from me, but simply an observation.

Sometimes people choose to eliminate certain things that are important, clinging to old patterns when they should let go. Other times people judge new concepts – without trying the concept – through the lens of their own experience, keeping their minds closed to new possibilities.

Before rejecting something, it is important to absorb what IT is. Lyssa Adkins outlined how martial arts students progress through three stages of proficiency in her book, Coachng Agile Teams. The three stages are called: Shu Ha Ri.

Shu: “Follow the rule.” A student should copy the techniques without modification and without yet attempting to understand the rationale behind them. This stresses the basics in an uncompromising fashion so that the student has a solid foundation for future learning and breaks people out of their existing well-worm patterns.

Ha: “Break the rule.” As a student reflects on the truth of everything, the student comes to a deeper understanding of the art than pure repetitive practice can allow. The student can now instruct others as an additional way to advance their own practices. In the quest of the advance, individuality will emerge. While breaking free, the student carefully upholds the principles underlying the practice.

Ri: “Be the rule.” The moves become a part of the student. “There are no techniques…all moves are natural.” At this point, a student can replace a technique with something else, but the replacement technique still achieves the principle of the original technique.

The lessons are simple: As managers, we need to adapt our leadership style based on the expertise and abilities of our people and teams. And for those who are learning and applying their learning, don’t start modifying anything until you’ve put something into practice and spent time reflecting on what the practice is and why it works. Understand the principle that the practice is addressing. This puts you on the path to building expertise. And you will avoid looking past the very things that can help make you successful.

The Challenge of Practice in Software Development

October 8, 2010

The term practice can take different forms. It can be a customary way of operating or acting, such as, “It is our practice to give annual raises in January.” It can be the pursuit of a profession, such as “practicing law.” It can be about putting an idea or concept into action, such as “putting a theory into actual practice.” And practice can be about repeating some activity with the goal of improving a particular skill.

Athletes have long periods of practice and short (relatively speaking), intense moments of competition where they apply what they have practiced. The contest is the moment. Practice for us professionals working in software development is more of a continual, real-time activity.

The exception is formal training. This is a form of practice, but it is only a first step. Except for those times when the instructor has been so poor that I came away feeling like I didn’t learn a thing, I’ve always felt that training equips me with new knowledge and insight, pointing me in a direction and providing solid guidance. Training means that I’ve been coached and instructed on the basics so that I can truly begin to put something into the actual practice of my day-to-day work.

If I want to become truly proficient, it’s up to me to take the ball and run with it. And I may need refresher or additional instruction once I’ve gotten some real experience under my belt to polish some rough spots or to take me to another level.

When it comes to software projects, here’s the challenge: Most businesses have a heavy bias towards planning and execution. It’s a, “Here’s what we’re planning on, now get me my results – and fast!” mindset. Practice and learning can have the appearance of poor execution. And sometimes it is poor execution.

Practice and learning come in different forms on a software project. For a start, we’re not writing the same applications over and over again (well, most of us aren’t). We’re contending with ever-changing business requirements and the continual advancement of technology, which provides uniqueness in every project. In the process, we’re learning new things and putting that knowledge into practice or we’re reinforcing what we already know through continued use and adaptation.

Since we’ve adopted Scrum, the emphasis on teamwork skills has increased, and now we all need to understand how to contribute both technically and collaboratively. Furthermore, and in support of Agile development, teams must strive to be autonomous, self-organizing, continuously improving entities. Needless to say, there’s a lot of learning and growing involved!

One origin of poor execution is management.

Poor alignment of the skill set and team assignments relative to the complexity and difficulty of the project. Assigning junior-level programmers to tackle projects that can and should have at least some more experienced, senior programmers is begging for trouble. Sometimes, assignments get made too casually. Take the time to understand the nature and needs of a project before making an assignment, and don’t just assign people because they happen to be available.

Equally poor execution in an Agile context can come from anointing a team as “self-organizing” without the proper training and preparation to be so. Make sure the teams have training and coaching to implement Agile development successfully. And it is certainly poor execution on management’s part to stand idly by while watching a team as it runs straight into a brick wall and fail miserably. Part of the organizational learning process is to assess where individuals and teams are at and given them the appropriate guidance and space relative to their preparation and track record – avoiding putting people into situations where they are over their heads.

Failures and problems will always plague us, but through proper staffing and preparation, the impact can be minimized and reduced to small affairs that can be recovered and learned from, not colossal failures that are highly visible, miserable experiences.

Finally,once proper team assignments and training are in place, continue to talk with your people at both individual and team levels. Make sure that you’re in tune with the work that they’re about to undertake and talk through the major points. Making an investment in people means they need to learn and grow, to stretch themselves and perhaps make some mistakes along the way. Keep in touch and make sure that they’re equipped and able to tackle the challenges they face. And don’t let a train wreck occur unless you are very prepared to make that investment!

Achieving Expertise and Mastery

October 5, 2010

What does it take to build true expertise and mastery? Ten is the magic number: Ten years and ten thousand hours of practice is the generally accepted rule of thumb. These numbers aren’t absolutes, but they are useful to gauge the amount of time and effort that you should plan on to develop your own expertise.

One study that illustrates this point involves a study of thirty violinists at the Music Academy of Berlin. All of the violinists had begun playing the violin around the age of eight, placing them on equal footing in terms of when they started. The study involved collecting vast amounts of data, including each violinist keeping a diary of his or her activities.

It turns out that the top performers – those destined to have professional careers as part of orchestras, with the best of the best being soloists – practiced an average of twenty-four hours a week. Those who were destined to become music teachers practiced only nine hours per week. In the end, the best solo violinists logged far more hours (7,410) than future music teachers (3,420).

While this demonstrates that practice matters, there is more to it than that. The ten-thousand-hour rule by itself is inadequate. How you practice is vitally important.

The top two violinists practiced an average of 3.5 hours per day, but they split their practice into 90 minute sessions, mostly in the mornings when they were rested and less distracted. Intense practice followed by intermittent rest is important. Our bodies are asking for a break every 90 minutes or so – and great performers intuitively understand this.

Purposeful practice is also important. Top performers take active steps to stretch their limitations in every session. The top violinists in the study above pushed themselves harder for longer – they used practice sessions to stretch their capabilities and test their limits, to learn and improve and not just re-hash what they already knew. They concentrated on developing specific skills that were just beyond their current proficiency levels.

The notion of continually stretching yourself is important. Too many people go on autopilot, and the status quo becomes “all that you will be.” Golfing expert Bill Kroen notes, “Many players confuse hitting balls with practice. If you watch golfers at a crowded driving range you will see many that are hitting the ball with the same club without ever checking their grips, stance, or alignment.”

This purposeful practice isn’t always easy or fun. As Sam Snead said, ”It is only human nature to want to practice what you can already do well, since it’s a hell of a lot less work and a hell of a lot more fun. Sad to say, though, that it doesn’t do a lot to lower your handicap…. I know it’s a lot more fun to stand on the practice tee and rip drivers than it is to chip and pitch, and to practice sand shots with sand flying back in your face, but it all comes back to the questions of how much you’re willing to pay for success.”

Part of that payment involves expert coaching. As a student seeking to develop expertise, you need to be prepared to receive constructive – and sometimes painful – feedback. Purposeful, deliberate practice that is designed to develop your expertise should not be left to chance. Quality practice involves quality coaching, so seek out the best to learn from.

Finally, reflecting on what you’ve learned – considering how and why things work – will provide you with a deeper understanding; often times, teaching others becomes a great way to consider – or reconsider – your understanding and beliefs. Teaching will force you to examine areas that you might have neglected because they didn’t apply to you – but are important to those you are instructing. And you might even find yourself changing your mind about beliefs that you have held dearly.

In the words of K. Anders Ericsson, “Expert practice is different. It entails considerable, specific, and sustained efforts to do something you can’t do well – or even at all. Research across domains shows that it is only by working at what you can’t do that you turn into the expert you want to become.”

Building Expertise: Cognitive Methods for Training and Performance Improvement

Bounce: Mozart, Federer, Picasso, Beckham, and the Science of Success

The Way We’re Working Isn’t Working

The Making of an Expert

Waterfall and Agile: The Same Principles Should Apply

October 1, 2010

There is a lot of sword-fighting about the differences between Waterfall and Agile, and I can understand why people draw lines in the sand. There are those who have tried Agile development, are genuinely excited about it, and want to tell the world about their discovery – mostly because it solves problems that they’ve encountered, including long hours of unsustainable development. On the opposite side, there are those who feel like they are being told that the way they have been developing software all along is wrong – and they feel resentful because the past is being indicted.

The problem is that many the arguments that do arise shouldn’t exist at all! This post explores the origin of Waterfall development and what the “originator” of the concept felt was the proper approach. The question is, have a good many Waterfall projects are approaching software development as recommended by the one who is credited in creating the Waterfall model?

Winston W. Royce is credited with describing what is known today as the Waterfall model in his paper, Managing the Development of Large Software Systems, published in 1970. Royce did NOT use the term Waterfall, in the paper, although he did include what is considered a classic Waterfall diagram in that paper:

As many agile enthusiasts are quick to point out, Royce – on the very next page – went on to state, “I believe in this concept, but the implementation described above is risky and invites failure.” Actually, I’ve heard some people paraphrase this into Royce saying that “You would never want to build software this way.” This is implicit rather than explicit, as Royce acknowledges only that this model is risky; the entire paper describes the challenges and how to make the process less risky, from Royce’s perspective.

First, the challenges:

According to Royce, one major challenge is where the testing occurs and that some things are difficult to get right and must be verified through testing. Royce notes that, “The testing phase which occurs at the end of the development cycle is the first event for which timing, storage, input/output transfers, etc., are experienced as distinguished from analyzed. These phenomena are not precisely analyzable.”

Royce also recognized the potential impact of these problems: “A simple octal patch or redo of some isolated code will not fix these kinds of difficulties. The required design changes are likely to be so disruptive that the software requirements upon which the design is based and which provides the rationale for everything are violated. Either the requirements must be modified, or a substantial change in the design is required. In effect the development process has returned to the origin and one can expect up to a lO0-percent overrun in schedule and/or costs.”

Royce also understood another major source of trouble with software projects: Requirements. Royce observes, “For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble. “

The steps Royce recommends to correct these problems illustrate significant insight into what software should have been all along – but hasn’t been.

Royce felt that it was important to get everyone on the same page. (Imagine that!) “Write an overview document that is understandable, informative and current. Each and every worker must have an elemental understanding of the system. At least one person must have a deep understanding of the system which comes partially from having had to write an overview document.”

The overview document was only the beginning for Royce. He had a strong preference for documentation, and lots of it: “In order to procure a 5 million dollar hardware device, I would expect that a 30 page specification would provide adequate detail to control the procurement. In order to procure5 million dollars of software I would estimate 1500 page specification is about right in order to achieve comparable control.” (Remember, we’re talking 1970 dollars here.)

Royce also observed that customer involvement was essential to success. “It is important to involve the customer in a formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble.”

Finally, Royce recommends staying away from the single-pass Waterfall model. In fact, his diagrams point towards iterations and what he hoped for versus what he found to be reality. The first being iterations confined to successive steps:

But Royce admits that iterating is likely to occur as shown here:

To make iterative development productive, Royce put forth the notion of doing it twice: “If the computer program in question is being developed for the first time, arrange matters so that the version finally delivered to the customer for operational deployment is actually the second version insofar as critical design/operations areas are concerned.”

Royce doesn’t mean to the entire project twice, but he does advocate using a simulation of the final product: “Note that it is simply the entire process done in miniature, to a time scale that is relatively small with respect to the overall effort. The nature of this effort can vary widely depending primarily on the overall time scale and the nature of the critical problem areas to be modeled. If the effort runs 30 months then this early development of a pilot model might be scheduled for 10 months. For this schedule, fairly formal controls, documentation procedures, etc., can be utilized. If, however, the overall effort were reduced to 12 months, then the pilot effort could be compressed to three months perhaps, in order to gain sufficient leverage on the mainline development.”

In the end, Royce’s recommendations for an effective Waterfall project are really recipes for success in any project. Involve the customer, make sure that the team is on the same page, prototype and iterate. The amount of documentation and level of team collaboration are the primary differences between Waterfall (Royce’s way) and Agile development.

And how many Waterfall projects keep Royce’s advice in mind? It would be interesting to see how many projects that are struggling are heeding Royce's advice, and to what extent.

Musings on Agile Performance Reviews and Goals

September 28, 2010

One of my recent posts fictionalized how an organization that has adopted Agile development can work at cross-purposes. The moral of the story is simple: Agile development emphasizes teamwork in ways that are likely to challenge your existing management approach – ultimately demanding change.

The performance management process is one area that has been historically focused like a laser on the individual and will need to be adjusted as you adopt Agile development. Being a knowledgeable, capable individual contributor isn’t enough for Agile development. Individuals need to be good team players, an easy transition for some and not for others.

As a manager in an Agile organization, you won’t be assigning tasks to individuals, either. Agile development is about self-organizing teams that welcome and respond to change. This means that you cannot determine in advance what tasks individuals will be working on, nor should you. Teams will need to learn to self-organize, and their learning that means you cannot do the organizing for them. Period.

This is a good thing! This actually raises the bar on you as a manager and on those who are directly involved on an Agile team. People need to be technically competent and cooperative, collaborative team players. As a manager, you need to be able to grow your staff to operate in this new model – and do so from arm’s distance.

Abolishing performance reviews and focusing on previews is where I’d like to be. But we’re not there yet. Since we can’t predict what people will be working on because they’re a part of a self-organizing team, what do we do? Part of the answer lies in what is normal for any situation: It’s about what people know, how they apply that knowledge in actual practice, how they conduct themselves, and the contributions that they ultimately make:

Knowledge = what you understand

Skill = how that knowledge or understanding is implemented in actual practice

Behavior = how you conduct yourself in the performance of your job and how you interact with others

Contribution = the value that you provided through delivering something or helping others deliver on something

By using these ingredients, as a manager you can observe, solicit feedback, and discuss with each of the people that work for you where they are strong or weak, plus develop plans to leverage their strengths and shore up any glaring weaknesses. (I’m a believer in leveraging strengths as much as possible versus focusing on weaknesses, unless a weakness is strong enough to get in someone’s way or prevent them from advancing up the career ladder.)

In an Agile context, individuals require more than just technical abilities. They will need to expand their understanding of team dynamics and technical practices in order for the team to improve. I think the reason that Scrum/XP hybrids are taking hold is because this combination provides an excellent foundation for defining the rules and roles for team interaction (so the team doesn’t have to define them) along with technical practices that improve software development.

You can measure how much someone knows. Something like technical knowledge can be measured by testing – formally or through actual work where someone produces a design or working code that is peer reviewed. And in the technology industry, there is always new knowledge to acquire, and learning goals should be a part of the equation, including things like:

Technical: Learning a new technology or practice, such as a new programming language, test-driven-development, test automation, etc.

Process: Obtaining a deeper understanding of Scrum and/or some aspect of Scrum like planning, retrospectives, coaching Scrum teams, etc.

Professional Development: Written or presentation skills development, taking workshops on teamwork, etc.

In real life, there are those who acquire knowledge but fall short in implementing that knowledge. Sometimes they lack confidence or are afraid to fail. Other times, a little practice is required to develop the understanding into a skill that enables the knowledge to be used effectively.

For example, knowing how to give a good presentation and being able to deliver one requires a little stage time and constructive feedback. If you are a programmer, object-oriented design requires some real-world practice to cement your understanding or take you to another level. And your practice should be done under the watchful eye of someone with experience, so that you don’t adopt or reinforce bad habits.

Behavior, or how you conduct yourself, is obviously important if you are a member of a team. If you are a self-centered, arrogant, selfish person who can’t or won’t work with others – like sharing knowledge – you will have a problem being perceived as a good, Agile team member. While the former is an extreme example, small adjustments can make big differences in the context of teamwork, and sometimes individual preferences must take a back seat to align the actions of everyone on a team. In general, the best Agile team members have a blend of technical and interpersonal skills and the willingness to help others succeed that is unmistakable. I outlined some key behaviors in my post, Ten Behaviors Required for Effective Teamwork.

In the final analysis, we all must be contributing. If you want higher pay, your value proposition will be based on the above and the ultimate delivery that you make. Did you work on that really complex problem? Did you help someone else work through a complex problem? To contribute at higher levels, we all need to continually build on our knowledge and work at applying that knowledge, working in a virtuous cycle to deliver the goods.

DUMB Goals Trump SMART Goals

September 24, 2010

A little boy asks three bricklayers who are working side-by-side what they are doing.

The first bricklayer says, “I’m putting one brick on top of another. Isn’t that obvious?”

The second says, “I’m building a wall for the west side of a church.”

The third says, “I’m creating a cathedral. It will stand for centuries and inspire people to do great deeds.”

(From the book, The Art of Engagement by Jim Haudan)

There are goals, and then there are GOALS. Exciting goals are about engaging peoples’ emotions. Which bricklayer above was truly excited and engaged?

Jim Collins and Jerry Porras coined the term BHAG, or Big Hairy Audacious Goal in their book, Built to Last. A BHAG is a long-term goal that is big, bold, powerful and exciting. And people want to be inspired, to be a part of some greater purpose. They want what they do to have meaning.

How much inspiration, purpose, meaning, and excitement are contained in the average employees SMART goals? Not much, I’ll wager. While most goals undoubtedly fit the definition of Specific, Measurable, Achievable, Realistic, and Time-bound, I’ll bet that many find their goals to be Stale, Monotonous, Annoying, Rational, and Transitory – reasonable, yes, but long on perspiration and short on inspiration.

Roger Bauer, CEO of SMB Consulting, Inc, has a fun post: SMART Goals are out DUMB Goals are in. But just what are DUMB goals?

DUMB goals unleash the entrepreneurial spirit.

DUMB stands for Dreamy, Unrealistic, Motivating and Bold.

Dreamy goals repeatedly wake you up at night wondering if something is possible with an effort that is truly remarkable.

Unrealistic goals are the ones traditionalists warn against and believe aren’t obtainable by anyone.

Motivating goals are those that make someone wake up each morning ready to take on the day versus figuring out a way to muddle through it looking busy even though time is being wasted.

Bold is charting a course competitors don’t dare take because the fear of failure or success is too daunting.

If you want to build a ship, don't drum up the men to gather wood, divide the work and give orders. Instead, teach them to yearn for the vast and endless sea. – Antoine de Saint Exupéry

BHAG and DUMB goals are all about having a mission and a purpose. Consider these goals from some well-known companies:

Microsoft: A computer on every desk and in every home.

Google: Organize the world's information and make it universally accessible and useful.

Amazon: Every book, ever printed, in any language, all available in less than 60 seconds.

Twitter: To become "the pulse of the planet."

SMART Isn't Always Intelligent

September 21, 2010

Sally was puzzled and concerned. The nature of her Scrum team’s daily standup had taken a step backwards these last several days. Because of the lack of meaningful response to her gentle prodding at the standups, Sally knew that as ScrumMaster, it was time to probe a little deeper. As she drove to work that morning, she resolved to talk to the three developers on the team one-on-one to see if they could shed any light on their recent behavior change.

The team was regressing from its highly collaborative state to a collection of individuals. The standups were no longer a coordination point where the team discussed their collective sprint commitment and their shared progress. Instead, the standup had devolved into a series of individual status updates. Sally noted just the day before that one developer who finished early simply took on another task instead of assisting someone else who was working on a higher-priority task – even when it was clearly evident that the other team member was struggling.

Worse, there was even some bickering between the developers about the various tasks. It seemed that suddenly, each developer had a strong preference to work solely in certain areas, to the exclusion of anything else and to the determinant of the team. And the effects and behaviors were beginning to trickle to the rest of the team.

Sally had tried to get the team to recognize the problem, talking to the developers using informal, open-ended inquires like, “How do you feel about the team’s standup this morning?”Sally was hopeful that she could guide them to reflect on their participation in context with Scrum practices.

Unfortunately, she received rather brief, “they’re fine” responses and shoulder-shrugs. While the QA staff had begun to voice some concerns of their own, those concerns were quickly dismissed by the developers. The new status quo was in danger of becoming good enough, odd for a team that had worked very hard the past year to understand Scrum and had seemed determined to excel as a team.

As soon as Sally reached the office, she walked directly to Mark’s desk. Mark was always in early, and she wanted to talk with him first, as the most senior developer on the team.

“Mark, do you have a moment?” Sally asked as she approached Mark’s desk.

“Sure,” Mark replied, turning away from his monitor and reaching for his coffee cup. “I need another cup of coffee, can we walk and talk?”

“Works for me!” Sally enthusiastically replied. She waited for Mark to get up and take a few steps away from his desk before continuing. Sally’s intent was to clearly state her observation and be direct as possible. She did not want any ambiguity or evasive answers.

“Mark,” she began, “I’ve noticed that during this sprint, you’re not interested in any task other than your own. Instead of collaborating, all that you’re doing is reporting your status. For example, you didn’t offer to help Allen with his task the other day, but chose instead to move onto another task. I’m sure that you have the knowledge and experience that would be valuable to Allen, but it seems that lately you and the other developers on the team don’t want to share any information or assist each other in any way. What’s really happening here?”

Mark’s eyebrows rose as he considered Sally’s questioning. Sally was a good mirror; he hadn’t considered how his behavior had altered in the past week or so, but he immediately recognized that Sally was right. And Mark was experienced enough to understand why.

He let out a deep breath and said, “Well, I’ve just had my annual performance review, and it’s a good bet the others did, too…”

After talking with Mark and the other two developers on the team, Sally determined that the management team, in an effort to “raise the productivity bar” – and conforming to the HR practices of the company – had worked hard at establishing SMART goals for the development staff.

Unfortunately, in an attempt to be as specific and measurable as possible, the line managers had established goals that involved each developer taking ownership of specific functionality along with the objective for each developer to personally and visibly drive results for improving that functionality. Aside from teamwork issues, sooner or later there would be debates about product priorities with the Product Owner!

This individual focus undermined the team-oriented nature of Agile/Scrum practices. It took a meeting with the VP of development to get agreement that the goals should be changed, and Sally pledged to work with the line managers to help craft goals that were team-oriented and fit within Scrum development. The VP also agreed to get more education for management on the Scrum process itself, so that they could understand how to change their management style and work with teams that ideally should become self-organizing and autonomous in nature.

While this post was a fictionalized account, I’m curious if any of those reading have experiences with performance management and goal-setting (good or bad) related to agile or team-based development that you would like to share. And does anyone have a great solution that they’ve implemented?

Book Review: The Art of Engagement

September 17, 2010

The Art of Engagement: Bridging the Gap Between People and Possibilities I’ve generated some posts about engagement and resourcefulness this past summer, so I feel that it is timely to review the book The Art of Engagement by Jim Haudan, CEO of Root Learning, Inc.

I’ll start by asking a question: Are your people afraid? If they are, they can’t be engaged. But just what are workers in the 21st century afraid of?

According to Jim Haudan, the list looks like this:
  • We’re afraid that our contributions aren’t really valued.
  • We’re afraid that our personal beliefs don’t align with those of the company.
  • We’re afraid that we won’t be able to adapt to changes in the way we work.
  • We’re afraid that we won’t have a safe place to practice new skills.
  • We don’t feel that it’s safe to say what we really think.
  • We don’t think it’s safe to suggest better ways of doing things.
  • We don’t know how to disagree and not become branded “a problem.”
Interestingly enough, Haudan points out that formality reinforces fear in an organization. Haudan states:

“Many of the formal aspects of our workplaces are reflections of the rules and procedures that define the culture of the business. Without a level of informality in the workplace, fear and caution take over and cause people to fall short of what they’re capable of achieving. Leaders need to remember that human beings work for them, and human beings need to feel safe.“

There’s also another problem with achieving engagement, and that’s the “piecemeal” problem. Haudan likens this to a thousand-piece jigsaw puzzle, where workers get sent pieces one at a time, minus the box top to show employees how the pieces fit together. Without the picture, the pieces don’t seem to hang together: “Once piece says ‘Innovate,’ and another says ‘Cut costs.’ One says ‘Go slow’ and another says ‘Go fast!’ One piece says ‘Delight customers’ and another says ‘Reduce Inventory.’”

The book outlines some typical “conversations” that highlight typical gaps between strategy and execution:

Leaders saying something like, “This is our vision and mission,” with those on the front lines are responding, “Sounds blue sky to me. What does it mean to me and my people?” Leaders are saying, “You need to work smarter,” and the doers are countering with, “We can’t possibly work any harder!” Leaders exclaiming, “You are empowered!” while the doers are responding, “More flavor-of-the-month management.”

The solution? The book drove an excellent point home about the strength of visualization, and how visualization is a critical ingredient of engagement with many benefits:
  1. Visualization makes it easy to think in systems. It allows people to understand, connect, and focus systematically.
  2. Visualization creates simplicity. It forces us to “think simpler.” You can’t draw a crisp picture of something that hasn’t been thought through in great detail.
  3. Visualization captures the drama of business. It illustrates struggles, risks, threats, opportunities, and emotion in ways that data and words cannot. Tapping into this emotion challenges complacency and inspires activism within a business.
  4. Visualization enables us to think big or think strategically by showing us the whole. Thinking big allows us to focus on the major forces that drive our business rather than the everyday tactics that often occupy much of our time.
  5. Visualization appeals to most learners. In general, a visual culture is quickly replacing the traditional print culture, and there’s no question that it will be the approach of choice in the future.
  6. Visualization provides for quick recall. Visual images help most people retain information efficiently.
  7. Visualization enables nonlinear connections. Not everybody learns in a straight, progressive path. Each of us has to personalize the connections.
  8. Visualization acts as a universal common language by minimizing misinterpretations. It’s a consistent way to communicate among different cultures and languages.
  9. Visualization allows visual storytelling. It enables people to easily see an integrated story and talk about how they can add to it.
  10. Visualization connects people because it can display both facts and emotion. It conveys not only how the business looks but how it feels.
The Art of Engagement provided an excellent portrayal and the benefits of the strategic engagement process through visualization. I like the concept of people connecting through images and stories; after all, how many times have we in the software realm represented systems visually?

As Haudan observed, when we use visualization to portray the operations of a business, employees can more easily understand difficult concepts. Images eliminate the opportunity for widespread misinterpretation and generate a common, quickly understood language. After all, without an understanding of a company’s strategy, people can’t take responsibility for change.

I like one other quote from the book about strategy, and ties to what other people are saying, such as Dan Pink and his Autonomy, Mastery and Purpose as motivators:

Strategy is an adventure; even more, it’s a purposeful adventure.

If you want to examine connecting strategy to execution from a fresh perspective, this book is a well-written, must read.

Illustrations in this post are examples from the book, The Art of Engagement