Lean-Agile Straight Talk

 Chapter 1: A Developer's Guide to Lean Software Development This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.  This show focuses on Chapter 1, A Developers Guide to Lean Software Development. We start to answer the question, if Lean's goal is to focus on speed, quality, and low cost. How do you do it? In the past, the approach has been to try to make every step and every person as efficient as possible. That doesn't work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality. Lean says the better approach is to focus on removing delays. We want to focus on the time between the idea is conceived until the customer can consume it. This involves realizing that product development is a conversation between developers and customers to discover what is required. Customers don't always know what they need. As much as possible, you want your process to improve the learning and feedback that is taking place so that customers can focus on what they really need. What is needed? Focus on removing delays, removing waste in the overall process. For example, Get feedback from the customer quickly. Write tests first. Then you immediately discover when bugs appear. Detect integration issues quickly. The bottomline is that We want to make value flow through the organization quickly and remove anything that causes delay. Finally, practices change depending on the context. How do you know the practices you are doing are good? By comparing them with the foundation lean principles. Teams have both responsibility and guidance for their work. That is the perspective they need. About Lean-Agile Software Development: Achieving Enterprise Agility The motivation of this book is to create a bigger picture what teams transitioning to agile need to do. Yes, teams need to understand the mechanics of the approach to get working, but there is more. Management needs to understand how to help teams work together. Business leadership prioritizing the right things to be working on. And there is a need to ensure technical quality so that development can be done in a sustainable way. We also want to introduce Lean and how it applies to the transition. We don't believe "scaling up" is a very effective approach. Rather, taking a more holistic view is needed to get success. That is how Lean thinking helps. This is not a book for experienced practitioners but for those who are picking Agile, Scrum, or Lean for software development. We expect you do understand a bit about Agile but not anything about Lean. For more information see the resource page for the book. Recommendations Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Design Patterns Explained by Alan Shalloway and James R Trott For more information, visit us at https://www.netobjectives.com/ Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds. Blog Type: PodcastLog in or register to post comments

 An Overview of Two New Books In this show, we give overviews of two new books by Net Objectives which we think you will find helpful: The Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We talk through both of these books: their motivation, their contents, why they are useful. In the next podcast, we will talk about the key ideas in each chapter by chapter of Lean-Agile Software Development, the ideas we have found is truly needed in order to be able to achieve enterprise agility. The Lean-Agile Pocket Guide for Scrum Teams The Pocket Guide fills the gap between one of those 10 page ("marketing") overviews of Scrum and the thousands of pages that have been written on various good Scrum practices. In our work, we found there was a need for a concise statement of what scrum is and a convenient distillation of the best practices. It also includes some techniques not traditionally taught in Scrum but which are very helpful. In 200 pages, it is a great tool to remind you what needs to happen from beginning to end of product development. Lots of checklists and templates to help you think. Some of our clients have found this tool so helpful that they have created a "private label" version of the pocket guide for their own use. It served as a baseline for their own process. And we are willing to do that with others. If you are interested in this for yourself, drop us a note. For more information see the resource page for the pocket guide. Lean-Agile Software Development The motivation of this book is to create a bigger picture what teams transitioning to agile need to do. Yes, teams need to understand the mechanics of the approach to get working, but there is more. Management needs to understand how to help teams work together. Business leadership prioritizing the right things to be working on. And there is a need to ensure technical quality so that development can be done in a sustainable way. We also want to introduce Lean and how it applies to the transition. We don't believe "scaling up" is a very effective approach. Rather, taking a more holistic view is needed to get success. That is how Lean thinking helps. This is not a book for experienced practitioners but for those who are picking Agile, Scrum, or Lean for software development. We expect you do understand a bit about Agile but not anything about Lean. For more information see the resource page for the book. Recommendations Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Design Patterns Explained by Alan Shalloway and James R Trott For more information, visit us at http://www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

 An Overview of Two New Books In this show, we give overviews of two new books by Net Objectives which we think you will find helpful: The Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We talk through both of these books: their motivation, their contents, why they are useful. In the next podcast, we will talk about the key ideas in each chapter by chapter of Lean-Agile Software Development, the ideas we have found is truly needed in order to be able to achieve enterprise agility. The Lean-Agile Pocket Guide for Scrum Teams The Pocket Guide fills the gap between one of those 10 page ("marketing") overviews of Scrum and the thousands of pages that have been written on various good Scrum practices. In our work, we found there was a need for a concise statement of what scrum is and a convenient distillation of the best practices. It also includes some techniques not traditionally taught in Scrum but which are very helpful. In 200 pages, it is a great tool to remind you what needs to happen from beginning to end of product development. Lots of checklists and templates to help you think. Some of our clients have found this tool so helpful that they have created a "private label" version of the pocket guide for their own use. It served as a baseline for their own process. And we are willing to do that with others. If you are interested in this for yourself, drop us a note. For more information see the resource page for the pocket guide. Lean-Agile Software Development The motivation of this book is to create a bigger picture what teams transitioning to agile need to do. Yes, teams need to understand the mechanics of the approach to get working, but there is more. Management needs to understand how to help teams work together. Business leadership prioritizing the right things to be working on. And there is a need to ensure technical quality so that development can be done in a sustainable way. We also want to introduce Lean and how it applies to the transition. We don't believe "scaling up" is a very effective approach. Rather, taking a more holistic view is needed to get success. That is how Lean thinking helps. This is not a book for experienced practitioners but for those who are picking Agile, Scrum, or Lean for software development. We expect you do understand a bit about Agile but not anything about Lean. For more information see the resource page for the book. Recommendations Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Design Patterns Explained by Alan Shalloway and James R Trott For more information, visit us at https://www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

A New Series This podcast kicks off a new series for Lean Agile Straight Talk. We have been busy finishing several books focused on Lean-Agile. One is called the Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We are proud of both of these books and wanted to introduce them to you. In this show, Alan Shalloway and I talk about the motivations behind these books, what is going in in the world of Lean and Agile software development and why they are needed. The next show will give a rundown of the pocket guide. After that, we will talk through each of the chapters in Lean-Agile Software Development. Each of these chapters has good, core concepts that we want you to know and this approach gives us a game plan for covering all of them. Each of the books Net Objectives offers aims to address the question, "What do people need to know to succeed in their role to do product development?" In a nutshell, we describe Lean-Agile with the phrase, Make-Value-Flow-Sustainably. Make. How do developers create software at the team-level? In the past, "making" was where the challenges were. Value. What does the business need? How do we get them to drive what really needs to get done? Flow. How do you get what multiple teams create to flow through the organization? Learning to work together, coordinating work. Sustainably. How to keep writing code so that it is always of sufficient quality, so that we do not keep incurring technical debt. And how to keep the organization growing in a healthy way so that it can continue to do the work. Even if you find a technique, such as Scrum, that works well at a team-level, it does not always work in every context. And, we have learned that trying to "scale" Scrum to the enterprise is not the correct approach to achieve enterprise agility. Understanding the principles helps you know what to do when confronting situations you have not yet encountered. And that leads to proficiency in this field. Recommendations Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Design Patterns Explained by Alan Shalloway and James R Trott For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/     Blog Type: PodcastLog in or register to post comments

A New Series This podcast kicks off a new series for Lean Agile Straight Talk. We have been busy finishing several books focused on Lean-Agile. One is called the Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We are proud of both of these books and wanted to introduce them to you. In this show, Alan Shalloway and I talk about the motivations behind these books, what is going in in the world of Lean and Agile software development and why they are needed. The next show will give a rundown of the pocket guide. After that, we will talk through each of the chapters in Lean-Agile Software Development. Each of these chapters has good, core concepts that we want you to know and this approach gives us a game plan for covering all of them. Each of the books Net Objectives offers aims to address the question, "What do people need to know to succeed in their role to do product development?" In a nutshell, we describe Lean-Agile with the phrase, Make-Value-Flow-Sustainably. Make. How do developers create software at the team-level? In the past, "making" was where the challenges were. Value. What does the business need? How do we get them to drive what really needs to get done? Flow. How do you get what multiple teams create to flow through the organization? Learning to work together, coordinating work. Sustainably. How to keep writing code so that it is always of sufficient quality, so that we do not keep incurring technical debt. And how to keep the organization growing in a healthy way so that it can continue to do the work. Even if you find a technique, such as Scrum, that works well at a team-level, it does not always work in every context. And, we have learned that trying to "scale" Scrum to the enterprise is not the correct approach to achieve enterprise agility. Understanding the principles helps you know what to do when confronting situations you have not yet encountered. And that leads to proficiency in this field. Recommendations Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Design Patterns Explained by Alan Shalloway and James R Trott For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com/     Blog Type: PodcastLog in or register to post comments

 Redefining Lean Lean Software Development is founded on Lean. But what is "Lean"? Some have said that "lean is just what Toyota does." That is not much of a definition and is not even accurate, although Toyota does do Lean. It is also not accurate to say that Lean is focused on manufacturing, although Lean is now widely used in manufacturing.Lean is not even principally about physical product even though most of the examples of Lean are in the physical world. No. It is better to see Toyota manufacturing and Toyota product development as just examples, as manifestations of this way of thinking we call Lean. Here is one good way to think about what is going in in Lean: There is Lean Science, Lean Management, and Lean Knowledge Stewardship. Lean Science: There are rules and principles that are present, observable, can be used to make predictions, and we can adapt and learn based on what we test and observe. The most flexible approach is to understand the Why that is behind the practices. This is how Don Reinertsen has helped us, identifying the fundamental rules. Lean Management: How to help the organization take advantage of the science and how to remove the problems people have. The manager is involved, neither hands-off nor command-and-control. Manager's role is education, helping people know how to think, how to see problems and how to think about the system, and also to set direction. Using visual controls helps managers see when process is going awry and there is a need to intervene, when to educate. Note: Jim Womack underscores this in his webinar, The Role of Leadership in Lean Lean Knowledge Stewardship: How to discover, share, adapt, apply, and take care of the knowledge we have in the organization. There are techniques such as A3, Kaizen, AAR/Retrospection, Root Cause and 5 Whys, Value Stream Maps, Make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com   Recommendations By Don Reinertsen The Principles of Product Development Flow: Second Generation Lean Product Development Managing the Design Factory By Corey Ladas Scrum-ban Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Redefining Lean Lean Software Development is founded on Lean. But what is "Lean"? Some have said that "lean is just what Toyota does." That is not much of a definition and is not even accurate, although Toyota does do Lean. It is also not accurate to say that Lean is focused on manufacturing, although Lean is now widely used in manufacturing.Lean is not even principally about physical product even though most of the examples of Lean are in the physical world. No. It is better to see Toyota manufacturing and Toyota product development as just examples, as manifestations of this way of thinking we call Lean. Here is one good way to think about what is going in in Lean: There is Lean Science, Lean Management, and Lean Knowledge Stewardship. Lean Science: There are rules and principles that are present, observable, can be used to make predictions, and we can adapt and learn based on what we test and observe. The most flexible approach is to understand the Why that is behind the practices. This is how Don Reinertsen has helped us, identifying the fundamental rules. Lean Management: How to help the organization take advantage of the science and how to remove the problems people have. The manager is involved, neither hands-off nor command-and-control. Manager's role is education, helping people know how to think, how to see problems and how to think about the system, and also to set direction. Using visual controls helps managers see when process is going awry and there is a need to intervene, when to educate. Note: Jim Womack underscores this in his webinar, The Role of Leadership in Lean Lean Knowledge Stewardship: How to discover, share, adapt, apply, and take care of the knowledge we have in the organization. There are techniques such as A3, Kaizen, AAR/Retrospection, Root Cause and 5 Whys, Value Stream Maps, Make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com   Recommendations By Don Reinertsen The Principles of Product Development Flow: Second Generation Lean Product Development Managing the Design Factory By Corey Ladas Scrum-ban Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Report from Lean Kanban 2009 Kanban is an emerging practice in Lean software development. Founded on solid principles of flow and utilization theory, it seems to address many of the issues people have had with Agile approaches. Over the next few years, Lean Kanban is going to become an important part of the software professional's toolkit. The Lean Kanban Conference 2009, May 6-9, 2009 in Miame, brought together practitioners and thought leaders to discuss how to help the community go forward. This podcast is a report by Alan Shalloway about what he, Guy Beaver, and Alan Chedalawada (all from Net Objectives) learned from this special event. Over the next few weeks, Alan will be posting some blogs about what he learned at the conference. See blogs.netobjectives.com. It will be the topic of several upcoming podcasts on Lean-Agile Straight Talk.  You can learn more about this conference at http://miami2009.leanssc.org/ And make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com Recommendations By Don Reinertsen The Principles of Product Development Flow: Second Generation Lean Product Development Managing the Design Factory By Corey Ladas Scrum-ban Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Report from Lean Kanban 2009 Kanban is an emerging practice in Lean software development. Founded on solid principles of flow and utilization theory, it seems to address many of the issues people have had with Agile approaches. Over the next few years, Lean Kanban is going to become an important part of the software professional's toolkit. The Lean Kanban Conference 2009, May 6-9, 2009 in Miame, brought together practitioners and thought leaders to discuss how to help the community go forward. This podcast is a report by Alan Shalloway about what he, Guy Beaver, and Alan Chedalawada (all from Net Objectives) learned from this special event. Over the next few weeks, Alan will be posting some blogs about what he learned at the conference. See blogs.netobjectives.com. It will be the topic of several upcoming podcasts on Lean-Agile Straight Talk.  You can learn more about this conference at http://miami2009.leanssc.org/ And make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com Recommendations By Don Reinertsen The Principles of Product Development Flow: Second Generation Lean Product Development Managing the Design Factory By Corey Ladas Scrum-ban Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Three Things You Gotta Know Lean is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. It can feel overwhelming. It is rich and there are many, many techniques and practices. It is always growing as it absorbs more good practices. That's why people can make careers out of Lean. But you don't have to know all of Lean before you can get started. And you don't have to even be committed to becoming Lean to get the benefit from using Lean a little. In this show, Alan Shalloway discusses some of the essentials that you do need to know in order to get started. The things you have to know about Lean include: Look at TIME not Resource Utilization. In mass production, you are trying to minimize the resources expended per unit of work. In Lean, you are trying to minimize the time it takes for the Idea to turn into something that returns value to the organization from using it (using it in the business or selling it). Errors usually arise from defects in a system, not poorly performing people. We don't aim for blame but we do aim for deep understanding about what happened. Management plays an important part in process improvement The proper role for management is neither command-and-control nor should be teams be "protected" or isolated from management. Rather, management is responsible for helping the team to see and how to think. They ask intelligent questions, question them when they are not following process, help them drive to how to solutions. Management creates the context within which problems can be addressed.  Recommendations The Role of Leadership in Lean (by Jim Womack and the LEI) Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio. Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Three Things You Gotta Know Lean is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. It can feel overwhelming. It is rich and there are many, many techniques and practices. It is always growing as it absorbs more good practices. That's why people can make careers out of Lean. But you don't have to know all of Lean before you can get started. And you don't have to even be committed to becoming Lean to get the benefit from using Lean a little. In this show, Alan Shalloway discusses some of the essentials that you do need to know in order to get started. The things you have to know about Lean include: Look at TIME not Resource Utilization. In mass production, you are trying to minimize the resources expended per unit of work. In Lean, you are trying to minimize the time it takes for the Idea to turn into something that returns value to the organization from using it (using it in the business or selling it). Errors usually arise from defects in a system, not poorly performing people. We don't aim for blame but we do aim for deep understanding about what happened. Management plays an important part in process improvement The proper role for management is neither command-and-control nor should be teams be "protected" or isolated from management. Rather, management is responsible for helping the team to see and how to think. They ask intelligent questions, question them when they are not following process, help them drive to how to solutions. Management creates the context within which problems can be addressed.  Recommendations The Role of Leadership in Lean (by Jim Womack and the LEI) Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio. Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Getting to the Benefits It has been estimated that 75% of companies undertaking Scrum are not experiencing the benefits they expected. Why do you suppose this is? Why don't we take time to stop, observe, and improve our processes? Why is lean perhaps a more natural starting point for the enterprise? These are some of the questions explored by Alan Shalloway in today's podcast. But first, Alan invites you to come to the Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio. It promises to be a powerful time. To learn more, visit the Kanban Dev Yahoo user group. Why aren't organizations manifesting the promise of Scrum? Ken Schwaeber says that 75% of companies who try Scrum do not manifest the problems of Scrum. This means that they do not get the benefits they thought they would. Why not? Scrum is a lightweight methodology that exposes impediments so you can fix them. Too often, rather than fixing them, teams just accommodate the impediments. and that is a problem. Why do teams do that? They are beset by the tyranny of the urgent. By the time they have time to reflect, the next problem is there and they have to move on. They just don't have time to stop! Why don't they stop to look? Because they are starting at the wrong end: at the team-level and then think about how to "scale up" and that is hard to do. It just leads to increasing levels of complexity. How much better it is to start with something that begins at the enterprise level The benefit of Lean is that it offers a better starting point. People don't talk about scaling up Lean because Lean already starts at the enterprise level. That is its natural environment. We think of Lean this way: It is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. You could see Lean as having absorbed Agile/Scrum practices into the Lean way of thinking (as well as seeing Scrum as manifesting Lean principles to the specific context of teams creating software). What matters is not where the practices came from but rather that they come into the enterprise in a way that lets them be put to work broadly: Testing it in concrete work, improving it with basic lean principles as needed, tossing it if it doesn't work. Recommendations Lean Kanban 2009 conference in Miami May 6-8, 2009.  Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Getting to the Benefits It has been estimated that 75% of companies undertaking Scrum are not experiencing the benefits they expected. Why do you suppose this is? Why don't we take time to stop, observe, and improve our processes? Why is lean perhaps a more natural starting point for the enterprise? These are some of the questions explored by Alan Shalloway in today's podcast. But first, Alan invites you to come to the Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio. It promises to be a powerful time. To learn more, visit the Kanban Dev Yahoo user group. Why aren't organizations manifesting the promise of Scrum? Ken Schwaeber says that 75% of companies who try Scrum do not manifest the problems of Scrum. This means that they do not get the benefits they thought they would. Why not? Scrum is a lightweight methodology that exposes impediments so you can fix them. Too often, rather than fixing them, teams just accommodate the impediments. and that is a problem. Why do teams do that? They are beset by the tyranny of the urgent. By the time they have time to reflect, the next problem is there and they have to move on. They just don't have time to stop! Why don't they stop to look? Because they are starting at the wrong end: at the team-level and then think about how to "scale up" and that is hard to do. It just leads to increasing levels of complexity. How much better it is to start with something that begins at the enterprise level The benefit of Lean is that it offers a better starting point. People don't talk about scaling up Lean because Lean already starts at the enterprise level. That is its natural environment. We think of Lean this way: It is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. You could see Lean as having absorbed Agile/Scrum practices into the Lean way of thinking (as well as seeing Scrum as manifesting Lean principles to the specific context of teams creating software). What matters is not where the practices came from but rather that they come into the enterprise in a way that lets them be put to work broadly: Testing it in concrete work, improving it with basic lean principles as needed, tossing it if it doesn't work. Recommendations Lean Kanban 2009 conference in Miami May 6-8, 2009.  Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: http://ghostnotes.blogspot.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

 Scrum and Management: Planning and Focusing Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face. There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve. This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development. In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus. Release Planning For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the other hand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value. This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next. Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets. Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look. Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth. Each of these features might involve many stories. The question is what is the minimum set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial splash in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration? Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage? There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimum set of features required for a release. And then you can still talk about how you will package the features into the final release to the customer. This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.   Iteration Planning Now, it is different when it comes to planning an iteration. Now that you have specified the minimum set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iterati

 Scrum and Management: Planning and Focusing Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face. There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve. This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development. In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus. Release Planning For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the other hand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value. This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next. Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets. Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look. Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth. Each of these features might involve many stories. The question is what is the minimum set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial splash in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration? Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage? There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimum set of features required for a release. And then you can still talk about how you will package the features into the final release to the customer. This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.   Iteration Planning Now, it is different when it comes to planning an iteration. Now that you have specified the minimum set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iterati