Lean-Agile Straight Talk

 Going beyond Scrum: Part 2 Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are taking it in two parts. Last time, we talked about the importance of optimizing the whole and taking a holistic view of the team if you want to be able to impact the enterprise. Now, we turn to two more key factors: the importance of managing your workflow and the value of accessing and using the good practices that have already been learned by others. In the book, we touched on the idea of Kanban for Software Development and it deserves some more consideration. We also cover resources and thought leaders to pay attention to as you look toward moving beyond (classic) Scrum to the enterprise. Kanban is an approach to managing work by focusing on the flow of work. How you organize the work - using a team-based swarming approach or a work-phase approach - is left to you; what is important is that you manage the amount of "work-in-progress" (WIP) that the team has going on at any time. And the organization manages WIP intentionally, by policy. Limiting WIP helps reduce delay. Improving the process, then, is focused on reducing anything that impedes the flow of work. That is how you choose what to improve. Kanban is appropriate even in your Scrum practice. It is truly remarkable how well it helps to have a defined workflow and process improvement approach. The Scrum Clinic In our years of coaching Scrum, we have learned some good practices that every team seems to have to learn. It makes sense to learn them early rather than forcing the team to have to discover them on its own (per the classic Scrum approach). Why reinvent the wheel when there is already so much more to discover. We pulled together essentialresources into one place, "The Scrum Clinic," which you can access for free. Each resource is small "chunk of high-leverage knowledge" that will get you going in your own use of Scrum much more quickly.  Examples include: How to vastly improve your team in one hour. A better method of estimationThe priority of removing delayThe new role of QA (webinar recording)A quick lesson on testingRecommendationsThe Lean-Agile Pocket Guide for Scrum TeamsLean Software and Systems Consortium: www.leanssc.orgLimited WIP Society D.J. Anderson Associates: www.agilemanagement.netDon Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product DevelopmentFor 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

 Going beyond Scrum: Part 2 Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are taking it in two parts. Last time, we talked about the importance of optimizing the whole and taking a holistic view of the team if you want to be able to impact the enterprise. Now, we turn to two more key factors: the importance of managing your workflow and the value of accessing and using the good practices that have already been learned by others. In the book, we touched on the idea of Kanban for Software Development and it deserves some more consideration. We also cover resources and thought leaders to pay attention to as you look toward moving beyond (classic) Scrum to the enterprise. Kanban is an approach to managing work by focusing on the flow of work. How you organize the work - using a team-based swarming approach or a work-phase approach - is left to you; what is important is that you manage the amount of "work-in-progress" (WIP) that the team has going on at any time. And the organization manages WIP intentionally, by policy. Limiting WIP helps reduce delay. Improving the process, then, is focused on reducing anything that impedes the flow of work. That is how you choose what to improve. Kanban is appropriate even in your Scrum practice. It is truly remarkable how well it helps to have a defined workflow and process improvement approach. The Scrum Clinic In our years of coaching Scrum, we have learned some good practices that every team seems to have to learn. It makes sense to learn them early rather than forcing the team to have to discover them on its own (per the classic Scrum approach). Why reinvent the wheel when there is already so much more to discover. We pulled together essentialresources into one place, "The Scrum Clinic," which you can access for free. Each resource is small "chunk of high-leverage knowledge" that will get you going in your own use of Scrum much more quickly.  Examples include: How to vastly improve your team in one hour. A better method of estimationThe priority of removing delayThe new role of QA (webinar recording)A quick lesson on testingRecommendationsThe Lean-Agile Pocket Guide for Scrum TeamsLean Software and Systems Consortium: www.leanssc.orgLimited WIP Society D.J. Anderson Associates: www.agilemanagement.netDon Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product DevelopmentFor more information, visit us at http://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

 Going beyond Scrum: Part 1 Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are going to take it in two parts. First, we want to consider the implications of the maturing and segmentation of the Scrum community and two key factors required for being able to scale Scrum to an enterprise: taking a systemic approach and looking at the team holistically, how it fits with and must work within the organization. Next time, we will look at Kanban, managing the flow of work, and using the Scrum clinic to (reusing) good practices learned by others. Over the last decade, the Scrum community has matured greatly. And, as often happens, it has begun to segment as people discover new, alternative paths that the founders never imagined. Sometimes, that means people move on from the original group When it comes time to investigate or add new profitable bodies of knowledge. I think that is what you see in the various Scrum, Lean-Agile, and Kanban communities. New ways are being explored. Clearly, there have been situations and teams where classic Scrum worked very beautifully and helped create a lot of value for an organization. It seems that that population has mostly been mined, that that market has been pretty much saturated. Going forward, there is a need to be able to help teams and organizations where more is needed, where classic Scrum, by itself, is just not enough. This chapter touches on two key understandings or beliefs that are required to be able to go beyond (classic) Scrum. One is that you can (indeed must) take a systematic approach. The other is that a team-centric focus is not sufficient. A systematic approach. One of the new approaches (which is not really new but reaches back to solid principles) tries to take a more systems-thinking approach, thinking along with Don Reinertsen that productivity comes by looking at PEOPLE X PROCESS. That is, the whole system - people and process - works together and neither can be ignored. Lean calls this "optimize the whole." Thus, as we have gained experience with Scrum - and especially as we have begun to incorporate it with other disciplines such as Lean, Test-Driven, patterns, and the like, we are learning what behaviors and patterns teams need to be effective and what processes help them. And once learned, why not use them again and again rather than forcing each team to have to discover them again on their own? That is part of the driving force behind this chapter and this book. A holistic view of the team. The second thing is to look beyond the individual team to how how they must interact with each other. Recommendations The Lean-Agile Pocket Guide for Scrum Teams Lean Software and Systems Consortium: www.leanssc.org Limited WIP Society D.J. Anderson Associates: www.agilemanagement.net/ Don Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development 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

 Going beyond Scrum: Part 1 Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are going to take it in two parts. First, we want to consider the implications of the maturing and segmentation of the Scrum community and two key factors required for being able to scale Scrum to an enterprise: taking a systemic approach and looking at the team holistically, how it fits with and must work within the organization. Next time, we will look at Kanban, managing the flow of work, and using the Scrum clinic to (reusing) good practices learned by others. Over the last decade, the Scrum community has matured greatly. And, as often happens, it has begun to segment as people discover new, alternative paths that the founders never imagined. Sometimes, that means people move on from the original group When it comes time to investigate or add new profitable bodies of knowledge. I think that is what you see in the various Scrum, Lean-Agile, and Kanban communities. New ways are being explored. Clearly, there have been situations and teams where classic Scrum worked very beautifully and helped create a lot of value for an organization. It seems that that population has mostly been mined, that that market has been pretty much saturated. Going forward, there is a need to be able to help teams and organizations where more is needed, where classic Scrum, by itself, is just not enough. This chapter touches on two key understandings or beliefs that are required to be able to go beyond (classic) Scrum. One is that you can (indeed must) take a systematic approach. The other is that a team-centric focus is not sufficient. A systematic approach. One of the new approaches (which is not really new but reaches back to solid principles) tries to take a more systems-thinking approach, thinking along with Don Reinertsen that productivity comes by looking at PEOPLE X PROCESS. That is, the whole system - people and process - works together and neither can be ignored. Lean calls this "optimize the whole." Thus, as we have gained experience with Scrum - and especially as we have begun to incorporate it with other disciplines such as Lean, Test-Driven, patterns, and the like, we are learning what behaviors and patterns teams need to be effective and what processes help them. And once learned, why not use them again and again rather than forcing each team to have to discover them again on their own? That is part of the driving force behind this chapter and this book. A holistic view of the team. The second thing is to look beyond the individual team to how how they must interact with each other. Recommendations The Lean-Agile Pocket Guide for Scrum Teams Lean Software and Systems Consortium: www.leanssc.org Limited WIP Society D.J. Anderson Associates: www.agilemanagement.net/ Don Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development For more information, visit us at http://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

 Reflections on a New Year: Part 1 The beginning of the year is a natural time to think about what is coming in the year. Alan Shalloway shares his thoughts about some of the areas in which Net Objectives will be investing its energy and thought as we help to serve our partners and customers.  In addition to our normal areas of training and coaching in Lean, Agile, acceptance test-driven development, design patterns, and process improvement. But what else? In this podcast, Alan and I talk about two key areas where we are going to be investing our energy: Kanban and what it takes to help enterprises and teams make the transition.   Kanban. We believe in Kanban for software development. We have joined with David Anderson and others to help foster the community of those who want to explore how to use this, the good practices, the deep principles - you might call it the "science" of Kanban software engineering. What it takes to realize the tremendous potential benefit of this approach. Two key communities to look into are the http://limitedwipsociety.ning.com/ in the UK and the LeanSSC.org, which is more worldwide. Transition. How to help enterprises and teams make the transition, the change to greater productivity in software development: managing the introduction of change to be productivity What prompted this was a training class with David Anderson of D.J. Anderson Associates. David is a leading expert in Kanban as applied to software engineering. I recommend his course for anyone who wants to sharpen skills in coaching Kanban because he has seen it all. This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February. Recommendations Lean Software and Systems Consortium: www.leanssc.org http://limitedwipsociety.ning.com/ D.J. Anderson Associates: www.agilemanagement.net/ William Bridges, Managing Transitions: Making the most of change Don Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development 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

 Reflections on a New Year: Part 1 The beginning of the year is a natural time to think about what is coming in the year. Alan Shalloway shares his thoughts about some of the areas in which Net Objectives will be investing its energy and thought as we help to serve our partners and customers.  In addition to our normal areas of training and coaching in Lean, Agile, acceptance test-driven development, design patterns, and process improvement. But what else? In this podcast, Alan and I talk about two key areas where we are going to be investing our energy: Kanban and what it takes to help enterprises and teams make the transition.   Kanban. We believe in Kanban for software development. We have joined with David Anderson and others to help foster the community of those who want to explore how to use this, the good practices, the deep principles - you might call it the "science" of Kanban software engineering. What it takes to realize the tremendous potential benefit of this approach. Two key communities to look into are the http://limitedwipsociety.ning.com/ in the UK and the LeanSSC.org, which is more worldwide. Transition. How to help enterprises and teams make the transition, the change to greater productivity in software development: managing the introduction of change to be productivity What prompted this was a training class with David Anderson of D.J. Anderson Associates. David is a leading expert in Kanban as applied to software engineering. I recommend his course for anyone who wants to sharpen skills in coaching Kanban because he has seen it all. This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February. Recommendations Lean Software and Systems Consortium: www.leanssc.org http://limitedwipsociety.ning.com/ D.J. Anderson Associates: www.agilemanagement.net/ William Bridges, Managing Transitions: Making the most of change Don Reinertsen, The Principles of Product Development Flow: Second Generation Lean Product Development For more information, visit us at http://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

 Introducing Kanban for Software Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach.  Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about. Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January. Recommendations Lean Software and Systems Consortium: www.leanssc.org 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

 Introducing Kanban for Software Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach.  Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about. Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January. Recommendations Lean Software and Systems Consortium: www.leanssc.org For more information, visit us at http://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

 Chapter 4: Lean Portfolio Management 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 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works. What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up. There is another benefit. We build these big project plans and even though we know they won't work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards - so bedeviling - become a thing of the past. 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

 Chapter 4: Lean Portfolio Management 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 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works. What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up. There is another benefit. We build these big project plans and even though we know they won't work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards - so bedeviling - become a thing of the past. 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 http://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

 Chapter 3: The Big Picture 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 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas. It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things? Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas: Team agility Technical agility Management agility Business agility Of course, where to start depends on your situation. 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 http://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

 Chapter 3: The Big Picture 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 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas. It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things? Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas: Team agility Technical agility Management agility Business agility Of course, where to start depends on your situation. 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

 Chapter 2: The Business Case for Agility 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 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition. It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile: Deliver value quicker. Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good! Helping customers discover what it is they need. Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang. Better project management. Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate. Improving process faster. It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months!  Letting your design emerge based on what you are learning. While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so: Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Agile Software Development, Principles, Patterns, and Practices by Bob Martin 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 http://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 regist

 Chapter 2: The Business Case for Agility 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 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition. It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile: Deliver value quicker. Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good! Helping customers discover what it is they need. Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang. Better project management. Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate. Improving process faster. It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months!  Letting your design emerge based on what you are learning. While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so: Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain Agile Software Development, Principles, Patterns, and Practices by Bob Martin 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 regis

 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 http://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