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....
...-.-
Sunday, January 24, 2010
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....
...-.-
Subscribe to:
Posts (Atom)
