Lean-Agile Straight Talk

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

   Lean-Agile, the Senior Developer, and Progressing toward Maturity Sometimes, as a coach, you encounter a team who knows their domain really well. They have been developing applications in this space for a long time. They may not see the need to change to a new method, when the usual approach has worked just fine, thank you. Agile just seems foreign to senior developers who know their domain really well. They may resist. They probably do not understand why they need to change and have little incentive to do so. They have to climb a fairly steep learning curve to get out of their old habits. It takes a while for teams to become efficient in Agile. Our experience shows that the first few iterations may actually be less efficient than using the more traditional approaches, until the team’s mindset starts to change. Rod Claar's rule of thumb is For a team to get truly proficient in agile, it will often take the same number of iterations as the number of stable members on the team. Thus, if you have 8 members on your team and you are doing 4 week iterations, you can expect the team to be truly proficient in about 8 months. They will certainly start making progress sooner, but won’t be rock-and-rolling until later. As a coach or a ScrumMaster, part of your job is to set expectations. It is crucial that you caution the team and the management about how long it will take them to get efficient, so that they do not lose heart. This is especially important if they have been exposed to some of the hype that can surround Agile. There are several reasons for this. Lean-Agile is all about continuous process improvement. You will be making changes and tweaks to your processes all the time; you can expect major tweaks as you start out and are still learning. Lean-Agile is about adapting to a context. What works in one team and one context will not translate exactly to another team and another context. That is why we teach principles and give descriptions of practices in other places and then coach teams in how to work it out for themselves. Adults take time to unlearn approaches before they can learn new approaches. Transition is hard. The more they understand the motivations to change, the easier it will be for them. Senior developers often see problems sooner This is both good and bad. Based on their experience, they can identify problems that they know will come up and can move to solve them more quickly. But they might try to build solutions that anticipate problems that might arise in the future. The problem here is that those problems may never come up and you end up with applications that are more complex than is required. One common example is building general frameworks. How many times have you seen developers build elegant frameworks that allow subtle and varied ways to interact with an application? They can be nightmares to maintain. And yet the developers become enamored of their solution and end up spending lots of time and building in lots of features that are rarely, if ever, used. In Lean-Agile, this is called “Waste”. The overuse of design patterns is another good example of this. Now, frameworks are good and design patterns are good, but we prefer to see them built and used based on an evolving understanding of the environment. The requirements should give you the hints about what is needed next. You want the requirements to “pull” the framework, rather than pushing a framework on a system. Scott Bain discusses this in his new book on Emergent Design. Rod thinks the same could be done for Emergent Database Design: the interface between systems needs to emerge over time. A series of conversations with Rod Claar This show begins a series of conversations with Rod Claar, a Senior Consultant with Net Objectives. Rod is a Lean-Agile coach and a trainer in design patterns and test-driven design. He has worked with many clients as they begin their journey into Lean-Agile approaches. In this podcast, we will cover: Lean-Agile Meet

   Lean-Agile, the Senior Developer, and Progressing toward Maturity Sometimes, as a coach, you encounter a team who knows their domain really well. They have been developing applications in this space for a long time. They may not see the need to change to a new method, when the usual approach has worked just fine, thank you. Agile just seems foreign to senior developers who know their domain really well. They may resist. They probably do not understand why they need to change and have little incentive to do so. They have to climb a fairly steep learning curve to get out of their old habits. It takes a while for teams to become efficient in Agile. Our experience shows that the first few iterations may actually be less efficient than using the more traditional approaches, until the team’s mindset starts to change. Rod Claar's rule of thumb is For a team to get truly proficient in agile, it will often take the same number of iterations as the number of stable members on the team. Thus, if you have 8 members on your team and you are doing 4 week iterations, you can expect the team to be truly proficient in about 8 months. They will certainly start making progress sooner, but won’t be rock-and-rolling until later. As a coach or a ScrumMaster, part of your job is to set expectations. It is crucial that you caution the team and the management about how long it will take them to get efficient, so that they do not lose heart. This is especially important if they have been exposed to some of the hype that can surround Agile. There are several reasons for this. Lean-Agile is all about continuous process improvement. You will be making changes and tweaks to your processes all the time; you can expect major tweaks as you start out and are still learning. Lean-Agile is about adapting to a context. What works in one team and one context will not translate exactly to another team and another context. That is why we teach principles and give descriptions of practices in other places and then coach teams in how to work it out for themselves. Adults take time to unlearn approaches before they can learn new approaches. Transition is hard. The more they understand the motivations to change, the easier it will be for them. Senior developers often see problems sooner This is both good and bad. Based on their experience, they can identify problems that they know will come up and can move to solve them more quickly. But they might try to build solutions that anticipate problems that might arise in the future. The problem here is that those problems may never come up and you end up with applications that are more complex than is required. One common example is building general frameworks. How many times have you seen developers build elegant frameworks that allow subtle and varied ways to interact with an application? They can be nightmares to maintain. And yet the developers become enamored of their solution and end up spending lots of time and building in lots of features that are rarely, if ever, used. In Lean-Agile, this is called “Waste”. The overuse of design patterns is another good example of this. Now, frameworks are good and design patterns are good, but we prefer to see them built and used based on an evolving understanding of the environment. The requirements should give you the hints about what is needed next. You want the requirements to “pull” the framework, rather than pushing a framework on a system. Scott Bain discusses this in his new book on Emergent Design. Rod thinks the same could be done for Emergent Database Design: the interface between systems needs to emerge over time. A series of conversations with Rod Claar This show begins a series of conversations with Rod Claar, a Senior Consultant with Net Objectives. Rod is a Lean-Agile coach and a trainer in design patterns and test-driven design. He has worked with many clients as they begin their journey into Lean-Agile approaches. In this podcast, we will cover: Lean-Agile Meet

Lean-Agile Meets the Enterprise Data Group Enterprise data is an extremely valuable asset that must be protected. Data stewards work very hard to avoid damaging the data and writing high performance code that won’t bog down the data systems or the code that is accessing it. “To protect and to serve” would be the motto of the data steward, and that is sometimes a hard balance to achieve. Especially when it comes to Agile projects whose designs tend to emerge over time. When it comes to working well with enterprise data, what kinds of things should the Lean-Agile coach think about? Acknowledge that data stewards have legitimate concerns Break down the barriers between data stewards and developers Allow the data stewards to follow their own processes At the same time, management must encourage data stewards to see themselves as part of the team, with a duty to support the development project Decoupling application development from the data system One of the issues that comes up in larger organizations is that they try to isolate the database team from every application development team. Then, they end up with dozens of database access routines, each one doing the same job. They end up with lots of redundancy, which exposes them to the likelihood of errors. This is a problem of code quality. This is something that the technical owner, with a lean perspective, should look out for. Perhaps think of it as a decoupling of development teams or processes into work cells. The database team then is responsible for ensuring code quality for routines accessing the database. Decoupling allows both teams can work independently. So that the database team can do whatever they need to – normalize, stored procedures, etc. – they can. You want to avoid redundant accesses to the database. This requires design patterns and a relentless focus on code quality across all of your processes A “Work Cell Approach” to Involving Specialty Areas on Agile Projects Ideally, the data steward is part of the Agile development team. This ensures the highest bandwidth communication between developers and DBA. However, data stewards are usually in short supply. Organizations cannot staff every project with its own DBA. One approach from Lean is to make a senior developer the “Agile DBA” for the team, someone whose job it is to look out for the interests of the data, doing simple things, and serving as the liaison with the data steward team. The Agile team treats the data steward team as a separate “work cell”. They flow requirements to the data steward work cell queue, which then pulls the work from the queue in the normal, lean way. Within the data steward work cell, they use whatever methods and techniques make sense for them, interacting with the Agile team’s liaison as needed. This approach recognizes that they have special work requirements, longer lead times, performance issues, etc. and allows them to enough autonomy. This work cell approach works well for many situations in which highly specialized work is required, such as user interface or data security. This approach requires discipline and lean thinking and must be accounted for in work iteration planning, so that the components are pulled in at the right time. The Technical Owner and ScrumMaster will want to be in regular communication with their counterparts in the work cell. To increase communication with the work cell, invite a representative of the work cell to the initial Define activity so that they can give their input. And then, invite them to the Planning Games for each iteration that will involve them. These work cells should be explicit parts of your Value Stream Mapping effort. You can even do DBA in an Agile way… The reason we use an agile process is that we do not understand the domain and the world changes. Agile processes allow more points of change in a very disciplined way. DBAs face this same challenge of change. It is reasonable to think you could even run a database group in an Agi

Lean-Agile Meets the Enterprise Data Group Enterprise data is an extremely valuable asset that must be protected. Data stewards work very hard to avoid damaging the data and writing high performance code that won’t bog down the data systems or the code that is accessing it. “To protect and to serve” would be the motto of the data steward, and that is sometimes a hard balance to achieve. Especially when it comes to Agile projects whose designs tend to emerge over time. When it comes to working well with enterprise data, what kinds of things should the Lean-Agile coach think about? Acknowledge that data stewards have legitimate concerns Break down the barriers between data stewards and developers Allow the data stewards to follow their own processes At the same time, management must encourage data stewards to see themselves as part of the team, with a duty to support the development project Decoupling application development from the data system One of the issues that comes up in larger organizations is that they try to isolate the database team from every application development team. Then, they end up with dozens of database access routines, each one doing the same job. They end up with lots of redundancy, which exposes them to the likelihood of errors. This is a problem of code quality. This is something that the technical owner, with a lean perspective, should look out for. Perhaps think of it as a decoupling of development teams or processes into work cells. The database team then is responsible for ensuring code quality for routines accessing the database. Decoupling allows both teams can work independently. So that the database team can do whatever they need to – normalize, stored procedures, etc. – they can. You want to avoid redundant accesses to the database. This requires design patterns and a relentless focus on code quality across all of your processes A “Work Cell Approach” to Involving Specialty Areas on Agile Projects Ideally, the data steward is part of the Agile development team. This ensures the highest bandwidth communication between developers and DBA. However, data stewards are usually in short supply. Organizations cannot staff every project with its own DBA. One approach from Lean is to make a senior developer the “Agile DBA” for the team, someone whose job it is to look out for the interests of the data, doing simple things, and serving as the liaison with the data steward team. The Agile team treats the data steward team as a separate “work cell”. They flow requirements to the data steward work cell queue, which then pulls the work from the queue in the normal, lean way. Within the data steward work cell, they use whatever methods and techniques make sense for them, interacting with the Agile team’s liaison as needed. This approach recognizes that they have special work requirements, longer lead times, performance issues, etc. and allows them to enough autonomy. This work cell approach works well for many situations in which highly specialized work is required, such as user interface or data security. This approach requires discipline and lean thinking and must be accounted for in work iteration planning, so that the components are pulled in at the right time. The Technical Owner and ScrumMaster will want to be in regular communication with their counterparts in the work cell. To increase communication with the work cell, invite a representative of the work cell to the initial Define activity so that they can give their input. And then, invite them to the Planning Games for each iteration that will involve them. These work cells should be explicit parts of your Value Stream Mapping effort. You can even do DBA in an Agile way… The reason we use an agile process is that we do not understand the domain and the world changes. Agile processes allow more points of change in a very disciplined way. DBAs face this same challenge of change. It is reasonable to think you could even run a database group in an Agi

Does testing make your OO project take longer? "Writing tests up-front sounds good in theory, but in practice, doesn't testing like this really take longer in an object-oriented way? Don't design patterns make it harder to write tests?" That was a question I received recently. The answer is no, but not why you might think. One of Alan Shalloway's favorite sayings is "Fixing bugs does not take very much time... finding bugs - that's what takes time. Once I know where the bug is, it is usually easy to fix." And this only gets worse as your system grows more complex or goes through more releases / revisions. Lean teaches us to focus on the entire value stream, to aim for perfection, to optimize the whole. One way to do this is to capture mistakes early and never to let mistakes repeat themselves. That is why we advocate writing tests early, testing automatically, and keeping your test suite up to date. Using your time to write tests that help you find bugs is ultimately more efficient and speedier than spending lots of time debugging code. Particularly if you are writing code that is meant to endure and grow. You might say, "Debugging is for a moment; tests are forever." Alan shares how he learned this the hard way - that writing more tests means writing fewer traces. And how writing object-oriented code actually requires upfront testing... Think "trust, but verify" - you want to know that you can trust an object. Recommendations - Training by Net Objectives Test Driven Design Lean Software Development Design Patterns Thinking Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Reading recommendations including testing and validation Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann Recommendations - Tools AgileCraft LeanKit 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

Does testing make your OO project take longer? "Writing tests up-front sounds good in theory, but in practice, doesn't testing like this really take longer in an object-oriented way? Don't design patterns make it harder to write tests?" That was a question I received recently. The answer is no, but not why you might think. One of Alan Shalloway's favorite sayings is "Fixing bugs does not take very much time... finding bugs - that's what takes time. Once I know where the bug is, it is usually easy to fix." And this only gets worse as your system grows more complex or goes through more releases / revisions. Lean teaches us to focus on the entire value stream, to aim for perfection, to optimize the whole. One way to do this is to capture mistakes early and never to let mistakes repeat themselves. That is why we advocate writing tests early, testing automatically, and keeping your test suite up to date. Using your time to write tests that help you find bugs is ultimately more efficient and speedier than spending lots of time debugging code. Particularly if you are writing code that is meant to endure and grow. You might say, "Debugging is for a moment; tests are forever." Alan shares how he learned this the hard way - that writing more tests means writing fewer traces. And how writing object-oriented code actually requires upfront testing... Think "trust, but verify" - you want to know that you can trust an object. Recommendations - Training by Net Objectives Test Driven Design Lean Software Development Design Patterns Thinking Scrum Recommendations - Reading Design Patterns Explained, 2nd Edition, by Alan Shalloway and Jim Trott Reading recommendations including testing and validation Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann Recommendations - Tools AgileCraft LeanKit 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

Seeing QA's as allies Good QA people are very valuable. Whether they are working in traditional or agile environments, they bring to bear many of the same tools and skills. So, what is special about working on a Lean-Agile team? How should QA's see themselves as part of the team? And how should management see QA? My neighbor told me a story of two QA guys who worked at his software company. They had received great performance reviews for creating a good testing culture and a great process. Then, they were transferred to another department where testing was informal and developers were managed more by fear. These QA's continued to do their job, testing, capturing bugs, offering suggestions, looking for ways to partner. But after their first year, they were trashed in their performance review and threatened with dismissal for poor team spirit! What made the difference? Neither group was particularly agile. But management in the first group saw QA as an ally while in the second group, they saw QA as a threat. Lean-Agile software development emphasizes the spirit of the first group: testing is an ally. In the last podcast, Alan Shalloway talked about testing within Lean-Agile. Now, we are going to dive a little deeper. How does lean and agile inform the QA practice? What are some of the skills you should know? Why do we emphasize so strongly the importance of writing acceptance tests up front before any code is created? Lean sets a larger context for QA. Lean says that everyone has two responsibilities: Run the business Improve the business Thus, lean teaches that you always want to pay attention to process. Follow the process. When something breaks, find root cause, improve the process, and then go. It requires discipline to want to improve. That is how you improve the process. In Lean-Agile Software Development, this is done by a relentless commitment to testing. Always write tests before you write code. This is part of the discipline and the skill that is required to be successful in Lean-Agile. Lean gives everyone - including management - a framework for understand testing's role and actively encouraging it and creating compensation systems that help it. Lean encourages and indeed requires the teaming of developers and testers to work together to deliver quality and value to customers. By the way, those two testers? My neighbor, their former manager, intervened for them all the way up to the division Vice-President. Their reviews - and compensation - were adjusted. One stayed with the company. The other left. There is a great demand for good testers. Recommendations - Training by Net Objectives Test Driven Development Scrum Recommendations - Reading Reading recommendations for testing and validation Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann 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

Seeing QA's as allies Good QA people are very valuable. Whether they are working in traditional or agile environments, they bring to bear many of the same tools and skills. So, what is special about working on a Lean-Agile team? How should QA's see themselves as part of the team? And how should management see QA? My neighbor told me a story of two QA guys who worked at his software company. They had received great performance reviews for creating a good testing culture and a great process. Then, they were transferred to another department where testing was informal and developers were managed more by fear. These QA's continued to do their job, testing, capturing bugs, offering suggestions, looking for ways to partner. But after their first year, they were trashed in their performance review and threatened with dismissal for poor team spirit! What made the difference? Neither group was particularly agile. But management in the first group saw QA as an ally while in the second group, they saw QA as a threat. Lean-Agile software development emphasizes the spirit of the first group: testing is an ally. In the last podcast, Alan Shalloway talked about testing within Lean-Agile. Now, we are going to dive a little deeper. How does lean and agile inform the QA practice? What are some of the skills you should know? Why do we emphasize so strongly the importance of writing acceptance tests up front before any code is created? Lean sets a larger context for QA. Lean says that everyone has two responsibilities: Run the business Improve the business Thus, lean teaches that you always want to pay attention to process. Follow the process. When something breaks, find root cause, improve the process, and then go. It requires discipline to want to improve. That is how you improve the process. In Lean-Agile Software Development, this is done by a relentless commitment to testing. Always write tests before you write code. This is part of the discipline and the skill that is required to be successful in Lean-Agile. Lean gives everyone - including management - a framework for understand testing's role and actively encouraging it and creating compensation systems that help it. Lean encourages and indeed requires the teaming of developers and testers to work together to deliver quality and value to customers. By the way, those two testers? My neighbor, their former manager, intervened for them all the way up to the division Vice-President. Their reviews - and compensation - were adjusted. One stayed with the company. The other left. There is a great demand for good testers. Recommendations - Training by Net Objectives Test Driven Development Scrum Recommendations - Reading Reading recommendations for testing and validation Creating a Lean Culture: Tools to Sustain Lean Conversions, by David Mann 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

QA and testing Do you use Quality Assurance in your coding practice? How do you use it? And when? And why? What drives you to do testing when you do it? We claim that QA is one of the most important facets of Lean-Agile software development. More than simply catching bugs or verifying user requirements, they are also partners in helping you improve your entire process. And yet, it is generally misunderstood and under-appreciated. In the last podcast, Rob Myers told a story about how testing can be misunderstood. This prompted me to want to explore in more depth testing and QA within the Lean-Agile Software Development framework. This podcast is part 1 of an interview with Alan Shalloway, who shares his perspective of QA in its role in overall process improvement in Lean-Agile. Fundamentally, the goal is to change our perspective from "I am producing a product" to "I am always trying to add value to the customer" (in line with business goals). What we are after is: Changing the dynamic of the conversation between the developer, customer, and tester Creating a positive, knowledge-generating environment in which process improvement happens naturally and quickly Automating this so that it becomes part of the standard work of the team Augmenting the nature of documentation to include executable specifications that are always current Recommendations - Training by Net Objectives Test-Driven Development Recommendations - Reading Reading recommendations including testing and validation 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

QA and testing Do you use Quality Assurance in your coding practice? How do you use it? And when? And why? What drives you to do testing when you do it? We claim that QA is one of the most important facets of Lean-Agile software development. More than simply catching bugs or verifying user requirements, they are also partners in helping you improve your entire process. And yet, it is generally misunderstood and under-appreciated. In the last podcast, Rob Myers told a story about how testing can be misunderstood. This prompted me to want to explore in more depth testing and QA within the Lean-Agile Software Development framework. This podcast is part 1 of an interview with Alan Shalloway, who shares his perspective of QA in its role in overall process improvement in Lean-Agile. Fundamentally, the goal is to change our perspective from "I am producing a product" to "I am always trying to add value to the customer" (in line with business goals). What we are after is: Changing the dynamic of the conversation between the developer, customer, and tester Creating a positive, knowledge-generating environment in which process improvement happens naturally and quickly Automating this so that it becomes part of the standard work of the team Augmenting the nature of documentation to include executable specifications that are always current Recommendations - Training by Net Objectives Test-Driven Development Recommendations - Reading Reading recommendations including testing and validation 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

Notes from Agile 2006 and Comments on Testing The Agile 2006 conference has come and gone. It was a good and eye-opening experience for me. I had lots of great conversations in the Net Objectives booth and over coffee. I got to help lead a session or two. And I had fun with customers and colleagues. All for something I really believe in, this connection between lean product development, agile software development, and technical skills, supported by lean management systems and tools. In this podcast, I thought I’d share two or three observations of my own observations from the show and then ask Rob Myers to talk about a conversation he had in our booth with a skeptic. We are going to be turning to issues around testing and QA and this makes a good start. I used this graphic to describe what we mean. I got to calling this the “three legs of the stool” for effective software development VersionOne is cool VersionOne gave away the coolest stuff: mini-rugby balls and rugby shirts (for Scrum). And their large screen TV had the "sizzle" factor, showing off the VersionOne tool quite well. And their tool is very nice. I am using it now and find that it works like I would expect and does not get in the way. Just what you’d hope for in an agile project support tool. We partnered with VersionOne to offer a cruise as an expression of thanks to our customers and associates. And to give them and us a chance to talk and connect. It was a lot of fun, a great way to unwind at the conference. Both of us hope to make this an annual event at the Agile conferences. Here’s a picture of the sternwheeler we went on. With thunderclouds in the distance, it was a gorgeous evening. Mature Questions The next thing I’d note is that people are serious about this stuff. There are people looking for what to do and many looking for what to do next, now that they have been using Agile for a while. There were a lot of great, insightful questions. Lots of good, practical insights being shared, together with some academic lessons. It is clear the field is still growing. There seemed to be a good balance in topics, covering the “iron triangle” of people, process, and technology. When people issues are being talked about at a software conference, that is a good sign. Hybrid Methods It also seemed to me that almost no one is using a “pure” methodology, as defined in a book. Most companies I talked to are using a hybrid solution, choosing from among several approaches and adapting them to fit their own context. And that is as it should be, in my opinion. Just because someone made something work in one context in one company doesn’t mean I should be able to bring those same practices and techniques over to my context and my company and expect them to work as is! I’ve had too many vendors come talk to me with their packaged methodology and, by the way, a tool ($$$) to support it. They are just trying to sell something and it has never worked out for me. What works better is to understand the principles and strategies underlying a methodology. Then read about how the methodology is practiced at other companies to give me guidance and ideas about how I might use it at my own company. That takes some thoughtful work. A friend of mine last night said, “but Jim, a lot of people simply want to be led, to be told what to do.” And that is where I would say, OK, there are lots of people who will take your money and tell you what to do, but it won’t be effective for you. This is knowledge work and learning and feedback and evolution are where it is at. So, it is better to have an experienced coach who can come alongside you and help you think about what will work for your situation and how to evolve an approach that fits your needs, that you can own. Anyway, that is what I believe. And it seems that that is what many people are looking for. And it is the approach that people who are successful are using. I want to use tools that fit me, not the other way around Along that line, I

Notes from Agile 2006 and Comments on Testing The Agile 2006 conference has come and gone. It was a good and eye-opening experience for me. I had lots of great conversations in the Net Objectives booth and over coffee. I got to help lead a session or two. And I had fun with customers and colleagues. All for something I really believe in, this connection between lean product development, agile software development, and technical skills, supported by lean management systems and tools. In this podcast, I thought I’d share two or three observations of my own observations from the show and then ask Rob Myers to talk about a conversation he had in our booth with a skeptic. We are going to be turning to issues around testing and QA and this makes a good start. I used this graphic to describe what we mean. I got to calling this the “three legs of the stool” for effective software development VersionOne is cool VersionOne gave away the coolest stuff: mini-rugby balls and rugby shirts (for Scrum). And their large screen TV had the "sizzle" factor, showing off the VersionOne tool quite well. And their tool is very nice. I am using it now and find that it works like I would expect and does not get in the way. Just what you’d hope for in an agile project support tool. We partnered with VersionOne to offer a cruise as an expression of thanks to our customers and associates. And to give them and us a chance to talk and connect. It was a lot of fun, a great way to unwind at the conference. Both of us hope to make this an annual event at the Agile conferences. Here’s a picture of the sternwheeler we went on. With thunderclouds in the distance, it was a gorgeous evening. Mature Questions The next thing I’d note is that people are serious about this stuff. There are people looking for what to do and many looking for what to do next, now that they have been using Agile for a while. There were a lot of great, insightful questions. Lots of good, practical insights being shared, together with some academic lessons. It is clear the field is still growing. There seemed to be a good balance in topics, covering the “iron triangle” of people, process, and technology. When people issues are being talked about at a software conference, that is a good sign. Hybrid Methods It also seemed to me that almost no one is using a “pure” methodology, as defined in a book. Most companies I talked to are using a hybrid solution, choosing from among several approaches and adapting them to fit their own context. And that is as it should be, in my opinion. Just because someone made something work in one context in one company doesn’t mean I should be able to bring those same practices and techniques over to my context and my company and expect them to work as is! I’ve had too many vendors come talk to me with their packaged methodology and, by the way, a tool ($$$) to support it. They are just trying to sell something and it has never worked out for me. What works better is to understand the principles and strategies underlying a methodology. Then read about how the methodology is practiced at other companies to give me guidance and ideas about how I might use it at my own company. That takes some thoughtful work. A friend of mine last night said, “but Jim, a lot of people simply want to be led, to be told what to do.” And that is where I would say, OK, there are lots of people who will take your money and tell you what to do, but it won’t be effective for you. This is knowledge work and learning and feedback and evolution are where it is at. So, it is better to have an experienced coach who can come alongside you and help you think about what will work for your situation and how to evolve an approach that fits your needs, that you can own. Anyway, that is what I believe. And it seems that that is what many people are looking for. And it is the approach that people who are successful are using. I want to use tools that fit me, not the other way around Along that line, I

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