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.
Tuesday, April 24, 2007
Friday, April 20, 2007
Google, Agile and Business Value
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.
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.
Three Google/Agile videos
Google is doing Agile, and four people have come to talk at the Googleplex about Agile. (Maybe more.)
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.
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.
Carnival of the Agilists for Apr 20
Mark Levison, a friendly Canadian (I am working with a bunch of those Canadians lately) has the controls for the Carnival of the Agilists this time. Again, we are honored to have been selected, this time for Adopting Agile and similar posts related to Lean.
Check it out.
And check out the Agile Tangents group that Mark set up. A number of good people there.
Check it out.
And check out the Agile Tangents group that Mark set up. A number of good people there.
Wednesday, April 18, 2007
Adopting Agile (Lean Software Development - 4)
Brad Appleton, whom I mentioned in my last short post, also had this post linking to Agile Adoption as reported in the Agile Journal. This issue is talking about top-down agile adoption.
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?)
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?)
Lean Resources
Brad Appleton had this post with a LOT of Lean resources. I have not reviewed them all. I will endeavor to annotate them later.
Monday, April 16, 2007
Little's Law - Lean Software Development - 3
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.
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.
Friday, April 13, 2007
Do we have to use the F-word?
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:
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.
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:
- Eliminate waste
- Build quality in
- Create knowledge
- Use the scientific method
- Standards exist to be challenged and improved
- Predictable performance is driven by feedback
- Defer commitment
- Deliver fast
- Respect people
- Optimize the whole
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.
Thursday, April 12, 2007
The Elements of Agile Style - 2
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.
If you are interested in this handbook, please see that post.
Wednesday, April 11, 2007
Lean Software Development - 1
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.
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:
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.
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). (Well, some say Taiichi Ohno identified the 7 wastes. Oh well.) 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:
- Uncoded documentation
- Unsynchronized code
- Untested code
- Undocumented code (if documentation will be needed; usually some will be needed in my experience)
- Undeployed code
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.
Tuesday, April 10, 2007
Agile is not like golf
We have to be careful with similes (or metaphors).
If you have played golf, you know that any fool can hit the golf ball a few yards with any of the clubs. It is getting that tiny ball in that tinier cup that's the problem. It is scoring near par that is hard. And mastery comes after lots and lots of practice. After only a few rounds and a few lessons, one can well appreciate the skill of the pros, and how much work it must have taken to get there.
But golf is an individual sport. Agile is a team sport. So, for that reason Agile is more like baseball or basketball or football or soccer. Or rugby (from whence Scrum takes its name). And there's probably a useful comparison to doubles tennis.
How much does one need to believe in the team or in teams to play Agile well? A question for another day.
If you have played golf, you know that any fool can hit the golf ball a few yards with any of the clubs. It is getting that tiny ball in that tinier cup that's the problem. It is scoring near par that is hard. And mastery comes after lots and lots of practice. After only a few rounds and a few lessons, one can well appreciate the skill of the pros, and how much work it must have taken to get there.
But golf is an individual sport. Agile is a team sport. So, for that reason Agile is more like baseball or basketball or football or soccer. Or rugby (from whence Scrum takes its name). And there's probably a useful comparison to doubles tennis.
How much does one need to believe in the team or in teams to play Agile well? A question for another day.
Sunday, April 8, 2007
Agile is like golf
I went to New York last week, to visit friends and to visit one of the greatest cities in the world. Wonderful energy.
A fairly well-known joke line goes like this: How do you get to Carnegie Hall?
Answer: Practice, practice, practice.
This is one of my main points as I watch The Masters golf tournament today from comfort in Greensboro, NC. These golfers have been playing under tremendous pressure and under very difficult conditions for 4 days. In a world full of duffer golfers, these are the masters of the masters.
And yet in Agile, it seems so many expect to be masters at Agile in 2 iterations, or 2 months, or 2 years.
In golf, one must practice putting, practice the short game (chipping), one must practice sand shots, and irons, and fairway woods, and one must practice tee shots. I particularly like Rule 13: "The ball must be played as it lies."
In Agile, you must practice getting value from released software, practice releasing faster, practice all the engineering disciplines in developing software, improve the TDD and continuous build process, improve the Scrum practices (including especially realizing the value from retrospectives), improve the use of user stories, and improve the definition of business value embedded in the user stories. And, along with all this, practice the communication within the team, and improve the leadership and motivation of the team. While all the factors around the team are changing. And the team must play it as it lies.
May your team reach the Masters.
A fairly well-known joke line goes like this: How do you get to Carnegie Hall?
Answer: Practice, practice, practice.
This is one of my main points as I watch The Masters golf tournament today from comfort in Greensboro, NC. These golfers have been playing under tremendous pressure and under very difficult conditions for 4 days. In a world full of duffer golfers, these are the masters of the masters.
And yet in Agile, it seems so many expect to be masters at Agile in 2 iterations, or 2 months, or 2 years.
In golf, one must practice putting, practice the short game (chipping), one must practice sand shots, and irons, and fairway woods, and one must practice tee shots. I particularly like Rule 13: "The ball must be played as it lies."
In Agile, you must practice getting value from released software, practice releasing faster, practice all the engineering disciplines in developing software, improve the TDD and continuous build process, improve the Scrum practices (including especially realizing the value from retrospectives), improve the use of user stories, and improve the definition of business value embedded in the user stories. And, along with all this, practice the communication within the team, and improve the leadership and motivation of the team. While all the factors around the team are changing. And the team must play it as it lies.
May your team reach the Masters.
Friday, April 6, 2007
Never send to know for whom the bell tolls
In my culture, this is the beautiful, daffodil time of year. When spring is sprung.
And when Passover and Easter come to pass yet again.
The long cold winter is over, and the stream of life bursts forth in joy. If just to be alive again.
With Easter, we see presented to us again, it seems for the millionth time, the mystery of death and re-birth. We learn again that we are not just matter, not just a bag of water and a few minerals, priced (I used to hear) at about 98 cents. We conquer death... for Christians, through our Savior. And, if I understand correctly, each of the great religions also conquers death.
Why do I mention all this is this blog? While I won't get too personal, some of these have been themes in my personal life for the last year or so. And even in the last few weeks.
But let's return to Agile & Business. So, if it will not seem profane to some, let us mention a few connections, although I think many more connections could be made.
First, Agile and Business are for the whole man. Not just his material wants, but all of his wants. Yes, it is concrete and limited; business does not stand awaiting perfection before trying to deal with some basic human needs. But business is involved in all of man's wants and needs. Business is involved with death. And with the new-born baby as well. Indeed, in some way with all of our hopes and dreams.
So, Agile tells us to see the whole man. In the customer, in the worker, in the shareholder. In each person we deal with.
Agile also calmingly invites us to little deaths. To small failures, so that we may learn, and in time have the greater triumph. Agile does not protect us from the awful truth; we still can die and we still can fail in a big way. But Agile shows us, if we watch and listen, how to have small failures and learn from them.
The title of this post is from John Donne, MEDITATION XVII. I urge you to read it. If you know Hemingway, you will recognize a title or two in Donne's works.
Donne observes that no man is an island. This is a lesson that Agile has incorporated by bringing all the people together. All of the technical abilities are brought together into a whole team. And the business side and the technology side are brought together to collaborate. Perhaps there are still a few projects that one man can still do, but they are few these days. So, Agile is a way to learn how we are engrafted, one to another, and yet at the same time free. A paradox it may seem, but still true.
Donne asks us also to learn from the afflictions of others. Perhaps you see others doing Agile not well enough. Perhaps you see Agile now waxing and now waning in one firm. While this may seem a borrowing of misery, yet if you learn from it, you will mine its gold. Be patient. With them and with yourself.
Life and Agile may seem to you far better ideas than their opposites. But everything must to some degree follow the patterns of life and of the universe, like the tides and the waves. If you are truly clever, perhaps you will help the people see that Agile is not just the latest wave (in IT, in project management, or in management nostrums). Perhaps you are helping them see it is more fundamental. But nonetheless, it will still wax and wane. Be not discouraged.
May the brightness of the new flowers (daffodils or whatever is near you) give you joy. And may you fulfill the promise of their hope.
And when Passover and Easter come to pass yet again.
The long cold winter is over, and the stream of life bursts forth in joy. If just to be alive again.
With Easter, we see presented to us again, it seems for the millionth time, the mystery of death and re-birth. We learn again that we are not just matter, not just a bag of water and a few minerals, priced (I used to hear) at about 98 cents. We conquer death... for Christians, through our Savior. And, if I understand correctly, each of the great religions also conquers death.
Why do I mention all this is this blog? While I won't get too personal, some of these have been themes in my personal life for the last year or so. And even in the last few weeks.
But let's return to Agile & Business. So, if it will not seem profane to some, let us mention a few connections, although I think many more connections could be made.
First, Agile and Business are for the whole man. Not just his material wants, but all of his wants. Yes, it is concrete and limited; business does not stand awaiting perfection before trying to deal with some basic human needs. But business is involved in all of man's wants and needs. Business is involved with death. And with the new-born baby as well. Indeed, in some way with all of our hopes and dreams.
So, Agile tells us to see the whole man. In the customer, in the worker, in the shareholder. In each person we deal with.
Agile also calmingly invites us to little deaths. To small failures, so that we may learn, and in time have the greater triumph. Agile does not protect us from the awful truth; we still can die and we still can fail in a big way. But Agile shows us, if we watch and listen, how to have small failures and learn from them.
The title of this post is from John Donne, MEDITATION XVII. I urge you to read it. If you know Hemingway, you will recognize a title or two in Donne's works.
Donne observes that no man is an island. This is a lesson that Agile has incorporated by bringing all the people together. All of the technical abilities are brought together into a whole team. And the business side and the technology side are brought together to collaborate. Perhaps there are still a few projects that one man can still do, but they are few these days. So, Agile is a way to learn how we are engrafted, one to another, and yet at the same time free. A paradox it may seem, but still true.
Donne asks us also to learn from the afflictions of others. Perhaps you see others doing Agile not well enough. Perhaps you see Agile now waxing and now waning in one firm. While this may seem a borrowing of misery, yet if you learn from it, you will mine its gold. Be patient. With them and with yourself.
Life and Agile may seem to you far better ideas than their opposites. But everything must to some degree follow the patterns of life and of the universe, like the tides and the waves. If you are truly clever, perhaps you will help the people see that Agile is not just the latest wave (in IT, in project management, or in management nostrums). Perhaps you are helping them see it is more fundamental. But nonetheless, it will still wax and wane. Be not discouraged.
May the brightness of the new flowers (daffodils or whatever is near you) give you joy. And may you fulfill the promise of their hope.
Subscribe to:
Posts (Atom)
