A common dysfunction I encounter when coaching Agile teams is a failure to understand the meaning of commitment. Scrum teams commit to delivering the Sprint backlog -- complete, tested, and ready to be shown to stakeholders by the end of the Sprint. That commitment means that the team members agree, freely and entirely of their own volition, to do their level best to meet their collective Sprint commitment. Does it always work out exactly as planned? No, of course not. But over the course of repeated Sprints, teams learn what that commitment looks and feels like and they get better at delivering on their commitments.
The lament I frequently hear is: "This team always misses its commitments." Oddly enough, I almost never hear that from members of the team in question. The source of the complaint is almost always from a stakeholder, functional manager, or executive at some level.
In the rare instance of a team whose members acknowledge that they routinely fail to meet their commitments, I work with the ScrumMaster, Product Owner, and team to ensure that they have good stories, solid acceptance criteria, follow the Agile rules for estimating, and that they understand the importance of building trust by doing what you say you are going to do. A team-based commitment failure is usually not difficult to overcome, although sometimes there can be a painful drop-off in perceived productivity as the team learns how to make a realistic commitment and deliver on it.
The much more common case of a stakeholder, functional manager, or executive expressing exasperation with routine commitment failure is usually easier to diagnose, but often more difficult to cure. The essential problem is a failure to understand that the team itself must commit to the Sprint backlog, freely and with complete consensus among team members. Any hint of a commitment that is forced from outside or arrived at without team consensus is automatically invalidated.
Think for a moment about the nature of commitment. We make commitments at many points in our lives. Marriage is a commitment. Having children and being a good parent is a commitment. While a Sprint backlog is trivial in comparison, the nature of the commitment required is exactly the same. Commitment must be voluntary. Commitments cannot be taken lightly. Commitment is a personal decision, sometimes taken in a collective context, as with a Sprint commitment when a team arrives at consensus.
One recent example of habitual commitment failure demonstrates very clearly a fundamental misunderstanding of the nature of commitment and the inevitable result. On a coaching engagement, I heard from an executive that several teams never met their Sprint commitments. He was intensely frustrated with the situation. A little probing of the situation revealed the exact nature of the problem: When asked where the Sprint commitment for the teams in question came from, his response was, "I tell them what they'll commit to each Sprint." It turns out that he had laid out the teams' Sprint commitments months in advance. I explained that a Sprint commitment forced on a team from outside placed the team under no obligation whatever and that such a policy had completely undermined the company's entire Agile practice. When the members of the teams confirmed my assessment of the situation, the executive backed off and started allowing each team to make and deliver its own Sprint commitments. The problem of Sprint commitments not delivered vanished instantly.
A related problem at the same client proved to be the result of the ScrumMaster assigning all tasks at Sprint planning. The team did have control over its Sprint backlog commitment, but pre-assigning tasks left the team fragmented, demoralized, and unable to make the daily adjustments necessary to meet their commitment. When the ScrumMaster agreed to allow team members to self-assign tasks on a daily basis and to self-organize, using the daily Scrum, to ensure that they did everything possible to meet their Sprint commitment, the result was amazing. The team became cohesive, lively, and productive. They began meeting their Sprint commitments and experienced a remarkable increase in velocity after a few Sprints.
Commitment is not just a buzz-word. It is a vital component of Agile and a key ingredient in every team's success. So do the right thing, empower your teams to commit and reap the benefits.
All for now....
...-.-
Friday, February 19, 2010
Sunday, January 24, 2010
Some Musings on Recognition
Watching the Golden Globe awards the other night, a couple of things struck me. The first was that people who do excellent work were being recognized for it. The reason that struck me is that, in my personal and consulting experience during the last decade, I have seen essentially nothing resembling a corporate award program for excellence in the workplace in the United States. I'm sure there are companies that still engage in this now seemingly quaint activity, but such things are not the norm anymore.
So what's up with that? Are we so deeply buried in the "just be happy you have a job" mentality that we have no time or interest to promote and reward excellence in the workplace? Perhaps this is a symptom of the pervasive job dissatisfaction plaguing the US. Currently 55% of Americans are dissatisfied with their jobs. I'm not sure where the answer lies. What I do know is that we cannot afford to have a largely disaffected workforce if we in the US intend to avoid a sharp and disastrous economic decline.
The other thing that struck me about the awards show was that, as each winner spoke about the privilege of receiving the award, thanking parents, spouses, children, directors, actors, the Hollywood Foreign Press Association, etc., they all kept coming back to the statement that their project was a collaborative endeavor involving a team of dedicated professionals. Martin Scorsese hit on this point repeatedly in his speech.
So what does any of this have to do with coaching Agile teams? The first thought I have is that there is nothing inimical to teamwork in recognizing individual contributions to the success of the team. We don't want to encourage the development of a hero mentality within a team or destructive internal competition, but it is entirely appropriate to recognize individual excellence in a team setting.
How do we recognize excellence in a way that promotes teamwork? One excellent way is to include appreciations in every team retrospective. Not only do appreciations help build a team mentality, they also provide an incredibly appropriate setting in which to recognize individual excellence in a team setting.
All for now....
...-.-
So what's up with that? Are we so deeply buried in the "just be happy you have a job" mentality that we have no time or interest to promote and reward excellence in the workplace? Perhaps this is a symptom of the pervasive job dissatisfaction plaguing the US. Currently 55% of Americans are dissatisfied with their jobs. I'm not sure where the answer lies. What I do know is that we cannot afford to have a largely disaffected workforce if we in the US intend to avoid a sharp and disastrous economic decline.
The other thing that struck me about the awards show was that, as each winner spoke about the privilege of receiving the award, thanking parents, spouses, children, directors, actors, the Hollywood Foreign Press Association, etc., they all kept coming back to the statement that their project was a collaborative endeavor involving a team of dedicated professionals. Martin Scorsese hit on this point repeatedly in his speech.
So what does any of this have to do with coaching Agile teams? The first thought I have is that there is nothing inimical to teamwork in recognizing individual contributions to the success of the team. We don't want to encourage the development of a hero mentality within a team or destructive internal competition, but it is entirely appropriate to recognize individual excellence in a team setting.
How do we recognize excellence in a way that promotes teamwork? One excellent way is to include appreciations in every team retrospective. Not only do appreciations help build a team mentality, they also provide an incredibly appropriate setting in which to recognize individual excellence in a team setting.
All for now....
...-.-
Saturday, January 16, 2010
Scrum != !Scrum
This formulation, which should really be an Assert() statement, struck me the other day as I was reading about some of the fallout from the recent changes in the board of directors of the Scrum Alliance. I have read about some of Ken Schwaber's famous (infamous?) conflicts with various members of the Scrum Alliance community. I also have colleagues who have faced the ire of Mr. Schwaber for promoting ideas that Ken found inimical to Scrum.
In a very major sense, I admire Ken for defending Scrum. Indeed, I find his tenacity refreshing, inspiring even. There are so many people who would dilute Scrum for whatever reason. As with some clients I have worked with, some people want to change or even drop key elements of Scrum because they would rather paper over dysfunctions Scrum has exposed instead of fixing the root cause of the problem. Ken's devotion to Scrum has helped me repeatedly in sticking to my guns and insisting that teams I am coaching follow Scrum practices rather than taking the path of least resistance.
Other people believe, not necessarily incorrectly, that they have discovered an optimization to one or more Scrum practices and then want to share their discovery with the rest of the Scrum community. I see no issues with sharing the idea or experience. That in and of itself, however, does not mean that Scrum has been extended, improved, or changed. The Scrum community must validate changes to the basic practices and adopt them as part of Scrum. There should not, in my view, be any restriction on the sharing of experiences and ideas about Scrum.
This brings us to what I see as two problem areas. The first is that the Scrum Alliance is perfectly justified in cautioning Certified Scrum Trainers against teaching practices in CSM or CSPO courses that are not part of the recognized and agreed-upon components of Scrum. Put more simply, no one should be passing off anything that is not Scrum as Scrum in certified training courses. Additional practices, extensions, or differing interpretations of Scrum and its practices should not be suppressed, simply not labeled as certified Scrum.
The second problem arises from extending the first problem beyond the bounds of certified Scrum. Colleagues of mine have been cautioned very strongly against presenting, teaching, or writing about extensions, modifications, or variations on standard Scrum practices, even when those non-standard items are never advertised as parts of certified Scrum. To me, this goes beyond defense of Scrum and into the realm of censorship. New ideas need to be given free hearing and either added to the body of knowledge and practices of certified Scrum or not. That decision rests with the Scrum community, however, and not with any specific individual.
So, to recapitulate, certified Scrum is what the Scrum Alliance says it is and should be taught as such. Other ideas should be given a free and open hearing and freely discussed, but should not be passed off as a part of certified Scrum. At least that's my interpretation.
All for now.
...-.-
In a very major sense, I admire Ken for defending Scrum. Indeed, I find his tenacity refreshing, inspiring even. There are so many people who would dilute Scrum for whatever reason. As with some clients I have worked with, some people want to change or even drop key elements of Scrum because they would rather paper over dysfunctions Scrum has exposed instead of fixing the root cause of the problem. Ken's devotion to Scrum has helped me repeatedly in sticking to my guns and insisting that teams I am coaching follow Scrum practices rather than taking the path of least resistance.
Other people believe, not necessarily incorrectly, that they have discovered an optimization to one or more Scrum practices and then want to share their discovery with the rest of the Scrum community. I see no issues with sharing the idea or experience. That in and of itself, however, does not mean that Scrum has been extended, improved, or changed. The Scrum community must validate changes to the basic practices and adopt them as part of Scrum. There should not, in my view, be any restriction on the sharing of experiences and ideas about Scrum.
This brings us to what I see as two problem areas. The first is that the Scrum Alliance is perfectly justified in cautioning Certified Scrum Trainers against teaching practices in CSM or CSPO courses that are not part of the recognized and agreed-upon components of Scrum. Put more simply, no one should be passing off anything that is not Scrum as Scrum in certified training courses. Additional practices, extensions, or differing interpretations of Scrum and its practices should not be suppressed, simply not labeled as certified Scrum.
The second problem arises from extending the first problem beyond the bounds of certified Scrum. Colleagues of mine have been cautioned very strongly against presenting, teaching, or writing about extensions, modifications, or variations on standard Scrum practices, even when those non-standard items are never advertised as parts of certified Scrum. To me, this goes beyond defense of Scrum and into the realm of censorship. New ideas need to be given free hearing and either added to the body of knowledge and practices of certified Scrum or not. That decision rests with the Scrum community, however, and not with any specific individual.
So, to recapitulate, certified Scrum is what the Scrum Alliance says it is and should be taught as such. Other ideas should be given a free and open hearing and freely discussed, but should not be passed off as a part of certified Scrum. At least that's my interpretation.
All for now.
...-.-
Insurgent Scrum
Just watching Everton take Manchester City apart. Nice to see the Toffees in full recovery from their awful start to the Premier League season. The snow is also finally beginning to melt off after over a month of cold weather and continuous snow cover. North-central Colorado isn't Minnesota after all and we're not used to snow cover for weeks on end.
Thinking about the ways in which Scrum can get started in an organization, one possibility is an insurgent movement on the ground. I have experienced Insurgent Scrum on a couple of occasions. The driving force is usually the total desperation of a development group in the face of an organization in chaos that is unwilling to change its ways. In my experience, the development manager and some or all of his charges decide that they are going to work as a team, deliver working increments of software, and use as much of Scrum as they possibly can. As a team, they convert requirements into user stories, prioritize the stories with or without direct input from the business/PMO, plan their Sprints, commit to the plan, and get on with it day-by-day. On one occasion, the development manager was able to bring the QA manager on board as well, resulting in good automated testing practices being put into place and the formation of something very closely resembling a cross-functional team.
The development of a team dynamic and the sense -- and reality -- of accomplishment that came from delivering working product increments every two weeks brought about great improvements in product quality, staff morale, and productivity. Everyone involved wanted nothing to do with going back to the old command-and-control, isolated individual style of work. The QA staff realized the biggest improvement in their working lives, the result of the emphasis on automated testing and the distribution of testing throughout the course of each Sprint, instead of the usual over-the-wall at the last minute testing push.
That was the end of the positive results, unfortunately. The business and PMO, once they figured out what was going on, applied massive pressure to return things to the way they had been before the Insurgent Scrum movement started. In both of my experiences, it turned out that vastly improved quality, increased productivity, and empirically derived planning were not sufficient to overcome the perceived loss of control. Allowing developers to chose their own daily work, and even worse, to determine their own Sprint commitments, constituted a threatening degree of freedom. The universal expectation in the business and the PMO was that they would give the orders, down to the level of specific design solutions and that development and QA were there simply to type in the code and test the results. Wow. Ultimately, control was more important than the success of the product and indeed the success of the company. Double wow.
In neither case that I experienced personally was Insurgent Scrum successful. It did lift product quality, improve planning, and, most importantly, improve the daily working lives of the people doing the work. In one instance, the front-line managers dug in their heels and refused to stop using Scrum. The only way the business could find to squash the insurgency was to lay off the entire development and QA staffs, including the managers. Triple wow. Strangely enough, I have seen similar outcomes, minus the layoffs, when coaching organizations that brought me in specifically to help them in their move to Agile/Scrum.
So what's the lesson here? Well, first of all, I am convinced that Insurgent Scrum is worth the risk. Improving the working lives of the people on the ground is worthwhile regardless of the ultimate outcome. There is also always the very distinct possibility that an organization will see the benefits of Scrum and adopt it on a grander scale, using the original insurgency as the example of success and the source of practical knowledge which could then be spread throughout the organization. Companies that are focused on winning, instead of on control and corporate politics, will clearly follow the model that leads to successful adoption of Scrum.
Is your organization focused on success? How will you know? It may be impossible to tell until you start, which is where courage comes into play. Be courageous, but always remember that discretion is truly the better part of valor. Get going with Scrum, but avoid open provocation. Demonstrate the benefits of Scrum: delivery of working product increments, fully tested, ready for release, and with much greater predictability than is possible under traditional defined process management; vastly improved staff morale and therefore productivity; innovation as a matter of course; and on and on. Build trust Sprint-by-Sprint. If your company is unable to recognize the benefits of Scrum, it's an unmistakable sign of where the organization's priorities lie.
All for now....
...-.-
Thinking about the ways in which Scrum can get started in an organization, one possibility is an insurgent movement on the ground. I have experienced Insurgent Scrum on a couple of occasions. The driving force is usually the total desperation of a development group in the face of an organization in chaos that is unwilling to change its ways. In my experience, the development manager and some or all of his charges decide that they are going to work as a team, deliver working increments of software, and use as much of Scrum as they possibly can. As a team, they convert requirements into user stories, prioritize the stories with or without direct input from the business/PMO, plan their Sprints, commit to the plan, and get on with it day-by-day. On one occasion, the development manager was able to bring the QA manager on board as well, resulting in good automated testing practices being put into place and the formation of something very closely resembling a cross-functional team.
The development of a team dynamic and the sense -- and reality -- of accomplishment that came from delivering working product increments every two weeks brought about great improvements in product quality, staff morale, and productivity. Everyone involved wanted nothing to do with going back to the old command-and-control, isolated individual style of work. The QA staff realized the biggest improvement in their working lives, the result of the emphasis on automated testing and the distribution of testing throughout the course of each Sprint, instead of the usual over-the-wall at the last minute testing push.
That was the end of the positive results, unfortunately. The business and PMO, once they figured out what was going on, applied massive pressure to return things to the way they had been before the Insurgent Scrum movement started. In both of my experiences, it turned out that vastly improved quality, increased productivity, and empirically derived planning were not sufficient to overcome the perceived loss of control. Allowing developers to chose their own daily work, and even worse, to determine their own Sprint commitments, constituted a threatening degree of freedom. The universal expectation in the business and the PMO was that they would give the orders, down to the level of specific design solutions and that development and QA were there simply to type in the code and test the results. Wow. Ultimately, control was more important than the success of the product and indeed the success of the company. Double wow.
In neither case that I experienced personally was Insurgent Scrum successful. It did lift product quality, improve planning, and, most importantly, improve the daily working lives of the people doing the work. In one instance, the front-line managers dug in their heels and refused to stop using Scrum. The only way the business could find to squash the insurgency was to lay off the entire development and QA staffs, including the managers. Triple wow. Strangely enough, I have seen similar outcomes, minus the layoffs, when coaching organizations that brought me in specifically to help them in their move to Agile/Scrum.
So what's the lesson here? Well, first of all, I am convinced that Insurgent Scrum is worth the risk. Improving the working lives of the people on the ground is worthwhile regardless of the ultimate outcome. There is also always the very distinct possibility that an organization will see the benefits of Scrum and adopt it on a grander scale, using the original insurgency as the example of success and the source of practical knowledge which could then be spread throughout the organization. Companies that are focused on winning, instead of on control and corporate politics, will clearly follow the model that leads to successful adoption of Scrum.
Is your organization focused on success? How will you know? It may be impossible to tell until you start, which is where courage comes into play. Be courageous, but always remember that discretion is truly the better part of valor. Get going with Scrum, but avoid open provocation. Demonstrate the benefits of Scrum: delivery of working product increments, fully tested, ready for release, and with much greater predictability than is possible under traditional defined process management; vastly improved staff morale and therefore productivity; innovation as a matter of course; and on and on. Build trust Sprint-by-Sprint. If your company is unable to recognize the benefits of Scrum, it's an unmistakable sign of where the organization's priorities lie.
All for now....
...-.-
Tuesday, January 5, 2010
Organic Scrum
Whenever I step into a coaching engagement, one of the first pieces of information I track down is where the initiative for the move to Scrum originated. The answer is invariably one of three: a top-down initiative; a move from the middle outward; or an organic, bottom-up approach. The first two types present challenges of their own, of course, but the third, what I have taken to calling Organic Scrum, presents many special circumstances and difficulties not generally found in the first two.
The usual path into an Organic Scrum setting is that a functional manager or technical lead either learns about Scrum or has been in a Scrum/Agile environment previously. The leverage is usually a troublesome project that is either in progress or on tap. The troublesome part of the proposed pilot project is that it is either stuck or has already failed at least once using traditional project management practices and needs to be restarted afresh. Either of these situations produces the right mix of management desperation and therefore openness to new ideas to make an Organic Scrum push possible. And despite the deck being stacked so unfavorably, troubled projects are often ideal candidates for Scrum.
Under the best of circumstances, the person championing the move to Scrum is able to coax management at a higher level to devote some resources to training and coaching, which is, of course, where I usually enter the scene. Under less favorable circumstances, the entire Scrum transition ends up without management support or resources and takes on the character of an insurgent movement. I'll try to cover insurgent Scrum in a later posting. Now, back to Organic Scrum....
The greatest challenges in an Organic Scrum environment, both for me as coach and for the people who want to get Scrum moving, are setting up a truly cross-functional, self-organizing, self-managing team and getting some level of cooperation from the business so that the team can work from a prioritized backlog. Let's examine each issue separately.
Most US companies are organized along functional lines, creating the very skill silos W. Edwards Deming decried over 60 years ago. Unless the silo walls can at least be bent or stretched, the nascent Scrum team will not be able to deliver a working product increment each Sprint. The major silo division is almost always between development and QA, although there can be others, equally insidious, that divide development into specialized segments that maintain a mutual over-the-wall mentality. Architecture and design also commonly form another silo. Punching holes in these functional silos is the first priority in an Organic Scrum movement. Breaking the shared-resource organizational model -- the "matrixed" organization -- is a common follow-on activity. The members of the Scrum team must be allowed to focus on the project Scrum is supposed to deliver. Failure in either of these areas generally proves to be a hard stop in the development of Organic Scrum.
Assuming the silo walls can be made permeable enough to allow the formation of a cross-functional product team and that the company allows the team members to exit the matrix, the next big step is to find a courageous ScrumMaster to support self-organization/self-management and protect the team from the inevitable distractions. The new cross-functional team members almost always report to different functional managers, yet as members of a self-organizing, self-managing Scrum team, that reporting relationship must change. It is often the ScrumMaster's unpleasant duty to inform various functional managers -- and sometimes higher-level managers as well -- that no one gives orders here anymore. The team commits to work and delivers on its commitments however the team members collectively see fit to do so.
A common area of team distraction is outside interference with the team's Sprint work in the form of requests to do something unrelated to the Sprint. It is not unusual for this form of interference to come from the very same functional managers who garner the ScrumMaster's attention for other reasons. It's really not the functional managers fault -- they have other projects that need to get done so they call on their direct reports, assigning work as they always have. The problem is that distractions are a common source of a team's failure to deliver on Sprint commitments. Delivering on Sprint commitments is the Scrum team's only way to build trust with the organization and with the business. Finding the right person to take on the ScrumMaster role is so vital that failure in this area also constitutes a hard stop.
The final major ingredient needed to grow Organic Scrum is cooperation of the business. When I coach in Organic Scrum situations, I invariably spend a huge amount of time and energy working with the business to help build an understanding of what the Scrum team is trying to do, why they're doing it, what the benefits are for the business, and how the business plays a vital role in making it all possible. In most cases the benefit side of the equation is an easy sell: the business gets a fully tested, working product increment at the end of each Sprint. The required input from the business can be more difficult to sell, however. It can be difficult for people schooled in traditional project management to let go of the detailed requirements document, delivered to development before a line of code gets written. It can also be difficult for traditional project managers to give up the perception of control that comes from telling people what to do and how to do it. If we can overcome those hurdles, the business must then at least agree to provide a Product Owner for the team or work with a Product Owner the team designates. The business must also agree to prioritize a backlog from which the team can work, to define acceptance criteria (the all-important definition of "done") for each user story, and to review the output of each Sprint.
The business can certainly be skeptical of the idea of Scrum, but must play by the rules, even if grudgingly, in order for Organic Scrum to have a chance to succeed. When I coach, I emphasize the inherent trust-building that takes place when a team commits to a Sprint backlog and then delivers on that commitment, Sprint-after-Sprint. As long as the business is more interested in results than in control, trust is the Scrum team's most powerful incentive to continue and indeed expand Scrum within the organization.
All for now....
...-.-
The usual path into an Organic Scrum setting is that a functional manager or technical lead either learns about Scrum or has been in a Scrum/Agile environment previously. The leverage is usually a troublesome project that is either in progress or on tap. The troublesome part of the proposed pilot project is that it is either stuck or has already failed at least once using traditional project management practices and needs to be restarted afresh. Either of these situations produces the right mix of management desperation and therefore openness to new ideas to make an Organic Scrum push possible. And despite the deck being stacked so unfavorably, troubled projects are often ideal candidates for Scrum.
Under the best of circumstances, the person championing the move to Scrum is able to coax management at a higher level to devote some resources to training and coaching, which is, of course, where I usually enter the scene. Under less favorable circumstances, the entire Scrum transition ends up without management support or resources and takes on the character of an insurgent movement. I'll try to cover insurgent Scrum in a later posting. Now, back to Organic Scrum....
The greatest challenges in an Organic Scrum environment, both for me as coach and for the people who want to get Scrum moving, are setting up a truly cross-functional, self-organizing, self-managing team and getting some level of cooperation from the business so that the team can work from a prioritized backlog. Let's examine each issue separately.
Most US companies are organized along functional lines, creating the very skill silos W. Edwards Deming decried over 60 years ago. Unless the silo walls can at least be bent or stretched, the nascent Scrum team will not be able to deliver a working product increment each Sprint. The major silo division is almost always between development and QA, although there can be others, equally insidious, that divide development into specialized segments that maintain a mutual over-the-wall mentality. Architecture and design also commonly form another silo. Punching holes in these functional silos is the first priority in an Organic Scrum movement. Breaking the shared-resource organizational model -- the "matrixed" organization -- is a common follow-on activity. The members of the Scrum team must be allowed to focus on the project Scrum is supposed to deliver. Failure in either of these areas generally proves to be a hard stop in the development of Organic Scrum.
Assuming the silo walls can be made permeable enough to allow the formation of a cross-functional product team and that the company allows the team members to exit the matrix, the next big step is to find a courageous ScrumMaster to support self-organization/self-management and protect the team from the inevitable distractions. The new cross-functional team members almost always report to different functional managers, yet as members of a self-organizing, self-managing Scrum team, that reporting relationship must change. It is often the ScrumMaster's unpleasant duty to inform various functional managers -- and sometimes higher-level managers as well -- that no one gives orders here anymore. The team commits to work and delivers on its commitments however the team members collectively see fit to do so.
A common area of team distraction is outside interference with the team's Sprint work in the form of requests to do something unrelated to the Sprint. It is not unusual for this form of interference to come from the very same functional managers who garner the ScrumMaster's attention for other reasons. It's really not the functional managers fault -- they have other projects that need to get done so they call on their direct reports, assigning work as they always have. The problem is that distractions are a common source of a team's failure to deliver on Sprint commitments. Delivering on Sprint commitments is the Scrum team's only way to build trust with the organization and with the business. Finding the right person to take on the ScrumMaster role is so vital that failure in this area also constitutes a hard stop.
The final major ingredient needed to grow Organic Scrum is cooperation of the business. When I coach in Organic Scrum situations, I invariably spend a huge amount of time and energy working with the business to help build an understanding of what the Scrum team is trying to do, why they're doing it, what the benefits are for the business, and how the business plays a vital role in making it all possible. In most cases the benefit side of the equation is an easy sell: the business gets a fully tested, working product increment at the end of each Sprint. The required input from the business can be more difficult to sell, however. It can be difficult for people schooled in traditional project management to let go of the detailed requirements document, delivered to development before a line of code gets written. It can also be difficult for traditional project managers to give up the perception of control that comes from telling people what to do and how to do it. If we can overcome those hurdles, the business must then at least agree to provide a Product Owner for the team or work with a Product Owner the team designates. The business must also agree to prioritize a backlog from which the team can work, to define acceptance criteria (the all-important definition of "done") for each user story, and to review the output of each Sprint.
The business can certainly be skeptical of the idea of Scrum, but must play by the rules, even if grudgingly, in order for Organic Scrum to have a chance to succeed. When I coach, I emphasize the inherent trust-building that takes place when a team commits to a Sprint backlog and then delivers on that commitment, Sprint-after-Sprint. As long as the business is more interested in results than in control, trust is the Scrum team's most powerful incentive to continue and indeed expand Scrum within the organization.
All for now....
...-.-
Thursday, December 10, 2009
Why ScrumMaster is a Full-time Job
Teams and sponsors invariably ask the following question during initial Agile/Scrum training: “Is ScrumMaster really a full-time job?” When I immediately answer with a resounding “Yes,” the looks of incredulity are impossible for the team and sponsors to hide and equally impossible for me to ignore. More explanation is always necessary.
It is, however, a perfectly valid question. My response to the accusatory stares and occasional guffaws begins with a description of what constitutes a living, breathing product team. In the software industry we have deluded ourselves for decades that a group of individuals who just happen to be working on the same project constitutes a “team.” Therein lies the essence of the problem: building actual product teams is hard work, harder than almost anyone who takes on the role of ScrumMaster for the first time can imagine.
The first problem I encounter as a coach is that most organizations lack a person with the correct skill set to be a successful ScrumMaster out of the gate. I always try to steer clients away from the idea of appointing a ScrumMaster at all, preferring that they ask for a volunteer – after I have described in detail what the role requires. Barring the self-organizing solution, I encourage clients not to appoint a technical lead, architect, or functional manager as ScrumMaster. The first two sets of people are usually interested in the technical aspects of the work only and would find the duties of the ScrumMaster role an unwelcome distraction. Functional managers typically find it particularly difficult to wrap their heads around the servant-leader concept, especially if they are accustomed to issuing detailed instructions to the people inside their functional silo. Functional managers generally also find it difficult to adapt to the idea of cross-functional product teams, seeing such a development as either against nature or as a direct threat to their own positions. Finally, even if a functional manager is completely on-board with Agile values and principles and Scrum practices, the authority relationship that exists may prevent team members from dealing with their manager/ScrumMaster properly. It is difficult as a team member, for example, to express concerns in a Retrospective about the ScrumMaster’s handling of the role when that same person is your functional manager.
None of this is to say that technical leads, architects, or functional managers are always unsuited to the role of ScrumMaster; it is simply a more difficult adjustment at best and an unwanted distraction at worst. My advice always comes back to self-organization. Sometimes the best ScrumMaster is the person on the team who doesn’t have the most advanced technical skills. Since a large portion of the ScrumMaster’s duties revolve around being a Scrum champion and coach, so-called soft skills are much more important to the role than sheer technical prowess. When everyone realizes fully just how thankless and even dangerous (in the corporate/professional sense) the role of ScrumMaster can be, only those individuals who are really interested will volunteer.
My friend and colleague Jeff McKenna often says that the most applicable training he ever received in preparation for being a ScrumMaster was his extensive coursework in family counseling. While this statement initially generates laughter, whether genuine or of the nervous variety, it gets the point across unambiguously. A product team is very much like a family, with the major exception that most or all of the members of a team can choose to join a different team if things get too difficult. For the most part, however, teams have to work through the inevitable rough patches if they are ever to achieve high levels of performance. Remember, the Tuckman Model ends with Performing, but only after passing through the Forming, Storming, and Norming stages.
So what are the essential skills and characteristics of a good ScrumMaster? How about starting with this list, which is neither complete nor exhaustive:
All for now.
...-.-
It is, however, a perfectly valid question. My response to the accusatory stares and occasional guffaws begins with a description of what constitutes a living, breathing product team. In the software industry we have deluded ourselves for decades that a group of individuals who just happen to be working on the same project constitutes a “team.” Therein lies the essence of the problem: building actual product teams is hard work, harder than almost anyone who takes on the role of ScrumMaster for the first time can imagine.
The first problem I encounter as a coach is that most organizations lack a person with the correct skill set to be a successful ScrumMaster out of the gate. I always try to steer clients away from the idea of appointing a ScrumMaster at all, preferring that they ask for a volunteer – after I have described in detail what the role requires. Barring the self-organizing solution, I encourage clients not to appoint a technical lead, architect, or functional manager as ScrumMaster. The first two sets of people are usually interested in the technical aspects of the work only and would find the duties of the ScrumMaster role an unwelcome distraction. Functional managers typically find it particularly difficult to wrap their heads around the servant-leader concept, especially if they are accustomed to issuing detailed instructions to the people inside their functional silo. Functional managers generally also find it difficult to adapt to the idea of cross-functional product teams, seeing such a development as either against nature or as a direct threat to their own positions. Finally, even if a functional manager is completely on-board with Agile values and principles and Scrum practices, the authority relationship that exists may prevent team members from dealing with their manager/ScrumMaster properly. It is difficult as a team member, for example, to express concerns in a Retrospective about the ScrumMaster’s handling of the role when that same person is your functional manager.
None of this is to say that technical leads, architects, or functional managers are always unsuited to the role of ScrumMaster; it is simply a more difficult adjustment at best and an unwanted distraction at worst. My advice always comes back to self-organization. Sometimes the best ScrumMaster is the person on the team who doesn’t have the most advanced technical skills. Since a large portion of the ScrumMaster’s duties revolve around being a Scrum champion and coach, so-called soft skills are much more important to the role than sheer technical prowess. When everyone realizes fully just how thankless and even dangerous (in the corporate/professional sense) the role of ScrumMaster can be, only those individuals who are really interested will volunteer.
My friend and colleague Jeff McKenna often says that the most applicable training he ever received in preparation for being a ScrumMaster was his extensive coursework in family counseling. While this statement initially generates laughter, whether genuine or of the nervous variety, it gets the point across unambiguously. A product team is very much like a family, with the major exception that most or all of the members of a team can choose to join a different team if things get too difficult. For the most part, however, teams have to work through the inevitable rough patches if they are ever to achieve high levels of performance. Remember, the Tuckman Model ends with Performing, but only after passing through the Forming, Storming, and Norming stages.
So what are the essential skills and characteristics of a good ScrumMaster? How about starting with this list, which is neither complete nor exhaustive:
- Calm
- Patient
- Able to listen rather than talk
- Has the courage to take on organizational and cultural impediments
- Comfortable when team members talk about personal issues that affect their work
- Encourages team members to express how they’re feeling about the work, Scrum, their teammates, etc.
- Understands and supports collaboration
- Supports – to the point of demanding – self-management and self-organization
- Tenaciously protects the team from distractions and outside interference
- Dedicated to learning tools and techniques to foster team development
- Understands that it’s about the team, not the ScrumMaster
All for now.
...-.-
Tuesday, November 17, 2009
The Trouble with Agile
I have been on a disturbing number of coaching engagements this year that ended in something less than complete success. Indeed, it would be more accurate to categorize these engagements as failures falling somewhere between dismal and catastrophic, depending on the engagement.
The storyline was disturbingly familiar in all cases, however. Every one of these engagements began with one or more standard Agile/Scrum training courses, which is always a good thing. The disturbing part was the degree to which the training revealed just how uninterested in Agile the organization really was. Attendance in the class or classes was by compulsion, usually to the extreme discomfort of the participants who typically received no reprieve from their normal responsibilities during the two or three days of training. That is always the first “uh-oh” moment in any training course. It doesn’t always end badly, but is certainly not a good way to start.
During the training, as I present the various principles and their related practices, comments from the class indicate where the entire engagement is headed. For example, when I talk about just-in-time planning, relative estimating done by the people doing the work, or working in Sprints and the implication of focusing on a single project for the duration, the responses usually fall into one of several categories depending on where we are in the failure continuum. If an engagement is in the “dismal failure” part of the spectrum, the participants’ responses fall into the realm of “That is so cool! Too bad we’ll never be able to do that here.” If, on the other hand, we’re in catastrophic failure country, the responses are more along the lines of “The PMO/management provides all of our deadlines/scoping/estimates/project matrices and there’s no way that’s ever going to change.” If such utterances emanate from a functional manager, Project Manager, or executive in the class, the needle hits the peg on the “Catastrophic Failure” side of the gauge. Ordinary working people express identical sentiments, but with a sigh of hopeless frustration. Either way, the result is inevitably the same.
Another fatal expression I hear during training sessions on doomed engagements is: “How can we change (insert Agile practice here) to fit with the way we work here?” Or, “How can we (insert company name here)-ize Scrum?” As a coach, you know you’re in serious trouble whenever you hear these statements.
All of these issues boil down to a failure to understand that Agile requires deep and sometimes difficult organizational and cultural change. There is no quick, easy fix, no veneer to overlay on top of a company’s current organization, culture, or processes that can fix their deep-seated dysfunctions.
The vast majority of these failed engagements break upon the rocks of the most fundamental Agile principles and practices: If a company is unwilling to change its organizational structure to break down functional silos so that real-live cross-functional product teams can come into existence, well, there’s simply no use in even talking about the additional layers of change that are required to move forward.
The trouble with Agile is that it is essentially an all-or-nothing package of principles and practices, that is, the rules of the game which must be followed. There is no picking and choosing among key principles and practices, and therefore no magic wand, no quick fix, no “Fix our quality/delivery/efficiency problems, but don’t change anything” solution. Executives, functional managers, Project Managers, and people on the front lines all have to be committed to changing their organizational structures, culture, and processes, sometimes in deep and potentially painful ways, if the company is to reap the full benefits of Agile and win in the market.
“Agile” is a hot buzzword these days and companies large and small (but mostly large) are hoping to jump on the bandwagon. Unfortunately, many companies are looking only for the quick, painless fix, the flavor of the week, not the kind of far-reaching change that is going to transform the organization into a powerhouse of innovation and adaptability. And that is the trouble with Agile.
All for now....
...-.-
The storyline was disturbingly familiar in all cases, however. Every one of these engagements began with one or more standard Agile/Scrum training courses, which is always a good thing. The disturbing part was the degree to which the training revealed just how uninterested in Agile the organization really was. Attendance in the class or classes was by compulsion, usually to the extreme discomfort of the participants who typically received no reprieve from their normal responsibilities during the two or three days of training. That is always the first “uh-oh” moment in any training course. It doesn’t always end badly, but is certainly not a good way to start.
During the training, as I present the various principles and their related practices, comments from the class indicate where the entire engagement is headed. For example, when I talk about just-in-time planning, relative estimating done by the people doing the work, or working in Sprints and the implication of focusing on a single project for the duration, the responses usually fall into one of several categories depending on where we are in the failure continuum. If an engagement is in the “dismal failure” part of the spectrum, the participants’ responses fall into the realm of “That is so cool! Too bad we’ll never be able to do that here.” If, on the other hand, we’re in catastrophic failure country, the responses are more along the lines of “The PMO/management provides all of our deadlines/scoping/estimates/project matrices and there’s no way that’s ever going to change.” If such utterances emanate from a functional manager, Project Manager, or executive in the class, the needle hits the peg on the “Catastrophic Failure” side of the gauge. Ordinary working people express identical sentiments, but with a sigh of hopeless frustration. Either way, the result is inevitably the same.
Another fatal expression I hear during training sessions on doomed engagements is: “How can we change (insert Agile practice here) to fit with the way we work here?” Or, “How can we (insert company name here)-ize Scrum?” As a coach, you know you’re in serious trouble whenever you hear these statements.
All of these issues boil down to a failure to understand that Agile requires deep and sometimes difficult organizational and cultural change. There is no quick, easy fix, no veneer to overlay on top of a company’s current organization, culture, or processes that can fix their deep-seated dysfunctions.
The vast majority of these failed engagements break upon the rocks of the most fundamental Agile principles and practices: If a company is unwilling to change its organizational structure to break down functional silos so that real-live cross-functional product teams can come into existence, well, there’s simply no use in even talking about the additional layers of change that are required to move forward.
The trouble with Agile is that it is essentially an all-or-nothing package of principles and practices, that is, the rules of the game which must be followed. There is no picking and choosing among key principles and practices, and therefore no magic wand, no quick fix, no “Fix our quality/delivery/efficiency problems, but don’t change anything” solution. Executives, functional managers, Project Managers, and people on the front lines all have to be committed to changing their organizational structures, culture, and processes, sometimes in deep and potentially painful ways, if the company is to reap the full benefits of Agile and win in the market.
“Agile” is a hot buzzword these days and companies large and small (but mostly large) are hoping to jump on the bandwagon. Unfortunately, many companies are looking only for the quick, painless fix, the flavor of the week, not the kind of far-reaching change that is going to transform the organization into a powerhouse of innovation and adaptability. And that is the trouble with Agile.
All for now....
...-.-
Subscribe to:
Posts (Atom)
