Lean Agile Straight Talk podcast

Redefining Lean

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Fri, 22 May 2009 14:48:24 -0600

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@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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)

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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

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

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

Present and the Possible in Software Development

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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.

Recommendations - Online Resources

Gemba Panta Rei blog

Recommendations - Training by Net Objectives

Design Patterns for Agile Developers

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/

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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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

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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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@netobjectives.com (Jim.Trott@netobjectives.com) — 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

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

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

Test-Driven Development and Design Patterns

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — 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:

“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: The Evolutionary Nature of Professional Software Development (webinar)

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Fri, 23 May 2008 17:58:24 -0600

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 iTunes

Note: 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 Development

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Mon, 12 May 2008 14:57:54 -0600

Overcoming Impediments to Test-Driven Development

Recently, 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 adoption

Before 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 productive
Developers know their code too well and cannot write tests well
Testing before coding seems nonsensical

Impediments after adoption

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

Overcoming these Impediments

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

Design, Testing and Programming

Recommendations - Reading and Resources

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

Post-Agile Scrum: The Need for Lean Software Development (webinar)

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Fri, 14 Mar 2008 12:30:42 -0600

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 iTunes

Caution: This webinar is 61 minutes long, so the files are large

Emergent Design: The Evolutionary Nature of Professional Software Development (webinar)

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Thu, 13 Dec 2007 19:38:33 -0700

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 December 11, 2007 . 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 58 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.

Enterprise Agility

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Fri, 12 Oct 2007 14:53:27 -0600

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 Points

Chances 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 SIPOC

When 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!

Recommendations

Web

Challenging Why (Not If) Scrum Works by Alan Shalloway - in Agile Journal or original blog entry

Books

Creating a Lean Culture: Tools to Sustain Lean Conversions by David Mann
The Leader's Handbook: Making Things Happen, Getting Things Done by Peter R. Scholtes

Training by Net Objectives

Lean Training Courses

Music 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

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Mon, 13 Aug 2007 02:00:00 -0600

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 covers
The motivation behind this program
Why the industry needs certification in Scrum
What we mean by “certification”
What certification will involve
When it will be ready

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

This is sure to be talked about and I welcome your thoughts. Drop me a line jim.trott@netobjectives.com

Enjoy the show!

Recommendations - Training by Net Objectives

Scrum Training Courses

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

Lean-Agile and the Process-Innovation Pendulum

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Mon, 30 Jul 2007 00:00:00 -0600

Lean-Agile and the Process-Innovation Pendulum

Alan 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 Scrum

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

Lean-Agile Software Development

Music 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: Overview

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Tue, 12 Jun 2007 15:40:32 -0600

Lean Anti-Patterns: Overview

It 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 problem
Anti-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 Addition

Alan 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.com

Personal Note

On a personal note: Today, I am wishing a happy 25th wedding anniversary to my lovely bride! Amazing, still!

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Music 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

Completing the Agile Development Puzzle

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Wed, 09 May 2007 00:00:00 -0600

Completing the Agile Development Puzzle

Bob 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 puzzle

This 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 earlier

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

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

Know Thy Audience - Part 2

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Sat, 05 May 2007 00:00:00 -0600

Know Thy Audience - Part 2

Happy 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 approach
It gives a sense of their openness to innovation
It 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 detail

The benefit of categorization

First, 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 more

Alan 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

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Music used in this podcast:

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

Know Thy Audience - Part 1

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Tue, 27 Mar 2007 00:00:00 -0600

Know Thy Audience

Dwight Eisenhower said, “Planning is everything, the plan is nothing.” 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: their motivations, experiences in development, world view, and their focus in development efforts. Who makes decisions and how are they made? The thought work you put into your planning now will help you create a plan that both helps you focus on the important things first and gives you a flexible framework for the future. The more you engage with the organization, the more you should expect to adjust your coaching plan: it will never be correct the first time out. Adjustment is completely acceptable in Lean-Agile. What is not acceptable is going in unprepared. Lean-Agile is not chaotic. It requires discipline and a framework to build on.

Early in his preparation to talk with a client, Alan spends a fair amount of time trying to understand who he will be talking to, what is driving them when it comes to software development. He classifies them as Entrepreneurial, Structured, or Highly Defined and that helps him decide what he will emphasize first. Of course, this is a tentative classification until he knows more. In this show, Alan discusses his classification approach.

On a personal note, I can hardly believe it has been 2 months since I have done a podcast. It has been a crazy few months for me at Net Objectives. I have been on a couple of client coaching visits, worked with the Information School at the University of Washington (http://www.ischool.washington.edu/), and helped to develop our new web site, which is based on the Drupal content management system (http://www.drupal.org/).

Drupal is a great tool and should serve as a good foundation for going forward. We had the good fortune to work with Scott McDaniel of Decisive Communications to help us with the new site. He is a WordPress expert who learned Drupal very well.

If you haven’t had a chance to see our new site, take a look: www.netobjectives.com. We have put up a lot of new resources for registered users and customers. Hopefully, you will find it helpful.

All of that and writing two books and learning to be a manager. Well, I am glad for VersionOne (http://www.versionone.com/) to help me manage my work in an agile way and for patience of my friends, family, and listeners. I hope to be on a more regular production track now.

Enjoy the show!

Talk to us

Recommendations - Training by Net Objectives

Lean-Agile Software Development

Recommendations - Technical

Drupal - Open source content management system
Scott McDaniel's blog. Scott is with Decisive Communications and helped us with the design of the new site, www.netobjectives.com

Music used in this podcast:

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

Lean and What do we do next? - Part 2

jim.trott@netobjectives.com (Jim.Trott@netobjectives.com) — Sat, 27 Jan 2007 00:00:00 -0700

Lean and "So, what do we do next?" - Part 2

These Lean-Agile principles all seem reasonable, but abstract. What do we do to put it into practice? This is part 2 of a discussion on this.

OK. Root causes, Agile, Value Stream. What else?

I held this interview just after a challenging Lean-Agile Overview class. Midway through, the students seemed restless or frustrated. One of those times where you know you are just not getting through to them, that something is blocking the students’ ability to hear what you have to say. That happens sometimes and when it is a crowd of managers in the room, you know that no amount of pushing through the material is going to help. Taking a cue from the lean thinking principle to “stop the line” when something is going wrong, Alan Shalloway decided that the best thing was to stop the class and see what was going on.

The feeling of relief was tangible. They were only too happy to vent. “We understand these lean concepts: eliminate waste, decrease cycle time, doing just enough, voice of the customer. The concepts make sense. So, tell us, what are we supposed to do?”

What sort of practical advice does lean offer me to start improving our processes? That is the question that every manager has. The principles of lean thinking seem obvious, general, and abstract. Putting them into practice is not so obvious. Help me make the connection.

There are a couple of ways to answer this question. The easy answer would be to hire me as a consultant and do whatever I tell you. But the better answer is to use this as an opportunity to learn lean thinking, to take on the eyes of lean. I wanted the students to learn to think honestly about the root causes that create limits to productivity. To learn to look for delays. And then to start using some simple tools that can help you remove bottlenecks in as smart a way as you can. And finally, to learn not to be afraid of starting where you can to make small improvements every day.

In jim.trott@netobjectives.com with the topics you want us to cover. This blog and podcast series is really about how we can provide value to you.

Recommendations - Training by Net Objectives