Thanks to Artem Marchenko for mentioning the Poppendieck’s talk at Google, titled Competing on the basis of Speed.
This also gives me another chance to say that we are delighted that Mary and Tom Poppendieck will be in Charlotte on May 9-10. See here. And they will speak at Agile-Carolinas.
Google announced on 4/20 that it earned $1.002 billion in the first quarter. The Net was up 69% from 2006. See WSJ.com – Google Displays Core Strength*. The sales increase was not too shabby either.
Maybe it’s a company we can learn from. (Or maybe they are just lucky.)
Google uses Agile. As I hear, Agile isn’t forced on anyone, and many different types of Agile are used. Which, in a way, is agile itself. My hypothesis is that the relationship between Agile and the increased profits is not coincidental.
But that is not my topic for today.
As I hear it, Google takes a very different view of how to use Business Value in its projects. It allows project teams to work on lots of things, as long as someone thinks there is potential of value. The value is not clearly defined upfront. Google gets a beta product in front of the customer world quickly, and gets feedback. After feedback and improvements, if the product has traction (internally and externally) then they release. Only then do they start to worry about monetizing the product (say, Google maps).
Again, they build, and give it away and build market share. And once they have a product that people want, then they figure out how to monetize it.
What’s the idea here?
I am guessing the idea goes like this….
1. The first thing is serving the customers.
2. Some products (for Google at least) don’t need to bring in money by themselves. They are looked at as filling out a whole customer relationship. It is those customer relationships that become profitable (in multiple ways, if you know how Google makes its money).
3. The first decisions are made by the bright employees deciding how much they want to invest (their own time) in creating or improving the product. My understanding is that each employee is almost an entrepreneur in the way he decides to invest his own time in projects. (I will guess this is something of an exaggeration, but you get the drift.)
4. Then each product team “sells” the product internally and externally, building users and buzz. And perhaps gathering input and more people (workers) for the project (product). So, the key tollgate is “does this product add value for the customer?” Early on, and to some degree later, internal people act as proxies for external customers. But the product is also out quickly to get external customer feedback as well.
5. Then, once they have a released “successful” product (ie, successful to the customers), then they worry about monetizing it (how Google will make money off it). Sometimes those earning are indirect (eg, via ads rather than via license fees to users).
To me, the main lesson here is that Google folks expects to learn along the way what the customers really want. And what business value really is. So they start getting feedback as soon as possible. It’s a question of who can learn more useful stuff faster.
One is Ken Schwaber, who talked to them for about an hour, mostly about Scrum. The excellent video of his talk is here. The nuances of Scrum become clearer when you hear Ken explain it. His website is here.
Esther Derby and Diana Larsen also visited the Googleplex. Their talk about Agile Retrospectives is here. I am a fan. Of Agile Retrospectives (the activity and their book). And of Esther and Diana.
See also their blogs here and here.
Again, Jeff Sutherland spoke at the Googleplex. His talk on Scrum tuning is here. Also highly recommended. His blog is here.
Check it out.
And check out the Agile Tangents group that Mark set up. A number of good people there.
My own view is generally that the workers deliver to the customers, and the managers support the workers. So, in line with that, I think the best agile adoption comes with both bottom-up and top-down support. And both sides have to rigorously and compassionately face the truth and root out impediments.
Now, let me take something from the Poppendiecks, that to me puts agile adoption in perspective. This is step 1 in their 21 step program. (See the end of their new book.)
But having teased you, let me digress for a moment. I have had several conversations over the last few months where people would say something like “…but after all, this is not about agile, this is about getting the work done.” And, depending upon the mood and meaning behind what they are saying, I am either nodding in agreement or shaking my head in amazement. If they understand agile and the value is brings, and their point is that agile is mainly about results and not about the perfection of the practices for their own sake, ok. But if they don’t appreciate agile, and consider it little more than the flavor of the month, and just really want to go back to the old tired ways of working and delivering, I am discouraged. Agile is valuable because it helps delivers better business results.
After that seeming digression, what was step 1? Step 1 was “implement lean across an entire value stream and a complete product.” Thus, before one considers software, one examines what the customers really want, in terms of some complete product or product set (product includes services), and what the full value stream is to deliver that. One uses lean techniques to identify how to improve that value delivery (more exactly what the customer wants, faster, cheaper, better quality).
Presumably improvements in the software will be identified as enablers to a “leaner” value stream. (“Leaner” meaning “better” in the most important ways rather than just the opposite of fat.) Even if the software is the product, bear in mind that creating that software is not the whole value stream. The problem to solve is to deliver to satisfy the need as soon as the need can reasonably be identified. Solving that problem is a lot more involved that just creating software.
If your firm is using Six Sigma or some other Business Process Reengineering approach to delivery, then connect Agile to that. (Exactly how is of course a potentially long discussion.)
Conclusions:
1. Start with a lean attitude toward value delivery to the end customer.
2. Place Agile in the context of helping to deliver business results for the end customer.
(Does my digression now make sense?)
Brad Appleton had this post with a LOT of Lean resources. I have not reviewed them all. I will endeavor to annotate them later.
Again, the Poppendieck’s are coming to Charlotte (see here), so this is a continuation of posts on ideas they talk about.
This one is a particular favorite of mine: Little’s Law. (No, not me.) This is from John Little, a professor at MIT’s Sloan School, and it’s in regard to queuing theory.
So, we believe (and in fact long experience has shown) that we should satisfy the customer as quickly as possible. Reduce end-to-end cycle time. Thus, for example, we use value stream mapping in Lean.
So, we have a black box (the business system/process) and we want things to go through that box as quickly as possible. One way of looking at this is queuing theory. Every time you stand in line at a grocery store or a bank or an airport, you are hoping that someone there has studied and implemented queuing theory.
Now, I am not going into queuing theory a lot. Let’s just discuss Little’s Law. It states something that is actually obvious common sense (and he proved it mathematically): the average time is takes a thing (say, a person) to go through the black box is equal to the number of items in process divided by the average completion rate per item (when the system is running well).
In other words, if there are 10 people in line, and each of two tellers can serve one person every 5 minutes, you can expect the last two people to be “completed” after 25 minutes. And, if people arrive in the queue at 2 per five minutes, you can expect the average completion time for the day to approach 25 minutes for all customers.
So what? How do I use this in my project?
Well, from this we deduce…put fewer things in process. To get stories done quickly, only work on one or two stories at a time. Don’t make a big backlog of stories, so that you can release more quickly. If you want your projects completed more quickly, start fewer of them.
These are simple statements, and in practice need some modification (eg, consideration of all the other factors in play).
One of the bigger ones is the cost for people doing task-switching. This is generally far larger than generally recognized (eg, effort and motivation and FUD). These costs for human systems (eg, a SW dev team) urges us even more to put fewer things in process.
There is generally minimal cost associated with implementing Little’s Law, except…for the cost of changing the way your colleagues look at work and work-in-process. An important cost, but worth it.
OK. It’s a provocative title. I like to talk about two F-words: Feelings and Failure. This post is about failure, and how to use it.
I was working in a firm recently and someone said: “We can’t talk about failure around here. That would hurt our careers.” Ummm.
First, let me (apparently) change subjects completely. As I mentioned earlier, Mary & Tom Poppendieck are coming to Charlotte May 9-10 to lead their Lean Software Development – Practitioners course. So I want to talk about some of the things they will talk about.
They posit 7 principles of lean software development:
As with all good ideas, most of these are obviously good at first glance. What is apparently (from what I see in real life) not so obvious is the full meaning and application of these principles. Which the Poppendiecks explain.
You will notice that I gave detail for only one: Create knowledge. (The others have more detail, not shown; perhaps subjects for another day.)
So, let’s talk about the scientific method. “But wait, weren’t you going to talk about failure?” Ah, I am talking about failure. Imagine the many failures of the Wright Brothers (two of my favorites) or Alexander Graham Bell. Only after a couple of years of failure did we hear: “Mr Watson—Come here—I want to see you”. And the telephone was born.
The Poppendiecks explain the scientific method this way: “Teach teams to establish hypotheses, conduct many rapid experiments, create concise documentation, and implement the best alternative.”
When we are creating something new (with software we always are), we need to fail, fail, fail, succeed. This is embedded in the Red, Green, Refactor of test driven development. This is what all inventors do. (Now you can call yourself an inventor. Really.)
Now, using failure to learn and make progress and discover is not an excuse to use failure to hide shoddy work or laziness. (Very few workers really want to do shoddy work or be lazy, but a few of us have that kind of motivation from time to time. Examining why is perhaps a subject for another post.)
So, if your firm or the people around you don’t want to hear the F-word, tell them your team is using the scientific method. You are testing hypotheses to identify the best one. Only by failing can we succeed. (Another paradox resolved.)
Good luck with your project.
Apparently my recent post about this new draft handbook was buried in the March posts.
If you are interested in this handbook, please see that post.
Mary & Tom Poppendieck will be visiting Charlotte to give their Lean Software Development – Practitioner’s course on May 9-10. [Written in 2007]
Partly because of that and because of an inquiry, I wanted to talk some about Lean. Specifically, about waste, which is known as muda in Japanese.
Earlier I posted about waste. This is a different perspective on the same basic subject.
Those who know Lean manufacturing know that Shigeo Shingo defined the Seven Wastes for manufacturing (derived from his work at Toyota). The Poppendiecks have defined the Seven Wastes of software development. See below.
Manufacturing
|
Software Development
|
|
In-Process Inventory |
Partially Done Work |
|
Over-Production |
Extra Features |
|
Extra Processing |
Relearning |
|
Transportation |
Handoffs |
|
Motion |
Task Switching |
|
Waiting |
Delays |
|
Defects |
Defects |
Some of them are obvious. Some maybe not.
Let’s pick on the first row. What is Partially Done Work?
The Poppendiecks identify several examples:
In fact, any work done prior to receiving the business benefits of the deployed software is “partially done work”.
Why is this waste? After all, from an accounting point of view, this is “inventory”, which is an asset. Right? (And so thought the auto industry for the longest time.)
But, what good can happen with or to partially done work? (My answer: almost nothing.)
And what bad can happen to partially done work? Lots. Every minute it is undeployed is a minute the customer is left unsatisfied. And with time, la donna e mobile (see lyrics), and so the customer’s needs also change. Ever happen to you? I would bet it has.
We lose our knowledge and understanding of that unfinished work. (What’s the half-life of our memory of a Requirements Doc, when we have worked on two more in the meantime?) People lose it, it gets harmed. We have to do Task Switching to come back to it.
Further, thousands of dollars have been invested in that unfinished work, which often can’t even be shown to the customer. The firm has to fund that investment, and the customer loses confidence that the development team can produce anything worthwhile. And the development team is unsure…how near finished is it, really? You have a guess, but nothing beats getting the ball over the goal line (oops, football metaphor, wrong season).
“But, but, but”, you complain, “I must have some partially done work.” Yes, indeed the team must. So, the goal is to limit that waste to the smallest amount possible. Example that might fit your situation: Only one story in-flight at a time.
More on waste later.
