Honesty and Scrum

Are people honest and transparent?

Short answer: Not completely.

Let’s digress first, and then come back to a better answer.

***

To digress….why are honesty and transparency important?

IMO, in two ways. The main reason: we can manage better with the truth.  For example, we get better feedback in the Sprint Review.  If we can see the product transparently and if people speak honestly.  The same notion applies in all official or unofficial meetings a Scrum team might have.

And because there is less to remember.

Honesty is also important in personal relationships.  People tend to like people who are honest.  More trust.  More sense that they know the real person.

And, of course, as it has for centuries, honesty has a bad side too.  These days we use the phrase ‘too much information’ or ‘over-sharing’.  Or we wince when someone gives feedback harshly.  Or says something in an ‘awkward’ way when a ‘smoother’ way would have been just as effective.

Then we have to face life, and some of us find certain parts of life very discomforting.  By this, I mean by work-related things, and things only indirectly related to work.

Here are some general facts we must face:

• our strengths and weaknesses
• time is short
• ‘all things must pass’
• humans are a lot like primates
• humans are not as rational as we want them to be (at least sometimes)
• certain body functions (was that delicate enough for you)
• the classic topics: sex and religion (and politics and money)

I tease.  Humans are primates. And in so many ways, maybe for good or ill or both, we refuse to think of ourselves as animals. Weird.

There are plenty of roughly similar ‘hard to discuss’ topics at your work.  But I won’t list those now.

As we work together, we must expect these ‘awkward’ topics to surface.

To some degree, as we gain trust with our teammates; they forgive us and we forgive them.  And its okay.  We talk openly, give feedback, and set some better boundaries.  But it can be awkward some times.

***

The main points here are a few.

1. We want more transparency and honesty in Scrum.  Mostly this is just to help make work better.
2. Much of the honesty is refreshing and welcome.  It’s fun to be known for who we really are.
3. Still, humans will never be completely honest.  Ever (I think).
4. Sooner or later, you are gonna hear things you do not want (or need, in your opinion) to hear.  We will tease ourselves with this quip: Some things you can’t unhear.

The ScrumMasters, the Team and others will forever be working to help people be more honest.  Also, sometimes ‘less honest’ (about some things).

People will make mistakes; that it will be painful sometimes…is to be expected.  It will just happen.

Mostly it is better. “No place to run to, no place to hide” is a good song, mostly.

The ScrumMaster Should Not be a People Manager - 2

This is a continuation of this post.

Some more observations.

***

Before we start…some more basics….

1. The PO has an important role.

Especially key in deciding which PBIs or user stories the team will get next, and important in many other ways too.

2. The SM has a key responsibility in making the ‘continuous improvement’ engine work in Scrum, and for the Team.

This is so important.  And soo seldom does it really happen.

3. Each Team is different, each SM is different.

So, while we can describe the SM (or any role) based on the ‘normal desirable’ state, we must also deal with people or groups that are different, or unusual SMs.  These are NOT included in this overall discussion, but are always something we must deal with, sooner or later.

4. Scrum is not the only way.

It is about the only way I advise, for many reasons. And there are some caveats, but too much to discuss here and now.  So, even though something else may work or ‘be better than we were before’, that does not mean one should not have done ‘real Scrum’ and have been yet better than that alternative.

Still, one can do something else, and maybe often get somewhat better results than you had before.

But the question should be: could we have gotten even better results with a different approach?

And, to the degree you are not doing ‘full scrum’, I am suggesting trying full scrum first.  Or as soon as possible.  And seeing if the results are not even better.

***

So, here are some issues:

A. The PO role is important, and the SM role should not challenge it.

It is true to say that the SM is a kind of leader in the Team.  The PO is a different kind of leader.  But it does not help if the SM challenges the PO in the PO domain. (I will call that domain: deciding which work is most important).

The SM often must teach the PO how to be a good PO, sometimes by helping him for a time.  But this is not taking over the PO job permanently.

B. The SM must make the Team own the success.

Talking as though the SM owns success is not going to help. As soon as the SM gets very powerful, compared to the other team members, it is not likely to be good.

In my opinion, as soon as you say the SM is responsible for success, everyone else in the Team drops down some in motivation and energy, and self-organization is not happening as well anymore.  Sometimes this is very subtle.  Sometimes it is ‘seen’ in the lack of increased productivity that we would have seen if they had continued to self-organize.

Just asking the team (‘do you own success?’) is not sufficient, especially if they know that the ‘right’ answer is yes.

C. The SM must ‘make’ the Team self-organize.

We have said this before.  The point now is, this is difficult, and almost on a knife’s edge.  If the SM moves much away from the servant leader, it is very likely that this will inhibit the self-organization of the Team.

Again, the change can be subtle, and people may barely perceive it at first.  And not talk about it.  If the SM pushes the Team, it may be mainly seen in the lack of improvement in productivity in the Team, rather than a clear decrease in productivity.

D. The Team needs transparency.

The Team must self-organize, self-direct, and self-control itself.  (Outside people can have some role and some influence.  More on that in a later post.)  To do that, the Team (that is, each of its members) needs to know where it is.  The facts need to be transparent. Or, more transparent, to enable the Team to use that information to self-organize more usefully, to make better decisions based on better information.

It is the SM who must foster transparency.  It is human nature to want to hide things, and the SM should be making it ok to tell more of the truth.

Again, the trendline on transparency is subtle.  It is usually either getting better or worse.  But is hard to identify the things that are not said, simply because they were not said.  People like to pretend they are very honest and open with each, and yet that is not really always the truth.  We know this without consulting Dr Freud’s ideas about the unconscious mind.

So, if the SM has power over the Team, especially all the Team, as the one who gives them reviews and compensation increases, then we should expect reduced transparency.  And yet, the SM will never know that the transparency is reduced.  If the Team kind of likes him, they typically will never say ‘I am not telling you everything.’  Often, they will not even admit to themselves they are withholding information.  And yet that is happening.

We think there are a few people who will say almost anything to almost anyone.  That is true.  And if their ‘boss’ is the SM, they will still say (almost?) everything to him (or her).  But we think these people are fewer than some of us want to think.  And even then, these ‘brave’ people are not quite as brave as they say, in our opinion.

Hence, we never advocate that the boss become the SM.  Never. It might work, but we do not advocate it.

E. The SM is essential to continuous improvement.

Even 100% dedicated SMs often ‘slack off’ in driving that impediments are being fixed every day.

If we give George additional roles, George is even more likely to not devote enough attention to impediments.

Impediments are all the things we can work on to become better, to improve.  And sem-naturally, the Team will address really key impediments, eg, the system is down.  But often they ignore impediments and focus on real work (as they call it).

So, the SM is key in making sure someone is working on the top impediment now.  Hence, the Team does not improve nearly as much as it could have.

Can a Team improve without an SM?  Yes, just in the fine art of working better together, a Team can get noticeable improvement.  And this can happen almost as if by magic.  But to get real continuous improvement, and start to get more of that faster, you must have a fulltime SM.

***

Can we live without doing all these things?

Well, certainly.  We did not die even though most of us a few years ago did not even know about Scrum.

Let me give one concrete example.

You have a person, George, who is the boss of the Team.  You look at the Team, and there is no one who would be a good SM.  You talk to George, and discover that in most respects George would be a good SM.  But, he is the boss of the Team.  You look at the relationships between George and the Team members, and you find that George is an ‘open’ manager, that his Team, by most standards, is very open with him.

Well, in this case, because there are so few options, it may be best to let George be the SM.  It is not the preferred state, and it should be fixed, but one judges that it is probably the least bad of several options, at least for now.

But, this would never lead us to recommend that the boss become the SM.  We might live with it as an accommodation to ‘today’s realities’, but we are not happy with that part of the situation.

***

Broader suggestions.  The SM must act on the following.

1. The ‘rules’ of Scrum are not as well known as we would like.

2. You may be forced to break the rules of Scrum, but try to do so knowingly, rather than without any thought.

3. Try to measure or in some other ‘open’ way, identify your Team’s biggest problems, and then do something about them.

4. If breaking some of the rules of Scrum turns out to be a big problem, identify that, and fix it soon. If it is a priority.

The truth: Scrum is not easy!

May I tell the truth? I am a trainer, and people come to my course.  And often they want an easy answer.  A magic answer that is not disturbing, or bothersome, but is in every way only good and friendly and just better. In other words, they come to change, but they don't want to change.  Well, maybe that brought a chuckle, but that is a bit unfair.  They want to change, but they don't want the change to be hard.  And we all feel that way sometimes, right?  This is human nature and no one's fault.  But... I could say that in a kinder way.  And maybe I should be kinder, but I am blunt.  I am blunt because I do not wish to waste their time (nor mine).  Because life is short. Because they need a kick in the pants.  But mostly, they and the people they serve need to move on to a new and better life.  We need a better life now! And denying them and their customers and us all a better life because some change is a bit painful.... that is not an acceptable answer. I am also compassionate. I see the suffering of their current lives, and I cry inside.  I see all the lost talent, and see all the pretending, and the dishonesty that their current work requires of them. And I cry inside for that. But I only have compassion enough to risk anger with a KITP. (Often friends get mad at us a bit when we give them a KITP, but good friends thank us later. At least for caring.)  Let us be fair too: A KITP (as I mean it here) is not an actual kick. "Sticks and stones may break my bones but words will never hurt me."  When we say KITP, we mean a serious conversation, we mean bluntness.  We do not mean a brutal conversation, we do not mean breaking someone down into tears in public, and we certainly do not mean anything approaching physical violence.  Of course. But, in these days, someone can complain now that you hurt their feelings and it is sometimes treated as a physical felony.  It has gotten a bit crazy. But this issue is not the subject of this post. *** So, why is Scrum hard? Well, the first truth us that Scrum is mostly a lot more fun.  It is, net net, more pleasurable, for everyone.  But it is also painful, particularly in the changing to it. 1. It requires that we try to see the truth, and the truth is sometimes painful.  And we typically often want to look away.  The truth often tells us unpleasant things about ourselves. And Scrum requires us to tell the truth.  And, that can be hard. 2. Scrum requires that we change, that we challenge everything, that we become better than we are now.  And it makes us move from our comfort zone to a zone that feels weird and different and dangerous.  Yikes! *** Should you talk about the truths in the class? Or ignore them? I feel there is no option.  I must tell the truth. But, some say, they are stupid, and you will upset them by telling these truths.  Don't tell them until they ask or at least until later. Is that the way you would want me to treat you?  No, I did not think so.  Yes, it is true that some of them in the class are not ready to make the change.  And, in some sense, if I could identify that and only teach the class to that one person, then I might 'more carefully tailor the course to the needs of the individual.'  But, again, I do not have those options. So, I do many things in the course to help you appreciate how life in a Team is different.  Things are moving fast. You must interact with all of your teammates.  That there is a new speed, a new informality, and directness, and a lack of hierarchy and 'respect'.  A lower 'formality'.  It is not all gone, but it is substantially changed.  And you want it to change.  Except that many of you, in your hearts, at least partly, do not want it to change.  But, in the class, with a thousand small remarks, I force you to feel the change.  People will say blunt things, people will say non-PC things.  The tight lid on all so-called 'bad words' is lifted.  For many people, this is not a problem at all, this is good, this is refreshing, liberating even.  For men and for women.  But for some people, it is very upsetting.  (If I upset you in a serious way, I am sorry.) Am I being mean?  Well, honestly, to some it can feel mean.  And if the pain is reasonable, I am ok with that. Life on a NYC street is a rough and tumble business.  We all get a bit bruised.  And whenever I hear it is painful, I back off in some way.  But some people hide their reactions, and what is humorous to one person can be painful to another.  One never knows. In some classes I get some especially sensitive people, and I back off some.  But, for those few, it is too late. To be fair, one is fairly sure that some feign sensitivity as a way not to change.  People have many ways to seek their goal indirectly.  But, one thinks. no always is this the case. But honestly, if they do not experience rough and tumble with me in a 'safe' environment, it will go much harder for them in a less safe environment. It is tricky and hard for me as a trainer to bring them up to speed with Scrum quickly.  I never do it perfectly for everyone in class.  I focus mainly on those who are likely to really 'get it.'  So, for some I fail or partly fail every time.  I am not happy about that, but it is a price we pay.  Time is short, as many a poet has written.  Later TS Eliot alluded to an earlier English poet, and had Prufrock say "Do I dare to eat a peach?"... a classic description of our current passivity.  We cannot be so passive.  Life is too short, and the opportunity of a better life is too great. So, Scrum is painful, some.  Bear the pain with dignity.  May it be that I am not the bringer of the pain (to you at least, Reader), that I have prepared you for the pain usefully.  And then may the pain be small. And indeed I have always found the pain to be very small compared to the benefit and the pleasure of doing Scrum with a good team.  And the benefit to the customers, and the satisfaction we get from having done something good for someone else, something we may not crow about, but in after years we may look back and be proud of.  

Changing culture

I am giving a presentation at Southern Fried Agile on Oct 18th, 2013.

On “Culture & Agile & Change”.

Here is the presentation slide deck so far.  To me, it is mainly a reference and a take-away.  But it does highlight some of the key things I will say (and many things I am sure I will not get time to go into).

Please read it and give me your comments.  It is a draft.  As I revise it, I will try to upload the new version.

Getting the right people in the Team - Richard Branson

For useful innovation, truly good and fast innovation, we think a Team is essential.  They must do knowledge creation in a Team. As Takeuchi and Nonaka have explained pretty darn well.

A real team, not a group of individuals.

As a friend just reminded me, probably the most important thing in getting a Team started is to bring a good Team together. Get the right people.  Frankly, with a great team, you probably could use almost any process, and succeed (although I have a strong bias and experience that suggests that Scrum is the better 'process framework' for them -- if they will do it decently).

And each Team is different.

Here is a post by Richard Branson in LinkedIn that I thought was really good.  He talks about focusing on 'personality'.  Well, at least do not put too much emphasis on the skill sets (aka knowledge domains currently mastered).

And he talks about introverts.

Full disclosure: I am rated an extrovert by Myers-Briggs. Not sure I believe it. I feel a lot like an introvert these days.  In any case, I love introverts (people more introverted than I)... and I learn more about other kinds of people each day.  Every type has something to offer. Fascinating.

Some of you may actually know an introvert or two. ;-)

Anyway, Branson gives some good advice about how to judge introverts. And how to work with people more generally.  For example, your Team may need a 'maverick.'

Enjoy the post.

Scrum 201: Desire

Any sports coach knows that the Team must have desire.

In my classes I talk to the people about how much improvement they expect to make in 1 year. With 1 team.  Often it is in the 20% range.

And I use Henry Ford’s famous quote: “Whether you think you can, or you can’t, you’re right.”  So, I usually think that 100% improvement in 1 year is realistic for a specific team.

As a coach or a SM, if they are going to achieve hyperproductivity, the Team must want it.  And, to some degree, they must believe it is possible.

So, the question becomes, how do you get them to have the desire?

This is not an easy thing. In fact, you cannot make them have desire.  But, if there is something inside them, you can draw on that.  You can blow on that ember of desire, and make it blaze.

Sometimes you can give them a challenge. To be the best team in your company, or your state.  For example. Or to be much better than they are today, and prove that with metrics.

In Lean, we have the idea, expressed in a Lexus ad, of the ‘continuous pursuit of perfection.’  So, we establish a vision of perfection. (Usually we know this vision is not perfect, or later we see it is not really perfect.  But it motivates us; it gives us something concrete that seems within our grasp.)  So, we use the vision of perfection to build the desire.

Little’s Second Law: People are remarkably good at doing what they want to do.

So, if you can help them build their desire, in a concrete way, then they can start to make the changes that can drive tremendous improvement.

We band of brothers

“We few, we happy few, we band of brothers.”  A great speech did Shakespeare write.
Here it is explained. The leadership in the real field of battle, against great odds.  You may find this interesting as well.
Here it is enacted. Kenneth Branagh. You may wish to go to about 2 mins 20 secs in.
A bit later King Henry speaks:

We are but warriors for the working-day;
Our gayness and our gilt are all besmirch’d
With rainy marching in the painful field;
…
And time hath worn us into slovenry:
But, by the mass, our hearts are in the trim;

You may perhaps recognize yourself in this situation: that time hath worn you down, yet still your heart is in the trim.
Enjoy!
And may your Team have its heart half so much in the trim.

We want a Stable Team

I think our (your) business is about knowledge creation.  (Well, I think it is for almost all the people who come to my courses and workshops.)  About innovation, creativity, inventiveness. About cool solutions to hard business-technology problems.  It is about some sort of intersection between people and technology. So, coming up with a great product requires something special.

And I believe the ‘special thing’ these days is far more likely to come out of a good Team.

So, from a business management viewpoint (and it is the managers we most need to convince about this) — we need a stable Team.

And it needs to include virtually all the functions (or far more so than we ever did before).  And that also means it needs to include business people and technology people.  Just for amusement, I like to call them suits and geeks. To me it suggests that it just might be ‘interesting’ to put them together.

We must mention two things.

It should be FUN to work in a real Team.  And in fact, in Scrum with all but dysfunctional teams, it is fun. (But maybe could be more fun, if you had a good ScrumMaster helping the fun along.)

It should be more satisfying working in a Team. It is my belief that the human animal has been selected to enjoy life in a small Team.  Like a family, but a bit different.  A small ‘pack’.  Maybe within a larger pack.

So, how long should a Team be stable?

To answer this question, we need to identify basically three situations.

1. Mediocre Team. This team improves 20-50% with Scrum.  Give them 6 months.  If they don’t become better by then, then try putting the individuals in different Teams.

2. Good Team.  This team improves in the 100-200% range.  Wow. Leave them alone. They are doing pretty darn well.

3. Great Team. This team improves in the 5x-10x range. Wow!  Don’t mess with them.  This is the goose that laid the golden egg.  You would be crazy to bother them unless and until they want to be bothered (want to change).  And, if you continue to give them good satisfying work to do, they may never need to change. But, of course, something will eventually happen…one of the usual human things (birth, marriage, death, move, etc, etc).

(There is also the situation of the occasional dysfunctional team. Usually that can be identified in a few Sprints. As soon as you are sure it is not just ‘storming’, then you must change the team composition or totally bust up the team.)

***

This idea of stable teams leads to a major shift in orientation. (The change can happen over time.) We no longer start with projects, and find people to do them.  We now start with a Team, and find good work for it to do.  Who knew that people were important?

Who is Scrum For?

A few months ago someone I know and respect in the Agile community said that they do agile to make the world safe for programmers.

This phrase as stuck with me. I don’t know how seriously the person meant it. I suspect it was partially a joke and partially a stronger statement than one might think.  I suspect it is a real driving force for that person.

And it is true that many implementers have had terrible lives, at least often, and making the world better for them is a very good thing.

But I think we should strive for more than that.

We need to make the world better for everyone.

For example, the customers do not want software (usually), they want something useful that will make their lives better.  The managers need a better life.  The project managers need a better life.  The business owners need a better life. The testers need a better life.

Everyone around or affected by Scrum should be getting a noticeably better life.  And one easily noticed, in terms of the improvement.

This is happening, although it is not happening as much and for as many people as it should. And when it is happening, it is not being noticed and celebrated as much as it should.

Why?

Well, I think one fairly important reason is that too many of us are being selfish.  For example, we are so afraid that the programmer may have to work and be modest and admit failure, that we disable the mechanisms (velocity and demos, for example) that enable the customers and business people to collaborate with the Team.

Anyway: It is an odd request. We want everyone’s life to improve at the same time. No trade offs.

Can it be true every minute?  Well, perhaps not.  But can it be true every sprint, looking back at the sprint in total?  Yes, I think so.

Meet the Meeting Killers

Here is an entertaining article in the WSJ.  About people "types" that kill meetings.

Scrum of course has some meetings. It is trying to minimize meetings, and make meetings better.

But as soon as you have people and meetings, you can have some....umm...interesting times.  So, may your meetings not be interesting this way. 

More on: The Product Owner and the Team

There has been some interesting discussion on this topic recently.

Two things I wanted to add to my prior post.

1. The business side cannot force the Doers to "do all that I say" in the Sprint.

This is of course a well-known rule of Scrum. But this rule does eject the PO from the Team.

So, in one scenario, the PO cannot force the Team to do all X stories that he or she wants done in the Sprint.

But even before that, the PO should want reliability, meaning, if the Team commits to 8 stories, then at least 8 stories will get done (or done, done -- if you prefer) in that Sprint.  The PO does some of the 'real work' (in the form of providing information about the stories and feedback, mainly), so the PO has a say about what he/she can or cannot do to support the Team that Sprint.

What I usually find in the real world, is that the Doers (eg, the coders and testers) want to over-commit.  And the PO (at least) should be saying "no, let's not over-commit -- I and we need to predict for the customer, and we need to know what the Team can really do at sustainable pace".

But at least the Business side (often in the person of the PO) cannot force the Team to do 8 stories when, in their professional judgment, they can only do 7. As an example.

Exactly how the Team self-organizes to reach that judgment is up to each team, but ejecting the PO is not an option.  The PO has at least some lights on the problem, and so should be heard, just as, for example, the junior tester has some lights on the problem.

There are many possible scenarios, but these are the basics.

2. The issue of whether the PO is part of the Team (yes!) is far greater than just the issue of Sprint commitment.

Yes, Scrum teams have problems with the Sprint commitment. All kinds of problems, with multiple root causes. This was partly discussed (indirectly) in a recent post.

But in the shorter term (eg, intra-day) and in the longer-term (eg, release), the PO is an important part of the (full) Team.

Let's take the Release, and the use of Pareto's idea of the vital few.  So, the whole team must be optimizing the 80-20 rule at every level of work (tasks, stories, epics, etc.).  And discovering how to do the least amount of work to deliver quickly the best possible product. (See the Agile Principles.)  This is a Team effort, led in large part by the PO.  But still a full Team effort.  The key related idea is cost-benefit analysis (hey, there's another new one!)... how to get the most benefit or business value for the least effort.  Again, a joint effort by the full Team.

When troubles arise (and troubles in some sense always arise), who is the Team that will address them? ....well, both the Business side and the Technology side together must collaborate to address them.  We might too easily say that in general, both sides must compromise.  Each side must accept "lack of control" but high "power to influence", and create some modus vivendi....some way out of the problem together.  How do we do this in a practical manner?  The simple way of saying it is that the full Team (with the PO) must figure it out.

Again, there are many scenarios, but those seem to us the basics.

***
Yes, I know there is much 'legacy code' in our wetware (our brains, etc.).  But this I think is the way forward.

Respect

I just led a course in Charleston. To mostly people working in/on government or military projects.

I was asked many good questions, and I was not able, in the time allotted (2 days) to answer them all as well as they deserved.

I have other clients who have also very difficult situations to deal with, but I was and remain very sympathetic with the difficulties they (this government-military group) face. In implementing Agile, for example. Still very possible. And still I believe it will yield very clear benefits. But also difficult. Perhaps especially given the surrounding 'culture'.

So, first, if my answers ever appeared to be disrespectful of the difficulties and challenges you face, my apologies. This was never my intent.

I, like you, have struggled and sweated or worried about how to implement lean-agile-scrum in specific situations. It is indeed hard. In fact, always it feels hard, in part because one wants to do it perfectly. So, again, if my comments seemed to be flip, they were not said with that intent.

So, what was I mainly trying to say?

1. Sometimes, we worry too much. Yes, sometimes we get all in a sweat about a certain issue and in fact that issue will resolve itself easily in good time (sometimes that means quickly, even). (This one is not #1, so much as easy and quick to say.)

2. Mindset, ie, the first and often hardest thing to change is our own mindset about the problem.

a. In part, this means we must start by seeing we are 'right', and they are wrong. Not in an arrogant way, but more in the core of our being. We hold the truth and therefore the real power, and we are patiently waiting for them (maybe a manager) to get a clue and get out of their fantasy world.

This attitude, if not done arrogantly, they can still feel. And it makes them realize, sub-consciously, that they are in the wrong place, and must change. Now, we sympathize with them as persons, but not with their wrong ideas.

b. We must understand that we approach certain ideas and issues with very different premises than they do. And so, understanding the mindset shift, we look for statements from them that reveal the old mindset so that we can attack it. For example, we know we want to optimize delivery to the customer. When they say they want to keep the workers busy, that opens up a good conversation about the goals of management.

Sp, often I did or will answer your question with something, maybe a sports metaphor, from left field (as we say). The reason often is to focus on the mindset shift. Not to diminish your issue or question.

3. Time.
Often attendees ask very good and very difficult questions. A good answer would really require 2 hours of Q&A to be sure I really understood the specifics of their situation. And probably then another hour to formulate and explain 10 approaches to dealing with a hard issue. In the CSM course, understandably, I do not have time for 3 hours devoted to one good question.

So, I say something brief. And I often worry later that it can be taken the wrong way by the questioner. I do usually ask "did I address your question at all or well enough?", but maybe in specific situations I need to say more to be better understood.

4. Self-sufficiency.
One of the properties of complex adaptive systems is that they 'solve' their own problems. Not always in isolation or fully or completely. But they can learn and can adapt. So, in part I am relying on you to use the values and principles we discuss (and maybe even some of the practices) to devise your own answers to the problems you pose.

I have confidence that you can and you will.

5. We always have impediments.
Meaning: We can still be successful even with lots and lots of impediments. Success with waterfall is one example of that. But, more generally, even though none of us ever reaches perfection, still we may say we are having many successes (eg, with lean-agile-scrum).

So, I know from experience, that even though your question may be about a very big impediment for you, still, even if we do not even address it, almost surely (I have seen this so many many times) you and your team can still have better success with Scrum than with what you used before. Even if that impediment is not addressed at all.

Now, yes, a few people might have had an impediment that does stop them in their tracks. I think this is possible. But, honestly, I have been doing and talking about this for a good while with many people, and I never seen such a case, I think. With the exception of 'people', which is indeed very difficulty to deal with. ("Our manager won't let us use Agile.")

Anyway, if I have seemed less than sufficiently concerned about your issue, it was not that I did not have sympathy, but maybe that I did think you could work through it or be successful despite it.

I did respect your question.

If you wait for perfection, ...

If you wait for perfection, you might wait too long.

There are some similar quotes, but so far as I know, this quote is mine. As the father, I kind of like it. But most parents love their own children. (If I am not the father, tell me now.)

This applies to all of life. And to Scrum and Agile and Lean. As the guy said to Jack Lemmon in that famous movie, "Nobody's perfect." In fact, not a single thing is perfect. So, my advice is: Don't wait for perfection.

Still a big problem out there. Too many people doing it. I usually don't do it more than 3 times per day.

Use this quote to work on 'em. Make life better now, before it gets to 'perfect.'

One of the biggest business problems we have.

How honest should you be in Scrum?

First answer: Completely.

Ah, if only the answer were that simple. Sorry, George, but Scrum and Agile provide no cookbook answer to this question.

Some people use "honesty" to mean they get a right to be brutal to others (and also to ignore their own imperfections).

Much more often, the de facto thinking is "honesty means I won't say anything obviously incorrect and I will speak up more than I did before." (Well, I don't want to hurt anyone's feelings. And I didn't say much before anyway.)

So, for most people, the operational answer is: Be a LOT more honest than you were before. Both with good news and with bad. And even about yourself.

It turns out that once there is trust on the team, this is not so hard.

Still, like most things: Easy for me to talk about here. Always challenging for a team to do at the highest level in the real world.

All business is personal

We are in the political season, sometimes called the silly season. I will avoid discussions of politics, but I said that to introduce a well-worn phrase: "All politics are local."

Whether that is true or not, it led me to the observation that "all business is personal." That phrase and a note on this blog by Shannon Wagner. And a discussion with my sister-in-law in the mountains.

Business is a revealing of who we really are. Business is an acting out of "love thine enemies". Business is the 12-step program to becoming a mature person. Business is how we really help our grandmothers, our kids and those members of our families who have known hard times. Business helps us appreciate that it is more blessed to give than to receive.

Yes, Virginia, there is much evil and much failure in our being and our doing. Business is that process of refining that out, however slowly it may drip out, drop by drop.

Some people think business is about money, as though it were a zero-sum game. This is not so.

Yes, making a reasonable return for capital investors is a constraint. Like side-lines in a football game. But it is not the game. In business, you score each time you make someone happy. Make just one someone happy...(if you remember that song that Jimmy Durante sang).

Agile is personal, for example. It's between persons.

Only solutions deliverers

As I was saying earlier, in all my clients there is this divide between Business and Technology. "I'm a business guy, not a technology guy." "Oh, I work in IT; go ask the business folks that."

This is an unhelpful distinction.

The customer does not want business or technology or even a product. The customer just wants a solution to his problem. Now.

So we all are just solutions deliverers.

And it becomes clearer each day that our job is to work together in teams, to create the knowledge needed for the next solution. To create the metaphor of what the problem really is; to envision how it might feel to have it solved. To brainstorm, to see the whole problem, to imagine how alternate solutions might fit, to transcend the constraints, and finally yet quickly to deliver what the customer really needs to solve his problem, not what he said he wanted.

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.

Face To Face Still Matters

Last Friday Esther Derby wrote a blog entry that struck a nerve.

Part of the reason I started this blog is because I see so many people worrying about costs without considering the benefits. Or the means without considering (enough about) the ends.

Esther's entry is "Face to Face Still Matters". And of course it does. Communication and learning take place fact-to-face at such a higher rate than over a phone or at even lower bandwidth.

Communication and learning are what we need more of to make the projects more successful.

So, people who want to consider distributed retrospectives (her particular concern) agree to save a few more costs and lose some big benefits.

Similarly, if we focus only on the cost side of Agile, or of projects more generally, we are short-changing ourselves and our customers. Almost always we (as business owners or customers) care more about the value delivered than the cost.

ACTION: Don't ever let anyone talk about cost-savings without also talking about the effect on value delivery. (It is not necessary a linear or even a direct relationship, but it can be.)

<>