Poppendieck Videos
newest 100 poppendieck videos / poppendieck widgets / media rss:

 Avoiding Over- and Under-Design in Agile Projects (audio of the webinar) Scrum# is an extension to Scrum that was developed by Net Objectives to solve challenges that were being encountered by many teams adopting Scrum. Read about more about the issues which Scrum# was created to solve. A webinar on August 17, 2008 presented by Alan Shalloway focuses on what developers must attend to when building systems with Agile methods. It discusses an alternative to the choices of: Design for the future which often results in overdesign Not designing at all which often makes code difficult to changeThe mantra of the talk is “minimizing complexity and rework” and shows how to use the advice from Design Patterns, coupled with the attitude of not building what you don’t need from Agile. The talk is basically a compendium of the essential ideas Net Objectives believes that developers need to understand after learning the basics of Scrum or Agile process. At the end of the day, you are still writing code. This webinar is a first start in what you need to know in writing code in an Agile environment. Attendees will learn: How Design Patterns give an alternative design approach to the common approaches of over and under design How decoupling modules from the start can often be done in a simple manner without requiring pre-cognitive abilities How the understanding of components written by one group and used by another can be defined betterThe webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunesNote: This webinar is close to an hour long, so the files are large. Attend other sessions in the Scrum# Webinar series.

 Managing Requirements in Agile Projects with Scrum Sharp (audio of the webinar) Scrum# is an extension to Scrum that was developed by Net Objectives to solve challenges that were being encountered by many teams adopting Scrum. Read about more about the issues which Scrum# was created to solve. A webinar on August 17, 2008 presented by Alan Shalloway discusses how Scrum# s enterprise and product focus improves on the standard method of managing with Epics and User Stories. By stepping back to include product portfolio management, Scrum# facilitates working on the right product features across the enterprise, not just working on the right stories in a project. Topics discussed include: Product Portfolio Management with Minimum Marketable Features (MMF) How MMFs are more useful than Epics Going beyond user stories Managing stories from business value Handling time and team dependencies in your Sprint backlogThe webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcast A (lower resolution) iPod Video that you can watch on your iPod or in iTunesNote: This webinar is close to an hour long, so the files are large. Attend other sessions in the Scrum# Webinar series.

 Lean-Agile in Tough TimesIn times of economic slowdown, you have many choices to make about how to allocate scarce time and people and money. Is it at all relevant to invest in Lean-Agile software development? Why? What would you say? Alan Shalloway believes it is more important than ever. And it is why he places so much emphasis on Lean for those who need to become more Agile. Focusing on local team efficiency is good... teams become more able to create product with a minimum of wasted effort. But the more important objective - and even more so now - has to be ensuring that the organization is delivering true value to customers as quickly as possible. This requires the entire stream of product creation to working effectively. The goal is not really to speed up software development. The goal is to speed up delivery of software that customers can use. To be faster now and faster in the future. Perhaps you would call this Enterprise Agility.  I ask Alan to comment on this and on a couple of related questions: In tough times, is it best to start with small pilot projects? Opinions are mixed. Where do assessments fit in the improvement mix?What lessons can we draw from successes and failures that we have seen in the transition to lean-agile?Recommendations - Online ResourcesThe TOWS Matrix - Going beyond SWOT Analysis (MindTools) Recommendations - Training by Net ObjectivesLean Software Development for Management Music used in this podcast“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Design Patterns in an Agile Environment (audio of the webinar)There is a myth that every iteration must be focused on customer value. Actually no customer value is delivered until the release. A webinar given on July 21, 2008 by Alan Shalloway relates an actual project using quality coding techniques and Lean principles to show that while releases should be based on customer value, individual stories should be based on a combination of customer value, risk mitigation and business value. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download: The audio track of the presentation as a podcastA (lower resolution) iPod Video that you can watch on your iPod or in iTunesThis webinar is close to an hour long, so the files are large.Attend other sessions in the Scrum# Webinar series.

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

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

Siegerehrung des "Best of Europe" Tournaments im Rahmen der La Onda Fight Night aus Magdeburg mit dem Promoter Sascha Poppendieck Author: Chris21121984 Keywords: andre reinders la onda fight night magdeburg freefigght mma muay thai k-1 sascha poppendieck Added: July 1, 2008

grandioser Auftritt des Freefighters aus Magdeburg bei der La Onda Fight Night Author: Chris21121984 Keywords: henrik oschmann la onda fight night magdeburg freefight mma muay thai k-1 sascha poppendieck Added: July 1, 2008

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

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

Overcoming Impediments to Test-Driven DevelopmentRecently, I had the chance to sit down with Scott Bain, author of Emergent Design and an expert in Test-Driven Development. He wanted to talk about what he has seen as impediments to implementing Test-Driven Development: impediments that arise before an organization decides to adopt TDD and impediments that arise after adopting TDD. He bases this on his conversations with clients who are in the midst of implementing TDD, on his coaching experience, and on own personal journey with TDD has he has incorporated the concepts into Net Objectives training in Design Patterns, TDD, and Analysis. Impediments before adoptionBefore organizations decide to adopt test-driven development, they usually have to address one or more of these challenges:Developers will be doing double work and be less productiveDevelopers know their code too well and cannot write tests wellTesting before coding seems nonsensicalImpediments after adoptionThe impediments do not stop after TDD has been adopted. What we see is that after Iteration 3, the TDD effort begins to collapse. It takes too long, the tests are difficult to change, or it is hard to keep up with multiple testsOvercoming these ImpedimentsThe answers to both of these impediments lies in gaingin a new, essential insight: in TDD, the entities we write not not actually tests. They are specifications. What we are doing is replacing traditional specs with automated specs.  The process of writing the specification is an analysis task, one that leaves behdind a suite of tests as a side-effect artifact; thus, it is not double work.TDD does not replace Quality Assurance. They will not be sufficient for all testing. TDD is another fundamental skill that developers, especially Agile developers,  must have. It is something that they can learn when they receive proper training.Recommendations - Training by Net ObjectivesDesign, Testing and ProgrammingRecommendations - Reading and ResourcesEmergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain The Net Objectives bibliography for Technical DevelopmentThe Net Objectives Resources library for TDDMusic 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

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

Enterprise Agility Often, organizations invite us in to help them think about how to bring Agile into their development practices. The initial focus is often at the local team level. Our experience is that this is not the best place to start. Instead, we prefer to look for pain points that the organization is feeling in their development work, and we talk with local teams to get indicators of these points. What is stopping you from delivering the value to customers that you feel you should?What opportunities do you see and what waste is there?We can predict some of the answers depending on whether it is an IT organization or a product organization. IT organizations tend to have people working on more than one project at a time whereas in product organizations, people usually focus on one project. This means that IT organizations often have less connection to the business and have more contention for resources. These are all opportunities for improvement that may or may not involve changes at the local team level. Enterprise Agility, Systems Thinking“Enterprise Agility” focuses on helping the overall development organization be more able to respond to the needs of the business. It starts by looking at what needs to be done and then on how to do it. Probably, this will involve Agile at the local team level, but that might not be the best place to start. There is a maxim that “Good people in bad systems still cannot produce.” It is always best to take a systems-view of process improvement, to focus on the systems that people work in. Otherwise, you can end up with sub-optimization – one part of the system doing well but overall, it still underperforms. Doing what is best for the enterprise involves optimizing the whole. Too often, consultants want to start at the local team level just out of habit. Then, they try to “scale up Scrum to the enterprise.” Beyond the problem with sub-optimization, there is a great danger that you may never even be given the chance to start. Why? If upper management has not already bought into the idea of Agile, then one failed experiment in Scrum can leave a permanent bad impression. Starting with a focus on the challenges of the enterprise – reducing waste and delay, improvements in the value stream – helps them see what they will be getting out of it. An experiment with a local team, then, becomes one of several things you could be trying as a start. Look for the Pain PointsChances are that the size of the organization will impact the issues we address, but that is not certain. Rather, it is complexity of process and connections between teams and organizational culture that leads to waste and inability to work with the business. For example, stove-piping, over-burdening processes, a disconnect between business and IT. What are the underlying lean principles that are being followed and what are being violated. The biggest challenge is that pain-points are not always recognized and we tend to think that it is just the way things have to be… that things cannot be improved. Do the SIPOCWhen it comes to analyzing where to start in helping a development organization, it often makes sense to talk to the Business, which is the customer of the dev group, as well as upstream to the Operations, which supplies the dev group. A standard lean technique is to do a simple SIPOC (Supplier-Input-Process-Output-Customer) to be explicit about who and how the organization interacts with the system. All too often, this simple step is forgotten as we are focused on building product. For example, a local team might already be reasonably productive, even without Scrum. But they are thrashing because their Business customer is not ready to work with them when they need answers. Or the change management system takes weeks to schedule a user acceptance test. These are structural issues dealing with upstream inputs and downstream outputs over which the local team has no control. Attack these root causes of thrashing and you improve the flow. Only then will it make a difference to improve the team. Enjoy the show! RecommendationsWeb Challenging Why (Not If) Scrum Works by Alan Shalloway - in Agile Journal or original blog entryBooksCreating a Lean Culture: Tools to Sustain Lean Conversions by David MannThe Leader s Handbook: Making Things Happen, Getting Things Done by Peter R. ScholtesTraining by Net ObjectivesLean Training CoursesMusic used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/

 Announcing Scrum Certification by Net Objectives Scrum Certification by Net Objectives is a new program by Net Objectives to help the industry and especially our clients have a reliable, repeatable, and meaningful process by which to assess the competency of individuals and teams to be on a Scrum Team, to be a Scrum Master, or to be a Product Owner. This podcast announces the program and the motivations behind it, including the following:What this program is and what it coversThe motivation behind this programWhy the industry needs certification in ScrumWhat we mean by “certification”What certification will involveWhen it will be readyThe need for this is borne out of our experience having trained almost 20,000 people in Scrum and working with many major corporations rolling out Scrum, what people need to get proficient with Scrum. From my own vantage point, it seems like time to do this. Other improvement initiatives, such as Six Sigma, Lean Manufacturing, and ITIL have meaningful certification programs based on observed best practices and defined competencies. Standards-based and open to improvement. It provides the objective foundation for a conversation by the profession in what it means to be a competent worker, mentor, or master trainer. And it provides a roadmap for people who want to progress.This program is ready now. If you want to get more information, you can call 1.888.LEAN.AGILE or read the press release at www.netobjectives.com/news/20070813-press-release-scrum-certificationThis is sure to be talked about and I welcome your thoughts. Drop me a line jim.trott@netobjectives.comEnjoy the show!Recommendations - Training by Net ObjectivesScrum Training CoursesMusic used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.For more information, contact info@netobjectives.com or visit us at www.netobjectives.com/

Lean-Agile and the Process-Innovation PendulumAlan was the keynote speaker at the SQE Better Software Conference in Las Vegas this year. Conferences are great for stirring up ideas and generating insights. For this podcast, I wanted to continue the series on Lean Anti-Patterns, sharing some more from what we are learning as we write this book. But you cannot always control a conversation. One of the hardest things to know as a facilitor is when to re-focus an individual or a group and when to let the ideas flow. You want the ideas to emerge and you want them to create the result. Today, I went with the passion, letting him share because I knew we’d get back to the other topic another day. Innovation or Process? Maybe it is a little like the challenge of the software industry: do we want process or do we want innovation? We keep shifting between the two. Software development methodology seems move between being creative and processes to control chaos. In the 70s, we had waterfall methods to structure our work. The 80s saw a burst of creativity with the rise of the PC, thousands of developers coming in and process took a back seat. The 90s saw a tension between the Internet (creative) and CMM (process). And where are we now?Maybe it is time for a happy medium. Maybe lean can help us achieve it.Lean sees process is the structure in which creativity can be expressed. Having standard work process frees me from having to think about the routine stuff so that I can spend creative energy on new stuff. The routine stuff always has to be done; standard work organizes it so that I do not have to devote more energy than necessary doing it. I do not have to decide if I am going to do testing, if I am going to have work-cell teams, if I am going to communicate with customers. That is the routine.As an example, I have just finished working with an organization where we needed to upgrade our Microsoft Office software. Now, you would think that ordering software would be fairly routine since the funds were already in place. But they had no process! Without process, it became an ordeal, all dependent on one guy to be a hero and figure out what to do next. We could go only as fast as he could work. Three weeks later, we are almost there. How much of his effort – and our time – was wasted because they had no process for the routine stuff.Scrum and Iterative Analysis Our biggest challenge is, and continues to be, to build products the customer wants. Thus, the biggest risk is building things the customer does not want. How do you manage this in a more complete way?Lean-Agile would say to do a little, learn a little, then adjust based on customer feedback. Do not do workarounds and do not build too much. Seen this way, Scrum is perhaps more of an iterative analysis technique than an iterative development technique. It helps to minimize that risk of building what the customer does not want. The rest of the Lean-Agile framework – Analysis, Design Patterns, Test-Driven Development, Scrum, Process, QA – certainly help us to have an environment where this can be done.Lean-Agile says it is OK to be productive, even without ScrumThat sounds flip, but it is a key point. We have had a number of clients where one of their groups is clearly more productive than the others. Yet none of them are doing Scrum, none of them are using iterative development. What accounts for the better performance? They are using Lean-based principles in their routine process while the others are not. They have co-location, voice of the customer, more up-front testing. And they are being productive.Here is a story. One friend, a development manager at a software company, told me that he is ready to kick off his teams people who are Scrum evangelists. They do not recognize that he is applying the principles already in ways that fit their situation and they are greatly more productive than others. Other Scrum practices just don’t fit their needs. Rather than rebuking them, Lean-Agile would praise them while encouraging them not to be satisfied. He could live with that.This is key because the goal is not to do Scrum. The goal is to produce more software that our customers see as valuable and less of what they do not want. Don t be dogmatic.Recommendations - Training by Net ObjectivesLean-Agile Software DevelopmentMusic used in this podcast is by Kevin McLeod: http://www.incompetech.com. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I’d encourage you to subscribe to his feed.For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Lean Anti-Patterns: OverviewIt doesn’t have to be this way. Haven’t you felt that in your tummy sometimes. You and your team end up doing the same thing again and again, and you just get the same results again and again. And here you area again, starting out on that familiar path and it is going to be painful again. Around and around. That is an “anti-pattern”: Repeated patterns of work and behavior that produce counterproductive results.Alan Shalloway has been training companies across the country in lean for software development. As he has been working with clients to help them implement lean, he has heard many of these similar stories and problems. After hearing some symptoms, he can often identify more fundamental, root issues because he has built up a mental library of these anti-patterns. Giving names to the problems, Alan and his clients discover they can delve into solutions more quickly.Alan has come to see the study of anti-patterns as very important for learning lean. In the West, people can usually identify what is going wrong much more quickly than they can see what to do right. Anti-patterns gives you the ability to discuss the “what’s wrong” without dropping into whining or complaining. They also give a common discussion point around why the lean principles are so important: when you violate the principle, this is what happens. Together, this helps management understand what needs to change and why it is important.Based on this, Alan and I have begun to write a book called Lean Anti-Patterns and what to do about them. This book has six or seven parts and future podcasts will cover each of these parts.A quick overview of lean. There are a lot of great books, so this will be fast. Poppendieck. Womack and jones. Liker. Fast-flexible-flow. How to get ideas in and get product out. How to deliver fast. Integrating the notions.Lean Anti-Patterns. Anti-pattern that violates lean principles is a lean anti-pattern. What is the principle that it violates and why that is a problemAnti-patterns in management. Patterns that are structural, process, customer-focused, the stuff that management must deal with all the time. This podcast will focus on one in particular: having too many projects.Technical anti-patterns. Not problems in coding, but but anti-patterns that occur in the technical team. Example: Delays in coding.Things that result from the anti-pattern. This discusses the symptoms that you likely to see when there is an anti-pattern. Tempting to think these are causative, but usually they are signs of deeper issues. Example is thrashing. Teams thrash when multi-tasking, get caught up not getting anything done. That is not the cause of the problem; instead, being caused by too many projects. If you keep doing what you keep doing, you are going to keep getting what you keep getting.Transitioning to lean. Lean is one of things that are simple but not easy. Find an easy gain to have. Little deeper. How keep it going. Book recommendations. What is the high level roadmap?Anti-patterns help management and workers work together to see beyond the current state to see what can change. No longer victims.In AdditionAlan is working on two other projects that support this book effort.Webinars. First, he is developing a series of webinars that will take a deeper cut into the topic.Online. Second, he is developing a series of online learning opportunities. The nature of lean requires learning a lot. A 2-3 day intensive course is good for teams, but maybe for individuals, it is more effective to do this over time, giving you time to think. If you are interested in this book or these trainings, send note to Alan at alshall@netobjectives.comPersonal NoteOn a personal note: Today, I am wishing a happy 25th wedding anniversary to my lovely bride! Amazing, still!Recommendations - Training by Net ObjectivesLean-Agile Software DevelopmentMusic used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I d encourage you to subscribe to his feed.For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com

An Overview of Lean - Agile Software DevelopmentSince my days working with manufacturing, I’ve been hearing about Six Sigma and about Lean. There is a lot to these programs. The “elevator speech” says that Six Sigma focuses on reducing variation and Lean focuses on reducing waste.Last year, I gained my Six Sigma Green Belt certification helping an internal help desk to improve self-service. We used a Lean Six Sigma approach and was a great process, very customer-centric which surprised me. I had thought six sigma was all about statistics. OK, well it had a lot of statistics, which made my little mathematical heart go pitter pat. But there was a lot of human focused work, too. It was fun… and it worked to improve their process. Great for production work. But does it to software development? It doesn’t seem that Six Sigma is quite the right set of tools for that.Alan Shalloway, the CEO of Net Objectives recommended a great book to me: Lean Software Development: An Agile Toolkit for Software Development Managers by Mary and Tom Poppendieck. I loved her book. And the Net Objectives course based on the book was really a lot of fun. It really got me to thinking.Lean-Agile Straight Talk was born out of a desire to help us and others share our thoughts about this emerging topic with people who really care about being more effective and suffering less to develop software. Without a bunch of hype. So, over this series of podcasts, I hope to explore how this applies to Requirements, product development, testing.How do you fit it in to an organization that has been used to waterfall processes? Can you do that? How do you help organizations make the transition? What are the human-centered tools that help? What makes for a successful ScrumMaster? And what in the world is a ScumMaster anyway? To start with, it seems like it would be worthwhile to get the 30000 foot view first.That’s where we will start, with some interviews with Alan Shalloway, CEO of Net Objectives.Recommendations - Training by Net ObjectivesLean Software DevelopmentDesign PatternsScrumRecommendations - ReadingLean Software Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck and Tom PoppendieckProduct Development for the Lean Enterprise: Why Toyota s System Is Four Times More Productive and How You Can Implement It by Michael N. KennedyDesign Patterns Explained : A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series) by Alan Shalloway and James TrottAgile Project Management with Scrum by Ken Schwaber and Mike BeedleMusic 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

Completing the Agile Development PuzzleBob Hartman is Net Objectives’ Vice President of Business Development and Marketing. He has over 20 years experience in the software industry and has seen it all. Maybe it is all those years in the trenches or maybe it is the gray in his beard or maybe it is living in Colorado, but I find his perspectives to be refreshing. He sees what organizations truly need and does a great job helping them.Recently, I had the chance to talk with Bob just after he gave a free public seminar called How to use lean principles to complete the Agile development puzzleThis seminar was motivated by Bob s keen awareness that Agile – as it is usually taught – is not nearly as effective for teams and organizations as it should be. Teams only go so far and are left to struggle with how to improve, or must hire expensive consultants. Lean helps complete the picture.Here s a little more detail. To paraphrase a familiar quote, “Give a team Agile and they can work effectively until it breaks. Teach them Lean principles and they can continuously improve.” Clearly, he’s a recovering geek. But it is still true.The thrust of his seminar was to help people understand the lean principles that provide the foundation for Agile, so that they can be freed from the “Agile recipe book” to know how to adapt processes for themselves. They need to know the “Why” behind the “What.”Repeatedly, Bob has helped organizations compare the Agile practices they are doing now – especially what is not working as they had hoped – with the lean principles that inform those Agile practices to help them see where they need to go. Then, they can develop plans to get there. Knowing the principles gives Bob the “power” to see gaps.Here are some examples of problems that we see time and again in Agile teams.Agile problem: Testing happens at the end of an iteration.What usually happens: The Agile team runs out of time, so they push testing off to the next iteration. And then they push more testing off to the next iteration. And so on, always building up “testing debt.” Testing early is not a typical Agile process.Lean principle being violated: “Build Quality In.” Lean teaches another perspective on testing – it is essential right from the start. The goal is not simply to uncover defects but to prevent them in the first place. We want to build quality in, not test it in. Otherwise, just doing risk management. But building quality in (using TDD and acceptance tests up front), the team knows that the product is defect free.Agile problem: Trying to do more than in the current iteration than you had in the previous iteration.What usually happens: A team is pushed to go faster or get more done in the next iteration than they had done in the past iteration. The work piles on. And teams think there is something wrong with them or that the last iteration was just an aberration.Lean Principle: “Respect People” and “Do not multitask” and “Deliver Fast.” Teams usually don’t go faster than they have done. It is better to let them go at their established, sustainable pace, using disciplines rather than heroics. If they get their work done, they can always pull more off of the backlog, but should not be pushing stuff off. Piling on more work comes from fear that the team is not performing adequately, not going to get all of the features finished. But it is better to deliver whole features earlier to customers than to wait and wait and deliver a set of features late – the customer gets more value earlierAgile seems to be focused on improving teams. This is good, but may be sub-optimal. Teams end up focusing on their piece of the overall effort. Lean thinking builds on this to say, “let’s look at the entire stream of work we do, from the initial concept to cash in the door.” It helps management see their part in orchestrating something that will optimize the entire flow.For example, suppose you have a team that can turn a requirement into a finished product instantly. A wave of the wand and a perfect product is created. They would be really impressed with themselves. But then, suppose it takes shipping 6 months to get it to the customer and it takes billing another 9 months before the purchase order is sent and product support does not get the support manuals for 15 months. Now, it appears that neither the customer nor the business is getting much value from that instant product. There is lots of room for improvement.Lean gives the eyes to improve the entire value stream.That is why we teach Lean and Agile and Test-Driven Development and Patterns in an integrated way. They all work together. And the people doing the work also work in an integrated way.That is why we believe in offering Implementing Scrum for Your Team as something for whole teams – business and technical – rather than sending people one at a time. Integrating people from the get go is the most effective path to success.Enjoy the show!Talk to us 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 ObjectivesLean-Agile Software DevelopmentImplementing Scrum for Your TeamMusic used in this podcast is by Kevin McLeod: http://www.incompetech.com/. I changed to the new tune just because it made me happy. Kevin has some great samples going up there all the time. If you need music - royalty free (Creative Commons) then I d encourage you to subscribe to his feed.For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Know Thy Audience - Part 2Happy Cinco de Mayo 2007! I will be doing a couple of shows with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. He is a gifted coach who connects with senior management as good as anyone I have seen. He knows how to get things moving.One of the critical success factors for introducing Lean-Agile software development into an organization is to be prepared. To understand who you are going to be working with. This is the first discipline you need to adopt to become a good Lean-Agile coach. Prepare and then prepare to be a learner (your first impressions are almost always wrong or at least incomplete).This show continues the conversation on preparation that we have been having with Alan Chedalawada, the Chief Operating Officer and manager of the coaching practice at Net Objectives. I am highlighting him to you because I find him to be a gifted coach who connects with senior management as well as anyone I have seen. He knows how to get things moving. I learn a lot by watching him and I think you will glean important ideas as well.You may recall, Alan categorizes clients into Entrepreneurial, Structured, and Highly-Defined organizations. How does this help him? He identifies several ways:It indicates the approaches to take to help the organization learn this new approachIt gives a sense of their openness to innovationIt helps predict the number of projects and variety of experiences that will be required during the discovery phase before management and workers can feel that this approach will work in their environment.Here is a little more detailThe benefit of categorizationFirst, categorization helps develop the approach to take to help the client learn this new way of doing product development. The more formal and specialized their work, the more they may have to unlearn before they can start to learn. The more centralized, the more likely it is that the central group will have to be involved in this “unlearning” early in the process.Along this line, it gives a sense of how likely the organization is to be able to learn, to improve, and to innovate. A very telling measure is to ask, “How often have practices been revised? And by whom?” The more entrepreneurial, the more likely they will be able to embrace change and empower local improvements.Categorizing customers indicates the breadth of “experimentation” or discovery that will be required in the consulting engagement. In an entrepreneurial organization, starting with local teams (the normal approach of Agile coaches) can be successful; but in highly-defined organizations, this will probably not be helpful: your sample size is just too small. The local team will often be so specialized that their issues will not be representative of the organization or the project types they face. You will not have demonstrated that the approach will work nor scale to the program level and so you will not get management buy-in.How will you drive out risks: in teams and in the organization (is Agile sufficient?)Remember, early in your consulting engagement, you are trying to drive out all of the risks that the client may face. It would be very easy to help local teams become highly productive product development engines. The main risk is just getting teams to adopt to a new way of thinking. If you can get over that, the “gossip network” will become a great ally. Emphasize an Agile approach and you will have good success with the team.However, simply emphasizing Agile will not lead to long-term success in more highly-defined organizations. The more highly-defined the organization, the more likely it is that the risks will not be evident right away. Local teams may become efficient, but there will still be organizational impediments that get in the way of the larger objective: improving the throughput of value to the customer. Will the team be allowed to work in an Agile way? Will the business be able to adopt to the new way of working closely with the product developers? Will teams be empowered to change processes? This is where lean comes in.In the more highly-defined organization, your consulting plan must be based on multiple projects and multiple team types to discover the impediments to success.Do as much planning as necessary to get started… and no moreAlan expects to do as little planning as necessary on the highest priority issues and risks. I will work with the client to decide how we will address or mitigate the issues and risks or whether we will choose not to address them for now. Do enough planning to get started.And then set the expectation that this will be a continually evolving effort.Enjoy the show! Talk to us 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 ObjectivesLean-Agile Software DevelopmentMusic 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/