Lean-Agile Straight Talk

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

Lean and the Reasons for Going Agile - Part 2 Agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future. This is the bottom-line message of two podcasts that talk about how Lean thinking offers compelling reasons for organizations to think about going Agile. This is based on conversations that Alan Shalloway has been having with customers across the country about this. The five most important reasons are: Add value to the business quickly Gaining clarity on customers’ needs Projects can be managed better Early feedback makes for motivated teams Engineer practices favor Agile In the last podcast, we talked about the first point: adding value to the business quickly. In this show, we cover the other four points. Really, I should have done these four together, but it would have made a show that was just too long. So, be sure to listen to both of them to get the full story. As you will hear, we are just jumping right into the conversation, so it may feel a little bumpy starting out. I think you will catch on. Make this series useful for you As we are dive into the issues of Lean-Agile, we want this series to be really useful to you. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com and let me know the topics you want us to cover. And keep checking our blog site at blogs.netobjectives.com for related information and to subscribe to be kept up to date on the shows. I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Release It! Design and Deploy Production-Ready Software by Michael Nygard Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

Lean and the Reasons for Going Agile - Part 2 Agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future. This is the bottom-line message of two podcasts that talk about how Lean thinking offers compelling reasons for organizations to think about going Agile. This is based on conversations that Alan Shalloway has been having with customers across the country about this. The five most important reasons are: Add value to the business quickly Gaining clarity on customers’ needs Projects can be managed better Early feedback makes for motivated teams Engineer practices favor Agile In the last podcast, we talked about the first point: adding value to the business quickly. In this show, we cover the other four points. Really, I should have done these four together, but it would have made a show that was just too long. So, be sure to listen to both of them to get the full story. As you will hear, we are just jumping right into the conversation, so it may feel a little bumpy starting out. I think you will catch on. Make this series useful for you As we are dive into the issues of Lean-Agile, we want this series to be really useful to you. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com and let me know the topics you want us to cover. And keep checking our blog site at blogs.netobjectives.com for related information and to subscribe to be kept up to date on the shows. I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Release It! Design and Deploy Production-Ready Software by Michael Nygard Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/ Blog Type: PodcastLog in or register to post comments

Lean and the Reasons for Going Agile - Part 1 We have been snowed in here in Seattle for the last week. It wasn’t that much snow, relative to Milwaukee, where I spent some of my childhood, but it was enough to disrupt most of our infrastructure. We just are not used to thinking about snow here. How to drive in it, what to do if we get stuck, how to adjust. It took my neighbor almost 8 hours to get from his Microsoft office to home the other night. Just a nightmare. I took my 16 year old daughter out on the ice to teach her how to drive. She needed to learn a new way of thinking so that she could adapt to the new realities she faced. Her normal thought processes would just land her in a ditch. She needed a coach to help adjust her thinking and time to practice. My hair isn’t too much whiter today, I’m pleased to say. In the same way, it is increasingly apparent that the older ways we did product development are inadequate. The world feels like it is changing and we need the skills to be flexible and adapt to these new situations. Perhaps it was always thus, but it is even more so now. We have to learn new ways of thinking, not just a new set of tools. Principles inform process and technique. Lean and Agile are these new ways to think about software product development. Lean provides the compelling reasons for going Agile. These are not often talked about in the Agile community, but are well worth considering to motivate the adoption of Agile. The more you understand the principles of Lean thinking, the more powerfully you can implement the processes of Agile and the tools of Lean. The bottom-line is that agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future. Alan Shalloway has been talking to customers across the country about this. In this show and the next, Alan and I will consider what he feels are the five most compelling reasons for going Lean-Agile: • Add value to the business quickly • Gaining clarity on customers’ needs • Projects can be managed better • Early feedback makes for motivated teams • Engineer practices favor Agile In this podcast, we talk about the first point, adding value to the business quickly. I confess that I am torn about stopping here because the next points flow rather nicely from this. But, if I didn’t stop, it would be an hour long and that is just too long for this format, I think. So, be sure to listen to this and the next podcast together! In this podcast, Alan refers to two diagrams in his podcast: The case for iterative development: Develop the product mix to maximize what the customer is clear about and do not work on what they must speculate about Scheduling Note Over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. He has been teaching the Lean-Agile Overview with major companies across the US and overseas and is bursting with important insights. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Enterprise Engineering for Developers: D

Lean and the Reasons for Going Agile - Part 1 We have been snowed in here in Seattle for the last week. It wasn’t that much snow, relative to Milwaukee, where I spent some of my childhood, but it was enough to disrupt most of our infrastructure. We just are not used to thinking about snow here. How to drive in it, what to do if we get stuck, how to adjust. It took my neighbor almost 8 hours to get from his Microsoft office to home the other night. Just a nightmare. I took my 16 year old daughter out on the ice to teach her how to drive. She needed to learn a new way of thinking so that she could adapt to the new realities she faced. Her normal thought processes would just land her in a ditch. She needed a coach to help adjust her thinking and time to practice. My hair isn’t too much whiter today, I’m pleased to say. In the same way, it is increasingly apparent that the older ways we did product development are inadequate. The world feels like it is changing and we need the skills to be flexible and adapt to these new situations. Perhaps it was always thus, but it is even more so now. We have to learn new ways of thinking, not just a new set of tools. Principles inform process and technique. Lean and Agile are these new ways to think about software product development. Lean provides the compelling reasons for going Agile. These are not often talked about in the Agile community, but are well worth considering to motivate the adoption of Agile. The more you understand the principles of Lean thinking, the more powerfully you can implement the processes of Agile and the tools of Lean. The bottom-line is that agile helps development teams get their projects done quickly. It helps to make development teams very much more effective. Lean helps the organization to deliver value to customers quickly while retaining the ability to add value quickly in the future. Alan Shalloway has been talking to customers across the country about this. In this show and the next, Alan and I will consider what he feels are the five most compelling reasons for going Lean-Agile: • Add value to the business quickly • Gaining clarity on customers’ needs • Projects can be managed better • Early feedback makes for motivated teams • Engineer practices favor Agile In this podcast, we talk about the first point, adding value to the business quickly. I confess that I am torn about stopping here because the next points flow rather nicely from this. But, if I didn’t stop, it would be an hour long and that is just too long for this format, I think. So, be sure to listen to this and the next podcast together! In this podcast, Alan refers to two diagrams in his podcast: The case for iterative development: Develop the product mix to maximize what the customer is clear about and do not work on what they must speculate about Scheduling Note Over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. He has been teaching the Lean-Agile Overview with major companies across the US and overseas and is bursting with important insights. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Enterprise Engineering for Developers: D

Lean-Agile and Project Management - Part 2 This show involves two conversations. First, a short discussion about how the need for speed-to-market to stay ahead of younger competition is a fundamental driver for Lean-Agile. Then, we continue the conversation we started last week about Lean-Agile and Project Managers. In particular, we focus on: The Project Manager as fundamental partner in optimizing processes (internal and external) The true responsibilities of the PM (improving what you can influence, not just what you can control) How PMs reduce waste (How project managers can help to reduce waste: multitasking; getting testing and development to be working more closely; equipping the team with knowledge and skills; improving the processes that support the team) Getting the team to follow Principle Zero (Principle Zero: There is always a cost to violating a principle, regardless whether it is the right decision to violate the principle; so always stop and count the cost to see if the decision is worth the cost. Facilitating frequent retrospections The PM and Metrics This show introduces Jean McAuliffe, a new senior consultant from Boulder, Colorado who has just joined Net Objectives. She comes with a lot of great experience in Agile processes and tools and is a great addition to the team. Scheduling Note Over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. He has been teaching the Lean-Agile Overview with major companies across the US and overseas and is bursting with important insights. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean-Agile and Project Management - Part 2 This show involves two conversations. First, a short discussion about how the need for speed-to-market to stay ahead of younger competition is a fundamental driver for Lean-Agile. Then, we continue the conversation we started last week about Lean-Agile and Project Managers. In particular, we focus on: The Project Manager as fundamental partner in optimizing processes (internal and external) The true responsibilities of the PM (improving what you can influence, not just what you can control) How PMs reduce waste (How project managers can help to reduce waste: multitasking; getting testing and development to be working more closely; equipping the team with knowledge and skills; improving the processes that support the team) Getting the team to follow Principle Zero (Principle Zero: There is always a cost to violating a principle, regardless whether it is the right decision to violate the principle; so always stop and count the cost to see if the decision is worth the cost. Facilitating frequent retrospections The PM and Metrics This show introduces Jean McAuliffe, a new senior consultant from Boulder, Colorado who has just joined Net Objectives. She comes with a lot of great experience in Agile processes and tools and is a great addition to the team. Scheduling Note Over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. He has been teaching the Lean-Agile Overview with major companies across the US and overseas and is bursting with important insights. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean-Agile and Project Management - Part 1 On Lean-Agile Straight Talk, we have taken a fair amount of time working through the basic dimensions of Lean-Agile product development: Lean Principles, Agile Processes, and Technical Practices. We have talked in general about how we got here and why it is important. We have laid enough foundation and can dive down a bit. Alan Shalloway has been teaching our Lean-Agile Software Overview course several times a month to companies and public gatherings across the United States and overseas. If you know Alan, you know that every time he does one of these, he gains some new insight, discovers a new implication. He is literally bursting at the seams with lessons and he wants to share them. So, over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. This podcast is the first of two parts covering Lean-Agile and the project manager. Most companies have project managers to help them bring projects in on schedule and on budget. I have had to deal with a number PMs who tried to win through strong arm tactics and sweet talking and it usually backfires over the long haul.The good PMs seem to be able to be a servant for the team, while asking the hard questions, while making management look good, while helping the team think better. Lean-Agile affirms all of this and adds more. These good PMs will take to Lean-Agile and feel stretched at the same time. Scheduling Note These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean-Agile and Project Management - Part 1 On Lean-Agile Straight Talk, we have taken a fair amount of time working through the basic dimensions of Lean-Agile product development: Lean Principles, Agile Processes, and Technical Practices. We have talked in general about how we got here and why it is important. We have laid enough foundation and can dive down a bit. Alan Shalloway has been teaching our Lean-Agile Software Overview course several times a month to companies and public gatherings across the United States and overseas. If you know Alan, you know that every time he does one of these, he gains some new insight, discovers a new implication. He is literally bursting at the seams with lessons and he wants to share them. So, over the next several months, Alan and I plan to have a series of discussions to delve into what he is learning and deepen our understanding about why this is so important to people doing product development. This podcast is the first of two parts covering Lean-Agile and the project manager. Most companies have project managers to help them bring projects in on schedule and on budget. I have had to deal with a number PMs who tried to win through strong arm tactics and sweet talking and it usually backfires over the long haul.The good PMs seem to be able to be a servant for the team, while asking the hard questions, while making management look good, while helping the team think better. Lean-Agile affirms all of this and adds more. These good PMs will take to Lean-Agile and feel stretched at the same time. Scheduling Note These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them. These are going to be longer podcasts, so I may only get 2 or 3 a month, so keep a watch for them. They will always be posted on this blog site, so keep looking for them.Make this series useful for you I want this to be very useful to you and want to dive into the issues you care most about. So, I would appreciate it if you would drop me a note to jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you. Recommendations - Training by Net Objectives Lean-Agile Software Development Recommendations - Reading Implementing Lean Software Development: From Concept to Cash (The Addison-Wesley Signature Series), by Mary and Tom Poppendieck Lean Software Development by Mary and Tom Poppendieck Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at https://www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Patterns give devs a language for collaboration Lean-Agile puts a premium on collaboration. We always talk about increasing the bandwidth of communication: between customer and developer, between members of a development team, between your team and other teams, and, indeed, between various generations of a team (why did they do it that way?) Gone are the day of a programmer sitting alone in cubicle; most developers find themselves as part of a team. Now, it has always been easy for developers to talk about implementation. We have coding structures and algorithms. All very precise and widely understood. But it has been very difficult to talk about design. Sure, we have UML diagrams and specifications and requirements documents. But, they don't really get to the essence of the thought behind a particular design. That is where patterns come in. Patterns give us a language to talk about design ideas. Each pattern is a shorthand for a bucket of forces and principles and constraints and the costs involved in the pattern. When I say I used a Decorator here, you can know what is expected and we can talk about why it was chosen and the rationale for what went into its particular implementation. We can discuss the tradeoff of this approach vs. that approach based on the pattern's cost. This is how professionals talk to each other. But not only within a team, patterns allow you to access the knowledge of a larger community of professional developers. If you are working on a particular design and discover part way through, "this looks like a Bridge", then you can turn to the Bridge pattern and see what else it is telling you should be there. It can accelerate your rate of development by predicting the elements that must be in your design. Now this works as long as you can see a pattern as the shorthand and remove yourself from a particular coding implementation. Too many patterns courses and books dwell too much on the implementation, and you lose the essence of - and thus the real power behind - the pattern. A central repository of patterns Now, for patterns to become a useful language, everyone has to have a common understanding of what they are about, what they mean. There is a large number of patterns and they grow as we learn more about them. What is needed is a central repository where we can talk together about the patterns. There are other pattern repositories, but none of them talk about patterns in the way Scott is talking about them: as a language, as a collection of forces and language elements. All of this has led Scott to create an open repository with this in mind: http://www.netobjectives.com/PatternRepository/. This is a community-based repository, sponsored by Net Objectives. You can read for free. Or if you want to contribute, you can register and become an editor, much like the wikipedia does. Net Objectives is sponsoring this because it brings value to the community. And that is one of the central tenets of Net Objectives. Emergent Design To complement this work, Scott is working on a book about Emergent Design, which covers two points Designs emerge The need for developing a professional language This book is out for review, to good response right now. The book helps get people ready. The repository then grows the community. He is also working on a course on these ideas. A Podcast Series with Scott Bain This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design PatternsThinking, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile. In this introduction, we cover: What are design patterns (and what are they not) Are design patterns still relevant? Patterns, TDD, and change Patterns as part of the language of professional developers Getting an Agile team started in patterns In the future, I will try to get Sco

Patterns give devs a language for collaboration Lean-Agile puts a premium on collaboration. We always talk about increasing the bandwidth of communication: between customer and developer, between members of a development team, between your team and other teams, and, indeed, between various generations of a team (why did they do it that way?) Gone are the day of a programmer sitting alone in cubicle; most developers find themselves as part of a team. Now, it has always been easy for developers to talk about implementation. We have coding structures and algorithms. All very precise and widely understood. But it has been very difficult to talk about design. Sure, we have UML diagrams and specifications and requirements documents. But, they don't really get to the essence of the thought behind a particular design. That is where patterns come in. Patterns give us a language to talk about design ideas. Each pattern is a shorthand for a bucket of forces and principles and constraints and the costs involved in the pattern. When I say I used a Decorator here, you can know what is expected and we can talk about why it was chosen and the rationale for what went into its particular implementation. We can discuss the tradeoff of this approach vs. that approach based on the pattern's cost. This is how professionals talk to each other. But not only within a team, patterns allow you to access the knowledge of a larger community of professional developers. If you are working on a particular design and discover part way through, "this looks like a Bridge", then you can turn to the Bridge pattern and see what else it is telling you should be there. It can accelerate your rate of development by predicting the elements that must be in your design. Now this works as long as you can see a pattern as the shorthand and remove yourself from a particular coding implementation. Too many patterns courses and books dwell too much on the implementation, and you lose the essence of - and thus the real power behind - the pattern. A central repository of patterns Now, for patterns to become a useful language, everyone has to have a common understanding of what they are about, what they mean. There is a large number of patterns and they grow as we learn more about them. What is needed is a central repository where we can talk together about the patterns. There are other pattern repositories, but none of them talk about patterns in the way Scott is talking about them: as a language, as a collection of forces and language elements. All of this has led Scott to create an open repository with this in mind: https://www.netobjectives.com/PatternRepository/. This is a community-based repository, sponsored by Net Objectives. You can read for free. Or if you want to contribute, you can register and become an editor, much like the wikipedia does. Net Objectives is sponsoring this because it brings value to the community. And that is one of the central tenets of Net Objectives. Emergent Design To complement this work, Scott is working on a book about Emergent Design, which covers two points Designs emerge The need for developing a professional language This book is out for review, to good response right now. The book helps get people ready. The repository then grows the community. He is also working on a course on these ideas. A Podcast Series with Scott Bain This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design PatternsThinking, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile. In this introduction, we cover: What are design patterns (and what are they not) Are design patterns still relevant? Patterns, TDD, and change Patterns as part of the language of professional developers Getting an Agile team started in patterns In the future, I will try to get Sc

Embrace Change through Patterns Perhaps one of the benefits of Agile is that you can get frequent, almost constant validation of what we are doing. In waterfall approaches, it too often happens that after a Plan-Do-Review cycle, the review results in bad news: something is wrong. Now, we have to go back and re-work a bunch of stuff. That is wasted effort. In Lean-Agile, we try for more frequent and early approvals. We recognize that developers almost never get it perfect the first or second (or third) time through. We recognize that the Business needs to change the system to respond to current conditions or as they learn more about what they need. We want to embrace change, but it comes with a cost. Lots and lots of change can be demoralizing if it causes a lot of re-work all the time. How can you embrace change without overwhelming the team? Patterns and Test-Driven Development address this issue. They are based on the premise of the Open-Closed Principle, which implies that if change is a problem for you, then change the rules. Patterns guide you to set up your environment so that, when change comes, you can accommodate it by adding something new rather than having to re-work something old. The impact on the overall system is much less. TDD helps you work in very small increments, allowing you to defer commitments to one design choice or another while you are still learning about your system. Make your commitments when you are smart, not when you are still ignorant. Together, they make change much less expensive and much easier to accommodate change. This is critical to Lean-Agile where we are trying to embrace, rather than prevent, change, as we try to create products that track with what customers truly want, and as we learn together what we want to do. How do patterns do this? Due to Open-Closed, they encapsulate variation, which means that you can contain the variation happening to your system. Containment reduces the overall impact. Each pattern addresses a different type of variation, each pattern allows me to be open-closed about some type of variation. For example, The Strategy Pattern encapsulates the variation of a single algorithm. If I get a new version of that algorithm, then I can introduce that variation without having to change the system. The Strategy Pattern hid the algorithm in an abstraction. The Decorator Pattern allows you add many behaviors on top of a base behavior (for example, think about filters on a camera). Decorator allows you to hide, or encapsulate, or be Open-Closed to the types and number and order of these behavior. Creational patterns allow you to encapsulate the ways in which objects are instantiated, allowing for changes in the future to the way you create objects. What is interesting is that this way of thinking about Patterns is not really in the Gang of Four book. But it is crucial to understand if you want to do Lean-Agile in a sustainable way, so that you can plan for change. You want to be able to think about which patterns you should use (and which to ignore for now) to allow for change. Learning While Doing Both Lean-Agile and waterfall have a Plan-Do-Review-type cycle. There are two primary differences between them. A matter of scale. Waterfall iterations are so big that the changes tend to be quite large. A problem of mapping. Waterfall was created for an engineering project where compliance is very important and where change is quite hard and expensive. Software is a creative process. You discover much by coding things, doing things. An unnecessary constraint. Software is easy to change. We want to allow change to happen. It is why we call it software. A podcast series with Scott Bain This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Thinking, Advanced Software Design and Test-Driven Development. He ha

Embrace Change through Patterns Perhaps one of the benefits of Agile is that you can get frequent, almost constant validation of what we are doing. In waterfall approaches, it too often happens that after a Plan-Do-Review cycle, the review results in bad news: something is wrong. Now, we have to go back and re-work a bunch of stuff. That is wasted effort. In Lean-Agile, we try for more frequent and early approvals. We recognize that developers almost never get it perfect the first or second (or third) time through. We recognize that the Business needs to change the system to respond to current conditions or as they learn more about what they need. We want to embrace change, but it comes with a cost. Lots and lots of change can be demoralizing if it causes a lot of re-work all the time. How can you embrace change without overwhelming the team? Patterns and Test-Driven Development address this issue. They are based on the premise of the Open-Closed Principle, which implies that if change is a problem for you, then change the rules. Patterns guide you to set up your environment so that, when change comes, you can accommodate it by adding something new rather than having to re-work something old. The impact on the overall system is much less. TDD helps you work in very small increments, allowing you to defer commitments to one design choice or another while you are still learning about your system. Make your commitments when you are smart, not when you are still ignorant. Together, they make change much less expensive and much easier to accommodate change. This is critical to Lean-Agile where we are trying to embrace, rather than prevent, change, as we try to create products that track with what customers truly want, and as we learn together what we want to do. How do patterns do this? Due to Open-Closed, they encapsulate variation, which means that you can contain the variation happening to your system. Containment reduces the overall impact. Each pattern addresses a different type of variation, each pattern allows me to be open-closed about some type of variation. For example, The Strategy Pattern encapsulates the variation of a single algorithm. If I get a new version of that algorithm, then I can introduce that variation without having to change the system. The Strategy Pattern hid the algorithm in an abstraction. The Decorator Pattern allows you add many behaviors on top of a base behavior (for example, think about filters on a camera). Decorator allows you to hide, or encapsulate, or be Open-Closed to the types and number and order of these behavior. Creational patterns allow you to encapsulate the ways in which objects are instantiated, allowing for changes in the future to the way you create objects. What is interesting is that this way of thinking about Patterns is not really in the Gang of Four book. But it is crucial to understand if you want to do Lean-Agile in a sustainable way, so that you can plan for change. You want to be able to think about which patterns you should use (and which to ignore for now) to allow for change. Learning While Doing Both Lean-Agile and waterfall have a Plan-Do-Review-type cycle. There are two primary differences between them. A matter of scale. Waterfall iterations are so big that the changes tend to be quite large. A problem of mapping. Waterfall was created for an engineering project where compliance is very important and where change is quite hard and expensive. Software is a creative process. You discover much by coding things, doing things. An unnecessary constraint. Software is easy to change. We want to allow change to happen. It is why we call it software. A podcast series with Scott Bain This podcast continues a series of conversations with Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Thinking, Advanced Software Design and Test-Driven Development. He ha

Note: I am re-publishing this entry because a few weeks ago, I messed up and had the wrong link to the podcast. It directed you to a conversation about domain analysis rather than estimating. Several alert listeners have pointed this out, and I appreciate it. My apologies! And don't hesitate to keep me honest: jim.trott@netobjectives.com The correct link is below: Estimating in Lean-Agile Stories should be between a half day and 2 days. If we cannot get it down to a couple of days, then we don’t really understand the problem yet. This is especially true for new code and new features. Of course, there are code bases that require more than a couple of days, but these tend to be code bases that already have code quality issues. The big benefits of having stories that about 2 days in length are: Developers understand what to do before they start working on the code Management can understand the progress that is being made, by tracking the velocity of story burndown. You avoid thrashing and being overwhelmed by having too many small tasks, having to go back to the well to try to figure out what is next. Sometimes, teams are reluctant to give estimates, especially when they have been motivated by fear and they have been whacked when they give bad estimates. Metrics can be used as a weapon. And that is too bad, because in new environments and with waterfall methods, it can be really hard to make good estimates. That’s when we resort to rules like “double it and add 10%”. This can arise when management requires a certain fixed number of features be released according to a fixed release schedule, without knowing if that is reasonable. In such situations, the only variable is code quality: you get features that are released, but with bugs that then have to be fixed in future cycles (but that is in the maintenance budget, so doesn’t count against you.) Helping teams build better estimates Very frequently, the people who are tasked with estimating projects ask the Lean-Agile coach for help in developing better approaches for estimating. They know that this is a big problem. They want to do better, both to build their own credibility and to give management the ability to prioritize better. To help them, Rod Claar does what most Lean-Agile coaches usually do: ask questions that help them think (rather than simply giving answers). What have you done and how has that worked for you? Did you work hard? Could you have worked harder? How do you know it has not worked? Did you learn a lot? In what specific ways did you refine your process based on what you learned? If it is possible to jettison the heavy up-front analysis in favor of Agile analysis, that is best. If the business requires that up-front analysis, then perhaps the coach can help management take a middle path: do everything that they would normally do in an upfront analysis effort, but time box it and put iterations around it. Thus, do a Planning Game for a week, then do development for a month, and then look at what was learned and plan again. This gives the benefit of the iterative approach while not really costing the business any more – they still get a good reasoned set of requirements at the end of a month. And you can still give them a 6-9 month plan, but it is updated after every (30-day) iteration. To effect this sort of change in estimation, the coach has to have the conversation both upstream, with management, and downstream, with developers and available customers. And the conversation must take place fairly early, say in the Define stage – especially if the decision to go Agile is coming from the top. And, increasingly, we are seeing the need to go Agile coming from the top of the IT organization. Recommendations - Training by Net Objectives Agile Analysis Lean Software Development Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnote

Patterns and Lean-Agile In other podcasts, we have talked about the “Three Legs of Software Development”: management processes, developer processes, and technical skills. “Technical skills” involves both Design Patterns and Test-Driven Development. But are design patterns still relevant? Or is that so 1990’s? The answer is “Patterns are more relevant now than they ever have been… and especially for Lean-Agile software development." Why? To answer this question, I am turning to Scott Bain, a senior consultant and one of the premier experts in patterns and test-driven development. He teaches and coaches three Net Objectives courses: Design Patterns Thinking, Advanced Software Design and Test-Driven Development. He has thought deeply about patterns and Lean-Agile. A Podcast Series with Scott Bain This begins a series of podcasts with Scott, where you will start to get a sense for what he is thinking . You will also get a great idea of who Scott is – and if you ever get the chance to take a course from him, it is worthwhile! In this series, we will cover: What are design patterns (and what are they not) Are design patterns still relevant? Patterns and change Patterns as part of the language of professional developers Obviously, we can’t go too deeply into patterns in 15 these introductory podcasts. But I want you to have some ideas for what patterns are and why they are important to the Lean-Agile software developer. Below are some of what Scott covers. What are design patterns? Scott prefers to think of “patterns”, not “design patterns”. In the pre-Agile, waterfall-methodology days, we thought of design as a discrete step you did before creating code. That approach never worked very well – change always overwhelmed the system. Thinking about patterns – rather than “design” patterns – allows you to think about your work and the things you do again and again that create value. A pattern is like a “bag” of compiled, collected wisdom that discusses things we do repeatedly to solve a particular kind of problem. We give them labels so that we can remember them and access them more readily. So, there are patterns in analysis, in design, in re-factoring, in testing, in deployment, in implementation. Are patterns still relevant in the Lean-Agile world? Yes! They are even MORE relevant The reason is that in the old days, our biggest expense, our biggest constraint, was the machines and the software. Programmer time was cheap in comparison, so we didn’t mind making people do more if it resulted in more machine efficiency. Today – and the Lean-Agile world recognizes this – it is the reverse. Computers are relatively inexpensive. Software is ubiquitous. And programmers are relatively expensive. Doing what we can to make people more efficient is crucial. And that includes increasing the communication of wisdom from person to person. (You could think of this as part of what I call Knowledge Management) One way to think about this is that, in the 90’s, we did what we could to make things easier for the computer, and if that caused programmers problems, well, that’s OK. Today, that is not OK. That is “waste”. Patterns help us create software that is more maintainable and more robust, at the expense of making the computer do a bit more… and that is great! And this is very consistent with Lean-Agile: eliminating waste, favoring process improvement, valuing local knowledge, and creating robust systems. If at all possible, I’d recommend taking our TDD and our Design Patterns courses, which has helped hundreds of developers gain the understanding they need to work with patterns and how to access the language of professional developers worldwide. The book, Design Patterns Explained, is also a great place to start. Recommendations - Training by Net Objectives Design Patterns Thinking Advanced Software Design Test-Driven Development Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Music used in this podca