The Hard Reality...

We all want to be really good at what we do... we strive to get better... we want to think that we are making a contribution to the success of our organizations... we want to think that we are adding value. The hard reality... and one we NEED to really come to grips with... is that sometimes we are doing great work... sometimes even building great working software... that has NO market value.

If our activities don't result in marketable, sellable software... we are wasting time and we are wasting money.

We might justify this to ourselves by saying that we can only control within our circle of influence... that we have to be the best we can be within the areas we can control. Maybe... but if you get really good at creating design documents for projects that get killed... it is still waste. If I build features for a system that never gets sold to a customer... it is still waste. If I build services for a component that never gets consumed by the application... it is still waste.

Anything you document... or code... or test... or even deploy... that doesn't get sold to a customer is ultimately waste. It doesn't matter how good... or how fast... or at what velocity you do your work... unless it sells... you have wasted time and money building it. And that... to me... is what makes Lean such an interesting topic right now...

Scrum really brought home some powerful ideas... revolutionary ideas that have changed how we think about product development. We've learned the value of building organizations around teams and the value of self-organization. We've learned to give the business the power decide what and empowered the team to decide how. Scrum helped us learn that real improvement comes from keeping everything visible and removing the impediments that are really slowing our teams down.

Lean brings a relentless focus on value... not just valuable software... but real delivered value to our customers. Lean expands the concept of value beyond just the product delivery organization... it recognizes that the enterprise value stream often includes other parts of IT... and other parts of the business. Lean gives us language and principles to really scale agile out to the enterprise.

Individual performance doesn't matter... team performance doesn't matter... until we can figure out how to bring it all together into something we can actually sell.

Subscribe to Leading Agile

Working Software or Customer Value

A few years back when I was still doing hands-on project management work... I used to teach internal classes on iterative and incremental product development. Officially... we were teaching a very light-weight instantiation of the Rational Unified Process. Unofficially... we were teaching agile values and principles within more of an Agile Unified Process framework.

The audience was always full of hard core waterfall folks... developers... testers... business analysts... project managers... one of the main things we'd try to talk about was the idea of frequent delivery of working software. I'd explain that charters and market requirements documents and detailed design specifications were not what provided value to our customers... all our customers really cared about was the working software.

Inevitably... someone from the audience would raise their hand and ask the question: Are you telling me that these detailed requirements documents... the ones I spend months and months creating... are not valuable? Are you telling me that the only one delivering value on the team were the developers?

I'd have to carefully explain that while those things were valuable... to the extent that they enabled communication... to the extent that they helped people understand... they were not the value that our customer's expected. If we had to kill the project 3 months in... would you rather have a detailed specification or an increment of potentially shippable code?

The potentially shippable code is always going to win.

The same idea holds for organizations with multi-part... multi-step value streams... organizations where it takes the activities of several teams working in coordination to deliver value back to the business. Even the smallest organizations... organizations with the simplest value streams... are going to need sales and marketing and support to deliver a viable product to market. Software doesn't usually sell all by itself.

More complex businesses... businesses with more complex value streams... are going to need not only sales and marketing and support... but also the ability to integrate the outcomes of many feature teams and component teams to get a product into the hands of their end-users. Does it do us any good to invest in one part of the value stream if the other parts are falling behind? Value is only created when all the parts are integrated into one cohesive whole.

So... when one part of the delivery organization gets too far ahead of the other parts of the delivery organization.... be it by writing all the requirements up front... or by building out one part of the component architecture too far ahead of all the others... it is easy to start confusing valuable activities with real value delivered into the product. It is especially easy when all that activity results in great team velocity and real working... albeit incomplete... software.

Subscribe to Leading Agile

Why a LeanSSC? Why a Lean Certification?

As you guys know, I was down at the Lean/Kanban conference last week and got involved in the formation of the Lean Software and Systems Consortium. As a result of all my blogging and Twittering... Mark Levison, an agile coach and editor from InfoQ... asked me why we needed a LeanSSC and why a new certification? It was a great question that needed more than 140 characters so we took the conversation off Twitter and into e-Mail.

After responding to Mark... it seemed that you guys might be interested in my response as well. For completeness, I'll give you Mark's question he posted to the Lean/Agile Yahoo! group and then my complete response:

Mark's Note

I wasn't at the conference and so all I can do is read the press release. After reading I'm confused.

1. Why does the world need a Lean Consortium?
2. What does the Consortium hope to achieve?
3. Why do we need another certification?
4. How will this certification be different from the CSM/CSC/CST?

Confused in Ottawa
Mark

My Response:

Hi Mark,

I don’t know that I’ll have all the answers here… the organization is brand new…. just barely out of concept… so some of this will shake out over the next few weeks. I can tell you the reason that I was interested in exploring creating a new organization.

As it stands right now, the DSDM Consortium and the Scrum Alliance are the only organizations offering certification. Very few people have heard of the DSDM certification and clearly the Scrum certification has exploded over the past few years. I like Scrum, I practice Scrum, and while not a CST… I teach Scrum. Scrum is a great small team framework but I do not believe that Scrum by itself is scalable.

Most of the teams that are scaling Scrum have expanded the idea of a single Product Owner to the idea of a Product Owner team. This is not part of base Scrum but is essential to coordinate the activities of many teams working in concert. Also, many large organizations are built around large system components, components that are products in themselves… these teams are building integrated systems within large component architectures. Scrum gives no guidance on how to do this.

In any organization that is large and complex enough for the feature team model to break down, you have to start looking for effective ways of managing flow across the organization… how to manage work in progress… how to manage constraints… how to manage dependencies. Scrum gives no guidance on these scaling issues… Lean does.

There were two primary camps in the room when the LeanSSC was formed. There were people that thought of Lean as a discipline unto itself… one with its own body of knowledge. The were also people in the room that felt strongly a LeanSSC needs to build on the foundation of agile, embrace what we know, but build lean scaling principles into the fabric of that body of knowledge. Personally, I am hoping the LeanSSC takes the latter approach.

So to answer your questions directly:

1. The world needs a LeanSSC because there is an agile body of knowledge that is bigger than what Scrum is prepared to address. By creating an organization that is broader than Scrum, one that can embrace a broader body of knowledge, we have the opportunity to engage academia, corporations, and individuals that are interested in advancing that body of knowledge.

2. Some of this will be worked out over the next few weeks but the general idea is to identify the body of knowledge, create a set of Lean/Agile competencies, and provide certification around these competencies. You might also imaging a structure that allows member organizations to contribute to and benefit from the growing collection of intellectual property. Ideally we create a very open system.

3. The Scrum certification has been great in leading the software industry to a broader knowledge of Scrum in particular and agile in general. Scrum as it stands now does not meet the needs of the enterprise… people that are making Scrum work in the enterprise are using techniques that are counter to Scrum and certainly not contained in the Scrum training material. The LeanSSC has the opportunity to broaden the certification track and give companies a path to build a more competent workforce. I can’t imagine that people believe Scrum is all you need to know to build large scale software projects.

4. I suspect it will be based on a set of published competencies. I suspect that there will be multiple training courses to address the various competencies. I suspect that any training organization will be able to deliver competency training and that to receive certification in a competency will require a test. I suspect there will be multiple paths through the competencies based on the objectives of the person or persons receiving the training (developer, manager, senior leader). This is not defined yet… but I suspect it will be a much more open system.

I would like to reiterate that this is all MY opinion and may not reflect the official position of the LeanSSC or any of the individual founders. There is a lot of work to do… the formation of the organization is just a first step.

Mike

What do you guys think of my response? Does it carry water? Do you think this team of people is off base? I am interested in your opinion....

Subscribe to Leading Agile

Subscribe to Leading Agile

Lean or Kanban or Agile

Here I am.. Sunday afternoon.. Mother's day. Just got back from taking the family out for a low key Mother's day celebration and now I've got a little quiet time before the week begins. The conference last week was quite a rush... had a great time... met a lot of great people. Before the week gets going I want to sort through some of my thoughts on this whole Lean/Kanban thing.

A bit of history... Mary Poppendieck was one of the first few authors I ever read when I got formally introduced into the agile community. I recall how much her book resonated with me then... and looking back I can see how much it influenced how I think about agile... and the agile movement as a whole. I tell you guys that to say I have never made much of a distinction between agile and lean. To me... it was just a different way of looking at the same fundamental truth.

A buddy of mine recently told me the story of the blind men and the elephant. The general idea of the story is that we have a bunch of blind guys in a room with an elephant (sounds like a problem waiting to happen to me). These guys are each touching the elephant on different parts of its body. The guy touching the tail says an elephant is like rope... the guy touching its leg says the elephant is like a tree... the guy touching its ear says it is like a giant leaf. You get the idea. The point is that without being able to see the whole... they each describe the elephant from their own particular point of view.

As I watch people debate over what it means to be agile... it seems we were a bunch of blind men arguing over the nature of the elephant. If your point of view is small, colocated teams... scrum brings a valid perspective. If your focus is more technical... the practices of XP tend to resonate. If you come from a larger more structured organization... you might need AUP or DSDM. If you have a really small team of experienced developers... let's talk Crystal. Context is everything.

It seems to me that much of our debate is out of context. When we get dogmatic about one methodology... about one set of practices... we are often not taking the other person's context into consideration. That is why the Agile Manifesto was so powerful... it was a set of value statements... it was a set of principles... that was broad enough to be applied in a situationally specific way. We have to take the local context into consideration.

I don't think the Lean/Kanban proponents are saying they have found a better way... I think that we are continuing to learn and to grow and to better understand what it takes to deliver great software. It seems to me that the Lean/Kanban movement is not out to replace XP or Scrum or DSDM but to help organizations that are having trouble adopting these practices... or have adopted them and need something else to increase their productivity.

Here is a quote from the Schwaber and Beedle book "Agile Software Development with Scrum"...

"Empirical process control models are elegantly simple. They employ feedback mechanisms to monitor and adapt to the unexpected, providing regularity and predictability. The actors in a Scrum team empirically devise and execute the best processes possible based on their skills, experience, and the situation in which they find themselves"

The line about the team devising the best processes possible based on their slkills, experience, and the situation in which they find themselves has always resonated with me. I think that Lean and Kanban give us another set of processes and tools that can help the team improve. I do not believe Lean and Kanban are at odds with Scrum... nor do I believe that Lean and Kanban are going to be successful without the engineering discipline encouraged by XP. We are just another set of blind men looking at a different part of the elephant.

My personal take...

Kanban is a visual process control tool that helps teams effectively manage the flow of work through the sprint. Scrum gives guidance that the team decides what they can do... and the team decides how it will get the work done. Kanban gives the team another way to inspect and adapt and to learn how to get better. I am not hung up on the fact that Kanban is iterationless... I can apply it within the iteration. If I determine that the iteration has become waste and no longer need it... I'll get rid of it.

My goal has never been to do Scrum... my goal is to build great software as fast as possible. In Scrum process improvement is implicit... the team inspects and adapts and find ways to get better. In Kanban we put specific visual controls in place that help the team better understand the flow of work through the sprint and make targeted improvements as necessary.

To me the idea of Lean is a bit broader... lean deals with the enterprise. Lean is about managing the flow of work across teams. How do I take an idea that comes from biz dev... turn it into a product idea... get the work assessed and approved... built... tested... delivered to the customer... billed... and supported. Lean can give us some guidance here for how to manage the flow of value through the organization. Kanban is a tool... Lean is a philosophy.

A team could use a Kanban board to manage the backlog item through the development phases... analysis, design, code, and test. An enterprise could use Kanban board to manage the flow of an idea from inception through development to billing and support. The principles of Lean can be applied within the team and across the teams. Understanding value streams... identiying constraints... eliminating waste are all explicit ways of helping the team get better. These are principles and tools that explicitly help the team inspect and adapt and make better decisions.

As a founding member of the Lean Software & Systems Consortium I hope we continue to build on what is out there and resist the urge to make this something wholy new. Remember... agile is all about uncovering better ways of developing software by doing it and helping others do it.

Lean/Kanban gives us another set of tools to help that come about.

Subscribe to Leading Agile Subscribe to Leading Agile