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.