Bill Blogs in C# -- Agile

Bill Blogs in C# -- Agile

Created: 1/20/2014 4:15:33 PM

The subtitle of Mary and Tom Poppendieck’s latest book is “Ask the Right Questions”.  This book guides you to a different Mindset, the Lean Mindset.

They begin by defining a Mindset as a mental model that enables us to make decisions. Throughout the book you are led by Anna and Otto, two characters that represent two modes of thinking.  Otto is our everyday mind, where we make most of our decisions.He makes decisions on autopilot, adjusting quickly to any new situation. Otto uses his current mental models to guide his thoughts and actions. Anna is far more analytical. She analyzes the data behind everything and makes decisions slowly and in a measured fashion. She’s more likely to apply new models to new situations. Together, these two different ways of thinking provide a balanced view of the world and help us make great decisions. Throughout the book, they’ll show you how using both your current mental model, and questioning that model, you can improve yourself and your organization. One skill is learning to both modes of thinking appropriately.

The Poppendieck’s have again written a great book that will make you think about your organization, and how to make it better. It’s not a long book. It can be read over a weekend. but it will make you think, and think deeply.

The book is divided into 5 chapters.

The first, The Purpose of Business, discusses the Shareholder Value Theory, and Rational Economics. Then, they discuss alternative business theories, such as cooperative work systems.  They stress the wisdom of centering your business around your customers. You must define your customers, your business, and the reason for your business’s existence.

The second, Energized Workers,explores techniques that can motivate and energize workers in your business.Poppendieck’s guide us through several case studies where organizations have created an environment where workers achieve beyond normal expectations. As you’ll learn, it takes empowerment and trust, among other things.

The third chapter, Delighted Customers, is a great read for anyone in an organization practicing Agile Development. Poppendieck’s talk about the risk of building just what is required, and never building features that truly delight customers. Again, case studies are provided from companies whose products delight you.

Chapter 4, Genuine Efficiency, talks about the tensions between productivity and flow efficiency. You’ll also learn the keys to energizing your team to build the right product, and to learn as quickly as possible what products and features are delighting customers, and which are not creating the reaction you want.

The final chapter, Breakthrough Innovation, provides a few case studies on companies that have made great innovative changes to their business and achieved great success. You’ll learn about a very successful news publisher, and how Intel moved from memory chips to CPUs.

This is not a cookbook filled with recipes you can just follow. In fact, Poppendiecks’ point out that the case studies in the first and 5th chapters follow opposing recommendations. What works for one company will not work for everyone. You must ask the right questions in order to find the right path for your organization.

Like all of the Poppendiecks’ books, I highly recommend this book. It provides many thoughtful questions that will help you make your organization more effective, following a lean mindset. If you want your organization to improve, you need to read this, and think about how it can help your organization.

Created: 1/16/2013 12:36:23 PM

One of our customers is grappling with how to manage a scrum process that involves multiple teams with multiple responsibilities. The larger organization produces a number of business applications, all built on a common library. They have teams for each application, and a framework library team.

I thought our recommendations would be of general interest, so I’m posting them here. This is still a work in progress, so I'd appreciate any thoughts from my readers.

Sprint Meetings

We recommended moving away from a process where every team attended one large sprint meeting. Every team planned their next sprint during these large meetings. Our customer was concerned that there was very little energy in these marathon meetings. The main reason was that for many attendees, over 75% of the content was not interesting: it was about other applications. The level of detail was too deep for members of other teams. By scheduling project-specific sprint meetings, each meeting had fewer people, and those people were engaged in the activity.

To make sure that the voice of the customer was represented, we recommended that one member of each application team attend the framework team's sprint meetings.

To make sure that the framework team knew of any issues relating to each application, we recommended that one member of the framework team attend each application team meeting. (Although not necessarily the same person. That would be a lot of meetings).

We made this recommendation because sprint meetings are in depth, and project focused. We feel it's important to have all attendees engaged for the entire meeting. We wanted to reduce the waste associated with attending meetings where someone is not really contributing.

It did raise the energy in the project meetings. It also brought some concerns.  Everyone felt this decreased the communication between application teams. That could lead to code duplication, missed opportunities for reuse, and siloes of knowledge.

On to Standups

Standups are a mechanism to communicate to everyone any progress, and any issues. We recommended having all the application teams and the framework team attend the same daily standup. That’s about 30 people, but it can still be a short meeting, if everyone follows the rules. We're finding two main advantages to this process.

If someone is stuck, a larger group of peers hears about the issue. That increases the chance that someone will say "I can help." Issues get solved quicker.

The framework team is becoming much more efficient. Imagine someone on an application team makes a feature request of the framework team at one of these standups. One of three outcomes are possible:

  • No one says anything. That likely means that no other app needs that feature. Maybe that feature is better implemented in the app team's code base.
  • Other App teams say they need (or will soon need) that same feature. That information helps the framework team prioritize requests.
  • Another App team says "we've already built that feature." Now, the work changes from a new feature to refactoring code (and associated unit tests) to move it from the application's codebase to the common framework. That avoid code duplication, and means the framework team can release the new feature more quickly.

It's working quite well so far.

What have you tried? How has it worked?

Current Projects

I create content for .NET Core. My work appears in the .NET Core documentation site. I'm primarily responsible for the section that will help you learn C#.

All of these projects are Open Source (using the Creative Commons license for content, and the MIT license for code). If you would like to contribute, visit our GitHub Repository. Or, if you have questions, comments, or ideas for improvement, please create an issue for us.

I'm also the president of Humanitarian Toolbox. We build Open Source software that supports Humanitarian Disaster Relief efforts. We'd appreciate any help you can give to our projects. Look at our GitHub home page to see a list of our current projects. See what interests you, and dive in.

Or, if you have a group of volunteers, talk to us about hosting a codeathon event.