Lean-Agile Straight Talk

 Announcing Scrum Certification by Net Objectives Scrum Certification by Net Objectives is a new program by Net Objectives to help the industry and especially our clients have a reliable, repeatable, and meaningful process by which to assess the competency of individuals and teams to be on a Scrum Team, to be a Scrum Master, or to be a Product Owner. This podcast announces the program and the motivations behind it, including the following: What this program is and what it covers The motivation behind this program Why the industry needs certification in Scrum What we mean by “certification” What certification will involve When it will be ready The need for this is borne out of our experience having trained almost 20,000 people in Scrum and working with many major corporations rolling out Scrum, what people need to get proficient with Scrum. From my own vantage point, it seems like time to do this. Other improvement initiatives, such as Six Sigma, Lean Manufacturing, and ITIL have meaningful certification programs based on observed best practices and defined competencies. Standards-based and open to improvement. It provides the objective foundation for a conversation by the profession in what it means to be a competent worker, mentor, or master trainer. And it provides a roadmap for people who want to progress. This program is ready now. If you want to get more information, you can call 1.888.LEAN.AGILE or read the press release at www.netobjectives.com/news/20070813-press-release-scrum-certification This is sure to be talked about and I welcome your thoughts. Drop me a line jim.trott@netobjectives.com Enjoy the show! Recommendations - Training by Net Objectives Scrum Training Courses Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed. For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

 Announcing Scrum Certification by Net Objectives Scrum Certification by Net Objectives is a new program by Net Objectives to help the industry and especially our clients have a reliable, repeatable, and meaningful process by which to assess the competency of individuals and teams to be on a Scrum Team, to be a Scrum Master, or to be a Product Owner. This podcast announces the program and the motivations behind it, including the following: What this program is and what it covers The motivation behind this program Why the industry needs certification in Scrum What we mean by “certification” What certification will involve When it will be ready The need for this is borne out of our experience having trained almost 20,000 people in Scrum and working with many major corporations rolling out Scrum, what people need to get proficient with Scrum. From my own vantage point, it seems like time to do this. Other improvement initiatives, such as Six Sigma, Lean Manufacturing, and ITIL have meaningful certification programs based on observed best practices and defined competencies. Standards-based and open to improvement. It provides the objective foundation for a conversation by the profession in what it means to be a competent worker, mentor, or master trainer. And it provides a roadmap for people who want to progress. This program is ready now. If you want to get more information, you can call 1.888.LEAN.AGILE or read the press release at www.netobjectives.com/news/20070813-press-release-scrum-certification This is sure to be talked about and I welcome your thoughts. Drop me a line jim.trott@netobjectives.com Enjoy the show! Recommendations - Training by Net Objectives Scrum Training Courses Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed. For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

Lean-Agile and the Process-Innovation Pendulum Alan was the keynote speaker at the SQE Better Software Conference in Las Vegas this year. Conferences are great for stirring up ideas and generating insights. For this podcast, I wanted to continue the series on Lean Anti-Patterns, sharing some more from what we are learning as we write this book. But you cannot always control a conversation. One of the hardest things to know as a facilitator is when to re-focus an individual or a group and when to let the ideas flow. You want the ideas to emerge and you want them to create the result. Today, I went with the passion, letting him share because I knew we’d get back to the other topic another day. Innovation or Process? Maybe it is a little like the challenge of the software industry: do we want process or do we want innovation? We keep shifting between the two. Software development methodology seems move between being creative and processes to control chaos. In the 70's, we had waterfall methods to structure our work. The 80's saw a burst of creativity with the rise of the PC, thousands of developers coming in and process took a back seat. The 90's saw a tension between the Internet (creative) and CMM (process). And where are we now? Maybe it is time for a happy medium. Maybe lean can help us achieve it. Lean sees process is the structure in which creativity can be expressed. Having standard work process frees me from having to think about the routine stuff so that I can spend creative energy on new stuff. The routine stuff always has to be done; standard work organizes it so that I do not have to devote more energy than necessary doing it. I do not have to decide if I am going to do testing, if I am going to have work-cell teams, if I am going to communicate with customers. That is the routine. As an example, I have just finished working with an organization where we needed to upgrade our Microsoft Office software. Now, you would think that ordering software would be fairly routine since the funds were already in place. But they had no process! Without process, it became an ordeal, all dependent on one guy to be a hero and figure out what to do next. We could go only as fast as he could work. Three weeks later, we are almost there. How much of his effort – and our time – was wasted because they had no process for the routine stuff. Scrum and Iterative Analysis Our biggest challenge is, and continues to be, to build products the customer wants. Thus, the biggest risk is building things the customer does not want. How do you manage this in a more complete way? Lean-Agile would say to do a little, learn a little, then adjust based on customer feedback. Do not do workarounds and do not build too much. Seen this way, Scrum is perhaps more of an iterative analysis technique than an iterative development technique. It helps to minimize that risk of building what the customer does not want. The rest of the Lean-Agile framework – Analysis, Design Patterns, Test-Driven Development, Scrum, Process, QA – certainly help us to have an environment where this can be done. Lean-Agile says it is OK to be productive, even without Scrum That sounds flip, but it is a key point. We have had a number of clients where one of their groups is clearly more productive than the others. Yet none of them are doing Scrum, none of them are using iterative development. What accounts for the better performance? They are using Lean-based principles in their routine process while the others are not. They have co-location, voice of the customer, more up-front testing. And they are being productive. Here is a story. One friend, a development manager at a software company, told me that he is ready to kick off his teams people who are Scrum evangelists. They do not recognize that he is applying the principles already in ways that fit their situation and they are greatly more productive than others. Other Scrum practices just don’t fit their needs. Rather than rebuking t

Lean-Agile and the Process-Innovation Pendulum Alan was the keynote speaker at the SQE Better Software Conference in Las Vegas this year. Conferences are great for stirring up ideas and generating insights. For this podcast, I wanted to continue the series on Lean Anti-Patterns, sharing some more from what we are learning as we write this book. But you cannot always control a conversation. One of the hardest things to know as a facilitator is when to re-focus an individual or a group and when to let the ideas flow. You want the ideas to emerge and you want them to create the result. Today, I went with the passion, letting him share because I knew we’d get back to the other topic another day. Innovation or Process? Maybe it is a little like the challenge of the software industry: do we want process or do we want innovation? We keep shifting between the two. Software development methodology seems move between being creative and processes to control chaos. In the 70's, we had waterfall methods to structure our work. The 80's saw a burst of creativity with the rise of the PC, thousands of developers coming in and process took a back seat. The 90's saw a tension between the Internet (creative) and CMM (process). And where are we now? Maybe it is time for a happy medium. Maybe lean can help us achieve it. Lean sees process is the structure in which creativity can be expressed. Having standard work process frees me from having to think about the routine stuff so that I can spend creative energy on new stuff. The routine stuff always has to be done; standard work organizes it so that I do not have to devote more energy than necessary doing it. I do not have to decide if I am going to do testing, if I am going to have work-cell teams, if I am going to communicate with customers. That is the routine. As an example, I have just finished working with an organization where we needed to upgrade our Microsoft Office software. Now, you would think that ordering software would be fairly routine since the funds were already in place. But they had no process! Without process, it became an ordeal, all dependent on one guy to be a hero and figure out what to do next. We could go only as fast as he could work. Three weeks later, we are almost there. How much of his effort – and our time – was wasted because they had no process for the routine stuff. Scrum and Iterative Analysis Our biggest challenge is, and continues to be, to build products the customer wants. Thus, the biggest risk is building things the customer does not want. How do you manage this in a more complete way? Lean-Agile would say to do a little, learn a little, then adjust based on customer feedback. Do not do workarounds and do not build too much. Seen this way, Scrum is perhaps more of an iterative analysis technique than an iterative development technique. It helps to minimize that risk of building what the customer does not want. The rest of the Lean-Agile framework – Analysis, Design Patterns, Test-Driven Development, Scrum, Process, QA – certainly help us to have an environment where this can be done. Lean-Agile says it is OK to be productive, even without Scrum That sounds flip, but it is a key point. We have had a number of clients where one of their groups is clearly more productive than the others. Yet none of them are doing Scrum, none of them are using iterative development. What accounts for the better performance? They are using Lean-based principles in their routine process while the others are not. They have co-location, voice of the customer, more up-front testing. And they are being productive. Here is a story. One friend, a development manager at a software company, told me that he is ready to kick off his teams people who are Scrum evangelists. They do not recognize that he is applying the principles already in ways that fit their situation and they are greatly more productive than others. Other Scrum practices just don’t fit their needs. Rather than rebuking t

Lean Anti-Patterns: Overview It doesn’t have to be this way. Haven’t you felt that in your tummy sometimes? You and your team end up doing the same thing again and again, and you just get the same results again and again. And here you are again, starting out on that familiar path and it is going to be painful again. Around and around. That is an “anti-pattern”: Repeated patterns of work and behavior that produce counterproductive results. Alan Shalloway has been training companies across the country in lean for software development. As he has been working with clients to help them implement lean, he has heard many of these similar stories and problems. After hearing some symptoms, he can often identify more fundamental, root issues because he has built up a mental library of these anti-patterns. Giving names to the problems, Alan and his clients discover they can delve into solutions more quickly. Alan has come to see the study of anti-patterns as very important for learning lean. In the West, people can usually identify what is going wrong much more quickly than they can see what to do right. Anti-patterns gives you the ability to discuss the “what’s wrong” without dropping into whining or complaining. They also give a common discussion point around why the lean principles are so important: when you violate the principle, this is what happens. Together, this helps management understand what needs to change and why it is important. Based on this, Alan and I have begun to write a book called Lean Anti-Patterns and what to do about them. This book has six or seven parts and future podcasts will cover each of these parts. A quick overview of lean. There are a lot of great books, so this will be fast. Poppendieck. Womack and Jones. Liker. Fast-flexible-flow. How to get ideas in and get product out. How to deliver fast. Integrating the notions. Lean Anti-Patterns. Anti-pattern that violates lean principles is a lean anti-pattern. What is the principle that it violates and why that is a problem Anti-patterns in management. Patterns that are structural, process, customer-focused, the stuff that management must deal with all the time. This podcast will focus on one in particular: having too many projects. Technical anti-patterns. Not problems in coding, but but anti-patterns that occur in the technical team. Example: Delays in coding. Things that result from the anti-pattern. This discusses the symptoms that you likely to see when there is an anti-pattern. Tempting to think these are causative, but usually they are signs of deeper issues. Example is thrashing. Teams thrash when multi-tasking, get caught up not getting anything done. That is not the cause of the problem; instead, being caused by too many projects. If you keep doing what you keep doing, you are going to keep getting what you keep getting. Transitioning to lean. Lean is one of things that are simple but not easy. Find an easy gain to have. Little deeper. How keep it going. Book recommendations. What is the high level roadmap? Anti-patterns help management and workers work together to see beyond the current state to see what can change. No longer victims. In Addition Alan is working on two other projects that support this book effort. Webinars. First, he is developing a series of webinars that will take a deeper cut into the topic. Online. Second, he is developing a series of online learning opportunities. The nature of lean requires learning a lot. A 2-3 day intensive course is good for teams, but maybe for individuals, it is more effective to do this over time, giving you time to think. If you are interested in this book or these trainings, send note to Alan at alshall@netobjectives.com Personal Note On a personal note: Today, I am wishing a happy 25th wedding anniversary to my lovely bride! Amazing, still! Recommendations - Training by Net Objectives Lean-Agile Software Development Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed t

Lean Anti-Patterns: Overview It doesn’t have to be this way. Haven’t you felt that in your tummy sometimes? You and your team end up doing the same thing again and again, and you just get the same results again and again. And here you are again, starting out on that familiar path and it is going to be painful again. Around and around. That is an “anti-pattern”: Repeated patterns of work and behavior that produce counterproductive results. Alan Shalloway has been training companies across the country in lean for software development. As he has been working with clients to help them implement lean, he has heard many of these similar stories and problems. After hearing some symptoms, he can often identify more fundamental, root issues because he has built up a mental library of these anti-patterns. Giving names to the problems, Alan and his clients discover they can delve into solutions more quickly. Alan has come to see the study of anti-patterns as very important for learning lean. In the West, people can usually identify what is going wrong much more quickly than they can see what to do right. Anti-patterns gives you the ability to discuss the “what’s wrong” without dropping into whining or complaining. They also give a common discussion point around why the lean principles are so important: when you violate the principle, this is what happens. Together, this helps management understand what needs to change and why it is important. Based on this, Alan and I have begun to write a book called Lean Anti-Patterns and what to do about them. This book has six or seven parts and future podcasts will cover each of these parts. A quick overview of lean. There are a lot of great books, so this will be fast. Poppendieck. Womack and Jones. Liker. Fast-flexible-flow. How to get ideas in and get product out. How to deliver fast. Integrating the notions. Lean Anti-Patterns. Anti-pattern that violates lean principles is a lean anti-pattern. What is the principle that it violates and why that is a problem Anti-patterns in management. Patterns that are structural, process, customer-focused, the stuff that management must deal with all the time. This podcast will focus on one in particular: having too many projects. Technical anti-patterns. Not problems in coding, but but anti-patterns that occur in the technical team. Example: Delays in coding. Things that result from the anti-pattern. This discusses the symptoms that you likely to see when there is an anti-pattern. Tempting to think these are causative, but usually they are signs of deeper issues. Example is thrashing. Teams thrash when multi-tasking, get caught up not getting anything done. That is not the cause of the problem; instead, being caused by too many projects. If you keep doing what you keep doing, you are going to keep getting what you keep getting. Transitioning to lean. Lean is one of things that are simple but not easy. Find an easy gain to have. Little deeper. How keep it going. Book recommendations. What is the high level roadmap? Anti-patterns help management and workers work together to see beyond the current state to see what can change. No longer victims. In Addition Alan is working on two other projects that support this book effort. Webinars. First, he is developing a series of webinars that will take a deeper cut into the topic. Online. Second, he is developing a series of online learning opportunities. The nature of lean requires learning a lot. A 2-3 day intensive course is good for teams, but maybe for individuals, it is more effective to do this over time, giving you time to think. If you are interested in this book or these trainings, send note to Alan at alshall@netobjectives.com Personal Note On a personal note: Today, I am wishing a happy 25th wedding anniversary to my lovely bride! Amazing, still! Recommendations - Training by Net Objectives Lean-Agile Software Development Music used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed t

Completing the Agile Development Puzzle Bob Hartman is Net Objectives’ Vice President of Business Development and Marketing. He has over 20 years experience in the software industry and has seen it all. Maybe it is all those years in the trenches or maybe it is the gray in his beard or maybe it is living in Colorado, but I find his perspectives to be refreshing. He sees what organizations truly need and does a great job helping them. Recently, I had the chance to talk with Bob just after he gave a free public seminar called How to use lean principles to complete the Agile development puzzle This seminar was motivated by Bob's keen awareness that Agile – as it is usually taught – is not nearly as effective for teams and organizations as it should be. Teams only go so far and are left to struggle with how to improve, or must hire expensive consultants. Lean helps complete the picture. Here's a little more detail. To paraphrase a familiar quote, “Give a team Agile and they can work effectively until it breaks. Teach them Lean principles and they can continuously improve.” Clearly, he’s a recovering geek. But it is still true. The thrust of his seminar was to help people understand the lean principles that provide the foundation for Agile, so that they can be freed from the “Agile recipe book” to know how to adapt processes for themselves. They need to know the “Why” behind the “What.” Repeatedly, Bob has helped organizations compare the Agile practices they are doing now – especially what is not working as they had hoped – with the lean principles that inform those Agile practices to help them see where they need to go. Then, they can develop plans to get there. Knowing the principles gives Bob the “power” to see gaps. Here are some examples of problems that we see time and again in Agile teams. Agile problem: Testing happens at the end of an iteration. What usually happens: The Agile team runs out of time, so they push testing off to the next iteration. And then they push more testing off to the next iteration. And so on, always building up “testing debt.” Testing early is not a typical Agile process. Lean principle being violated: “Build Quality In.” Lean teaches another perspective on testing – it is essential right from the start. The goal is not simply to uncover defects but to prevent them in the first place. We want to build quality in, not test it in. Otherwise, just doing risk management. But building quality in (using TDD and acceptance tests up front), the team knows that the product is defect free. Agile problem: Trying to do more than in the current iteration than you had in the previous iteration. What usually happens: A team is pushed to go faster or get more done in the next iteration than they had done in the past iteration. The work piles on. And teams think there is something wrong with them or that the last iteration was just an aberration. Lean Principle: “Respect People” and “Do not multitask” and “Deliver Fast.” Teams usually don’t go faster than they have done. It is better to let them go at their established, sustainable pace, using disciplines rather than heroics. If they get their work done, they can always pull more off of the backlog, but should not be pushing stuff off. Piling on more work comes from fear that the team is not performing adequately, not going to get all of the features finished. But it is better to deliver whole features earlier to customers than to wait and wait and deliver a set of features late – the customer gets more value earlier Agile seems to be focused on improving teams. This is good, but may be sub-optimal. Teams end up focusing on their piece of the overall effort. Lean thinking builds on this to say, “let’s look at the entire stream of work we do, from the initial concept to cash in the door.” It helps management see their part in orchestrating something that will optimize the entire flow. For example, suppose you have a team that can turn a requirement into a finished p

Completing the Agile Development Puzzle Bob Hartman is Net Objectives’ Vice President of Business Development and Marketing. He has over 20 years experience in the software industry and has seen it all. Maybe it is all those years in the trenches or maybe it is the gray in his beard or maybe it is living in Colorado, but I find his perspectives to be refreshing. He sees what organizations truly need and does a great job helping them. Recently, I had the chance to talk with Bob just after he gave a free public seminar called How to use lean principles to complete the Agile development puzzle This seminar was motivated by Bob's keen awareness that Agile – as it is usually taught – is not nearly as effective for teams and organizations as it should be. Teams only go so far and are left to struggle with how to improve, or must hire expensive consultants. Lean helps complete the picture. Here's a little more detail. To paraphrase a familiar quote, “Give a team Agile and they can work effectively until it breaks. Teach them Lean principles and they can continuously improve.” Clearly, he’s a recovering geek. But it is still true. The thrust of his seminar was to help people understand the lean principles that provide the foundation for Agile, so that they can be freed from the “Agile recipe book” to know how to adapt processes for themselves. They need to know the “Why” behind the “What.” Repeatedly, Bob has helped organizations compare the Agile practices they are doing now – especially what is not working as they had hoped – with the lean principles that inform those Agile practices to help them see where they need to go. Then, they can develop plans to get there. Knowing the principles gives Bob the “power” to see gaps. Here are some examples of problems that we see time and again in Agile teams. Agile problem: Testing happens at the end of an iteration. What usually happens: The Agile team runs out of time, so they push testing off to the next iteration. And then they push more testing off to the next iteration. And so on, always building up “testing debt.” Testing early is not a typical Agile process. Lean principle being violated: “Build Quality In.” Lean teaches another perspective on testing – it is essential right from the start. The goal is not simply to uncover defects but to prevent them in the first place. We want to build quality in, not test it in. Otherwise, just doing risk management. But building quality in (using TDD and acceptance tests up front), the team knows that the product is defect free. Agile problem: Trying to do more than in the current iteration than you had in the previous iteration. What usually happens: A team is pushed to go faster or get more done in the next iteration than they had done in the past iteration. The work piles on. And teams think there is something wrong with them or that the last iteration was just an aberration. Lean Principle: “Respect People” and “Do not multitask” and “Deliver Fast.” Teams usually don’t go faster than they have done. It is better to let them go at their established, sustainable pace, using disciplines rather than heroics. If they get their work done, they can always pull more off of the backlog, but should not be pushing stuff off. Piling on more work comes from fear that the team is not performing adequately, not going to get all of the features finished. But it is better to deliver whole features earlier to customers than to wait and wait and deliver a set of features late – the customer gets more value earlier Agile seems to be focused on improving teams. This is good, but may be sub-optimal. Teams end up focusing on their piece of the overall effort. Lean thinking builds on this to say, “let’s look at the entire stream of work we do, from the initial concept to cash in the door.” It helps management see their part in orchestrating something that will optimize the entire flow. For example, suppose you have a team that can turn a requirement into a finished p

Know Thy Audience - Part 2 Happy Cinco de Mayo 2007! I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving. One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with. This is the first discipline you need to adopt to become a good Lean-Agile coach. Prepare and then prepare to be a learner (your first impressions are almost always wrong or at least incomplete). This show continues the conversation on preparation that we have been having with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. I am highlighting him to you because I find him to be a gifted coach who connects with senior management as well as anyone I have seen. He knows how to get things moving. I learn a lot by watching him and I think you will glean important ideas as well. You may recall, Alan categorizes clients into Entrepreneurial, Structured, and Highly-Defined organizations. How does this help him? He identifies several ways: It indicates the approaches to take to help the organization learn this new approach It gives a sense of their openness to innovation It helps predict the number of projects and variety of experiences that will be required during the discovery phase before management and workers can feel that this approach will work in their environment. Here is a little more detail The benefit of categorization First, categorization helps develop the approach to take to help the client learn this new way of doing product development. The more formal and specialized their work, the more they may have to unlearn before they can start to learn. The more centralized, the more likely it is that the central group will have to be involved in this “unlearning” early in the process. Along this line, it gives a sense of how likely the organization is to be able to learn, to improve, and to innovate. A very telling measure is to ask, “How often have practices been revised? And by whom?” The more entrepreneurial, the more likely they will be able to embrace change and empower local improvements. Categorizing customers indicates the breadth of “experimentation” or discovery that will be required in the consulting engagement. In an entrepreneurial organization, starting with local teams (the normal approach of Agile coaches) can be successful; but in highly-defined organizations, this will probably not be helpful: your sample size is just too small. The local team will often be so specialized that their issues will not be representative of the organization or the project types they face. You will not have demonstrated that the approach will work nor scale to the program level and so you will not get management buy-in. How will you drive out risks: in teams and in the organization (is Agile sufficient?) Remember, early in your consulting engagement, you are trying to drive out all of the risks that the client may face. It would be very easy to help local teams become highly productive product development engines. The main risk is just getting teams to adopt to a new way of thinking. If you can get over that, the “gossip network” will become a great ally. Emphasize an Agile approach and you will have good success with the team. However, simply emphasizing Agile will not lead to long-term success in more highly-defined organizations. The more highly-defined the organization, the more likely it is that the risks will not be evident right away. Local teams may become efficient, but there will still be organizational impediments that get in the way of the larger objective: improving the throughput of value to the customer. Will the team be allowed to work in an Agile way? Will the business be able t

Know Thy Audience - Part 2 Happy Cinco de Mayo 2007! I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving. One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with. This is the first discipline you need to adopt to become a good Lean-Agile coach. Prepare and then prepare to be a learner (your first impressions are almost always wrong or at least incomplete). This show continues the conversation on preparation that we have been having with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. I am highlighting him to you because I find him to be a gifted coach who connects with senior management as well as anyone I have seen. He knows how to get things moving. I learn a lot by watching him and I think you will glean important ideas as well. You may recall, Alan categorizes clients into Entrepreneurial, Structured, and Highly-Defined organizations. How does this help him? He identifies several ways: It indicates the approaches to take to help the organization learn this new approach It gives a sense of their openness to innovation It helps predict the number of projects and variety of experiences that will be required during the discovery phase before management and workers can feel that this approach will work in their environment. Here is a little more detail The benefit of categorization First, categorization helps develop the approach to take to help the client learn this new way of doing product development. The more formal and specialized their work, the more they may have to unlearn before they can start to learn. The more centralized, the more likely it is that the central group will have to be involved in this “unlearning” early in the process. Along this line, it gives a sense of how likely the organization is to be able to learn, to improve, and to innovate. A very telling measure is to ask, “How often have practices been revised? And by whom?” The more entrepreneurial, the more likely they will be able to embrace change and empower local improvements. Categorizing customers indicates the breadth of “experimentation” or discovery that will be required in the consulting engagement. In an entrepreneurial organization, starting with local teams (the normal approach of Agile coaches) can be successful; but in highly-defined organizations, this will probably not be helpful: your sample size is just too small. The local team will often be so specialized that their issues will not be representative of the organization or the project types they face. You will not have demonstrated that the approach will work nor scale to the program level and so you will not get management buy-in. How will you drive out risks: in teams and in the organization (is Agile sufficient?) Remember, early in your consulting engagement, you are trying to drive out all of the risks that the client may face. It would be very easy to help local teams become highly productive product development engines. The main risk is just getting teams to adopt to a new way of thinking. If you can get over that, the “gossip network” will become a great ally. Emphasize an Agile approach and you will have good success with the team. However, simply emphasizing Agile will not lead to long-term success in more highly-defined organizations. The more highly-defined the organization, the more likely it is that the risks will not be evident right away. Local teams may become efficient, but there will still be organizational impediments that get in the way of the larger objective: improving the throughput of value to the customer. Will the team be allowed to work in an Agile way? Will the business be able t

Know Thy Audience Dwight Eisenhower said, “Planning is everything, the plan is nothing.” One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with: their motivations, experiences in development, world view, and their focus in development efforts. Who makes decisions and how are they made? The thought work you put into your planning now will help you create a plan that both helps you focus on the important things first and gives you a flexible framework for the future. The more you engage with the organization, the more you should expect to adjust your coaching plan: it will never be correct the first time out. Adjustment is completely acceptable in Lean-Agile. What is not acceptable is going in unprepared. Lean-Agile is not chaotic. It requires discipline and a framework to build on. I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving. Early in his preparation to talk with a client, Alan spends a fair amount of time trying to understand who he will be talking to, what is driving them when it comes to software development. He classifies them as Entrepreneurial, Structured, or Highly Defined and that helps him decide what he will emphasize first. Of course, this is a tentative classification until he knows more. In this show, Alan discusses his classification approach. On a personal note, I can hardly believe it has been 2 months since I have done a podcast. It has been a crazy few months for me at Net Objectives. I have been on a couple of client coaching visits, worked with the Information School at the University of Washington (http://ischool.uw.edu/), and helped to develop our new web site, which is based on the Drupal content management system (http://www.drupal.org/). Drupal is a great tool and should serve as a good foundation for going forward. We had the good fortune to work with Scott McDaniel of Decisive Communications to help us with the new site. He is a WordPress expert who learned Drupal very well. If you haven’t had a chance to see our new site, take a look: www.netobjectives.com. We have put up a lot of new resources for registered users and customers. Hopefully, you will find it helpful. All of that and writing two books and learning to be a manager. Well, I am glad for my online virtual Kanban Boards to help me manage my work in an agile way and for patience of my friends, family, and listeners. I hope to be on a more regular production track now. Enjoy the show! Talk to us I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Technical Drupal - Open source content management system Scott McDaniel's site Decisive Communications. He helped us with the design of the new site, www.netobjectives.com Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Know Thy Audience Dwight Eisenhower said, “Planning is everything, the plan is nothing.” One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with: their motivations, experiences in development, world view, and their focus in development efforts. Who makes decisions and how are they made? The thought work you put into your planning now will help you create a plan that both helps you focus on the important things first and gives you a flexible framework for the future. The more you engage with the organization, the more you should expect to adjust your coaching plan: it will never be correct the first time out. Adjustment is completely acceptable in Lean-Agile. What is not acceptable is going in unprepared. Lean-Agile is not chaotic. It requires discipline and a framework to build on. I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving. Early in his preparation to talk with a client, Alan spends a fair amount of time trying to understand who he will be talking to, what is driving them when it comes to software development. He classifies them as Entrepreneurial, Structured, or Highly Defined and that helps him decide what he will emphasize first. Of course, this is a tentative classification until he knows more. In this show, Alan discusses his classification approach. On a personal note, I can hardly believe it has been 2 months since I have done a podcast. It has been a crazy few months for me at Net Objectives. I have been on a couple of client coaching visits, worked with the Information School at the University of Washington (http://ischool.uw.edu/), and helped to develop our new web site, which is based on the Drupal content management system (http://www.drupal.org/). Drupal is a great tool and should serve as a good foundation for going forward. We had the good fortune to work with Scott McDaniel of Decisive Communications to help us with the new site. He is a WordPress expert who learned Drupal very well. If you haven’t had a chance to see our new site, take a look: www.netobjectives.com. We have put up a lot of new resources for registered users and customers. Hopefully, you will find it helpful. All of that and writing two books and learning to be a manager. Well, I am glad for my online virtual Kanban Boards to help me manage my work in an agile way and for patience of my friends, family, and listeners. I hope to be on a more regular production track now. Enjoy the show! Talk to us I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Technical Drupal - Open source content management system Scott McDaniel's site Decisive Communications. He helped us with the design of the new site, www.netobjectives.com Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean and "So, what do we do next?" - Part 2 These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice? This is part 2 of a discussion on this. OK. Root causes, Agile, Value Stream. What else? I held this interview just after a challenging Lean-Agile Overview class. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on. The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?” What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection. There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day. In jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Managing Transitions: Making the most of change, by William Bridges Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean and "So, what do we do next?" - Part 2 These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice? This is part 2 of a discussion on this. OK. Root causes, Agile, Value Stream. What else? I held this interview just after a challenging Lean-Agile Overview class. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on. The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?” What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection. There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day. In jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Managing Transitions: Making the most of change, by William Bridges Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean and "So, what do we do next?" - Part 1 These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice? The problem of thrashing It has been one of those years this last month. Snow, holidays, and hospitals conspired to put me behind. So I have gotten really far behind and am slowly digging myself out. I suppose you could say to me, “Physician, heal thyself!” because I have gotten caught up in the multi-tasking / thrashing trap that we are going to talk about today. Has that ever happened to you? Where you have so much going on, so many tasks clamoring for your attention that you don’t know where to turn next? I think I am a good multi-tasker, so I was amazed at how behind I got. I decided to adopt the Lean-Agile technique of doing more by doing less at one time. My throughput has improved, even if it means I have not gotten some things – such as the blog and podcast – done according to schedule. Well, last week was spent working on a new content management system, based on Drupal. It is part of our knowledge management efforts here at Net Objectives. My prototype is done (and I’d be happy to share with you what I learned). We should get back to a weekly schedule on the podcasts soon. OK. So, what do we do now? I held this interview just after a challenging Lean-Agile Overview class that Alan had had. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on. The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?” What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection. There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day. Think about root causes Alan’s first answer to the question, “so, what do we do now” is to make the connection between the problems of delay you are seeing and the root causes for those problems. Organizational silos and thrashing are two primary types of root causes for delay. Thrashing is caused by multi-tasking, often brought on by having too many projects going on at once or having projects that are too large and complex. A “Bold Claim”: Do more by doing less at one time We see organizational silos and thrashing in one form or another in so many software development groups we talk to. Alan echoes a bold claim made by Mary and Tom Poppendieck that the best way to get out of thrashing, to improve your throughput when your pipeline is overfull is to stop trying to do so much at one time. As an organization and as an individual, you are better off focusing on one (or two) things at once, get them done, and then move on to the next thing. Having fewer projects