LAST_view

Notes from the LeanSSC Atlanta 2010 conference

Jim Trott — Fri, 07 May 2010 13:21:30 -0600

Notes from LeanSSC Atlanta 2010

In this show, Alan Shalloway shares his impressions from the inaugural conference of the LeanSSC which was held in Atlanta, Georgia. LeanSSC stands for the Lean Software and Systems Consortium. This is a consortium of practitioners and experts from many organizations who are committed to assisting enterprises that depend on software – from start-ups to those that build complex, software intensive products, systems & services – with the application of Lean Thinking throughout the enterprise.

The conference website is at Atlanta2010.LeanSSC.org and we are busily posting presentations and video from the conference to give you a notion of the many topics that were discussed.

The speakers at this conference were from the top notch of our industry, people who have done the hard work of bringing these good approaches to the enterprise. There was a lot of talk about what works and what doesn't work. It was great to be among like-minded people who could debate passionately about the issues but coming from a common foundation.

We talk about who was there, what was surprising, and some of the future vision that speakers shared. Amidst all the diversity was that there were common themes: respect for the knowledge of people, the importance of paying attention to key principles, maintaining a common vision.

We hope you can come to the next conference: either this this fall in Europe or next year in Los Angeles!

This is a movement. It is open and driven by a broad spectrum community of practitioners, making knowledge available to industry.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Reflections on a New Year: Part 2

Jim Trott — Wed, 17 Feb 2010 15:49:32 -0700

Reflections on a New Year: Part 2

We continue reflecting about the trends in 2010 and areas in which Net Objectives will be investing some of its energy and thought as we help to serve our partners and customers. In this podcast, we talk more about transitions: the team that is involved, how it helps to think about the entire value stream.

Introducing change requires a partnership of business, management/leadership, and the team. No one has the complete picture. All three have to be engaged to succeed. It is driven by the business. Management leads, coaches, guides. The team sees its process and applies technical skills.
The goal is to introduce change in a way that is most effective for the whole value stream. This guides you in deciding when, where to introduce what kind of change. The good news is that it doesn't have to be (only) the team that has to be the focus of change efforts.

This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Going beyond Scrum, Part 2

Jim Trott — Wed, 17 Feb 2010 15:43:18 -0700

Going beyond Scrum: Part 2

Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are taking it in two parts. Last time, we talked about the importance of optimizing the whole and taking a holistic view of the team if you want to be able to impact the enterprise. Now, we turn to two more key factors: the importance of managing your workflow and the value of accessing and using the good practices that have already been learned by others.

In the book, we touched on the idea of Kanban for Software Development and it deserves some more consideration. We also cover resources and thought leaders to pay attention to as you look toward moving beyond (classic) Scrum to the enterprise.

Kanban is an approach to managing work by focusing on the flow of work. How you organize the work - using a team-based swarming approach or a work-phase approach - is left to you; what is important is that you manage the amount of "work-in-progress" (WIP) that the team has going on at any time. And the organization manages WIP intentionally, by policy. Limiting WIP helps reduce delay. Improving the process, then, is focused on reducing anything that impedes the flow of work. That is how you choose what to improve.

Kanban is appropriate even in your Scrum practice. It is truly remarkable how well it helps to have a defined workflow and process improvement approach.

The Scrum Clinic

In our years of coaching Scrum, we have learned some good practices that every team seems to have to learn. It makes sense to learn them early rather than forcing the team to have to discover them on its own (per the classic Scrum approach). Why reinvent the wheel when there is already so much more to discover.

We pulled together essentialresources into one place, "The Scrum Clinic," which you can access for free. Each resource is small "chunk of high-leverage knowledge" that will get you going in your own use of Scrum much more quickly.

Examples include:

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Going beyond Scrum, Part 1

Jim Trott — Wed, 17 Feb 2010 15:25:10 -0700

Going beyond Scrum: Part1

Chapter 5 of the new book, Lean-Agile Software Development: Achieving Enterprise Agility, discusses "Going beyond Scrum." This is a big chapter, so we are going to take it in two parts. First, we want to consider the implications of the maturing and segmentation of the Scrum community and two key factors required for being able to scale Scrum to an enterprise: taking a systemic approach and looking at the team holistically, how it fits with and must work within the organization. Next time, we will look at kanban, managing the flow of work, and using the Scrum clinic to (reusing) good practices learned by others.

Over the last decade, the Scrum community has matured greatly. And, as often happens, it has begun to segment as people discover new, alternative paths that the founders never imagined. Sometimes, that means people move on from the original group When it comes time to investigate or add new profitable bodies of knowledge. I think that is what you see in the various Scrum,

Lean-Agile, and Kanban communities. New ways are being explored. Clearly, there have been situations and teams where classic Scrum worked very beautifully and helped create a lot of value for an organization. It seems that that population has mostly been mined, that that market has been pretty much saturated. Going forward, there is a need to be able to help teams and organizations where more is needed, where classic Scrum, by itself, is just not enough.

This chapter touches on two key understandings or beliefs that are required to be able to go beyond (classic) Scrum. One is that you can (indeed must) take a systematic approach. The other is that a team-centric focus is not sufficient.

A sytematic approach. One of the new approaches (which is not really new but reaches back to solid principles) tries to take a more systems-thinking approach, thinking along with Don Reinertsen that productivity comes by looking at PEOPLE X PROCESS. That is, the whole system - people and process - works together and neither can be ignored. Lean calls this "optimize the whole."

Thus, as we have gained experience with Scrum - and especially as we have begun to incorporate it with other disciplines such as Lean, Test-Driven, patterns, and the like, we are learning what behaviors and patterns teams need to be effective and what processes help them. And once learned, why not use them again and again rather than forcing each team to have to discover them again on their own? That is part of the driving force behind this chapter and this book.
A holistic view of the team. The second thing is to look beyond the individual team to how how they must interact with each other.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Reflections on a New Year: Part 1

Jim Trott — Tue, 19 Jan 2010 00:00:00 -0700

Reflections on a New Year: Part 1

The beginning of the year is a natural time to think about what is coming in the year. Alan Shalloway shares his thoughts about some of the areas in which Net Objectives will be investing its energy and thought as we help to serve our partners and customers. In addition to our normal areas of training and coaching in Lean, Agile, acceptance test-driven development, design patterns, and process improvement. But what else? In this podcast, Alan and I talk about two key areas where we are going to be investing our energy: Kanban and what it takes to help enterprises and teams make the transition.

Kanban. We believe in Kanban for software development. We have joined with David Anderson and others to help foster the community of those who want to explore how to use this, the good practices, the deep principles - you might call it the "science" of kanban software engineering. What it takes to realize the tremendous potential benefit of this approach.

Two key communities to look into are the http://www.limitedwipsociety.org/ in the UK and the LeanSSC.org, which is more worldwide.
Transition. How to help enterprises and teams make the transition, the change to greater productivity in software development: managing the introduction of change to be productivity

What prompted this was a training class with David Anderson of D.J. Anderson Associates. David is a leading expert in Kanban as applied to software engineering. I recommend his course for anyone who wants to sharpen skills in coaching kanban because he has seen it all.

This is a break in the walk-through of Lean-Agile Software Development: Achieving Enterprise Agility. We will turn back to it in mid-February.

Recommendations

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com/ and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Introducing Kanban for Software

Jim Trott — Mon, 21 Dec 2009 18:46:03 -0700

Introducing Kanban for Software

Phil Cave is a new consultant with Net Objectives. Phil has a long history with Lean, XP, Scrum, and Kanban. He has worked at all levels: developer, lead, manager, division manager, vice-president, Lean coach. Phil just got back from Krackow, teaching our Lean Software Development course. Half of this course involved helping them integrate the Kanban technique into their Lean-Agile software methodology. Kanban is gaining ground as an important technique for Lean-Agile groups because it is widely applicable in both process-oriented and specialty-oriented shops. It does not require fundamental shifts in work (unlike other Agile methods) if that is not appropriate for you. It is something we need to learn more about.

Here at the end of the year, I want to express how grateful I am for you. I hope you have a blessed holiday and a warm new year. I look forward to being with you again in January.

Recommendations

Lean Software and Systems Consortium: www.leanssc.org

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Chapter 4 - Lean Portfolio Management

Jim Trott — Mon, 09 Nov 2009 16:08:33 -0700

Chapter 4: Lean Portfolio Management

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 4, Lean Portfolio Management. The premise is that managing the work you are feeding the team is more important than how well the team works.

What you want is for the business to drive small increments, giving the development team just enough to get value out at a sustainable pace. It is possible to do a better job planning! There are many techniques and that is the subject of another book. However, just knowing about shorter planning increments does help. Smaller, well-defined things running through the pipeline is better than big batches that clog things up.

There is another benefit. We build these big project plans and even though we know they won't work as laid out, they seem to take a life of their own. If someone proposes a change request, it is a huge effort because those plans are so cumbersome. Lean portfolio management cuts through all of this! Since we are planning in shorter cycles, if a new change comes through, we just compare it with all of the other requirements in the next cycle and insert it if has higher business value. Those change boards - so bedeviling - become a thing of the past.

About Lean-Agile Software Development: Achieving Enterprise Agility

The motivation of this book is to create a bigger picture what teams transitioning to agile need to do. Yes, teams need to understand the mechanics of the approach to get working, but there is more. Management needs to understand how to help teams work together. Business leadership prioritizing the right things to be working on. And there is a need to ensure technical quality so that development can be done in a sustainable way.

We also want to introduce Lean and how it applies to the transition. We don't believe "scaling up" is a very effective approach. Rather, taking a more holistic view is needed to get success. That is how Lean thinking helps.

This is not a book for experienced practitioners but for those who are picking Agile, Scrum, or Lean for software development. We expect you do understand a bit about Agile but not anything about Lean.

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Chapter 3 - The Big Picture

Jim Trott — Mon, 09 Nov 2009 13:12:21 -0700

Chapter 3: The Big Picture

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 3, The Big Picture. We talk about why, if you want to see improvements in throughput in product development, it is vital to focus on the entire value stream, the entire process from when an idea is formed until it reaches the user or customer. In fact, a transition to Lean-Agile involves agility in at least four areas.

It is not enough just to focus on helping developers. In order to see improvements in the throughput for product development, you have to look at the whole value stream: the entire process from when an idea is formed until it reaches the user or customer. You want to focus not on where you are spending your money but where you are spending your time. And this means looking at the time you spend waiting as well. Keeping people busy can be counter-productive if it keeps them from being available on the most important things. Think of it this way: What is the impact if projects are having to wait on the most productive, highest value people just because they are working on too many things?

Agile coaches often have a technical background. This means that too often, Agile deployments focus chiefly on helping developers. This is good and necessary but it is not sufficient. If delays are being caused elsewhere, then improving development will only offer marginal gains. When you are transitioning, you have to look at improving agility in four areas:

Team agility
Technical agility
Management agility
Business agility

Of course, where to start depends on your situation.

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Chapter 2 - The Business Case for Agility

Jim Trott — Mon, 09 Nov 2009 12:20:45 -0700

Chapter 2: The Business Case for Agility

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 2, The Business Case for Agility. We cover the five most important reasons for going Agile and how it is that understanding the whys of Agile helps you with this transition.

It is important to understand the reasons for going Agile. Perhaps as important is understanding the whys of Agile: It helps you navigate your journey as you make the transition. Here are five of the most important reasons for going Agile:

Deliver value quicker.
Getting to market quicker is good. It is often possible to deliver some important features in stages. It allows faster return with less investment and that is always good!
Helping customers discover what it is they need.
Agile is best understood as a process that helps customers and developers discover in stages what it is that software should do. It helps customers focus on specifying what they know and avoid having to guess about requirements that they are not yet sure of. The most important book that covers this is Software by Numbers by Denne and Clelland-Huang.
Better project management.
Waterfall tends to steer projects based on milestones, which is an inaccurate guide about where a project really is. Agile steers based on working code which is much more accurate.
Improving process faster.
It would be better if teams learned continually but at least Lean-Agile has them learn after each iteration. Short iterations let teams learn quickly what is working and what is not. It is much better to learn lessons after two weeks rather than after two months!
Letting your design emerge based on what you are learning.
While it is often ignored, there is also a technical reason for going Agile. With some discipline and appropriate tools (automated regression testing), it is possible to avoid up front design (almost always wrong or incomplete) and allow design to emerge based on what the team is discovering. This is powerful. There are two good books that describe why this is so:

- Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
- Agile Software Development, Principles, Patterns, and Practices by Bob Martin

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

Chapter 1: A Developer's Guide to Lean Software Development

Jim Trott — Sun, 01 Nov 2009 09:07:48 -0700

Chapter 1: A Developer's Guide to Lean Software Development

This show continues a chapter by chapter discussion about the new book, Lean-Agile Software Development: Achieving Enterprise Agility, by Alan Shalloway, Guy Beaver, and Jim Trott.

This show focuses on Chapter 1, A Developers Guide ot Lean Software Development. We start to answer the question, if Lean's goal is to focus on speed, quality, and low cost. How do you do it?

In the past, the approach has been to try to make every step and every person as efficient as possible. THat doesn't work. Instead, you have to look at optimizing the whole process. It is different than efficiency and cost; in fact, lowering cost can increase speed to market and lower quality.

Lean says the better approach is to focus on removing delays.

We want to focus on the time between the idea is conceived until the customer can consume it. This involves realizing that product development is a conversation between developers and customers to discover what is required. Cusotmers don't always know what they need. As much as possible, you want your process to improve the learning and feedback that is taking place so that customers can focus on what they really need.

What is needed? Focus on removing delays, removing waste in the overall process. For example,

Get feedback from the customer quickly.
Write tests first. Then you immediately discover when bugs appear.
Detect integration issues quickly.

The bottomline is that We want to make value flow through the organization quickly and remove anything that causes delay.

Finally, practices change depending on the context. How do you know the practices you are doing are good? By comparing them with the foundation lean principles. Teams have both responsibility and guidance for their work. That is the perspective they need.

About Lean-Agile Software Development: Achieving Enterprise Agility

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

Music used in this podcast is by Bill Cushman at http://ghostnotes.blogspot.com and Kevin McLeod: http://www.incompetech.com/. If you need music, I’d encourage you to subscribe to their feeds.

An Overview of Two New Books

Jim Trott — Mon, 12 Oct 2009 13:40:06 -0600

An Overview of Two New Books

In this show, we give overviews of two new books by Net Objectives which we think you will find helpful: The Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We talk through both of these books: their motivation, their contents, why they are useful. In the next podcast, we will talk about the key ideas in each chapter by chapter of Lean-Agile Software Development, the ideas we have found is truly needed in order to be able to achieve enterprise agility.

The Lean-Agile Pocket Guide for Scrum Teams

The Pocket Guide fills the gap between one of those 10 page ("marketing") overviews of Scrum and the thousands of pages that have been written on various good Scrum practices.

In our work, we found there was a need for a concise statement of what scrum is and a convenient distillation of the best practices. It also includes some techniques not traditionally taught in Scrum but which are very helpful. In 200 pages, it is a great tool to remind you what needs to happen from beginning to end of product development. Lots of checklists and templates to help you think.

Some of our clients have found this tool so helpful that they have created a "private label" version of the pocket guide for their own use. It served as a baseline for their own process. And we are willing to do that with others. If you are interested in this for yourself, drop us a note.

For more information see the resource page for the pocket guide.

Lean-Agile Software Development

For more information see the resource page for the book.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, visit us at http://www.netobjectives.com/

A New Series

Jim Trott — Mon, 28 Sep 2009 16:04:39 -0600

A New Series

This podcast kicks off a new series for Lean Agile Straight Talk. We have been busy finishing several books focused on Lean-Agile. One is called the Lean-Agile Pocket Guide for Scrum Teams and another is Lean-Agile Software Development: Achieving Enterprise Agility. We are proud of both of these books and wanted to introduce them to you. In this show, Alan Shalloway and I talk about the motivations behind these books, what is going in in the world of Lean and Agile software development and why they are needed. The next show will give a rundown of the pocket guide. After that, we will talk through each of the chapters in Lean-Agile Software Development. Each of these chapters has good, core concepts that we want you to know and this approach gives us a game plan for covering all of them.

Each of the books Net Objectives offers aims to address the question, "What do people need to know to succed in their role to do product development?" In a nutshell, we describe Lean-Agile with the phrase, Make-Value-Flow-Sustainably.

Make. How do developers create software at the team-level. In the past, "making" was where the challenges were.
Value. What does the business need? How do we get them to drive what really needs to get done?
Flow. How do you get what multiple teams create to flow through the organization. Learning to work together, coordinating work.
Sustainably. How do keep writing code so that it is always of sufficient quality? So that we do not keep incurring technical debt. And ow do keep the organization growing in a healty way so that it can continue to do the work.

Even if you find a technique, such as Scrum, that works well at a team-level, it does not always work in every context. And, we have learned that trying to "scale" Scrum to the enterprise is not the correct approach to achieve enterprise agility. Understanding the principles helps you know what to do when confronting situations you have not yet encountered. And that leads to proficiency in this field.

Recommendations

Lean-Agile Software Development: Achieving Enterprise Agility by Alan Shalloway, Guy Beaver, and James R Trott
The Lean-Agile Pocket Guide for Scrum Teams by Alan Shalloway and James R Trott
Emergent Design: The Evolutionary Nature of Professional Software Development by Scott Bain
Design Patterns Explained by Alan Shalloway and James R Trott

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Redefining Lean

Jim Trott — Fri, 22 May 2009 14:48:24 -0600

Redefining Lean

Lean Software Development is founded on Lean. But what is "Lean"? Some have said that "lean is just what Toyota does." That is not much of a definition and is not even accurate, although Toyota does do Lean. It is also not accurate to say that Lean is focused on manufacturing, although Lean is now widely used in manufacturing.Lean is not even principally about physical product even though most of the examples of Lean are in the physical world.

No. It is better to see Toyota manufacturion and Toyota product development as just examples, as manifestations of this way of thinking we call Lean. Here is one good way to think about what is going in in Lean: There is Lean Science, Lean Management, and Lean Knowledge Stewardship.

Lean Science: There are rules and principles that are present, observable, can be used to make predictions, and we can adapt and learn based on what we test and observe. The most flexible approach is to understand the Why that is behind the practices. This is how Don Reinertsen has helped us, identifying the fundamental rules.
Lean Management: How to help the organization take adavantage of the science and how to remove the problems people have.
The manager is involved, neither hands-off nor command-and-control. Manager's role is education, helping people know how to think, how to see problems and how to think about the system, and also to set direction. Using visual controls helps managers see when process is going awry and there is a need to intervene, when to educate.
- Note: Jim Womack underscores this in his webinar, The Role of Leadership in Lean
Lean Knowledge Stewardship: How to discover, share, adapt, apply, and take care of the knowledge we have in the organization. There are techniques such as A3, Kaizen, AAR/Retrospection, Root Cause and 5 Whys, Value Stream Maps,

Make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com

Recommendations

By Don Reinertsen
- The Principles of Product Development Flow: Second Generation Lean Product Development
- Managing the Design Factory
By Corey Ladas
- Scrum-ban

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Report from Lean Kanban 2009

Jim Trott — Mon, 11 May 2009 16:07:03 -0600

Report from Lean Kanban 2009

Kanban is an emerging practice in Lean software development. Founded on solid principles of flow and utilization theory, it seems to address many of the issues people have had with Agile approaches. Over the next few years, Lean Kanban is going to become an important part of the software professional's toolkit.

The Lean Kanban Conference 2009, May 6-9, 2009 in Miame, brought together practitioners and thought leaders to discuss how to help the community go forward. This podcast is a report by Alan Shalloway about what he, Guy Beaver, and Alan Chedalawada (all from Net Objectives) learned from this special event.

Over the next few weeks, Alan will be posting some blogs about what he learned at the conference. See blogs.netobjectives.com. It will be the topic of several upcoming podcasts on Lean-Agile Straight Talk.

You can learn more about this conference at www.leankanbanconference.com/

And make your plans now to attend the UK Lean Kanban conference in September. For information, see www.ukleanconference.com

Recommendations

By Don Reinertsen
- The Principles of Product Development Flow: Second Generation Lean Product Development
- Managing the Design Factory
By Corey Ladas
- Scrum-ban

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Three Things You Gotta Know

Jim Trott — Fri, 27 Mar 2009 23:18:26 -0600

Three Things You Gotta Know

Lean is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations. It can feel overwhelming. It is rich and there are many, many techniques and practices. It is always growing as it absorbs more good practices. That's why people can make careers out of Lean.

But you don't have to know all of Lean before you can get started. And you don't have to even be committed to becoming Lean to get the benefit from using Lean a little. In this show, Alan Shalloway discusses some of the essentials that you do need to know in order to get started.

The things you have to know about Lean include:

Look at TIME not Resource Utilization. In mass production, you are trying to minimize the resources expended per unit of work. In Lean, you are trying to minimize the time it takes for the Idea to turn into something that returns value to the organization from using it (using it in the business or selling it).
Errors usually arise from defects in a system, not poorly performing people. We don't aim for blame but we do aim for deep understanding about what happened.
Management plays an important part in process improvement The proper role for management is neither command-and-control nor should be teams be "protected" or isolated from management. Rather, management is responsible for helping the team to see and how to think. They ask intelligent questions, question them when they are not following process, help them drive to how to solutions.
Management creates the context within which problems can be addressed.

Recommendations

The Role of Leadership in Lean (by Jim Womack and the LEI)
Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio.

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Getting to the Benefit

Jim Trott — Wed, 18 Mar 2009 13:43:11 -0600

Getting to the Benefits

It has been estimated that 75% of companies undertaking Scrum are not experiencing the benefits they expected. Why do you suppose this is? Why don't we take time to stop, observe, and improve our processes? Why is lean perhaps a more natural starting point for the enterprise?

These are some of the questions explored by Alan Shalloway in today's podcast.

But first, Alan invites you to come to the Lean Kanban 2009 conference in Miami May 6-8, 2009. Join David Anderson, Josh Kerievski, Peter Middleton, Alan Shalloway, and other industry thought leaders as we consider together the next wave of software management and leadership. It offers the chance to interact in a small attendee/speaker ratio. It promises to be a powerful time. To learn more, visit the Kanban Dev Yahoo user group.

Why aren't organizations manifesting the promise of Scrum?

Ken Schwaeber says that 75% of companies who try Scrum do not manifest the problems of Scrum. This means that they do not get the benefits they thought they would. Why not?

Scrum is a lightweight methodology that exposes impediemnts so you can fix them. Too often, rather than fixing them, teams just accomodate the impediments. and that is a problem. Why do teams do that? They are beset by the tyrrany of the urgent. By the time they have time to reflect, the next problem is there and they have to move on. They just don't have time to stop!

Why don't they stop to look? Because they are starting at the wrong end: at the team-level and then think about how to "scale up" and that is hard to do. It just leads to increasing levels of complexity. How much better it is to start with something that begins at the enterprise level

The benefit of Lean is that it offers a better starting point. People don't talk about scaling up Lean because Lean already starts at the enterprise level. That is its natural environment.

We think of Lean this way:

It is a pragmatic framework for absorbing principles and practices that other people have learned and putting them to work in large organizations.

You could see Lean as having absorbed Agile/Scrum practices into the Lean way of thinking (as well as seeing Scrum as manifesting Lean principles to the specific context of teams creating software). What matters is not where the practices came from but rather that they come into the enterprise in a way that lets them be put to work broadly: Testing it in concrete work, improving it with basic lean principles as needed, tossing it if it doesn't work.

Recommendations

Lean Kanban 2009 conference in Miami May 6-8, 2009.

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Managing Multiple Team Projects in VSTS

Rod Claar — Thu, 13 Nov 2008 12:22:10 -0700

Managing Multiple Team Projects in VSTS (audio of the webinar)

Many Agile/Scrum projects have more than one team, but few Microsoft Visual Studio Team System (tm) Process Templates address the issues of managing multiple teams pulling from the same product backlog. The Implementing Agile Development process template provides the data, reporting and team communication features to manage the multiple team project successfully.

On October 16, Rod Claar gave a webinar discussing how to manage multiple team projects using VSTS. He discussed and demonstrated the following features of the IAD process template.

Work Item Support for multiple teams.
Team communication features including the Agile Team SharePoint sub-site and the Agile Team blog feature.
Agile Team reporting.

The webinar also provides basic information of how to download and install the IAD process template.

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

Note: This webinar is close to an hour long, so the files are large.

An Overview of Lean-Agile Software Development

alshall — Fri, 03 Oct 2008 11:19:18 -0600

An Overview of Lean - Agile Software Development

Since 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 Objectives

Recommendations - Reading

Lean Software Development: An Agile Toolkit for Software Development Managers by Mary Poppendieck and Tom Poppendieck
Product Development for the Lean Enterprise: Why Toyota's System Is Four Times More Productive and How You Can Implement It by Michael N. Kennedy
Design Patterns Explained : A New Perspective on Object-Oriented Design (2nd Edition) (Software Patterns Series) by Alan Shalloway and James Trott
Agile Project Management with Scrum by Ken Schwaber and Mike Beedle

Music used in this podcast:

“Pizzaman” and “Chocolate” ©2006 William Cushman: ghostnotes.blogspot.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Scrum and Management: Planning and Focusing

alshall — Tue, 23 Sep 2008 14:36:20 -0600

Scrum and Management: Planning and Focusing

Over the last several years, teams of developers have been trying Agile and getting success at their level. Now, management is getting engaged, both to figure out how to do this across divisions and the enterprise, as well as how to do a better job in less-than-simple situations that most enterprises face.

There have been notable examples where things did not go as well as expected when teams face complexity, where the fit is not exactly good, where maybe the initial approach taken was just too simplistic. It is management's job to help teams look at ways to improve.

This is why at conferences, we are encountering more and more mid-level managers. And they are asking very different sorts of questions than technical, development teams ask. This is stimulating and exciting. Clearly, Agile is beginning to enter the mainstream as a better way to manage software product development.

In this podcast, we will touch on two topics Alan that are concerns for management: Release Planning and Focus.

Release Planning

For example, one of Alan's talks at SQE focused on User Stories. Now, typically, developers want to know about how to use User Stories to write features and code. Managers, on the otherhand, ask questions about how to get User Stories in the first place, how to manage them, how to use them to create more business value.

This is a great question. It comes from the perspective about why we are doing something rather than what we are doing next.
Our approach, which is covered in our Agile Analysis course, uses Minimally Releasable Feature Sets.

Here is an example. Suppose you are embedding graphic presentation of data streams on a web page and your customer is very particular about how the graphics look.

Looking just at features, you might specify a releasable feature is that you provide a histogram, which is a useful type of chart. A second releasable feature might be a pie chart. Another might be choosing colors. And so forth.
Each of these features might involve many stories.

The question is what is the minimal set of releasable features required before giving it to the customer? From a technical standpoint, you might want to have them all done first. It feels less risky, technically, and may make for a greater initial spalsh in the market. But what if, instead, you provided a basic histogram that let the customer validate the entire data collection and display process and the rough placement on the web page? And, with that basic system, they could begin showing it to early adopters in the marketplace and thus begin to establish market penetration?

Which option provides the most business value? How would you feel if you targeted release of all of the features in 6 months only to find that your competition promised to release half of the features in 3 months with the rest of the features in another 3 months. Would that put you at a competitive disadvantage?

There might be good arguments for various alternatives. The point is that as a product development team, you need to have the conversation and not make assumptions. The outcome of your conversation will be the minimal set of features required for a release.And then you can still talk about how you will package the features into the final release to the customer.

This bringing the business perspective to Agile release planning is a needed corrective to what many Scrum teams do. Too often, they dive right into stories and then try to coordinate with Epics and Themes. This local team approach is, perhaps, too narrow of a perspective; it cannot address the portfolio of products that the business needs to be working on.

Iteration Planning

Now, it is different when it comes to planning an iteration. Now that you have specified the minimal set of features that will go into the release, you are not constrained to work on one feature and then another. You are not required to work according to adding business value iteration by iteration (remember, business value comes with releases, not with iterations). Instead, you select work from across the set of features, doing whatever is required for the team (or teams) to make progress toward the release goal. Your selection criteria is based on other sorts of factors, such as:

maximizing feedback
mitigating risk through architecture
mitigating risk of teams working together
minimizing contention for resources

This is consistent with the Lean notion of "optimize the whole."

The Right Focus

One of our customers is a defense contractor, making missile systems. In one of my classes, I asked the students what theyre responsibilty was. One bright student piped up, "we are responsible for making missiles perform reliably. They need to launch when they are supposed to launch and not launch when they are not supposed to. They are supposed to follow the proper flight plan to the right target and then go off when they are supposed to go off. That is our responsibility."

Exactly right!

As software developers, we are responsible for the larger picture. Writing software is part of what we do to fulfill that responsibility.

Naive implementations of Scrum attempt to protect teams from management. This is sad because too often, teams quickly end up focusing on local issues. One of management's jobs is to help teams figure out where best to focus. The proper and more powerful uses of Scrum is when management and teams are working together.

Recommendations

Training by Net Objectives

Agile Analysis

Reading

Software by the Numbers by Mary Denne and Jane Cleland-Huang
Creating a Lean Culture by David Mann

Music used in this podcast by Kevin McLeod at www.incompetch.com

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com

Avoiding Coupling and Using Mocks (Webinar)

alshall — Tue, 23 Sep 2008 13:29:53 -0600

Avoiding Coupling and Using Mocks (audio of the webinar)

A webinar on September 02, 2008 presented by Alan Shalloway discusses how, in Agile projects, neither full up-front designs nor no design proper. This webinar discusses some techniques for decoupling modules early on. In other words, although we may not know how things will change, we often know of dependencies between modules that will morph over time. He presents three case studies:

Decoupling informational dependencies between components
How to define the API for a component being built by one group and used by another
Using mocks to never be blocked - avoiding delays caused by dependencies of different tiers

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Understanding Why Scrum Works (Webinar)

Jim Trott — Tue, 23 Sep 2008 13:25:39 -0600

Understanding Why Scrum Works (audio of the webinar)

A webinar on September 02, 2008 presented by Alan Shalloway discusses why Scrum works and how Lean's metaphor of Fast-Flexible-Flow can be used to modify standard Scrum practices as needed. Additionally, Scrum#'s enterprise view and Lean Management philosophy will be the basis for creating an Enterprise/Organization wide team to manage dependencies across teams without command and control. This webinar covers:

Why Scrum works
How Lean-Thinking can identify root cause of problems
How to use Lean-Thinking to eliminate delays
Breaking down the silos between development and Quality Assurance
How to coordinate multiple development teams so that they work together - going beyond Scrum-of-Scrums

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Database Agility

Jim Trott — Tue, 23 Sep 2008 13:12:51 -0600

Database Agility

Databases are central to almost any software development project of any size. Developers have been gaining big improvements as they adopt Agile approaches: higher quality, more satisfaction, delivering more value to customers. It seems time for database developers to begin to experience the same gains!

But database development is special. It is not like just copying new bits into the environment. Databases need to retain their identity and the data that are in them. They have history and investment and must survive. Transitioning change is much harder and requires more care.

Is it possible to use iterative, Agile approaches with databases?

Yes it is. This podcast describes the landscape for doing so. Early adopters of this approach have learned the key principles involved and tools for testing and transition management are now available. Training is also available to equip teams with the new skills and ways of thinking that are required in order to be successful.

This podcast features a conversation with Max Guernsey, an associate trainer with Net Objectives. He has been developing professionally for 10 years and been consulting in Agile database development for the last year. He has turned this expertise into a course - really an on-site, practical bootcamp - to help teams successfully incorprate this approach into their development practice. It is called the TDD Database Boot Camp.

As you might expect, Test-Driven Development (TDD) is going to be as central to this approach as it is to Agile development in general. The trick is to see what what this means in the database world. As Max touches on in this podcast, it goes beyond UAT and unit to focus on testing how the database is changing. "Transition Testing" is a major part of the course.

This involves a new way of thinking about how databases are expressed: You want to design and develop based on transitions in the database.

About the Boot Camp

In this podcast, Max gives a quick overview of the TDD Database Boot Camp. Its goals are:

Teach the principles of database agility
Teach technologies that facilitate this approach. We help the team create the environment they will require including:
- Test suites, transition tests
- DataConstructor. Every team receives a 10 user license for DataConstructor, a tool by Hexagon Software. This tool works with NUnit, JUnit, TFS, etc to implement the suites of tests focused on transitions (see Features of DataConstructor). It makes it possible to have live data version control.
Focus on problems that the team is facing now

The boot camp is designed to be an on-site course so that conversations can be confidential and frank, (which is required with database work). It is best if the whole team takes the course - developers, QA, Scrum Master.

Recommendations - Online Resources

Scott Ambler's website: www.agiledata.org
Max Guernsey's Rethinking Agility in Databases
DataConstructor, a tool by Hexagon Software

Recommendations - Training by Net Objectives

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Present and the Possible in Software Development

Jim Trott — Tue, 23 Sep 2008 13:11:36 -0600

The Present and the Possible

There is a gap between what is possible and what is present - what is done - in the software industry. How much time and effort is wasted, how much re-inventing and re-discovery is done because we don't always understand the hard won insights from the past about what is required to create quality, sustainable product? How many companies have not realized the success of process improvements, like Agile, because they have not really understood its principles?

This gap, and the pain and waste it causes, is frustrating. Closing the gap involves a little re-orientation, becoming intentional to learn and try and adjust, to improve continually. To become more professional.

Professionals strive to build on the learnings of others. They avoid taking unnecessary shortcuts, especially when that could harm the product over the long term (imagine what would happen to the civil engineer who kludges together something for the last 2 feet of a bridge just to get it finished up or just to try some new, cool idea). They follow the best practices in how we develop and manage people, in the processes and methods we use, and in the proper way to use tools and technologies.

Laws of the Wood

Professional carpenters know that there are certain "laws of the wood" that they must follow in order to build products that will endure and to build them efficiently and profitably. For example, cross-cutting across the grain give you one kind of cut and cutting with the grain is very different. They are basic laws or principles that must be followed to avoid wasted effort, wasted wood, designs that fail.

We have our own "Laws of the Wood." For example, there are design principles such as the Dependency Inversion Principle, the Open-Closed Principle, the Liskov Substitution Principle (all things that we have written about in Design Patterns Explained). Failing to work within these laws, principles, forces, leads to wasted effort, products that cannot be maintained, designs that fail.

Bob Martin has been advocating this for a long time, calling software developers to become "craftsmen." While Alan uses the term "professional" to describe this, he is in "violent agreement" with Bob and his intent.

It is time for us to raise the bar in terms of how we are building software.

But what about creativity? We don't like to be constrained as developers. Far from taking away creativity, cooperating with these laws and principles allows creativity to flourish. It helps reduce the complexity in what is surely one of the most complex of human endeavors so that what we do create has the greatest chance of succeeding. In the 1960's, NASA put a man on the moon. They cooperated with their "laws of the wood" (e.g. gravity) to create solutions to an amazing array of problems to create a thing of beauty. The laws give us parameters and boundaries within which to be innovative and get problems solved.

If you don't follow the laws, principles, you just won't be as effective.

The Long Journey

Why don't people follow the laws of development?

They don't understand the implications of not following the laws...
They feel time pressures: feel a need for a short cut now.
They fall back into old habits,

Sadly, these short cuts don't always give longer term gain... and if they understood the principles better, the good practices approach is just as efficient as those "short cuts."

It is natural. And change is going to involve taking what Gemba Panta Rei and Toyota calls the "long path".

What this means is that we adopt a mindset to make progressive improvement, learning as we go and adjusting our thinking as we discover what does or does not work. Constantly, intentionally perfecting what we do, sometimes in small steps that take us down the right path.

The good newes is that, at some level, many developers do know - or almost know - many of these good practices. They may be buried in our intuition, but at least they are not foreign to us. Sometimes, it is just a matter of surfacing these so that we are conscious about them. And that helps shift our thinking.

The long path involves shifting our thinking at all levels: as individuals, as teams, and organizationally.

The further along we go, the closer we are going to get.The higher we are going to raise the bar on our work. The more satisfying our work will become. The more our customers will realize value from the work we do.

Avoiding Over- and Under-Design in Agile Projects (Webinar)

Jim Trott — Wed, 20 Aug 2008 10:40:54 -0600

Avoiding Over- and Under-Design in Agile Projects (audio of the webinar)

A webinar on August 18, 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 change

The 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 better

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Managing Requirements in Agile Projects with Scrum Sharp (Webinar)

Jim Trott — Wed, 20 Aug 2008 10:33:41 -0600

Managing Requirements in Agile Projects with Scrum Sharp (audio of the webinar)

A webinar on August 18, 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 backlog

The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

Lean-Agile in Tough Times

Jim Trott — Mon, 28 Jul 2008 19:11:40 -0600

Lean-Agile in Tough Times

In 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 Resources

The TOWS Matrix - Going beyond SWOT Analysis (MindTools)

Recommendations - Training by Net Objectives

Lean Software Development for Management

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Design Patterns in an Agile Environment (Webinar)

Jim Trott — Sat, 26 Jul 2008 15:33:07 -0600

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 podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

This 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 (Webinar)

Jim Trott — Sat, 26 Jul 2008 14:51:51 -0600

Scaling Scrum to the Enterprise with Lean Software Development (audio of the webinar)

Scrum# is an extension to Scrum that was developed by Net Objectives to solve challenges that were being encountered by many teams adopting Scrum. Read about more about the issues which Scrum# was created to solve. A webinar on July 21, 2008 presented by Alan Shalloway presents a broad stroke of Scrum#. It gives a high view of the process and analysis extensions of Scrum#. The webinar is available to registered users of the Net Objectives website for 30 days and to Net Objectives customers always. However, you can still download:

The audio track of the presentation as a podcast
A (lower resolution) iPod Video that you can watch on your iPod or in iTunes

Note: This webinar is close to an hour long, so the files are large.

Attend other sessions in the Scrum# Webinar series.

The ideas and strategies introduced in this webinar are also being explored in a book which is currently being written by Alan Shalloway, Jim Trott with contributions from other Net Objectives consultants. Learn more about the book and read selected chapters.

Coming Up at Agile 2008

Jim Trott — Fri, 25 Jul 2008 19:23:28 -0600

Coming Up at Agile 2008

Once again, Net Objectives is a co-sponsor of the Agile 2008 conference. This is a premier gathering for people and organizations involved in Agile software development. This year, it is being held in Toronto, Canada, August 4-8. Every year, we devote a podcast to what Net Objectives is doing at Agile 2008, both to help people who are going know what we are up to and to help people who cannot go know what trends we see that are important, where we will be devoting energy.

In this show, Alan Shalloway covers five primary topics:

Why we are involved with the Agile conferences and why they are important for the industry
The Certification by Net Objectives program, which was announced at Agile 2007, including: Scrum Master Certification, Scrum Team Member Certification, and Product Owner Certification
The announcement of the Implementing Agile Development using Microsoft Visual Studio process template, which has just been completed by Net Objectives
An announcement of Scrum#, which is an extension of Scrum that helps to integrate Lean thinking, Scrum/Agile practices, and Emergent Design practices (patterns and test-driven development).
The Talks that Net Objectives will be giving at Agile 2008

The Net Objectives Talks at Agile 2008 include:

Introduction to Lean software Development by Alan Shalloway
Distributed Teams by Ken Pugh
A Half Day workshop on Value Stream Mapping by Alan Shalloway
Two Open Spaces every day, facilitated by Guy Beaver, Ken Pugh, and Alan Shalloway

Recommendations - Training by Net Objectives

Recommendations - Webinar Series by Net Objectives

Three-part webinar series on Scrum#

Music used in this podcast

For more information, contact info@netobjectives.com or visit us at http://www.netobjectives.com/

Test-Driven Development and Design Patterns

Jim Trott — Thu, 12 Jun 2008 00:00:00 -0600

Test-Driven Development and Design Patterns

Last month, in my conversation with Scott Bain on Impediments to TDD, I wanted to explore how he was incorporating TDD and Design Patterns, two areas of particular expertise for Scott. That is the topic of today's conversation.

Scott has been thinking deeply about patterns for many years and his perspective on TDD and patterns are based on the special insights he has developed - insights that are covered in the Design Patterns Explained course he teaches. What he says goes well beyond the normal way in which patterns are described. As you will hear, we came up with some delightful surprises during our talk together

Embracing Change

In this conversation, we cover how TDD is like design patterns. Both deal with change, something that is always with us in product development. Our natural 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.netobjectives.com/PatternRepository/ and invites your insights, comments, and additions.

How to Learn this Way of Thinking with Patterns and Testing

This is affecting the way Scott teaches Design Patterns Explained and Test-Driven Development, but not in the way I would have thought. DPE is very focused on helping people understand what patterns are. There is usually a lot of unlearning/re-learning that has to take place. This means that the course is almost entirely consumed by the pattern-specific training. The same is true for the TDD course. The Emergent Design book that is out now and the course that will be coming will serve as the bridge between them, talking about how they interact, how this allows for evolutionary design.

If you want to get good at this, is it better to start with TDD or with DPE, given that you really should know both? In Scott's opinion, it is best to start with DPE because it gives you the essential thinking framework that then equips you for the practical TDD instruction. What seems to work best is to take them with just a one week gap in between. In his experience, this makes for a solid performer on the back 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 Objectives

Design, Testing and Programming

Recommendations - Reading and Resources

Music used in this podcast:

For more information, contact info@netobjectives.com or visit us at www.netobjectives.com