Lean-Agile Straight Talk

Scaling Scrum to the Enterprise with Lean Software Development (audio of the webinar) Scrum# is an extension to Scrum that was developed by Net Objectives to solve challenges that were being encountered by many teams adopting Scrum. Read about more about the issues which Scrum# was created to solve. A webinar on July 21, 2008 presented by Alan Shalloway presents a broad stroke of Scrum#. It gives a high view of the process and analysis extensions of Scrum#. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Note: This webinar is close to an hour long, so the files are large. Attend other sessions in the Scrum# Webinar series. The ideas and strategies introduced in this webinar are also being explored in a book which is currently being written by Alan Shalloway, Jim Trott with contributions from other Net Objectives consultants. Learn more about the book and read selected chapters. Blog Type: PodcastLog in or register to post comments

 Coming Up at Agile 2008 Once again, Net Objectives is a co-sponsor of the Agile 2008 conference. This is a premier gathering for people and organizations involved in Agile software development. This year, it is being held in Toronto, Canada, August 4-8. Every year, we devote a podcast to what Net Objectives is doing at Agile 2008, both to help people who are going know what we are up to and to help people who cannot go know what trends we see that are important, where we will be devoting energy. In this show, Alan Shalloway covers five primary topics: Why we are involved with the Agile conferences and why they are important for the industry The Certification by Net Objectives program, which was announced at Agile 2007, including: Scrum Master Certification, Scrum Team Member Certification, and Product Owner Certification The announcement of the Implementing Agile Development using Microsoft Visual Studio process template, which has just been completed by Net Objectives An announcement of Scrum#, which is an extension of Scrum that helps to integrate Lean thinking, Scrum/Agile practices, and Emergent Design practices (patterns and test-driven development). The Talks that Net Objectives will be giving at Agile 2008 The Net Objectives Talks at Agile 2008 include: Introduction to Lean software Development by Alan Shalloway Distributed Teams by Ken Pugh A Half Day workshop on Value Stream Mapping by Alan Shalloway Two Open Spaces every day, facilitated by Guy Beaver, Ken Pugh, and Alan Shalloway Recommendations - Training by Net Objectives Implementing Agile Development with Microsoft Visual Studio Team System Scrum Master Certification by Net Objectives Scrum Team Member Certification, Product Owner Certification by Net Objectives Recommendations - Webinar Series by Net Objectives Three-part webinar series on Scrum# Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: 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

 Coming Up at Agile 2008 Once again, Net Objectives is a co-sponsor of the Agile 2008 conference. This is a premier gathering for people and organizations involved in Agile software development. This year, it is being held in Toronto, Canada, August 4-8. Every year, we devote a podcast to what Net Objectives is doing at Agile 2008, both to help people who are going know what we are up to and to help people who cannot go know what trends we see that are important, where we will be devoting energy. In this show, Alan Shalloway covers five primary topics: Why we are involved with the Agile conferences and why they are important for the industry The Certification by Net Objectives program, which was announced at Agile 2007, including: Scrum Master Certification, Scrum Team Member Certification, and Product Owner Certification The announcement of the Implementing Agile Development using Microsoft Visual Studio process template, which has just been completed by Net Objectives An announcement of Scrum#, which is an extension of Scrum that helps to integrate Lean thinking, Scrum/Agile practices, and Emergent Design practices (patterns and test-driven development). The Talks that Net Objectives will be giving at Agile 2008 The Net Objectives Talks at Agile 2008 include: Introduction to Lean software Development by Alan Shalloway Distributed Teams by Ken Pugh A Half Day workshop on Value Stream Mapping by Alan Shalloway Two Open Spaces every day, facilitated by Guy Beaver, Ken Pugh, and Alan Shalloway Recommendations - Training by Net Objectives Implementing Agile Development with Microsoft Visual Studio Team System Scrum Master Certification by Net Objectives Scrum Team Member Certification, Product Owner Certification by Net Objectives Recommendations - Webinar Series by Net Objectives Three-part webinar series on Scrum# Music used in this podcast “Pizzaman” and “Chocolate” ©2006 William Cushman: 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

 Test-Driven Development and Design Patterns Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation. Scott has been thinking deeply about patterns for many years and his perspective on TDD and patterns are based on the special insights he has developed - insights that are covered in the Design Patterns Explained course he teaches. What he says goes well beyond the normal way in which patterns are described. As you will hear, we came up with some delightful surprises during our talk together Embracing Change  In this conversation, we cover how TDD is like design patterns. Both deal with change, something that is always with us in product development. Our natural tendency is to want to resist change because change usually causes us pain. TDD and patterns both help remove the "sting" of change. But beyond that, it becomes something that we can even embrace as a good thing, something that can work to our advantage. Working together, TDD and patterns form a virtuous feedback loop, each reinforcing the other. This is the sweet spot for patterns and TDD. Evaluating Designs and Testing Strategies  Going deeper, Scott explores how testability becomes an essential factor in evaluating design alternatives. Like Occam's Razor, when you have competing design alternatives, choose the one that is more testable. This is especially important when you are working from a TDD perspective. Well, if you are working from a patterns perspective, you will naturally have highly testable designs: highly cohesive, minimally coupled, focused on just one thing. That is just what patterns do. Take this deeper. Each pattern is focused on resolving certain forces; it has certain structures and characteristics that are more important. By focusing on testing these characteristics, you have the head start on what would be the most effective testing strategy to use. And this is a cool insight that could be very powerful for our industry. What if testing became part of how we talk about patterns, became yet another essential characteristic of the pattern? Would that free us up from reinventing testing strategies for what are commonly occurring situations? Wouldn't this further our knowledge transfer about what is an essential need? Wouldn't it give us a good language to use? Even more, testing approaches, such as mock objects, dependency injection, shunts, can be expressed as patterns. "Testing patterns" become a whole new class of patterns that professional software developers can use, discuss, refine. To this end, Scott has entered the first testing pattern, a Mock Object Pattern, into the Pattern Repository at http://www.netobjectives.com/PatternRepository/ and invites your insights, comments, and additions. How to Learn this Way of Thinking with Patterns and Testing This is affecting the way Scott teaches Design Patterns Explained and Test-Driven Development, but not in the way I would have thought. DPE is very focused on helping people understand what patterns are. There is usually a lot of unlearning/re-learning that has to take place. This means that the course is almost entirely consumed by the pattern-specific training. The same is true for the TDD course. The Emergent Design book that is out now and the course that will be coming will serve as the bridge between them, talking about how they interact, how this allows for evolutionary design. If you want to get good at this, is it better to start with TDD or with DPE, given that you really should know both? In Scott's opinion, it is best to start with DPE because it gives you the essential thinking framework that then equips you for the practical TDD instruction. What seems to work best is to take them with just a one week gap in between. In his experience, this makes for a solid performer on the back end. Scott is an excellent speaker.

 Test-Driven Development and Design Patterns Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation. Scott has been thinking deeply about patterns for many years and his perspective on TDD and patterns are based on the special insights he has developed - insights that are covered in the Design Patterns Explained course he teaches. What he says goes well beyond the normal way in which patterns are described. As you will hear, we came up with some delightful surprises during our talk together Embracing Change  In this conversation, we cover how TDD is like design patterns. Both deal with change, something that is always with us in product development. Our natural tendency is to want to resist change because change usually causes us pain. TDD and patterns both help remove the "sting" of change. But beyond that, it becomes something that we can even embrace as a good thing, something that can work to our advantage. Working together, TDD and patterns form a virtuous feedback loop, each reinforcing the other. This is the sweet spot for patterns and TDD. Evaluating Designs and Testing Strategies  Going deeper, Scott explores how testability becomes an essential factor in evaluating design alternatives. Like Occam's Razor, when you have competing design alternatives, choose the one that is more testable. This is especially important when you are working from a TDD perspective. Well, if you are working from a patterns perspective, you will naturally have highly testable designs: highly cohesive, minimally coupled, focused on just one thing. That is just what patterns do. Take this deeper. Each pattern is focused on resolving certain forces; it has certain structures and characteristics that are more important. By focusing on testing these characteristics, you have the head start on what would be the most effective testing strategy to use. And this is a cool insight that could be very powerful for our industry. What if testing became part of how we talk about patterns, became yet another essential characteristic of the pattern? Would that free us up from reinventing testing strategies for what are commonly occurring situations? Wouldn't this further our knowledge transfer about what is an essential need? Wouldn't it give us a good language to use? Even more, testing approaches, such as mock objects, dependency injection, shunts, can be expressed as patterns. "Testing patterns" become a whole new class of patterns that professional software developers can use, discuss, refine. To this end, Scott has entered the first testing pattern, a Mock Object Pattern, into the Pattern Repository at https://www.netobjectives.com/PatternRepository/ and invites your insights, comments, and additions. How to Learn this Way of Thinking with Patterns and Testing This is affecting the way Scott teaches Design Patterns Explained and Test-Driven Development, but not in the way I would have thought. DPE is very focused on helping people understand what patterns are. There is usually a lot of unlearning/re-learning that has to take place. This means that the course is almost entirely consumed by the pattern-specific training. The same is true for the TDD course. The Emergent Design book that is out now and the course that will be coming will serve as the bridge between them, talking about how they interact, how this allows for evolutionary design. If you want to get good at this, is it better to start with TDD or with DPE, given that you really should know both? In Scott's opinion, it is best to start with DPE because it gives you the essential thinking framework that then equips you for the practical TDD instruction. What seems to work best is to take them with just a one week gap in between. In his experience, this makes for a solid performer on the back end. Scott is an excellent speaker

Emergent Design (audio of the webinar) What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development. When are you doing design? Just up front? When do you test your design? How much design is enough? How can design be done in a more natural, evolutionary way and, at the same time, more professional? These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented May 22, 2008 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Note: This webinar is 64 minutes long, so the files are large. This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008. Blog Type: PodcastLog in or register to post comments

Emergent Design (audio of the webinar) What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development. When are you doing design? Just up front? When do you test your design? How much design is enough? How can design be done in a more natural, evolutionary way and, at the same time, more professional? These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented May 22, 2008 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Note: This webinar is 64 minutes long, so the files are large. This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008. Blog Type: PodcastLog in or register to post comments

Overcoming Impediments to Test-Driven Development Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis. Impediments before adoption Before organizations decide to adopt test-driven development, they usually have to address one or more of these challenges: Developers will be doing double work and be less productive Developers know their code too well and cannot write tests well Testing before coding seems nonsensical Impediments after adoption The impediments do not stop after TDD has been adopted. What we see is that after Iteration 3, the TDD effort begins to collapse. It takes too long, the tests are difficult to change, or it is hard to keep up with multiple tests Overcoming these Impediments The answers to both of these impediments lies in gaining a new, essential insight: in TDD, the entities we write not not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs.  The process of writing the specification is an analysis task, one that leaves behind a suite of tests as a side-effect artifact; thus, it is not double work. TDD does not replace Quality Assurance. They will not be sufficient for all testing. TDD is another fundamental skill that developers, especially Agile developers,  must have. It is something that they can learn when they receive proper training. Recommendations - Training by Net Objectives Design, Testing and Programming Recommendations - Reading and Resources Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain  The Net Objectives bibliography for Technical Development The Net Objectives Resources library for TDD Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com For more information, contact info@netobjectives.com or visit us at www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Overcoming Impediments to Test-Driven Development Recently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis. Impediments before adoption Before organizations decide to adopt test-driven development, they usually have to address one or more of these challenges: Developers will be doing double work and be less productive Developers know their code too well and cannot write tests well Testing before coding seems nonsensical Impediments after adoption The impediments do not stop after TDD has been adopted. What we see is that after Iteration 3, the TDD effort begins to collapse. It takes too long, the tests are difficult to change, or it is hard to keep up with multiple tests Overcoming these Impediments The answers to both of these impediments lies in gaining a new, essential insight: in TDD, the entities we write not not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs.  The process of writing the specification is an analysis task, one that leaves behind a suite of tests as a side-effect artifact; thus, it is not double work. TDD does not replace Quality Assurance. They will not be sufficient for all testing. TDD is another fundamental skill that developers, especially Agile developers,  must have. It is something that they can learn when they receive proper training. Recommendations - Training by Net Objectives Design, Testing and Programming Recommendations - Reading and Resources Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain  The Net Objectives bibliography for Technical Development The Net Objectives Resources library for TDD Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com For more information, contact info@netobjectives.com or visit us at www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Post-Agile Scrum (audio of the webinar) The Agile Manifesto and the Agile movement have ushered in a new way of developing software. Today, many practitioners are discovering limitations to the usual approach to Agile which focuses mostly on local teams and projects. This limited focus developed as a reaction to heavy processes and teams' inability to make their own commitments. This resulted in many leading Agile practitioners to advocate an approach to "let the team figure it out," going so far as to state that the beauty of the Agile approach (such as Scrum) is that it avoids any kind of prescriptive formula. Yes, prescriptive formulas can be dangerous; however, having a set of principles to guide Agile practices can be extremely useful. Moreover, incorporating Lean management practices are critical for extending the capabilities of an organization using Agile methods. Today, what is required is helping the entire enterprise become Agile. What is an Agile enterprise? An enterprise that can respond quickly to customer, environment and internal changes to create a competitive advantage. This requires much more than merely trying to apply practices that work for local teams to the entire enterprise - that approach is too simplistic. This Agile Enterprise-perspective is one of the biggest differences between current Agile practitioners and those going beyond Scrum. These and other questions are pondered by Alan Shalloway in a webinar on Post-Agile Scrum, presented January 24, 2008. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Caution: This webinar is 61 minutes long, so the files are large Blog Type: PodcastLog in or register to post comments

Post-Agile Scrum (audio of the webinar) The Agile Manifesto and the Agile movement have ushered in a new way of developing software. Today, many practitioners are discovering limitations to the usual approach to Agile which focuses mostly on local teams and projects. This limited focus developed as a reaction to heavy processes and teams' inability to make their own commitments. This resulted in many leading Agile practitioners to advocate an approach to "let the team figure it out," going so far as to state that the beauty of the Agile approach (such as Scrum) is that it avoids any kind of prescriptive formula. Yes, prescriptive formulas can be dangerous; however, having a set of principles to guide Agile practices can be extremely useful. Moreover, incorporating Lean management practices are critical for extending the capabilities of an organization using Agile methods. Today, what is required is helping the entire enterprise become Agile. What is an Agile enterprise? An enterprise that can respond quickly to customer, environment and internal changes to create a competitive advantage. This requires much more than merely trying to apply practices that work for local teams to the entire enterprise - that approach is too simplistic. This Agile Enterprise-perspective is one of the biggest differences between current Agile practitioners and those going beyond Scrum. These and other questions are pondered by Alan Shalloway in a webinar on Post-Agile Scrum, presented January 24, 2008. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Caution: This webinar is 61 minutes long, so the files are large Blog Type: PodcastLog in or register to post comments

Emergent Design (audio of the webinar) What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development. When are you doing design? Just up front? When do you test your design? How much design is enough? How can design be done in a more natural, evolutionary way and, at the same time, more professional? These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented December 11, 2007 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Note: This webinar is 58 minutes long, so the files are large. This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008.   Blog Type: PodcastLog in or register to post comments

Emergent Design (audio of the webinar) What is design? An opportunity to mitigate risk. A way to look for eliminating waste. It is certainly not simply the "thinking" part of software development. When are you doing design? Just up front? When do you test your design? How much design is enough? How can design be done in a more natural, evolutionary way and, at the same time, more professional? These and other questions are pondered by Scott Bain in a webinar on Emergent Design, presented December 11, 2007 . The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunes Note: This webinar is 58 minutes long, so the files are large. This webinar is based on Scott's book, Emergent Design: The Evolutionary Nature of Professional Software Development, published by Addison-Wesley, 2008.   Blog Type: PodcastLog in or register to post comments

Enterprise Agility Often, organizations invite us in to help them think about how to bring Agile into their development practices. The initial focus is often at the local team level. Our experience is that this is not the best place to start. Instead, we prefer to look for pain points that the organization is feeling in their development work, and we talk with local teams to get indicators of these points. What is stopping you from delivering the value to customers that you feel you should? What opportunities do you see and what waste is there? We can predict some of the answers depending on whether it is an IT organization or a product organization. IT organizations tend to have people working on more than one project at a time whereas in product organizations, people usually focus on one project. This means that IT organizations often have less connection to the business and have more contention for resources. These are all opportunities for improvement that may or may not involve changes at the local team level. Enterprise Agility, Systems Thinking “Enterprise Agility” focuses on helping the overall development organization be more able to respond to the needs of the business. It starts by looking at what needs to be done and then on how to do it. Probably, this will involve Agile at the local team level, but that might not be the best place to start. There is a maxim that “Good people in bad systems still cannot produce.” It is always best to take a systems-view of process improvement, to focus on the systems that people work in. Otherwise, you can end up with sub-optimization – one part of the system doing well but overall, it still under-performs. Doing what is best for the enterprise involves optimizing the whole. Too often, consultants want to start at the local team level just out of habit. Then, they try to “scale up Scrum to the enterprise.” Beyond the problem with sub-optimization, there is a great danger that you may never even be given the chance to start. Why? If upper management has not already bought into the idea of Agile, then one failed experiment in Scrum can leave a permanent bad impression. Starting with a focus on the challenges of the enterprise – reducing waste and delay, improvements in the value stream – helps them see what they will be getting out of it. An experiment with a local team, then, becomes one of several things you could be trying as a start. Look for the Pain Points Chances are that the size of the organization will impact the issues we address, but that is not certain. Rather, it is complexity of process and connections between teams and organizational culture that leads to waste and inability to work with the business. For example, stove-piping, over-burdening processes, a disconnect between business and IT. What are the underlying lean principles that are being followed and what are being violated. The biggest challenge is that pain-points are not always recognized and we tend to think that it is just the way things have to be… that things cannot be improved. Do the SIPOC When it comes to analyzing where to start in helping a development organization, it often makes sense to talk to the Business, which is the customer of the dev group, as well as upstream to the Operations, which supplies the dev group. A standard lean technique is to do a simple SIPOC (Supplier-Input-Process-Output-Customer) to be explicit about who and how the organization interacts with the system. All too often, this simple step is forgotten as we are focused on building product. For example, a local team might already be reasonably productive, even without Scrum. But they are thrashing because their Business customer is not ready to work with them when they need answers. Or the change management system takes weeks to schedule a user acceptance test. These are structural issues dealing with upstream inputs and downstream outputs over which the local team has no control. Attack these root causes of thrashing and

Enterprise Agility Often, organizations invite us in to help them think about how to bring Agile into their development practices. The initial focus is often at the local team level. Our experience is that this is not the best place to start. Instead, we prefer to look for pain points that the organization is feeling in their development work, and we talk with local teams to get indicators of these points. What is stopping you from delivering the value to customers that you feel you should? What opportunities do you see and what waste is there? We can predict some of the answers depending on whether it is an IT organization or a product organization. IT organizations tend to have people working on more than one project at a time whereas in product organizations, people usually focus on one project. This means that IT organizations often have less connection to the business and have more contention for resources. These are all opportunities for improvement that may or may not involve changes at the local team level. Enterprise Agility, Systems Thinking “Enterprise Agility” focuses on helping the overall development organization be more able to respond to the needs of the business. It starts by looking at what needs to be done and then on how to do it. Probably, this will involve Agile at the local team level, but that might not be the best place to start. There is a maxim that “Good people in bad systems still cannot produce.” It is always best to take a systems-view of process improvement, to focus on the systems that people work in. Otherwise, you can end up with sub-optimization – one part of the system doing well but overall, it still under-performs. Doing what is best for the enterprise involves optimizing the whole. Too often, consultants want to start at the local team level just out of habit. Then, they try to “scale up Scrum to the enterprise.” Beyond the problem with sub-optimization, there is a great danger that you may never even be given the chance to start. Why? If upper management has not already bought into the idea of Agile, then one failed experiment in Scrum can leave a permanent bad impression. Starting with a focus on the challenges of the enterprise – reducing waste and delay, improvements in the value stream – helps them see what they will be getting out of it. An experiment with a local team, then, becomes one of several things you could be trying as a start. Look for the Pain Points Chances are that the size of the organization will impact the issues we address, but that is not certain. Rather, it is complexity of process and connections between teams and organizational culture that leads to waste and inability to work with the business. For example, stove-piping, over-burdening processes, a disconnect between business and IT. What are the underlying lean principles that are being followed and what are being violated. The biggest challenge is that pain-points are not always recognized and we tend to think that it is just the way things have to be… that things cannot be improved. Do the SIPOC When it comes to analyzing where to start in helping a development organization, it often makes sense to talk to the Business, which is the customer of the dev group, as well as upstream to the Operations, which supplies the dev group. A standard lean technique is to do a simple SIPOC (Supplier-Input-Process-Output-Customer) to be explicit about who and how the organization interacts with the system. All too often, this simple step is forgotten as we are focused on building product. For example, a local team might already be reasonably productive, even without Scrum. But they are thrashing because their Business customer is not ready to work with them when they need answers. Or the change management system takes weeks to schedule a user acceptance test. These are structural issues dealing with upstream inputs and downstream outputs over which the local team has no control. Attack these root causes of thrashing and