Lean-Agile Straight Talk

Interview with Ken Pugh Ken Pugh is an expert consultant with a ready smile, great instincts, and, like so many of the experts and trainers I have had the pleasure to work with, he takes particular joy in watching the light bulbs turn on as he works with students. At Agile 2006, Ken talked with me about one of his key observations: most agile teams have challenges with people, yet most of the training developers receive still focuses on technical skills. In some sense, that can set them up for failure. People issues show up in several forms: A person who does not want to collaborate or cannot collaborate Time problems (too many meetings, etc) A developer who simply plows ahead for rear of asking questions and looking incompetent Conflict resolution Difficulties in communication This is perhaps especially a challenge in individualistic, highly competitive, or isolated environments. So, what do you do? Do you exclude people who cannot fit in? Or do you work with them to help them transition or to find alternatives? The key is not to force the solution on the individual, not to impose a fix. Instead, you have to work with the individual to help them discover the solution. This is sensitive and tough work. In Scrum, this would be a primary responsibility for the ScrumMaster (who is responsible for focusing on the health of the team). In Scrum, it means that ScrumMasters must learn "soft skills", how to work with people discover their own solutions. There is no way around this. To help with this, Ken recommends books by Jerry Weinberg. This relates quite well to last week’s podcast on interviewing techniques for staffing agile teams, above. Ken has been in business since 1982, offering OO, Java, C++, C, customer programming, design, process issues, and expert testimony, with its headquarters in Durham NC. If you get a chance to hear Ken speak, I highly recommend it. His speaking schedule is on the Pugh-Killeen Associates website. Recommendations - Reading By Jerry Weinberg The Secrets of Consulting: A Guide to Getting and Giving Advice Successfully More Secrets of Consulting: The Consultant's Toolkit Recommendations - Online Weinberg's Blog, Secrets of Consulting: http://www.geraldmweinberg.com/ Ken Pugh's website: http://www.pughkilleen.com/ Music used in this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com “On the Cool Side” ©2006 Kevin McLeod: http://www.incompetech.com/ For more information, contact info@netobjectives.com or visit us at www.netobjectives.com Blog Type: PodcastLog in or register to post comments

An Overview of ScrumMaster - Part 2 The Agile method called Scrum empowers the “Team” (the group of developers and the business working together to produce product) to decide together how to do their work without lots of external influence. People who are used to working in a hierarchical, specification and deliverable-oriented environment may have a lot of trouble at first with this combination of freedom and responsibility. It can feel very disorienting. So, within Scrum, there is a role called the “ScrumMaster” whose job it is to help the team with this transition, to stay healthy, and to stay focused on producing product (that's the "hand" in the diagram on the right). It is a hard job! I am running a little Scrum project for a relief and development organization I support. The team is composed of college interns editing and producing video training. They are quite uncomfortable with the freedom I am giving them, and appreciate why I am doing it. It has made for some involved conversations to help them see what they are supposed to do, how I am there to help but not to do and not to dictate. So, I really appreciate the difficulty that ScrumMasters face. This podcast is Part 2 of a "ScrumMaster Overview" conversation I had with Doug Shimp, a Certified ScrumMaster Trainer and former senior consultant with Net Objectives. so if you haven’t listened to Part 1 yet, I’d encourage you to take a listen. In Part 1, Doug covered these issues around being a ScrumMaster: Where did the term “ScrumMaster” com from? The qualifications and personality types and organizational origins of good ScrumMasters How many teams one ScrumMaster can serve Impediment removal In Part 2, I continue my conversation with Doug, covering these issues: Examples Doug has seen of both good ScrumMasters and those that have challenges The partnership between the ScrumMaster and the Product Owner. How to become a ScrumMaster. (which is quite similar to the process for becoming a Lean-Six Sigma Greenbelt) Why every team member needs to take the CSM training. Why is it so hard to find good ScrumMasters? Consider these characteristics that a ScrumMaster must have: Humble enough to serve the team Strong character and confident enough to stay in the background, promoting the team. High integrity and high trust relationship with all the team. Politically savvy with a strong relationship with product owner Able to understand both business and technical people Note: This podcast jumps right in to the phone conversation I was having with Doug, so it might seem to start a little abruptly. Recommendations - Training by Net Objectives Scrum Recommendations - Reading Reading recommendations for Agile Practices Agile Software Development with Scrum by Schwaber and Beedle Recommendations - Tools AgileCraft LeanKit Wikis and Spreadsheets (no particular recommendation here) Recommendations - Online Concango's Scrum FAQ Podcast Transcripts 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 www.netobjectives.com Blog Type: PodcastLog in or register to post comments

An Overview of ScrumMaster - Part 2 The Agile method called Scrum empowers the “Team” (the group of developers and the business working together to produce product) to decide together how to do their work without lots of external influence. People who are used to working in a hierarchical, specification and deliverable-oriented environment may have a lot of trouble at first with this combination of freedom and responsibility. It can feel very disorienting. So, within Scrum, there is a role called the “ScrumMaster” whose job it is to help the team with this transition, to stay healthy, and to stay focused on producing product (that's the "hand" in the diagram on the right). It is a hard job! I am running a little Scrum project for a relief and development organization I support. The team is composed of college interns editing and producing video training. They are quite uncomfortable with the freedom I am giving them, and appreciate why I am doing it. It has made for some involved conversations to help them see what they are supposed to do, how I am there to help but not to do and not to dictate. So, I really appreciate the difficulty that ScrumMasters face. This podcast is Part 2 of a "ScrumMaster Overview" conversation I had with Doug Shimp, a Certified ScrumMaster Trainer and former senior consultant with Net Objectives. so if you haven’t listened to Part 1 yet, I’d encourage you to take a listen. In Part 1, Doug covered these issues around being a ScrumMaster: Where did the term “ScrumMaster” com from? The qualifications and personality types and organizational origins of good ScrumMasters How many teams one ScrumMaster can serve Impediment removal In Part 2, I continue my conversation with Doug, covering these issues: Examples Doug has seen of both good ScrumMasters and those that have challenges The partnership between the ScrumMaster and the Product Owner. How to become a ScrumMaster. (which is quite similar to the process for becoming a Lean-Six Sigma Greenbelt) Why every team member needs to take the CSM training. Why is it so hard to find good ScrumMasters? Consider these characteristics that a ScrumMaster must have: Humble enough to serve the team Strong character and confident enough to stay in the background, promoting the team. High integrity and high trust relationship with all the team. Politically savvy with a strong relationship with product owner Able to understand both business and technical people Note: This podcast jumps right in to the phone conversation I was having with Doug, so it might seem to start a little abruptly. Recommendations - Training by Net Objectives Scrum Recommendations - Reading Reading recommendations for Agile Practices Agile Software Development with Scrum by Schwaber and Beedle Recommendations - Tools AgileCraft LeanKit Wikis and Spreadsheets (no particular recommendation here) Recommendations - Online Concango's Scrum FAQ Podcast Transcripts 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 www.netobjectives.com Blog Type: PodcastLog in or register to post comments

An Overview of ScrumMaster - Part 1 I was in a meeting last week with a number of Chief Information Officers. One of the speakers, talking about Agile and Scrum, used the term “Scrum Master” and got a lot of blank stares. They had no idea what she was talking about. This is a fundamental role in Scrum, one of the better approaches for Agile software development. There have been some good articles and books written about ScrumMasters and there is formal Scrum Master Certification by Net Objectives course available. Yet, the term seems to get in the way of understanding the role. Note: Net Objectives is not affiliated with the Scrum Alliance. This is because the terms “Scrum” and “ScrumMaster” were chosen because they were essentially value-free. Thus, the developers of Scrum were free to “pour” their own meanings into the terms. This has proved to be both a blessing and a curse. "ScrumMaster" is probably a good term, within the context of Scrum. In particular, "ScrumMaster" is not a “Project Manager”, which is loaded with so many concepts as not to be useful and yet seems a bit stronger and more connected than a “Facilitator.” To me, it seems more equivalent to a Green Belt in the Six Sigma sense. The ScrumMaster role is fairly unique. It is a servant role – someone whose focus is the health of the team on their ability to produce product as quickly as possible. Usually, this means they must sacrifice their own desire to create code so that others can do so. They must be trusted and trustworthy, able to listen, and tenacious in representing the team to the outside. Where do ScrumMasters come from? They can come from anywhere in the organization. We have seen a lot of good ScrumMasters come from the QA department – they seem to have the right mindset. Project managers can be good ones, but it often requires them to readjust their thinking. To get a handle on this, I had a conversation with Doug Shimp, a former senior consultant and Certified ScrumMaster Trainer with Net Objectives. I decided to break my conversation with Doug into two parts to make it easier to listen to. In Part 1, Doug covers these issues around being a ScrumMaster: Where did the term “ScrumMaster” com from? The qualifications and personality types and organizational origins of good ScrumMasters (approachable, people-oriented, detail-oriented, politically-savvy. They have to have the right mindset.) How many teams one ScrumMaster can serve Impediment removal. One of the main jobs of the ScrumMaster is to help remove impediments to progress but it is not (always or even often) her job to remove them. She must help prioritize the effort to remove them, track progress, and help the team decide when to fight and when to work around it. In Part 2, I continue my conversation with Doug, covering these issues: Examples Doug has seen of both good ScrumMasters and those that have challenges The partnership between the ScrumMaster and the Product Owner. He is a partner with the entire team, both developers and the Business. The ScrumMaster has to help the Business think about the product and the problem they are trying to solve, and the questions they should be asking. How to become a ScrumMaster. This involves a learn-by-doing approach very similar to the Six Sigma Green Belt process, involving training, experience in running a project under a coach, and coaching a project, making a report out. Why every team member needs to take the ScrumMaster Certification training. Helps the team understand what scrum expects of them and what they can do to help the ScrumMaster help them do their work Budgeting and project management and the ScrumMaster Tools and infrastructure you need to know EDITOR'S NOTE Doug lives in the midwest and I am in Seattle. So, I did this interview on the telephone (I got his permission first!). But what do you think? Does this sound OK to you? Is it irritating? Drop me a note and let me know what you think. Recommendations - Training by Net Objective

An Overview of ScrumMaster - Part 1 I was in a meeting last week with a number of Chief Information Officers. One of the speakers, talking about Agile and Scrum, used the term “Scrum Master” and got a lot of blank stares. They had no idea what she was talking about. This is a fundamental role in Scrum, one of the better approaches for Agile software development. There have been some good articles and books written about ScrumMasters and there is formal Scrum Master Certification by Net Objectives course available. Yet, the term seems to get in the way of understanding the role. Note: Net Objectives is not affiliated with the Scrum Alliance. This is because the terms “Scrum” and “ScrumMaster” were chosen because they were essentially value-free. Thus, the developers of Scrum were free to “pour” their own meanings into the terms. This has proved to be both a blessing and a curse. "ScrumMaster" is probably a good term, within the context of Scrum. In particular, "ScrumMaster" is not a “Project Manager”, which is loaded with so many concepts as not to be useful and yet seems a bit stronger and more connected than a “Facilitator.” To me, it seems more equivalent to a Green Belt in the Six Sigma sense. The ScrumMaster role is fairly unique. It is a servant role – someone whose focus is the health of the team on their ability to produce product as quickly as possible. Usually, this means they must sacrifice their own desire to create code so that others can do so. They must be trusted and trustworthy, able to listen, and tenacious in representing the team to the outside. Where do ScrumMasters come from? They can come from anywhere in the organization. We have seen a lot of good ScrumMasters come from the QA department – they seem to have the right mindset. Project managers can be good ones, but it often requires them to readjust their thinking. To get a handle on this, I had a conversation with Doug Shimp, a former senior consultant and Certified ScrumMaster Trainer with Net Objectives. I decided to break my conversation with Doug into two parts to make it easier to listen to. In Part 1, Doug covers these issues around being a ScrumMaster: Where did the term “ScrumMaster” com from? The qualifications and personality types and organizational origins of good ScrumMasters (approachable, people-oriented, detail-oriented, politically-savvy. They have to have the right mindset.) How many teams one ScrumMaster can serve Impediment removal. One of the main jobs of the ScrumMaster is to help remove impediments to progress but it is not (always or even often) her job to remove them. She must help prioritize the effort to remove them, track progress, and help the team decide when to fight and when to work around it. In Part 2, I continue my conversation with Doug, covering these issues: Examples Doug has seen of both good ScrumMasters and those that have challenges The partnership between the ScrumMaster and the Product Owner. He is a partner with the entire team, both developers and the Business. The ScrumMaster has to help the Business think about the product and the problem they are trying to solve, and the questions they should be asking. How to become a ScrumMaster. This involves a learn-by-doing approach very similar to the Six Sigma Green Belt process, involving training, experience in running a project under a coach, and coaching a project, making a report out. Why every team member needs to take the ScrumMaster Certification training. Helps the team understand what scrum expects of them and what they can do to help the ScrumMaster help them do their work Budgeting and project management and the ScrumMaster Tools and infrastructure you need to know EDITOR'S NOTE Doug lives in the midwest and I am in Seattle. So, I did this interview on the telephone (I got his permission first!). But what do you think? Does this sound OK to you? Is it irritating? Drop me a note and let me know what you think. Recommendations - Training by Net Objective

The Technical Aspects of Lean-Agile A lot of our podcasts have been focused on process and on roles – especially the product owner role. And indeed that seems to be what much of the Agile community seems to focus on. Because together, they help us make a lot of progress quickly. But they are not enough. In the corporate world, we always talked about paying attention to the “Iron Triangle” – People, Process, and Technology. All three are important. If you don’t have a balanced emphasis, the “machinery” of your development process will soon grind to a halt. In this podcast, Al Shalloway starts bringing a focus on that third side of the triangle: the technical aspects. Now, maybe this reflects Alan’s bias as an educator, because by “technical”, he is primarily focusing on the technical skills of the development team rather than on specific tools. Developers have to have the mindset and the skills to use their tools in a Lean-Agile way. That said, there are tools and infrastructure aspects to consider. Technical skills for developers include the following: Requirements analysis. Building minimally functional systems. QA and Acceptance Testing, especially using Fit – Framework for Integrated Test – and FitNesse. This is because it is very important to move QA to the beginning of development. Lean-Agile Architectures through Design Patterns. Software architectures define relationships within which software components fit. Creating architectures that allow your system to change, to encapsulate variation. This directly supports a key lean principle: Defer commitment. Test-driven development. Creating your tests up front so that you can design to interfaces and your product is always perfect. How to refactor, how to test. Extracting stories from use cases. Especially if you work in environments that is used to creating heavy use cases. Object-orientation. Nothing helps you understand how to create code that can be modified with minimal impact better than a good grasp of object-orientation. Infrastructure requirements include the following: Source code control Automatic builds Project management Coding standards. The team has to figure out their coding standards, but using the same tool really helps. Recommendations - Training by Net Objectives Test Driven Development Design Patterns Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Reading recommendations including testing and validation 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

The Technical Aspects of Lean-Agile A lot of our podcasts have been focused on process and on roles – especially the product owner role. And indeed that seems to be what much of the Agile community seems to focus on. Because together, they help us make a lot of progress quickly. But they are not enough. In the corporate world, we always talked about paying attention to the “Iron Triangle” – People, Process, and Technology. All three are important. If you don’t have a balanced emphasis, the “machinery” of your development process will soon grind to a halt. In this podcast, Al Shalloway starts bringing a focus on that third side of the triangle: the technical aspects. Now, maybe this reflects Alan’s bias as an educator, because by “technical”, he is primarily focusing on the technical skills of the development team rather than on specific tools. Developers have to have the mindset and the skills to use their tools in a Lean-Agile way. That said, there are tools and infrastructure aspects to consider. Technical skills for developers include the following: Requirements analysis. Building minimally functional systems. QA and Acceptance Testing, especially using Fit – Framework for Integrated Test – and FitNesse. This is because it is very important to move QA to the beginning of development. Lean-Agile Architectures through Design Patterns. Software architectures define relationships within which software components fit. Creating architectures that allow your system to change, to encapsulate variation. This directly supports a key lean principle: Defer commitment. Test-driven development. Creating your tests up front so that you can design to interfaces and your product is always perfect. How to refactor, how to test. Extracting stories from use cases. Especially if you work in environments that is used to creating heavy use cases. Object-orientation. Nothing helps you understand how to create code that can be modified with minimal impact better than a good grasp of object-orientation. Infrastructure requirements include the following: Source code control Automatic builds Project management Coding standards. The team has to figure out their coding standards, but using the same tool really helps. Recommendations - Training by Net Objectives Test Driven Development Design Patterns Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Reading recommendations including testing and validation 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

Why you need a product owner for Agile The Voice of the Customer should set the priorities and vision for the product you seek to deliver. But getting a handle on that Voice can be really hard. Customers can be hard to pin down. They may feel like they are too busy to talk to you or too far away to engage with them successfully. Often, there is more than one customer with a variety of demands – even conflicting demands. And then how do you decide who to listen to? Have you ever found yourself in that situation? Have you found yourself having to guess what customers want? Or, even worse, having to rely on the Marketing department to guess for you? Has that worked well for you? Guessing never works well for me. And it violates one of my fundamental rules for project management: Assume Nothing. Never assume you know what the customer is wanting. Never assume an impediment is too hard to overcome. Never assume a requirement is written in stone. Assume Nothing. Ask someone who knows. The Lean-Agile solution to this challenge is the “Product Owner” role. We discussed this in the Product Owner as part of the Product Development Team podcast. But because the Product Owner is so central to Lean-Agile approaches, it seemed good to get an additional perspective. So, I am turning to Alan Shalloway to get his take. Recommendations - Training by Net Objectives Design Patterns Thinking Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott 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

Why you need a product owner for Agile The Voice of the Customer should set the priorities and vision for the product you seek to deliver. But getting a handle on that Voice can be really hard. Customers can be hard to pin down. They may feel like they are too busy to talk to you or too far away to engage with them successfully. Often, there is more than one customer with a variety of demands – even conflicting demands. And then how do you decide who to listen to? Have you ever found yourself in that situation? Have you found yourself having to guess what customers want? Or, even worse, having to rely on the Marketing department to guess for you? Has that worked well for you? Guessing never works well for me. And it violates one of my fundamental rules for project management: Assume Nothing. Never assume you know what the customer is wanting. Never assume an impediment is too hard to overcome. Never assume a requirement is written in stone. Assume Nothing. Ask someone who knows. The Lean-Agile solution to this challenge is the “Product Owner” role. We discussed this in the Product Owner as part of the Product Development Team podcast. But because the Product Owner is so central to Lean-Agile approaches, it seemed good to get an additional perspective. So, I am turning to Alan Shalloway to get his take. Recommendations - Training by Net Objectives Design Patterns Thinking Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott 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

Lean Product Development is the right approach for software development Toyota can bring new products from initial concept to the production floor in 18 months while other manufactures may take twice as long. Some software companies seem to have a knack for understanding what customers really want while others go through many versions to get something that merely works. What is the difference? Their approach to new product development. Toyota discovered that applying lean principles to the development and design of their products is somewhat different from lean applied to production and manufacturing. The goals are different and so the application of the tools is different, too. Michael Kennedy describes product development as “the collective activity or system that a company uses to convert its technology and ideas into a stream of products that meet the needs of customers and the strategic goals of the company.” Product development is process of discovery. Discovering what customers desire and need and then designing product that will meet that. Indeed, perhaps 70% - 80% of a product’s cost lies in this discovery process; the production is relatively straightforward. In this show, Alan Shalloway argues that this is also true for software development. The process of discovery of what customers desire and need is by far the largest contributor to the cost of the software product. Therefore, learning how to apply the principles of lean product development to software development is essential to an effective software development process. Elements of Lean Product Development include: A relentless focus on what the customer desires, wants, or needs Driving out waste – the things we do that do not help us understand what the customer wants or that get in the way of creating product that satisfies those needs. How to manage intellectual work Software lives in the larger context of the business. Lean helps set the context in which software fits in the business. Before the how, we have to understand the why. Recommendations - Training by Net Objectives Lean Software Development Recommendations - Reading Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It by Michael N. Kennedy The Machine That Changed the World : The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos Music used on this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com For more information, send us an e-mail at info@netobjectives.com or visit www.netobjectives.com Blog Type: PodcastLog in or register to post comments

Lean Product Development is the right approach for software development Toyota can bring new products from initial concept to the production floor in 18 months while other manufactures may take twice as long. Some software companies seem to have a knack for understanding what customers really want while others go through many versions to get something that merely works. What is the difference? Their approach to new product development. Toyota discovered that applying lean principles to the development and design of their products is somewhat different from lean applied to production and manufacturing. The goals are different and so the application of the tools is different, too. Michael Kennedy describes product development as “the collective activity or system that a company uses to convert its technology and ideas into a stream of products that meet the needs of customers and the strategic goals of the company.” Product development is process of discovery. Discovering what customers desire and need and then designing product that will meet that. Indeed, perhaps 70% - 80% of a product’s cost lies in this discovery process; the production is relatively straightforward. In this show, Alan Shalloway argues that this is also true for software development. The process of discovery of what customers desire and need is by far the largest contributor to the cost of the software product. Therefore, learning how to apply the principles of lean product development to software development is essential to an effective software development process. Elements of Lean Product Development include: A relentless focus on what the customer desires, wants, or needs Driving out waste – the things we do that do not help us understand what the customer wants or that get in the way of creating product that satisfies those needs. How to manage intellectual work Software lives in the larger context of the business. Lean helps set the context in which software fits in the business. Before the how, we have to understand the why. Recommendations - Training by Net Objectives Lean Software Development Recommendations - Reading Product Development for the Lean Enterprise: Why Toyota’s System Is Four Times More Productive and How You Can Implement It by Michael N. Kennedy The Machine That Changed the World : The Story of Lean Production by James P. Womack, Daniel T. Jones, and Daniel Roos Music used on this podcast: “Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com For more information, send us an e-mail at info@netobjectives.com or visit www.netobjectives.com Blog Type: PodcastLog in or register to post comments