diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..757fe50 --- /dev/null +++ b/.gitignore @@ -0,0 +1,2 @@ +*.pdf +!97-things-every-agile-developer-shoud-know.pdf diff --git a/97-things-every-agile-developer-should-know.pdf b/97-things-every-agile-developer-should-know.pdf new file mode 100644 index 0000000..351ad99 Binary files /dev/null and b/97-things-every-agile-developer-should-know.pdf differ diff --git a/Create_Real_and_Lasting_Change.asciidoc b/Create_Real_and_Lasting_Change.asciidoc deleted file mode 100644 index 0543a00..0000000 --- a/Create_Real_and_Lasting_Change.asciidoc +++ /dev/null @@ -1,73 +0,0 @@ -== How to Create Real and Lasting Change - -As a developer you're probably well aware that there's a better way to do many things in your organization. Because you are on the front lines of product development you acutely feel the effects of the dysfunction in other departments and undoubtedly see things others don't. -This is why most Agile transformations I've seen start with agitation from the people actually building the product. - -If we think of an organizations as an organism the pain the development team feels—and the subsequent loss of business performance the organization notices—is the proverbial thorn in the paw that finally creates an opening for an organization to ask for help and make a change. -The challenge you face however once you wade into a change of process is that what you're up to defies logic, doesn't move in a linear path, and is more about a shift of culture than it is about any specific practice you may want to change. - -The Thigh Bone's Connected to the Leg Bone Not only are your products complex with each technical decision having far-reaching impacts on scalability, stability, extensibility, and more. But your organization is complex as well. And the most important algorithms that govern the behavior of our businesses are poorly understood, poorly documented, and so mysterious that even the inmates running the asylum often don't know what to do to make real change. - -For instance, one of the most common anti-patterns I see in organization is the heroin-like dependency on big up-front requirements definition and multiple layers of approval for these requirements. - -I frequently work with teams to install a just-in-time, collaborative flows for the elaboration of requirements. This is something foundational to organizational agility and whose value I can demonstrate to almost anyone with a few pennies and some balls of paper—e.g. by teaching the penny-flip and ball-point games. And yet I'm frequently thwarted because the team at hand does not have the autonomy to finalize requirements AND they are locked into explicit (or implicit and hidden) development phase gates. - -This problem might seem simple on the surface. All we need to do is get those people to give us some autonomy and get the heck out of the way so we can do our darn jobs. But peeling this onion reveals layer upon layer of messy human stuff. - -There's the product manager, dev lead, and project manager who are wondering what their job actually is if they are not signing off on each layer. There's the paper trail that management requires—but no one reads. There are auditors to satisfy and funding to secure for each project. - -And there's the development team that, having spent the last several years working in a command and control environment finds it spooky and unsafe to take responsibility. - -Dysfunction is Baked In The truth is that most of our organizations have fear and a lack of accountability at the core of their culture. "command and-control" is just a nice way of saying "my way or the highway" and managing with implied threats and seeking compliance out of fear. - -If we are to change our process and really start doing things iteratively, incrementally, and with front-line responsibility for quality, we must wade into the strange waters of the human psyche. As we do so we are going to agitate the organizational antibodies that always seem ready to attack any threat to the status quo. -So we start by saying "let's change the way we do things around here" and eventually find ourselves wrestling with sticky questions of identity. We move from doing something different to being something different. This is not a bad thing, this flow from doing to being. It's actually one of the only means of change that actually works. Where we run into trouble is if we work to change and don't anticipate the messy human stuff coming up. - -One of the most demonstrably effective forms of psychological therapy is Cognitive Behavioral Therapy that starts with behavior and uses this as a lever to change the way an individual feels. The focus of the behavioral therapist is on helping the individual do the things they want to do and then manage the feelings that arise as they do the new behavior or quit the old one. Therapies that focus on creating the right feelings first are, ironically, far less successful at creating sustainable changes in the way people feel. -Agile is a kind of behavioral therapy for an organization. You change the habitual behaviors of the org and the mood of the organization improves over time. This is why I believe morale is a Key Performance Indicator. As my colleague Jean Tabaka has said "there are only two things worth measuring: employee satisfaction and customer satisfaction. And if you have to choose, start with your employees." - -This morale improvement is not a direct line often and there will be trouble along the way as individuals resist, but if we keep coming back to the behaviors and what we can do to install them the more successful we'll be in our transformation efforts. - -In many ways Agile practices are similar to an install application your organization can run to create a new culture. Individual tools, practices, and roles are just a way to get your organization to default towards values like trust, autonomy, and collaboration in interacting with each other and with customers. And these values are the heart of real organizational agility. - -Installing New Behaviors So if what we are up to is changing behavior we need to have a clear understanding of how new behaviors come about on a social and psychological level. And there is great news for us. Much of the mystery of these sometimes-messy topics has been removed by recent research. For many years I've been studying personal and organizational change systems, reading the latest psychology and sociology of change, and watching closely what works and what doesn't work in the companies I work with. - -Through this process I've come to recognize certain first principles of change. Once you understand these principles and are aware of the order of operations they must happen in, you'll be well prepared to get change going in your organization. These basic principles show up again and again in change methodologies and once you know them you'll see them everywhere. - -I call these change principles The Turn and there are 3 distinct steps: - -* Step 1: Crisis If you've been part of a deep personal or organizational change you've no doubt noticed that the change is always preceded by crisis. The Challenger disaster of 1986 ushered in some deep process changes at NASA and government contractors. These changes had been asked and agitated for by engineers and leaders for years but until the disaster there was, tragically, insufficient organizational will to actually make the change. - -Likewise when Salesforce began their Scrum-at-scale experiment a few years ago it was because they recognized a deep and looming economic crisis in the organization. And this story is repeated in almost every transformation I've worked on. - -There are well-documented psychological reasons why crisis is needed. Essentially it boils down to the idea that overwhelming current thought and behavior patterns creates opportunity for new patterns to take over. We simply aren't wired to be in deep uncertainty for too long and these states create an opportunity for individuals and organizations to expend the energy—financial, political and emotional—that real change requires. - -This doesn't mean that your organization needs to be on the precipice of failure to make change. A crisis is just a visible problem, so you're job as someone agitating for change is to make the cost of the current problem as visible and palpable as possible. - -If you're change has stalled or isn't taking hold you likely need to return to this principle and see what you can do to make the need for change palpable and obvious to all. - -* Step 2: Vision You've probably noticed that while change is always preceded by crisis, not all crises create change. In fact far from it. The difference between a crisis that creates change—a breakthrough—and a crisis that destroys an organization—a breakdown—is the presence of a vision. - -Most people when faced with a discrepancy between what they have and what they want will most of the time choose to rationalize. This is the cheapest way for an individual or group to deal with the discomfort. Meaning it takes the fewest psychological or organizational resources. It may seem incredibly non-sensical but from an evolutionary perspective it makes sense—risk aversion even to the point of illogic is more likely to ensure survival than risk taking. The trouble is one can survive for a long time in discomfort, what we want is to thrive. - -Behavior change is expensive and for us to embark on. It means we need to have a vision that things might possibly get better. And this means a solid vision of where we might go, what things might be like, and what it will take to get there. - -In 12-step programs like Alcoholics Anonymous there is an emphasis on individuals telling their stories of: what it was like (the situation), what happened (the crisis), and what it's like now (the solution). These stories are crucial for inspiring others to stay on the path of change, or even choose it in the first place. -So your next job once you've made the cost of the current situation clear is to paint a clear and compelling vision of what may be. This usually involves big-win future visions as well as near term, it-won't-cost-too-much tactical plans. Though for the sake of inspiration these plans should be kept vague otherwise you might jump into the weeds which is not where you want to be at this stage. - -* Step 3: Make a Change Once you've made the cost of the current situation clear, and painted a vision of the future, your next job is to actually make a change. We need to choose new behaviors that the organization can begin to adopt to take a real and visible step towards the new vision. - -There is danger here of both doing too much or too little. Too many changes all at once, with insufficient momentum, and the organizational antibodies will attack and destroy the new change—often in very subtle ways that are hard to trace back to a source or individual. Too few changes and you won't realize the short-term small wins that are so crucial in building wide support for a new program. - -A skilled coach is invaluable at this stage and will help you map out the boundaries of the program to be changed, clearly articulate success metrics, and define what changes individuals will need to make. The trick is to pick changes big enough to make a real difference and create some visible success but small enough that you're not betting the entire farm which tends to create fear and resistance. The perceived size of the crisis will dictate the extent of the change you can take on. - -Be prepared to make mistakes at this stage and keep yourself flexible and experimental. The experimental mindset is the most valuable attitudinal change your organization can make and this starts with you. - -Good luck on your journey and if you want to read more deeply about change check out: http://bobgower.com/my-favorite-books-on-change-and-transformation/ for my favorite resources on the topic. - -.About the Author -[NOTE] -**** -Name:: Bob Gower -Biography:: -**** diff --git a/book.asciidoc b/book.asciidoc deleted file mode 100644 index a6725f8..0000000 --- a/book.asciidoc +++ /dev/null @@ -1,53 +0,0 @@ -= 97 Things Every Agile Developer Should Know - -include::README.asciidoc[] - -include::Contributor_Guidelines.asciidoc[] - -include::LICENSE.asciidoc[] - -include::SAMPLE_CONTRIBUTION.asciidoc[] - -include::Beware_Of_Agile_Zealots.asciidoc[] - -include::Dont_Write_Smart_Code.asciidoc[] - -include::lifelong_learning.asciidoc[] - -include::Create_Real_and_Lasting_Change.asciidoc[] - -include::The_Daily_Commit.asciidoc[] - -include::working_with_water_scrum_test.asciidoc[] - -include::Dont_Get_Attached_to_Code.asciidoc[] - -include::CI_attitude.asciidoc[] - -include::Stop_Worrying_About_Being_Agile.asciidoc[] - -include::3_Steps_of_a_Change_Agent.asciidoc[] - -include::Plan_for_Code_Delivery_Aftershocks.asciidoc[] - -include::Role_Of_Visionary_On_Agile_Teams.asciidoc[] - -include::Is_Someone_Running_Your_Agile_Project.asciidoc[] - -include::No_Blockers_No_Way.asciidoc[] - -include::Its_Not_Scrum_Its_You.asciidoc[] - -include::Balancing_Speed_and_Quality.asciidoc[] - -include::Scrummaster_as_Servant_Leader.asciidoc[] - -include::Tell_Your_Boss_What_Makes_You_Tick.asciidoc[] - -include::The_Cost_Of_Compliance.asciidoc[] - -include::Transforming_to_a_High_Performance_Agile_Organization.asciidoc[] - -include::What_Prevents_Teams_from_Becoming_or_Stop.asciidoc[] - -include::Egoless_Code_Reviews.asciidoc[] \ No newline at end of file diff --git a/chapters/book.asciidoc b/chapters/book.asciidoc new file mode 100644 index 0000000..279611a --- /dev/null +++ b/chapters/book.asciidoc @@ -0,0 +1,52 @@ += 97 Things Every Agile Developer Should Know + +include::ch01_Beware_Of_Agile_Zealots.asciidoc[] + +include::ch02_Dont_Write_Smart_Code.asciidoc[] + +include::ch03_lifelong_learning.asciidoc[] + +include::ch04_Create_Real_and_Lasting_Change.asciidoc[] + +include::ch05_The_Daily_Commit.asciidoc[] + +include::ch06_working_with_water_scrum_test.asciidoc[] + +include::ch07_Dont_Get_Attached_to_Code.asciidoc[] + +include::ch08_CI_attitude.asciidoc[] + +include::ch09_Stop_Worrying_About_Being_Agile.asciidoc[] + +include::ch10_3_Steps_of_a_Change_Agent.asciidoc[] + +include::ch11_Plan_for_Code_Delivery_Aftershocks.asciidoc[] + +include::ch12_Role_Of_Visionary_On_Agile_Teams.asciidoc[] + +include::ch13_Is_Someone_Running_Your_Agile_Project.asciidoc[] + +include::ch14_No_Blockers_No_Way.asciidoc[] + +include::ch15_Its_Not_Scrum_Its_You.asciidoc[] + +include::ch16_Balancing_Speed_and_Quality.asciidoc[] + +include::ch17_Scrummaster_as_Servant_Leader.asciidoc[] + +include::ch18_Tell_Your_Boss_What_Makes_You_Tick.asciidoc[] + +include::ch19_The_Cost_Of_Compliance.asciidoc[] + +include::ch20_Transforming_to_a_High_Performance_Agile_Organization.asciidoc[] + +include::ch21_What_Prevents_Teams_from_Becoming_or_Stop.asciidoc[] + +include::ch22_Egoless_Code_Reviews.asciidoc[] + +include::ch23_untethered_activities.asciidoc[] + +include::ch24_software_engineering_costs_of_quality.asciidoc[] + +include::ch25_Enterprise_Agile_Requires_Greater_Discipline.asciidoc[] + diff --git a/Beware_Of_Agile_Zealots.asciidoc b/chapters/ch01_Beware_Of_Agile_Zealots.asciidoc similarity index 100% rename from Beware_Of_Agile_Zealots.asciidoc rename to chapters/ch01_Beware_Of_Agile_Zealots.asciidoc diff --git a/Dont_Write_Smart_Code.asciidoc b/chapters/ch02_Dont_Write_Smart_Code.asciidoc similarity index 100% rename from Dont_Write_Smart_Code.asciidoc rename to chapters/ch02_Dont_Write_Smart_Code.asciidoc diff --git a/lifelong_learning.asciidoc b/chapters/ch03_lifelong_learning.asciidoc similarity index 100% rename from lifelong_learning.asciidoc rename to chapters/ch03_lifelong_learning.asciidoc diff --git a/How_To_Create_Lasting_Change.asciidoc b/chapters/ch04_Create_Real_and_Lasting_Change.asciidoc similarity index 91% rename from How_To_Create_Lasting_Change.asciidoc rename to chapters/ch04_Create_Real_and_Lasting_Change.asciidoc index d0963b7..c8e3515 100644 --- a/How_To_Create_Lasting_Change.asciidoc +++ b/chapters/ch04_Create_Real_and_Lasting_Change.asciidoc @@ -2,86 +2,86 @@ As a developer you're probably well aware that there's a better way to do many things in your organization. Because you are on the front lines of product development you acutely feel the effects of the dysfunction in other departments and undoubtedly see things others don't. -This is why most Agile transformations I've seen start with agitation from the people actually building the product. +This is why most Agile transformations I've seen start with agitation from the people actually building the product. -If we think of an organizations as an organism the pain the development team feels—and the subsequent loss of business performance the organization notices—is the proverbial thorn in the paw that finally creates an opening for an organization to ask for help and make a change. +If we think of an organizations as an organism the pain the development team feels—and the subsequent loss of business performance the organization notices—is the proverbial thorn in the paw that finally creates an opening for an organization to ask for help and make a change. -The challenge you face however once you wade into a change of process is that what you're up to defies logic, doesn't move in a linear path, and is more about a shift of culture than it is about any specific practice you may want to change. +The challenge you face however once you wade into a change of process is that what you're up to defies logic, doesn't move in a linear path, and is more about a shift of culture than it is about any specific practice you may want to change. *The Thigh Bone's Connected to the Leg Bone* -Not only are your products complex with each technical decision having far-reaching impacts on scalability, stability, extensibility, and more. But your organization is complex as well. And the most important algorithms that govern the behavior of our businesses are poorly understood, poorly documented, and so mysterious that even the inmates running the asylum often don't know what to do to make real change. +Not only are your products complex with each technical decision having far-reaching impacts on scalability, stability, extensibility, and more. But your organization is complex as well. And the most important algorithms that govern the behavior of our businesses are poorly understood, poorly documented, and so mysterious that even the inmates running the asylum often don't know what to do to make real change. -For instance, one of the most common anti-patterns I see in organization is the heroin-like dependency on big up-front requirements definition and multiple layers of approval for these requirements. +For instance, one of the most common anti-patterns I see in organization is the heroin-like dependency on big up-front requirements definition and multiple layers of approval for these requirements. -I frequently work with teams to install a just-in-time, collaborative flows for the elaboration of requirements. This is something foundational to organizational agility and whose value I can demonstrate to almost anyone with a few pennies and some balls of paper—e.g. by teaching the penny-flip and ball-point games. And yet I'm frequently thwarted because the team at hand does not have the autonomy to finalize requirements AND they are locked into explicit (or implicit and hidden) development phase gates. +I frequently work with teams to install a just-in-time, collaborative flows for the elaboration of requirements. This is something foundational to organizational agility and whose value I can demonstrate to almost anyone with a few pennies and some balls of paper—e.g. by teaching the penny-flip and ball-point games. And yet I'm frequently thwarted because the team at hand does not have the autonomy to finalize requirements AND they are locked into explicit (or implicit and hidden) development phase gates. -This problem might seem simple on the surface. All we need to do is get those people to give us some autonomy and get the heck out of the way so we can do our darn jobs. But peeling this onion reveals layer upon layer of messy human stuff. +This problem might seem simple on the surface. All we need to do is get those people to give us some autonomy and get the heck out of the way so we can do our darn jobs. But peeling this onion reveals layer upon layer of messy human stuff. -There's the product manager, dev lead, and project manager who are wondering what their job actually is if they are not signing off on each layer. There's the paper trail that management requires—but no one reads. There are auditors to satisfy and funding to secure for each project. +There's the product manager, dev lead, and project manager who are wondering what their job actually is if they are not signing off on each layer. There's the paper trail that management requires—but no one reads. There are auditors to satisfy and funding to secure for each project. -And there's the development team that, having spent the last several years working in a command and control environment finds it spooky and unsafe to take responsibility. +And there's the development team that, having spent the last several years working in a command and control environment finds it spooky and unsafe to take responsibility. *Dysfunction is Baked In* The truth is that most of our organizations have fear and a lack of accountability at the core of their culture. "command and-control" is just a nice way of saying "my way or the highway" and managing with implied threats and seeking compliance out of fear. -If we are to change our process and really start doing things iteratively, incrementally, and with front-line responsibility for quality, we must wade into the strange waters of the human psyche. As we do so we are going to agitate the organizational antibodies that always seem ready to attack any threat to the status quo. +If we are to change our process and really start doing things iteratively, incrementally, and with front-line responsibility for quality, we must wade into the strange waters of the human psyche. As we do so we are going to agitate the organizational antibodies that always seem ready to attack any threat to the status quo. -So we start by saying "let's change the way we do things around here" and eventually find ourselves wrestling with sticky questions of identity. We move from _doing_ something different to _being_ something different. This is not a bad thing, this flow from doing to being. It's actually one of the only means of change that actually works. Where we run into trouble is if we work to change and don't anticipate the messy human stuff coming up. +So we start by saying "let's change the way we do things around here" and eventually find ourselves wrestling with sticky questions of identity. We move from _doing_ something different to _being_ something different. This is not a bad thing, this flow from doing to being. It's actually one of the only means of change that actually works. Where we run into trouble is if we work to change and don't anticipate the messy human stuff coming up. -One of the most demonstrably effective forms of psychological therapy is Cognitive Behavioral Therapy that starts with behavior and uses this as a lever to change the way an individual feels. The focus of the behavioral therapist is on helping the individual do the things they want to do and then manage the feelings that arise as they do the new behavior or quit the old one. Therapies that focus on creating the right feelings first are, ironically, far less successful at creating sustainable changes in the way people feel. +One of the most demonstrably effective forms of psychological therapy is Cognitive Behavioral Therapy that starts with behavior and uses this as a lever to change the way an individual feels. The focus of the behavioral therapist is on helping the individual do the things they want to do and then manage the feelings that arise as they do the new behavior or quit the old one. Therapies that focus on creating the right feelings first are, ironically, far less successful at creating sustainable changes in the way people feel. -Agile is a kind of behavioral therapy for an organization. You change the habitual behaviors of the org and the mood of the organization improves over time. This is why I believe morale is a Key Performance Indicator. As my colleague Jean Tabaka has said "there are only two things worth measuring: employee satisfaction and customer satisfaction. And if you have to choose, start with your employees." +Agile is a kind of behavioral therapy for an organization. You change the habitual behaviors of the org and the mood of the organization improves over time. This is why I believe morale is a Key Performance Indicator. As my colleague Jean Tabaka has said "there are only two things worth measuring: employee satisfaction and customer satisfaction. And if you have to choose, start with your employees." -This morale improvement is not a direct line often and there will be trouble along the way as individuals resist, but if we keep coming back to the behaviors and what we can do to install them the more successful we'll be in our transformation efforts. +This morale improvement is not a direct line often and there will be trouble along the way as individuals resist, but if we keep coming back to the behaviors and what we can do to install them the more successful we'll be in our transformation efforts. -In many ways Agile practices are similar to an install application your organization can run to create a new culture. Individual tools, practices, and roles are just a way to get your organization to default towards values like trust, autonomy, and collaboration in interacting with each other and with customers. And these values are the heart of real organizational agility. +In many ways Agile practices are similar to an install application your organization can run to create a new culture. Individual tools, practices, and roles are just a way to get your organization to default towards values like trust, autonomy, and collaboration in interacting with each other and with customers. And these values are the heart of real organizational agility. *Installing New Behaviors* -So if what we are up to is changing behavior we need to have a clear understanding of how new behaviors come about on a social and psychological level. And there is great news for us. Much of the mystery of these sometimes-messy topics has been removed by recent research. For many years I've been studying personal and organizational change systems, reading the latest psychology and sociology of change, and watching closely what works and what doesn't work in the companies I work with. +So if what we are up to is changing behavior we need to have a clear understanding of how new behaviors come about on a social and psychological level. And there is great news for us. Much of the mystery of these sometimes-messy topics has been removed by recent research. For many years I've been studying personal and organizational change systems, reading the latest psychology and sociology of change, and watching closely what works and what doesn't work in the companies I work with. Through this process I've come to recognize certain first principles of change. Once you understand these principles and are aware of the order of operations they must happen in, you'll be well prepared to get change going in your organization. These basic principles show up again and again in change methodologies and once you know them you'll see them everywhere. I call these change principles *_The Turn_* and there are 3 distinct steps: -*Step 1: Crisis* -If you've been part of a deep personal or organizational change you've no doubt noticed that the change is always preceded by crisis. The Challenger disaster of 1986 ushered in some deep process changes at NASA and government contractors. These changes had been asked and agitated for by engineers and leaders for years but until the disaster there was, tragically, insufficient organizational will to actually make the change. +*Step 1: Crisis* +If you've been part of a deep personal or organizational change you've no doubt noticed that the change is always preceded by crisis. The Challenger disaster of 1986 ushered in some deep process changes at NASA and government contractors. These changes had been asked and agitated for by engineers and leaders for years but until the disaster there was, tragically, insufficient organizational will to actually make the change. -Likewise when Salesforce began their Scrum-at-scale experiment a few years ago it was because they recognized a deep and looming economic crisis in the organization. And this story is repeated in almost every transformation I've worked on. +Likewise when Salesforce began their Scrum-at-scale experiment a few years ago it was because they recognized a deep and looming economic crisis in the organization. And this story is repeated in almost every transformation I've worked on. There are well-documented psychological reasons why crisis is needed. Essentially it boils down to the idea that overwhelming current thought and behavior patterns creates opportunity for new patterns to take over. We simply aren't wired to be in deep uncertainty for too long and these states create an opportunity for individuals and organizations to expend the energy—financial, political and emotional—that real change requires. -This doesn't mean that your organization needs to be on the precipice of failure to make change. A crisis is just a visible problem, so you're job as someone agitating for change is to make the cost of the current problem as visible and palpable as possible. +This doesn't mean that your organization needs to be on the precipice of failure to make change. A crisis is just a visible problem, so you're job as someone agitating for change is to make the cost of the current problem as visible and palpable as possible. -If you're change has stalled or isn't taking hold you likely need to return to this principle and see what you can do to make the need for change palpable and obvious to all. +If you're change has stalled or isn't taking hold you likely need to return to this principle and see what you can do to make the need for change palpable and obvious to all. *Step 2: Vision* -You've probably noticed that while change is always preceded by crisis, not all crises create change. In fact far from it. The difference between a crisis that creates change—a breakthrough—and a crisis that destroys an organization—a breakdown—is the presence of a vision. +You've probably noticed that while change is always preceded by crisis, not all crises create change. In fact far from it. The difference between a crisis that creates change—a breakthrough—and a crisis that destroys an organization—a breakdown—is the presence of a vision. -Most people when faced with a discrepancy between what they have and what they want will most of the time choose to rationalize. This is the cheapest way for an individual or group to deal with the discomfort. Meaning it takes the fewest psychological or organizational resources. It may seem incredibly non-sensical but from an evolutionary perspective it makes sense—risk aversion even to the point of illogic is more likely to ensure survival than risk taking. The trouble is one can survive for a long time in discomfort, what we want is to thrive. +Most people when faced with a discrepancy between what they have and what they want will most of the time choose to rationalize. This is the cheapest way for an individual or group to deal with the discomfort. Meaning it takes the fewest psychological or organizational resources. It may seem incredibly non-sensical but from an evolutionary perspective it makes sense—risk aversion even to the point of illogic is more likely to ensure survival than risk taking. The trouble is one can survive for a long time in discomfort, what we want is to thrive. -Behavior change is expensive and for us to embark on. It means we need to have a vision that things might possibly get better. And this means a solid vision of where we might go, what things might be like, and what it will take to get there. +Behavior change is expensive and for us to embark on. It means we need to have a vision that things might possibly get better. And this means a solid vision of where we might go, what things might be like, and what it will take to get there. -In 12-step programs like Alcoholics Anonymous there is an emphasis on individuals telling their stories of: what it was like (the situation), what happened (the crisis), and what it's like now (the solution). These stories are crucial for inspiring others to stay on the path of change, or even choose it in the first place. +In 12-step programs like Alcoholics Anonymous there is an emphasis on individuals telling their stories of: what it was like (the situation), what happened (the crisis), and what it's like now (the solution). These stories are crucial for inspiring others to stay on the path of change, or even choose it in the first place. -So your next job once you've made the cost of the current situation clear is to paint a clear and compelling vision of what may be. This usually involves big-win future visions as well as near term, it-won't-cost-too-much tactical plans. Though for the sake of inspiration these plans should be kept vague otherwise you might jump into the weeds which is not where you want to be at this stage. +So your next job once you've made the cost of the current situation clear is to paint a clear and compelling vision of what may be. This usually involves big-win future visions as well as near term, it-won't-cost-too-much tactical plans. Though for the sake of inspiration these plans should be kept vague otherwise you might jump into the weeds which is not where you want to be at this stage. *Step 3: Make a Change* -Once you've made the cost of the current situation clear, and painted a vision of the future, your next job is to actually make a change. We need to choose new behaviors that the organization can begin to adopt to take a real and visible step towards the new vision. +Once you've made the cost of the current situation clear, and painted a vision of the future, your next job is to actually make a change. We need to choose new behaviors that the organization can begin to adopt to take a real and visible step towards the new vision. -There is danger here of both doing too much or too little. Too many changes all at once, with insufficient momentum, and the organizational antibodies will attack and destroy the new change—often in very subtle ways that are hard to trace back to a source or individual. Too few changes and you won't realize the short-term small wins that are so crucial in building wide support for a new program. +There is danger here of both doing too much or too little. Too many changes all at once, with insufficient momentum, and the organizational antibodies will attack and destroy the new change—often in very subtle ways that are hard to trace back to a source or individual. Too few changes and you won't realize the short-term small wins that are so crucial in building wide support for a new program. -A skilled coach is invaluable at this stage and will help you map out the boundaries of the program to be changed, clearly articulate success metrics, and define what changes individuals will need to make. The trick is to pick changes big enough to make a real difference and create some visible success but small enough that you're not betting the entire farm which tends to create fear and resistance. The perceived size of the crisis will dictate the extent of the change you can take on. +A skilled coach is invaluable at this stage and will help you map out the boundaries of the program to be changed, clearly articulate success metrics, and define what changes individuals will need to make. The trick is to pick changes big enough to make a real difference and create some visible success but small enough that you're not betting the entire farm which tends to create fear and resistance. The perceived size of the crisis will dictate the extent of the change you can take on. -Be prepared to make mistakes at this stage and keep yourself flexible and experimental. The experimental mindset is the most valuable attitudinal change your organization can make and this starts with you. +Be prepared to make mistakes at this stage and keep yourself flexible and experimental. The experimental mindset is the most valuable attitudinal change your organization can make and this starts with you. -Good luck on your journey and if you want to read more deeply about change check out: http://bobgower.com/my-favorite-books-on-change-and-transformation/ for my favorite resources on the topic. +Good luck on your journey and if you want to read more deeply about change check out: http://bobgower.com/my-favorite-books-on-change-and-transformation/ for my favorite resources on the topic. .About the Author [NOTE] **** Name:: Bob Gower -Biography:: +Biography:: **** diff --git a/The_Daily_Commit.asciidoc b/chapters/ch05_The_Daily_Commit.asciidoc similarity index 100% rename from The_Daily_Commit.asciidoc rename to chapters/ch05_The_Daily_Commit.asciidoc diff --git a/working_with_water_scrum_test.asciidoc b/chapters/ch06_working_with_water_scrum_test.asciidoc similarity index 100% rename from working_with_water_scrum_test.asciidoc rename to chapters/ch06_working_with_water_scrum_test.asciidoc diff --git a/Dont_Get_Attached_to_Code.asciidoc b/chapters/ch07_Dont_Get_Attached_to_Code.asciidoc similarity index 100% rename from Dont_Get_Attached_to_Code.asciidoc rename to chapters/ch07_Dont_Get_Attached_to_Code.asciidoc diff --git a/CI_attitude.asciidoc b/chapters/ch08_CI_attitude.asciidoc similarity index 100% rename from CI_attitude.asciidoc rename to chapters/ch08_CI_attitude.asciidoc diff --git a/Stop_Worrying_About_Being_Agile.asciidoc b/chapters/ch09_Stop_Worrying_About_Being_Agile.asciidoc similarity index 100% rename from Stop_Worrying_About_Being_Agile.asciidoc rename to chapters/ch09_Stop_Worrying_About_Being_Agile.asciidoc diff --git a/3_Steps_of_a_Change_Agent.asciidoc b/chapters/ch10_3_Steps_of_a_Change_Agent.asciidoc similarity index 100% rename from 3_Steps_of_a_Change_Agent.asciidoc rename to chapters/ch10_3_Steps_of_a_Change_Agent.asciidoc diff --git a/Plan_for_Code_Delivery_Aftershocks.asciidoc b/chapters/ch11_Plan_for_Code_Delivery_Aftershocks.asciidoc similarity index 100% rename from Plan_for_Code_Delivery_Aftershocks.asciidoc rename to chapters/ch11_Plan_for_Code_Delivery_Aftershocks.asciidoc diff --git a/Role_Of_Visionary_On_Agile_Teams.asciidoc b/chapters/ch12_Role_Of_Visionary_On_Agile_Teams.asciidoc similarity index 100% rename from Role_Of_Visionary_On_Agile_Teams.asciidoc rename to chapters/ch12_Role_Of_Visionary_On_Agile_Teams.asciidoc diff --git a/Is_Someone_Running_Your_Agile_Project.asciidoc b/chapters/ch13_Is_Someone_Running_Your_Agile_Project.asciidoc similarity index 100% rename from Is_Someone_Running_Your_Agile_Project.asciidoc rename to chapters/ch13_Is_Someone_Running_Your_Agile_Project.asciidoc diff --git a/No_Blockers_No_Way.asciidoc b/chapters/ch14_No_Blockers_No_Way.asciidoc similarity index 100% rename from No_Blockers_No_Way.asciidoc rename to chapters/ch14_No_Blockers_No_Way.asciidoc diff --git a/Its_Not_Scrum_Its_You.asciidoc b/chapters/ch15_Its_Not_Scrum_Its_You.asciidoc similarity index 100% rename from Its_Not_Scrum_Its_You.asciidoc rename to chapters/ch15_Its_Not_Scrum_Its_You.asciidoc diff --git a/Balancing_Speed_and_Quality.asciidoc b/chapters/ch16_Balancing_Speed_and_Quality.asciidoc similarity index 100% rename from Balancing_Speed_and_Quality.asciidoc rename to chapters/ch16_Balancing_Speed_and_Quality.asciidoc diff --git a/Scrummaster_as_Servant_Leader.asciidoc b/chapters/ch17_Scrummaster_as_Servant_Leader.asciidoc similarity index 100% rename from Scrummaster_as_Servant_Leader.asciidoc rename to chapters/ch17_Scrummaster_as_Servant_Leader.asciidoc diff --git a/Tell_Your_Boss_What_Makes_You_Tick.asciidoc b/chapters/ch18_Tell_Your_Boss_What_Makes_You_Tick.asciidoc similarity index 100% rename from Tell_Your_Boss_What_Makes_You_Tick.asciidoc rename to chapters/ch18_Tell_Your_Boss_What_Makes_You_Tick.asciidoc diff --git a/The_Cost_Of_Compliance.asciidoc b/chapters/ch19_The_Cost_Of_Compliance.asciidoc similarity index 100% rename from The_Cost_Of_Compliance.asciidoc rename to chapters/ch19_The_Cost_Of_Compliance.asciidoc diff --git a/Transforming_to_a_High_Performance_Agile_Organization.asciidoc b/chapters/ch20_Transforming_to_a_High_Performance_Agile_Organization.asciidoc similarity index 100% rename from Transforming_to_a_High_Performance_Agile_Organization.asciidoc rename to chapters/ch20_Transforming_to_a_High_Performance_Agile_Organization.asciidoc diff --git a/What_Prevents_Teams_from_Becoming_or_Stop.asciidoc b/chapters/ch21_What_Prevents_Teams_from_Becoming_or_Stop.asciidoc similarity index 100% rename from What_Prevents_Teams_from_Becoming_or_Stop.asciidoc rename to chapters/ch21_What_Prevents_Teams_from_Becoming_or_Stop.asciidoc diff --git a/Egoless_Code_Reviews.asciidoc b/chapters/ch22_Egoless_Code_Reviews.asciidoc similarity index 100% rename from Egoless_Code_Reviews.asciidoc rename to chapters/ch22_Egoless_Code_Reviews.asciidoc diff --git a/Rolf_Reitzig.asciidoc b/chapters/ch23_untethered_activities.asciidoc similarity index 69% rename from Rolf_Reitzig.asciidoc rename to chapters/ch23_untethered_activities.asciidoc index b2ed48b..995781e 100644 --- a/Rolf_Reitzig.asciidoc +++ b/chapters/ch23_untethered_activities.asciidoc @@ -1,22 +1,33 @@ -==Untethered Activities +== Untethered Activities Its no secret that many software projects miss their planned delivery dates. So why is this happening? Typical suspects include: -1) Senior Management Mandates - These occur when executives essentially tell the project when they will deliver without giving them a chance to estimate and plan. In fact, some managers believe stretch goals are a good way to motivate teams. Other times, mandates reflect business problems: -- Competitors have announced a competing product launch, and therefore the project has to match them -- Customers demand certain features/functionality in order to authorize a PO, and executives promise delivery -2) Scope Changes - Unplanned additions (or deletions) to software functionality that increases the work required to deliver, without any corresponding increase in the time allotted to deliver. Typically, numerous "small" requirements/scope changes are allowed, but they eventually add up to real work and real schedule slips. "More is more, less is more, the same is more." -3) Poor Estimation - Flat out poor/incorrect estimation of the work by practitioners. +. *Senior Management Mandates* - These occur when executives essentially tell the project when they will deliver without giving them a chance to estimate and plan. In fact, some managers believe stretch goals are a good way to motivate teams. Other times, mandates reflect business problems: +* Competitors have announced a competing product launch, and therefore the project has to match them +* Customers demand certain features/functionality in order to authorize a PO, and executives promise delivery +. *Scope Changes* - Unplanned additions (or deletions) to software functionality that increases the work required to deliver, without any corresponding increase in the time allotted to deliver. Typically, numerous "small" requirements/scope changes are allowed, but they eventually add up to real work and real schedule slips. "More is more, less is more, the same is more." +. *Poor Estimation* - Flat out poor/incorrect estimation of the work by practitioners. While all 3 above are perfectly valid and occur frequently, there is one situation that, in my experience, happens a lot but isn't discussed or talked about much. Its what I refer to as "untethered activities". -Untethered activities are those that must be performed to deliver software functionality, but are never planned, estimated, or scheduled. Since these untethered activities must be completed, others are short-sheeted or delayed to get the job done. The end result is a delayed schedule, or worse, a poor quality product that requires expensive rework and thus, more delay. Some typical examples of untethered activities include planning, project/organizational meetings, reviews, CM, unit testing, and development and test environment implementation. +Untethered activities are those that must be performed to deliver software functionality, but are never planned, estimated, or scheduled. Since these untethered activities must be completed, others are short-sheeted or delayed to get the job done. The end result is a delayed schedule, or worse, a poor quality product that requires expensive rework and thus, more delay. -A story I like to share involves an Agile project that was consistently missing the deliverables and dates they promised each iteration. A "rule" was established by the team that any work a team member performed needed a development card tied to it. At the start of the 4 week iteration, the team estimated their tasks and time associated with completing the work via development cards. By the end of the iteration, a full 4 weeks late, they found that their development cards "exploded" to twice the number originally estimated and twice the work estimated. Some of the culprits included: +Some typical examples of untethered activities include: -- Establishing CM enviroments +* Planning +* Project/organizational meetings +* Reviews +* Configuration management +* Unit testing +* and development and test environment implementation. + +A story I like to share involves an Agile project that was consistently missing the deliverables and dates they promised each iteration. A "rule" was established by the team that any work a team member performed needed a development card tied to it. + +At the start of the 4 week iteration, the team estimated their tasks and time associated with completing the work via development cards. By the end of the iteration, a full 4 weeks late, they found that their development cards "exploded" to twice the number originally estimated and twice the work estimated. Some of the culprits included: + +- Establishing configuration management enviroments - Creating and performing builds - Getting test environments in place for unit, functional, and system testing - Various system administration tasks @@ -33,17 +44,11 @@ In summary, incorporating all the activities/tasks that need to be executed in p Bottom Line: If you aren't estimating and tracking all effort associated with a project, you're shooting in the dark! -About the Author - -Name - -Rolf W. Reitzig - -Biography +.About the Author +[NOTE] +**** +Name:: Rolf W. Reitzig +Biography:: Mr. Rolf W. Reitzig is the Director of ALM Transformation for Avnet Services. Mr. Reitzig has 20 years of practical experience in software engineering and has helped dozens of Fortune 500 companies improve software engineering quality, productivity and project results through the implementation of best practices like Agile, RUP, and CMMI, as well as leading ALM solutions from IBM. He has worked closely with the Software Engineering Institute in understanding and communicating the return on investment of process and tool standardization efforts to the software development community. Mr. Reitzig speaks regularly at international conferences, seminars and user groups sponsored by IBM Rational, the SEI, and many others. He advises executive and senior managers, helping them understand the economics of engineering improvement and its implications on organizational change. Mr. Reitzig holds a Bachelor’s degree in Computer Science and an MBA in Finance from the University of Colorado and is on the Board of Advisors for the Computer Science Department at Metropolitan State University in Denver, CO. - -Image - -http://www.linkedin.com/profile/view?id=30259298&goback=%2Enmp_*1_*1_*1_*1_*1_*1_*1_*1_*1&trk=spm_pic - +**** diff --git a/Rolf_Reitzig2.asciidoc b/chapters/ch24_software_engineering_costs_of_quality.asciidoc similarity index 94% rename from Rolf_Reitzig2.asciidoc rename to chapters/ch24_software_engineering_costs_of_quality.asciidoc index f6129e1..612e0ec 100644 --- a/Rolf_Reitzig2.asciidoc +++ b/chapters/ch24_software_engineering_costs_of_quality.asciidoc @@ -1,4 +1,4 @@ -==Software Engineering Costs of Quality +== Software Engineering Costs of Quality What does software engineering productivity mean, anyway? How do you know if you are more, or less, productive than your competitor? @@ -16,22 +16,10 @@ The truth is the average software organizations spends 65% of its resources and By understanding your organization's cost of quality and how much inefficiencies are costing you will be able to shift resources and attention towards prevention. The result: You’ll see an increase in not only software quality but also productivity, customer satisfaction and employee morale. Defects delivered to the field, employee turnover and development cycle times will be significantly reduced. -About the Author - - -Name - - -Rolf W. Reitzig - - -Biography - - +.About the Author +[NOTE] +**** +Name:: Rolf W. Reitzig +Biography:: Mr. Rolf W. Reitzig is the Director of ALM Transformation for Avnet Services. Mr. Reitzig has 20 years of practical experience in software engineering and has helped dozens of Fortune 500 companies improve software engineering quality, productivity and project results through the implementation of best practices like Agile, RUP, and CMMI, as well as leading ALM solutions from IBM. He has worked closely with the Software Engineering Institute in understanding and communicating the return on investment of process and tool standardization efforts to the software development community. Mr. Reitzig speaks regularly at international conferences, seminars and user groups sponsored by IBM Rational, the SEI, and many others. He advises executive and senior managers, helping them understand the economics of engineering improvement and its implications on organizational change. Mr. Reitzig holds a Bachelor’s degree in Computer Science and an MBA in Finance from the University of Colorado and is on the Board of Advisors for the Computer Science Department at Metropolitan State University in Denver, CO. - - -Image - - -http://www.linkedin.com/profile/view?id=30259298&goback=%2Enmp_*1_*1_*1_*1_*1_*1_*1_*1_*1&trk=spm_pic +**** diff --git a/Enterprise_Agile_Requires_Greater_Discipline.asciidoc b/chapters/ch25_Enterprise_Agile_Requires_Greater_Discipline.asciidoc similarity index 79% rename from Enterprise_Agile_Requires_Greater_Discipline.asciidoc rename to chapters/ch25_Enterprise_Agile_Requires_Greater_Discipline.asciidoc index b6e2f75..895313d 100644 --- a/Enterprise_Agile_Requires_Greater_Discipline.asciidoc +++ b/chapters/ch25_Enterprise_Agile_Requires_Greater_Discipline.asciidoc @@ -1,14 +1,14 @@ == Enterprise Agile Requires Greater Discipline -Many organizations are struggling to apply agile software development methods within enterprise environments. In some cases it’s because they haven’t sufficiently invested in training and coaching, but often it’s because agile strategies that work well in simple situations fall down in the greater complexity found in enterprise environments. This complexity arises from having an existing legacy infrastructure, an existing organization structure that covers far more than just software development, and people with a range of belief systems than often differ from the agile mindset. +Many organizations are struggling to apply agile software development methods within enterprise environments. In some cases it’s because they haven’t sufficiently invested in training and coaching, but often it’s because agile strategies that work well in simple situations fall down in the greater complexity found in enterprise environments. This complexity arises from having an existing legacy infrastructure, an existing organization structure that covers far more than just software development, and people with a range of belief systems than often differ from the agile mindset. The Disciplined Agile Delivery (DAD) framework, which grew out of observing both challenged and successful enterprise agile implementations, promotes a robust view of agile. The following values summarize critical aspects of the greater discipline required for successful enterprise agile: . *Delivery over construction.* Agile teams will often invest time doing a bit of up front planning and modeling, sometimes referred to as “populating the backlog”, they will spend time on construction activities, and they will spend a bit of time at the end of the lifecycle deploying their solutions into production (or the marketplace). Disciplined agile teams adopt a full delivery lifecycle that explicitly addresses the full range of tasks they face, not just a lifecycle that only addresses the construction activities in the middle. -. *Consumerable solutions over shippable software.* Although “potentially shippable software” has a nice ring to it, it is easy to empirically observe this isn’t sufficient. A solutions focus recognizes that in addition to software we also sometimes need to upgrade the hardware infrastructure, produce deliverable documentation, evolve the business process, and even evolve the organization structure. Furthermore we should produce solutions that people want to work with, solutions that are consumable and desirable to use, not just potentially shippable. -. *Pragmatism over prescription.* Any given agile team finds itself in a unique situation and therefore should tailor its approach to meet the context they face. Yet many methods prescribe a single way of working, for example to manage change Scrum prescribes the use of a product backlog. A more pragmatic approach is to provide teams with options and to help them to choose the most effective option, which DAD does via process goals. For example, to fulfill the goal _Address Changing Stakeholder Needs_ DAD teams will choose from product backlog, work item stack, work item pool, or even formal change management. +. *Consumerable solutions over shippable software.* Although “potentially shippable software” has a nice ring to it, it is easy to empirically observe this isn’t sufficient. A solutions focus recognizes that in addition to software we also sometimes need to upgrade the hardware infrastructure, produce deliverable documentation, evolve the business process, and even evolve the organization structure. Furthermore we should produce solutions that people want to work with, solutions that are consumable and desirable to use, not just potentially shippable. +. *Pragmatism over prescription.* Any given agile team finds itself in a unique situation and therefore should tailor its approach to meet the context they face. Yet many methods prescribe a single way of working, for example to manage change Scrum prescribes the use of a product backlog. A more pragmatic approach is to provide teams with options and to help them to choose the most effective option, which DAD does via process goals. For example, to fulfill the goal _Address Changing Stakeholder Needs_ DAD teams will choose from product backlog, work item stack, work item pool, or even formal change management. . *Enterprise awareness over team awareness.* A strength of agile is its promotion of a team-based mindset. Unfortunately this has led some teams to produce silo applications that meet the immediate needs of their users but which do not reflect the overall goals of their organization. Disciplined agile teams are enterprise aware, striving to work closely with enterprise professionals such as enterprise architects and operations staff so that they can leverage and enhance assets within their organizational ecosystem by following common guidance and enterprise roadmaps. -. *Govered self-organization over self-organization.* Agile teams have gained significant benefit from self organization, but once again we need to do better in an enterprise setting. Because disciplined agilists are enterprise aware they realize that they are being governed (hopefully well) and therefore act accordingly. They recognize that they are constrained by the existing IT infrastructure, that someone will be keeping an eye on the financial aspects of their efforts, that someone will monitor the quality and value being produced, and that senior management can actually streamline their solution delivery efforts when given the chance to. In short, disciplined agilists embrace good governance. +. *Governed self-organization over self-organization.* Agile teams have gained significant benefit from self organization, but once again we need to do better in an enterprise setting. Because disciplined agilists are enterprise aware they realize that they are being governed (hopefully well) and therefore act accordingly. They recognize that they are constrained by the existing IT infrastructure, that someone will be keeping an eye on the financial aspects of their efforts, that someone will monitor the quality and value being produced, and that senior management can actually streamline their solution delivery efforts when given the chance to. In short, disciplined agilists embrace good governance. .About the Authors [NOTE] diff --git a/preface.asciidoc b/preface.asciidoc deleted file mode 100644 index 9a62017..0000000 --- a/preface.asciidoc +++ /dev/null @@ -1,3 +0,0 @@ -== Preface - -Agile development is the greatest thing ever. \ No newline at end of file