Since the agile product manager/product owner topics get a lot of interest on the blog, I thought I’d push this Chapter out for review.  It’s available at the book resource tab, too.

Ch 11 Role of the Product Owner (Rev 11)

In order to aggregate content for my upcoming book Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, I’ve built a new resource page at the “Agile Requirements (the book)” tab above. I’ve also aggregated the currently relevant, public content there.

In an earlier  post, I announce my latest book project, Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise, and noted that I’d be sending out snippets for review (and hopefully use by others) during the project. Of course, you can’t write about agile requirements without writing about user stories, and although I’ve blogged a bit on this topic in the past, I’ve never taken the time to describe them in  the depth that would be appropriate for the book. While writing the chapter, Pete Behrens (a friend and Certified Scrum Trainer) decided to dive in with me and co-author that Chapter.

We thought it might be useful to others, so we’ve published it whitepaper form: User Story Primer

You can also find it on the Resource page.

Comments are always welcome.

Enterprise release planning is my favorite (business!) activity. Put all the right people in a room for a day or two, fuel them with caffeine and sugar. Present the strategy. Convert the strategy to vision and a set of the next-release objectives. Understand the impact of architectural refactors. Acknowledge deadlines that exist prior to even entering the session. Factor that against the teams actual velocity for new development. Look at the technical debt pile. Discuss and debate. Heat…smoke…then hopefully …light!

Wow, that can be fun. Fresh off her most recent release planning session, Jennifer Fawcett (agileproductowner.com) muses on her recent experiences on her blog at Agile Release Planning Musings. I don’t know for sure how it went, but I’m told that her boss took her out for many drinks afterward. Could have been to celebrate.  Could have been simple encouragement to come back into work the next day.  Check it out; might even be a few chuckles in it for you.

As readers of this blog know, I’ve been using my previous book, Scaling Software Agility: Best Practices for Large Enterprises, as a source reference to help guide large-scale enterprises in becoming more agile in their software development projects. In the course of many engagements with these large enterprises, a recurring theme keeps popping up, “How do I handle requirements at scale in an agile environment?” It’s a good question that deserves a thorough treatment of the subject and, hopefully, some practical answers to that question. I’ve been addressing some of the answers in various blog posts and whitepapers (see Agile Requirements category and A Lean and Scalable Requirements Model for Agile Enterprises.) Also, I’ve written fairly extensively on the requirements topic in the past, in Managing Software Requirements: First and Second Editions, from Addison-Wesley.

While thinking about this issue for the last few years, I’ve accumulated a lot of practical approaches to the question of managing requirements for big systems in an agile world. In addition, several agilists have been thinking about this problem as well and have made substantial contributions to the art. Although I tried to duck the issue, it just wouldn’t go away, so I’ve decided to write another book (with help from collaborators such as Mauricio Zamora, Pete Behrens, Jennifer Fawcett and others) that focuses specifically on this matter. I’ve tentatively titled the book Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise and, with help from my co-author, Don Widrig, it should be published by Addison-Wesley sometime early next year.

As in all things agile, it isn’t completely nailed down yet but here is the Table of Contents that I’m working from now. A lot of the book exists in draft form, so don’t hesitate to contact me if you’re interested in helping me shape this book for final publication. In future posts, I’m going to push various whitepapers and snippets to gather early feedback, and to help anyone who might actually find this stuff helpful between now and the time the book is published.

===============

Preliminary Table of Contents

Agile Requirements: Lean Requirements Practices for Teams, Programs and the Enterprise

by Dean Leffingwell, with Don Widrig

Forward

Preface

About the Author

Front Matter

·      Preface

·      How to Read this Book

·      Acknowledgements

Part I – Overview: The Big Picture

1.             A Brief History of Software Requirements Methods

2.             The Big Picture

3.             Agile Requirements for the Project Team

4.             Agile Requirements for the Program

5.             Agile Requirements for the Portfolio

Interlude Case Study: Tendril Residential Energy Ecosystem

Part II – Agile Requirements for the Team

6.             User Stories

7.              Stakeholders, User Personas and User Experiences

8.             Estimating and Velocity

9.             Iterating

10.          Acceptance Tests

11.          Role of the Product Owner

12.          Requirements Discovery Toolkit

Part III – Agile Requirements for the Program

13.          Vision, Features, and the Solution Roadmap

14.          Role of the Product Manager

15.          Release Planning and Execution

16.          Nonfunctional Requirements

17.          Requirements Analysis Toolkit

18.          Use Cases

Part IV – Agile Requirements for the Portfolio

19.          Systems Engineering

20.          Business Modeling

21.          Epics and Agile Portfolio Management

22. Epics and Enterprise Architecture

In my last post, I described some work I’ve been doing with lean thinking in some larger software enterprises – not so much for teams themselves, who generally find Scrum and/with/or XP to be adequate for their needs – but to other levels in the organization – project office, sales, marketing and distribution – where value stream analysis, reduction of waste and elimination of delays in time to market resonate better than the agile manifesto or the methods themselves. In addition, lean provides a broader set of both philosophies and practical tools to apply in  making their departments and organizations more agile.

In that post, I noted that a bigger question naturally arises:

“Do we have two different, complementary or even competing philosophies at work – lean for the enterprise and agile for the teams? Or is agile really a “software instance of lean”, making the philosophy of approach and language of discussion, one harmonious construct, where agile is the lean development practice subset of an overall lean enterprise approach. “

XP and Lean?

I also quoted Kent Beck in noting that:

“I think that Agile and Lean are strongly related, but that they are two different ideas. Lean aims to achieve efficiency through eliminating waste and respecting people. Agility is a by-product in lean as rapid cycles are required to identify and eliminate waste. Agile software development aims to meet the evolving needs of customers through the early and continuous deployment of valuable software.

The values, principles, and practices of the two approaches are different, even though complementary.”

With XP, the linkage is indirect – well correlated and complementary for certain- but it’s clear that Kent doesn’t see XP as being derived from, or based on, lean.

What About Scrum?

A few years back, I came across a presentation that Jeff Sutherland on the The Roots of Scrum. Jeff also pointed me to a video of his actual, physical presentation, which can be found on InfoQ.

In this presentation, Jeff notes that there are many roots of Scrum, including such things as the advent of OO methods (rapid development and less painful refactoring), process and productivity research (empirical methods work best when process is to complex to be predicted), and even evolutionary biology and complex adaptive systems(central command and control will kill it!), but right at the top of the list are some of the philosophies concurrent with, but not the same as,  the development of lean.

Jeff notes that the “Godfathers of Scrum” are Takeuchi and Nonaka (authors of The New, New Product Development Game. This is my personal favorite, root philosophy, of all things agile and includes the first use of the words “Scrum”, “Rugby” and “Sashimi” in a software context that I am aware of (also see my earlier post). Takeuchi and Nonaka are also the authors of The Knowledge Creating Company and Hitotsubashi on Knowledge Management.

Just a few excerpts from these works:

From the New, New, Product Development Game:

“leading companies show six characteristics in managing their new product development process:

1.            Built-in instability.

2.            Self-organizing project teams

3.            Overlapping development phases.

4.            Multi-learning.

5.            Subtle control.

6.            Organizational transfer of learning. “

From Jeff’s presentation and Hitotsubashi on Knowledge Management:

Ba- the Zen of Scrum (shared “context in motion” and the energy that drives a self-organizing team):

• “Dynamic interaction of individuals and organization creates synthesis in the form of a self-organizing team
• The fuel of ba is its self-organizing nature a shared context in which individuals can interact
• Team members create new points of view and resolve contradictions
  through dialogue
• New knowledge as a stream of meaning emerges
• This emergent knowledge codifies into working software
• Ba must be energized with its own intentions, vision, interest, or mission to be directed effectively
• Leaders provide autonomy, creative chaos, redundancy, requisite variety, love, care, trust, and commitment
• Creative chaos can be created by implementing demanding performance goals. The team is challenged to question every norm of development
• Time pressures will drive extreme use of simultaneous engineering
• Equal access to information at all levels is critical.”

Does this look like the good Scrum teams you know?

Of course, this background describes the roots of Scrum from certain philosophies, practices and authors perspectives contemporaneous with development of lean thinking and concurrent development, but does not specifically place lean in the roots of Scrum.

Additional Background

In my lean research, I’ve been going back to some of the earlier and quintessentially lean works, including: Lean Thinking from Womack and Jones, The Toyota Way by Jeffrey Liker, Lean Software Strategies by Peter Middleton and James Sutton (both founding members of Lean Software and Systems Consortium), to better understand both lean, and its application in the software development context.

In this review, I’ve been struck again and again by common principles – not just like principles or complementary principles – but virtually identical, fundamental, and immutable principles that provide the cornerstone values and philosophies of both lean and agile approaches. I’ve become more and more convinced that agile is a software instance of lean– purpose built for the unique challenges, intangibles and thought-based work of developing software as fast as efficiently as possible – but as lean as lean can be in that context.

Next Post

With respect to Scrum, in particular, the similarity is just too hard to ignore. I’ll describe that in my next post Scrum in the House of Lean?

As I mentioned in my last post, I’m working with a number of large-scale agile transformations, most deploying Scrum. However, while Scrum drives agility and efficiency for the software development team, Scrum (or XP) doesn’t have so much to offer to the line managers, directors and VPs engaged in managing development, project, program, and product management and all the other surrounds that are necessary in the larger enterprise. And we all know that a set of agile teams, by themselves, does not assure an agile enterprise.

To address these larger issues, I’m using the principles and tools of lean – value stream analysis, flow, pull, kaizen mind, limiting work in process, etc. – because these principles apply equally well to a program office processing incoming requirements as they do to manufacturing lines. In addressing this larger problem, you have to consider the value stream in total, from the sales office where an order originates – to the development team – to production and distribution. As you know, that can be a long and arduous process in the enterprise, resulting in unacceptably slow time to market, even if the teams themselves are agile.

So the question arises, do we have two different, complementary or even competing philosophies at work – lean for the enterprise and agile for the teams? Or is agile really a “software instance of lean”, making the philosophy of approach, and language of discussion, one harmonious construct, where agile is the lean development practice subset of an overall lean enterprise approach.

Based on my personal experiences with lean manufacturing a decade or so back, I’ve always seen agile development in lean terms, and it certainly seems to be a “lean instance” to me.  Many others do to. For example, Ryan Martens recently blogged on the topic at Agile and Lean Software Development – an Oxymoron?  However, some of the experts comments he received back were not so simpatico.

With respect to XP, Kent Beck commented on Ryan’s post:

“I think that Agile and Lean are strongly related, but that they are two different ideas. Lean aims to achieve efficiency through eliminating waste and respecting people. Agility is a by-product in lean as rapid cycles are required to identify and eliminate waste. Agile software development aims to meet the evolving needs of customers through the early and continuous deployment of valuable software.

The values, principles, and practices of the two approaches are different, even though complementary.”

Now personally, I’ve never considered the elimination of waste as the primary driver behind lean (I rather think of flow, pull, kaizen, reduced wip, faster cycle times – which of course tends to happen when you reduce waste!). However, in the popular book Lean Thinking: Banish Waste and Create Wealth in Your Corporation (Womack and Jones), eliminating “muda” (waste) is the primary theme, so that there can be no doubt of the objective from their expert perspective. Larman and Vodde however,  disagree in noting “the pillars of lean are not tools and waste reduction”.

No matter whether elimination of waste is or isn’t the primary objective of lean, it’s clear that Kent Beck does not see XP as a subset of lean, as they have “different values, principles, and practices”.  And who would argue with Kent on the philosophy and roots of XP?

As for Scrum, however, which is the primary method being use in the enterprise projects I’m involved with, its roots are quite different, as you’ll see in my next post.

As readers of this blog are probably aware,  I’ve been thinking a lot about Lean Thinking lately. (see Lean Thinking category on this blog).

The cause is natural: as agile moves across the chasm to the large (and really large) enterprise, which is where I spend most of my time, impediments to further enhancing productivity and delivery pace move from the team to the department level and across to other organizations such as data farm operations, IT, packaging and distribution, support and the mother ship of potential agile impediments, the Project Management Office (PMO).

Once you get past the boundary of the team’s who define, build and test the software, our agile principles and practices, from Scrum, XP and the like, along with the agile manifesto, start to lose their impact. Most of these key outside stakeholders could care less about the manifesto, empowering development teams, user stories, agile estimating, and all the other seemingly odd practices and cultures of agile development.

In other words, it’s hard to “agilify” a PMO, IT shop or data farm. While many of the principles still apply, the practices and tools, and the organizations themselves, are quite different. Moreover, they have been getting along without us just fine prior to our conversion, (after all, every larger enterprise has been, by definition, successful) and they aren’t particularly interested in our new learnings, no matter how enthusiastic we might be.

[Here’s a thought experiment: a newly-converted-to-agile dev VP/Director walks into the IT shop, (substitute data farm ops, distribution, support, etc) and says “I’m here from software development and I’m here to help you make your operations more agile”. Note: do not try this at home!]

Indeed the main reason I’m participating in the LeanSSC consortium is to participate in the development of a set of trainings, tools and practices that we can apply effectively outside of the software team to help make the entire enterprise more agile. To accomplish this, we need different forms of supra-agile thinking, along with the management training and inculcation necessary to for such a significant change program to take root in the larger enterprise.

For many reasons, which I won’t elaborate here, the answer for me to this next set of challenges comes from the history and practices of Lean Thinking. I have some personal background in lean, starting with actually running a small manufacturing enterprise with lean and theory of constraints back in the 80s, to serving as a director and advisor to a lean manufacturing software systems provider (Pelion Systems, later acquired by DemandPoint) in the early 2000s.   I have always seen agile as an “instance of lean thinking for software development” and that’s why I’ve resonated so heavily with the agile movement.

For some time, I’ve been meaning to put my lean thoughts down on paper, but I’m distracted by my consulting work, book projects (Next: Agile Requirements) and life in general.

Recently, I got a note from Craig Larman, describing a new whitepaper he and Bas Vodde have published on line at www.leanprimer.com. It’s really well done and covers a lot of territory I now won’t have to write about. I recommend it highly. (And it’s free!)

In it, they describe the general background and philosophies of lean and build a big picture of lean for the reader. As you may know, I love these big placemat-sized graphics that attempt to tell a long story in executive summary/gestalt form.  When I saw theirs, I thought, that’s the starting point, but of course I was compelled to try to improve it.

Here’s my attempt at the House of Lean Thinking graphic.

Figure: The House of Lean. Adapted from Larman and Vodde (2009) and the Toyota Way (2004).

However, for an explanation, I refer you to the whitepaper above.

This graphic is based heavily on the Toyota Way and as such, is not software specific. I expect to blog more extensively on agile-as-an-instance-of-lean in the future, along with some derivations for “the house of lean software”, but no promises, because I never know quite what direction the enterprise agile ship will take me next.

Also, on a side note, anyone interested in Lean Software Development should familiarize themselves with the excellent works of the Poppendiecks as well.

Hardcopy proceedings of the Lean and Kanban 2009 Conference are available at the WordClay Bookstore. This is excellent reading for anyone who wants to understand what the latest “tip revision” thinking from Lean and Kanban experts like David Anderson, Eric Landes, Alan Shalloway, James Sutton, Corey Ladis and others. (My article with Juha-Markus Aalto on the Lean and Scalable Requirements Information Model is in there too.).

Here’s the abstract:

“The application of Lean Thinking represents the next wave in software development process and technology management. This collection of papers contributed by speakers at the Lean & Kanban 2009 conference in Miami May 6^th – 8^th 2009 represents state-of-the-art thinking on improving the performance of software development teams and gracefully introducing change with a minimal degree of resistance. This book will appeal to managers in the technology sector and those with an interest in Agile Software Development, Project Management, Software Process Engineering, and management of technology businesses.”

If you are thinking about Kanban and Lean in the software context, you owe it to yourselves to buy a copy. All proceedings go to operating funds for the Lean Software And Systems Consortium (Lean SSC), which is a non-profit organization dedicated to promoting Lean Thinking in the software industry.