Tag Archives: Lean

The PO – The Team Daily Scrum

Posted on by
Reply

I have some different views on this, and wanted to share them.

Your comments are of course welcome.

I am NOT asking what is or should be in the Scrum Guide. Or whichever ‘scrum bible’ you use.

I am just saying what my thoughts and experiences have, together, taught me.  I want to discover just what is most effective for ‘pretty good’ Scrum teams.  (Maybe not best for super teams or for beginner teams.)  So, I am trying to have a conversation — maybe about what to add to Scrum — not a religious war.

OK.  My views expressed too quickly:

  1. The PO is very important to success.
  2. Understanding business value and understanding detailed ‘requirements’ is very important to success. Both these ‘activities’ are extremely difficult.  Both for the PO and for the Team.
  3. Knowledge creation as a full team is very important. In multiple domains. All domains impinge on all other domains. (Key example: cost-benefit analysis.)
  4. The full Scrum team delivers the product. Each provides his unique skills and ideas and creativity.
  5. The PO is definitely a member of the Team.  Given real life, often 100% of his time is not enough (see also #7 below).
  6. The only team that matters is the full Scrum Team.  It is this team that self-orgs, most importantly. (Yes, every person, pair, teamlet self-orgs….not the most important aspect of self-org though.)
  7. I do not think it is useful to talk about a team within the team. (I hardly ever say ‘Dev Team’.)  Talking about a team within the team  creates an us-them attitude. And anyway is not useful. And at first at least, a bit confusing.
  8. The PO must spend a lot of time with ‘people outside the team’.  I will call them, at times, customers. managers, business stakeholders, etc etc.
  9. Still, the PO should attend the Daily Scrum as often as possible (by phone if not in person).  And should answer the 3 questions. His work affects the output of the Team.
  10. The simplest example is: On Day 1, a question is asked by the coder. On Day 2, the PO can give the answer (or at least say ‘I got the answer’) in the Daily Scrum.
  11. If the PO does not do the Daily Scrum (ever), I think most team members start to think or feel (sub-consciously): “who is that guy; he is not part of the real team”.

OK.  This is my experience.  Maybe limited experience.   Maybe just bad thinking.

Imagine that you disagree.

Where we differ, I expect my main reaction or push-back would be: “Well, I can see that happening, and it has happened to me, but I think we should coach them to be better, and often, if we coach them to be better, they actually will be.”  Meaning for example: If the PO comes to the Daily Scrum (usually), then over time it will make them at least a bit better.

Certainly some of you have done different things and been fairly successful. For example, with the PO not coming to the Daily Scrum.  But could you have been more successful by having him come?  Or might ‘my’ teams be more successful doing it your way?  This, to me, is the question.

Again, I am not sure I would coach all beginning teams to do it this way.  I am sure some super teams might be more successful another way.  My inquiry is: For most ‘good’ (but not super) teams, which is the best way to do these things? (PO, Team, Daily Scrum)

Of course, there are many other things in life and in Scrum than just the 3 things I discuss above.

BTW, while what I am saying above is not exactly how it is described in the current Scrum Guide, I do not think it is contrary to what the authors would want.  But it may be more than ‘the bare Scrum framework’.  The minimum that they want.

Refactoring the release plan

Posted on by
Reply

At the end of the last post, we had complete the initial release plan.
What were the key outcomes?

[This is one in a series of posts about release planning. See here.]

Well, the plan had some sort of scope, date and budget. Usually on Day zero the quality is ‘crappy’ to use the technical term. As it must be, given how much we don’t know on Day zero.

The real win was that we now have ‘everyone’ on the same page, at a useful middle level of detail: what is this elephant?  What are we about to do…

And then we start the first sprint.  Or more specifically, we start the first Sprint Planning Meeting.

But that is not really the end of release planning. But the beginning of RPR (release plan refactoring).

It is absolutely fundamental to agile release planning that we refactor the release plan frequently. I say (and many others that I greatly respect say) that we must refactor the release plan every sprint. Every sprint.  Ok, maybe during every 10th sprint there will be so little change, that we don’t have to change the release plan at all.  Ok, maybe this very occasionally happens. But at least we must evaluate that that is the case.

Now, when I say release plan refactoring, I mean all of the following:

* changing the vision (all of these are ‘if needed’)
* improving the product backlog items (more, fewer, smaller, better)
* re-evaluating business value (very key and very hard)
* Re-estimating the effort (eg, where Story Points are wrong, for new stories, for newly sliced stories, etc.)
* taking a new look at the benefit-cost ratios
* including new learning about risks, dependencies, learning, MMFS, etc.
* re-ordering the work
* doing a new scope-date trade-off.  Usually to make the initial release smaller (fewer aggregate story points — is one way of expressing it).
* including the newest velocity expectations (based on recent trends).
* adjusting the buffers and communicating the new, new release plan (scope, date, budget) to the right people

Now, I also include in Release Plan Refactoring all the changes to the Product Backlog information to make it ready for the Team to be successful in doing the Sprint work.  Some people use phrases such as ‘product backlog grooming’ for this. (Note: I think ‘product backlog grooming’ can have other meanings too, depending on who is using the phrase.)

These activities include:
* breaking down stories or epics into small sprint-sized stories.
* improving the stories or PBIs (wording, INVEST criteria, etc.)
* estimating the business value of the smaller stories
* estimating the effort of the smaller stories
* answering questions from the Team about the expected sprint stories
* adding detail (notes, acceptance criteria, etc.)
* adding an agile spec for each PBI to be in the next sprint.  [Sometimes this may be done 2 sprints or more ahead. But not 'way' ahead.]
* checking that the Team thinks each story (likely to go in the next sprint) is ‘ready’ before the Sprint Planning Meeting

One could argue that release plan refactoring and product backlog grooming are completely different.  I think this way of thinking is unhelpful.  One of the purposes of release planning is to make the work in the sprints more successful. Release planning is not completed until, for each sprint planning meeting, we have ‘the stuff’ ready for a successful sprint planning meeting. Among the key success criteria of that meeting is: we used the time of the business stakeholders well.

Let me pause.

Why is using the time of the business stakeholders important?

Well, they are the key independent check on the thinking of the Product Owner.  We know from long experience in our industry that ‘knowing what the customer wants’ is extremely hard. Extremely. The business stakeholders are people whose time is scarce and yet these people are essential to us in getting a much better fix on what the customer really wants (or what the firm wants).  We want them in the Sprint Planning Meeting, agreeing with what the Team takes in and, at the Sprint Review, giving us feedback.  Because these independent input and output checks are so vital, we must use their time efficiently.

Thus, for me it is better to think of higher level release plan refactoring and lower level release plan refactoring. And when people say ‘product backlog grooming’ they often mean lower level release plan refactoring of those stories about to go into the next sprint.

Again, the key idea here is that we ALWAYS refactor the release plan every sprint.  We improve it.  This is absolutely key to adaptive planning.

Release Planning: Risks, Dependencies, Learning, MMFS and Other

Posted on by
Reply

Now we come to the point of (re)ordering the Product Backlog.

(This is a continuation of a series on Release Planning that starts here.)

You will recall that the Product Owner’s main goal is to maximize the Business Value from the Team.  In some time period (shorter or longer, as makes best business sense in your specific situation).  So, in theory the R factor (see the previous post) should be the way to organize the Product Backlog, ceretis paribus (other things equal).

But of course other things are never exactly equal.

So, here is where the most uncommon thing comes into play.  Common sense.

And we re-order the work based on these factors: Risks, dependencies, learning, MMFS, and other factors.

We recommend that anyone in the Team can propose to move a user story earlier or later based on these factors. But he or she must discuss the change with the Team and get reasonable consensus.  If there is no consensus, then the Product Owner gets the final decision.

So, let’s discuss each factor in turn.

Risks. There are potentially many types of risk. Business risk is often a big one. For example, we need to get a feature out before a competitor.  Or we have a weak understanding of the specific detailed features needed in area X.  Technology risk is another common factor. We are about to use new technology, and we are not sure how it will work.  And there are other types of risk.  In Scrum, we tend to want to attack risk early, by doing one or more stories in that area, to see if the risk is just a worry, or a real roadblock.

Dependencies.  Again, these can be of several types.  In the past, we often organized the work mainly by technical dependencies.  Since the job now is to maximize business value, we sometimes must sacrifice efficiency of the Team.  But if technical dependencies will destroy the efficiency of the Team, then we must deal with that. (Ok, seriously diminish the efficiency…).  And there can be business dependencies as well.  It makes more sense to develop step 1 in a process before step 2.  At least sometimes.

Learning. In Agile we recognize the importance of learning. We need to learn what the customers really want. We need to learn some technical things to become more effective.  These can be good reasons to chnage the order of the work.

MMFS.  Minimum market feature set.  This phrase is from Software By Numbers by Mark Denne and Jane Cleland-Huang.  The idea is that there is some minimal set of features that must be put together before a customer can realize the value of the whole set.  Sometimes this minimum is quite small, quite small indeed.  In other circumstances it is much larger.  In general, too many of us (producers and customers) have been brainwashed into believing the 100%-100% rule, so that we think the MMFS is much larger than it really is.  In any case, low value features sometimes must be moved up, in order to add the ‘missing something’ to make the next release truly ‘usable’.

Other. This is a catch-all for all the other reasons we have to change the order of the user stories.  My favorite example is this: A committee is going to me in 3 weeks to decide on the funding for our project.  George is on the committee.  In our opinion as PO and in the opinion of everyone else, George is much too excited about user story 87, which currently would not be built until the third release, and that is assuming no new user stories get identified, which is very very unlikely.  But, George is on the committee. And user story 87 is only 5 story points (our velocity is 25).  So, we ask the Team to go ahead and get the story done in the next Sprint so that George helps assure that the project gets further funding.  Not rational, not ‘the right thing to do’, but sometimes you have to deal with real people and irrational things have to happen.

In our experience, Risks and Learning should be used more often to re-order the product backlog.  And Dependencies less often.  But in any case, using the R factor solely is almost never the right answer.

How to do this

We recommend that the product backlog already be ordered by the R factor.

We recommend that the whole Team be there (PO, SM and implementers) and the business stakeholders.

Then, anyone in the group can start to suggest re-ordering the product backlog based on any of the ideas above.  Any move has to be explained to the whole group.  If there are disagreements, the PO makes the final decision.

Again, let me emphasize that sharing knowledge with the whole team is at least as important as any other outcome we are trying to achieve.  So, doing this without the Team is not recommended.

Normally this does not take very long. Again, 6 months of work for one team is typically expressed as about 50 user stories.  So, re-ordering 50 user stories, where most do not move, does not take long.

More to come….

Agile Specification

Posted on by
Reply

This is a “just enough, just in time” concept.

Please read these blog posts:
http://scrum.jeffsutherland.com/2009/11/enabling-specifications-key-to-building.html
http://scrum.jeffsutherland.com/2008/09/agile-spefiction-is-it-hoaz-or.html

OK.  So, it is something ‘written’ that the PO gets done for the Implementers in the team. The Implementers define exactly what they need, and the agile spec is neither more nor less than what they need.  To get it done right. Quickly. High quality. Etc.

What might it contain?

Well, anything useful.

I think it is easiest to think of conceptually if you think of 1/2 page (or 1 page or maybe 2-3 pages if the drawings are big) tied to each small sprint-sized user story.

It is simplest to think of the Agile Spec being ‘written’ ‘one sprint ahead’.  And being checked for ‘ready, ready’ before the Sprint Planning Meeting.  But your real world may require some common sense adjustments to that. But be careful; common sense is remarkably uncommon.

Maybe hand-written, maybe on a wiki.  Maybe in a Word doc.

Who writes it?  Well, the best people, of course (self-organize!).

It might hold:

  • the acceptance criteria
  • a business flow
  • a list of business rules
  • a wire frame(s)
  • a mock-up of the screen (if that means something different to you)
  • a simple use case kind of flow (not all the darn UML use case stuff… just something, just enough) (to me, this is a variation on a business flow, using a few specific symbols)
  • a data flow
  • new data elements (or whatever you guys call them)
  • key data elements and key values in this context
  • a screen flow
  • a simple design picture
  • a data flow, maybe simplified
  • an example (eg, if X, Y, Z inputs, then we expect A, B, C outputs)
  • anything else they may find useful to build it quickly and for it to EXCITE the customer

Any one Agile Spec will NOT have all of these things.

It does not repeat the usual BS that we used to put in specs. That no one really read.

It does not say all the stuff they know well already.  It is not trying to be ‘comprehensive’.

We are _not_ managing through documentation. Consider this sentence repeated 15 times, 15 different ways.

We are sharing knowledge in one effective way. It is not the only way to share knowledge, and create knowledge. Two people at a white board is still going to be used. A lot.

And we definitely use the Agile Spec as a basis for conversation, to confirm that everyone is seeing the same elephant (well, in this case, the same small sprint-sized user story).

For some people, who maybe had too much fun in college, we need to write or draw more.

For some people, who maybe took their Ginkgo today, we need to write or draw less.

Any questions?

Ozymandias: Creation birth pangs

Posted on by
Reply

It is hard sometimes to create. We wonder, will our darlings ever survive.  I have spoken already of a book called The Courage to Create by Rollo May.

Now I want to show a short poem by Shelley.  Ozymandias, it is called.

I met a traveller from an antique land
Who said: Two vast and trunkless legs of stone
Stand in the desart. Near them, on the sand,
Half sunk, a shattered visage lies, whose frown,
And wrinkled lip, and sneer of cold command,
Tell that its sculptor well those passions read
Which yet survive, stamped on these lifeless things,
The hand that mocked them and the heart that fed:
And on the pedestal these words appear:
“My name is Ozymandias, king of kings:
Look on my works, ye Mighty, and despair!”
Nothing beside remains. Round the decay
Of that colossal wreck, boundless and bare
The lone and level sands stretch far away.

Ozymandias was once a famous king, of surpassing wealth and power in his time. And Shelley wrote this after seeing the ruins of his kingdom.  You will note that Shelley, the great poet, was not daunted by this vision of despair.

I note with irony and pun-ishness, that in our computer world, the lone and level sands stretch far away.  (Ok, Virginia, I am alluding to how sand becomes silicon, as in Silicon Valley. The valley of dreams.)

I hope that you do not seek that fickle goddess, Power.  Or wealth (perhaps slightly less fickle, if you know a good Swiss banker).

But if we only build castles of dreams in the breasts of our friends, even those dreams, once built, can die surprisingly quickly.  A new product will come along and charm them a different way.  I am sure any of you can think quickly of an example.

We must have the courage to create, and the laughter to let that beautiful creation come crashing down. And then to create again.

I will close with this quote from Henry Ford:

I cannot discover that anyone knows enough to say definitely what is and what is not possible.

The importance of a real team

Posted on by

Scrum requires a real team.

The word ‘team’ is often used, often in different ways.  So, let us define it.

According to “The Discipline of Teams” by Katzenbach and Smith, this is what you should look for:

1. A meaningful common purpose that the Team has helped shape.

2. Specific performance goals that flow from the common purpose.

3. A mix of complementary skills. Including technical/functional, decision-making, and interpersonal.

4. A strong commitment to how the work is done.

5. Mutual accountability.

For more discussion, see The Discipline of Teams.

The team needs to be small (~7), stable, cross-functional, and self-organizing.  The team is in it together.  And should help each other.

In general it is best if the team is fully dedicated to one missson, one purpose, or at least the one team’s goals.

All of these team characteristics together are key to starting Scrum.  Got to start with a real Team.

Note: Not everyone wants to be on a Team.  And for sure, not everyone walks into the office knowing how to act in a real Team.

What to do with managers?

Posted on by

First, unlike some in the agile community, I think managers can and should be useful in lean-agile-scrum.

Still, there is a lot of evidence, on many levels for two propositions:
1. Some managers can be very detrimental to a lean-agile-scrum implementation.
2. Many managers have not been well trained in how to manage. In fact, what they have been taught seems to be, to a large degree, the wrong stuff. (At least, it seems, in the US.  In other countries, this may be better.)

So, we agile advocates have a long way to go to get all of management ‘fixed’.  I mean both middle and senior managers now. (Yes, the solution for the middle managers might be somewhat different than the solution for the senior managers.)  On the right page with the right attitudes and practices that are consistent with lean-agile-scrum.

So, a few quick ideas on how to fix this:

1. Check out the “Stoos” group. A few are a bit too radical for my taste, but that group is working on ‘management’.  They have useful ideas on this problem.

2. Respect change. It is hard. It does happen. You cannot always make it happen, especially on your own schedule. But sometimes, either before or after you want, people will change. And even in the direction you want, due (partly) to the efforts you made.   …Do not let yourself get depressed, do not give up.

3. Respect the people you are trying to change, and that, at least in some ways, their concerns are legitimate.  At least from where they are coming from, there is typically some internal logic to the way they think.  … I find this is hard, because I can so palpably feel the damage these people are doing. It feels like they are trying to be evil sometimes.  Certainly stupid. And I grow impatient.  But mostly there are not (evil); they are usually trying to do they best they know how.

4. Look (again) at the standard change books. Kotter’s books. Fearless Change by Manns and Rising. Others (if you prefer). Many great ideas about getting people to change.  Most of the following are discussed well and at length in these books.

5. Make the case. Repeat it often.  It starts with a Sense of Urgency.

6. A sense of urgency, to me, starts with one person having a passion that, dammit, things have to get better. And conveying that passion. Maybe in a quiet way. Certainly in a respectful way. But in more an emotional way than a ‘numbers’ way. Although numbers usually need to be in there as well.

7. Use some experiences. Maybe from articles. Maybe from nearby firms. Maybe from your own firm. Data of one sort or another.  There are tons and tons of great articles about lean-agile-scrum now.

8. Five books for managers.
Toyota Production System by Taiichi Ohno.
Radical Management by Stephen Denning.
The Power of Scrum by Jeff Sutherland et al.
Software in 30 Days by Schwaber and Sutherland
Drive by Daniel Pink.

9. Motivation. Often the key, I think, is they misunderstand motivation. Particularly motivation for knowledge workers. This is why I think Daniel Pink’s book is so useful.

***
Please comment here. I think this is a hard problem. If we knew the answer well, this problem would be a lot better now.  So please suggest better things.

We are also discussing this topic in the Agile Business yahoo group. Please join us.

Release Planning: Business Value

Posted on by

Now we move on to Business Value in Release Planning.

For those who have not been reading before, this is a continuation of a series that starts here.

Per Yogi Berra: “You have to be very careful if you don’t know where you’re going, because you might not get there.”

If you are in the mood, this can be very funny.  Or just a chuckle.  But this is our problem. How do we identify what the customer really really wants.  Well, business value is part of that.

When we did the vision, we directly or indirectly probably talk ed about business value.

Now we want to talk about business value for each individual PBI (product backlog item) or user story.

Again, we want to have two actions within this.

People: Again, to do this work, I want the whole team of pigs (PO, SM, implementers) and the BSHs (business stakeholders).  Again, the BSHs are the best people we can get to attend Release Planning to represent the customers and the firm well.

Business Drivers:  It is my contention that the key thoughts and phrases we want to use about business value vary by the situation. The product, the customers, the people involved.  It may be that the high-level basics of business value for all for-profit firms could be distilled into 5 phrases. But I find for useful discussions in specific products, it helps to ‘invent’ the 3-7 top drivers each time.

Business drivers may include making money, risk, customer satisfaction and lots of other things. Or not.

So, they whole group gets together and discusses and agrees on the top 5 (about) business drivers that apply to the set of work (the product) as represented in the existing Product Backlog (its PBIs).  Sometimes this will lead to the identification of some new stories (or PBIs).

Priority Poker: Most of you are familiar with Planning Poker, which is where we use the planning poker cards to vote as a team on the relative story points of [new story] compared to the 1 SP on the [reference story].

Priority Poker is very similar to Planning Poker, except that it is about business value, not effort.  In fact, we assume there is no correlation between effort and value.

So, the similarities: use a team, vote, use Fibonacci cards, discuss assumptions, share knowledge and ideas, average the numbers after reaching some consensus, the number is comparative, relatively quick, somewhat imprecise for each individual card but fairly accurate over a set of cards, etc.

Some differences: a different team (the experts on business value), reference story is the TOP story (for business value) rather than the SMALLEST story (for effort), prefer the real Fibonacci sequence at the top end, done in the presence of the implementers, etc.

So, first the top experts (usually between 4 and 7 people) on business value huddle around the user stories (or PBIs) and determine which one has the most business value.  This one is arbitrarily given a value of 90 or 100 (it is minor which one you choose).

The Business Value experts are typically the PO, the BSHs and maybe one member of the Team who has a lot of experience with customers. Or for some other reason, knows BV pretty well.

OK, now we have the reference story for Business Value. Then the BV experts start to add relative BVP (business value points) to each user story (or PBI).

Here are the rules:
* pick a story randomly (we do not want to prejudice the panel by already putting stories in BV order).
* discuss the story
* identify drivers of BV for that story (but not how much the driver is affected)
* ask each person to pick a Fibonacci card, but don’t reveal the vote to anyone
* once everyone has selected a card, 1-2-3, they all reveal the card
* the people with the two extreme cards discuss why each was high or low
* the team re-votes until within 3 consecutive Fibonacci cards of each other
* then the averages the numbers, to the nearest integer.

Example: The vote is 34, 55, 55, 89. The value for that story is 58.

Meaning: If the reference story is 100, and they vote 50, that means that they feel that the new story has 1/2 the business value of the reference story, considering all the different drivers of business value.

The others listening (the non-voters) may ask questions at the end of each “card.”  The purpose for them being there is so they can pick up the tacit knowledge about business value, and which stories are more important (and why).

Final review: Once all the cards have been assigned BVP (business value points), the experts then gather around all the cards on the wall, and look for “the stupidest” numbers. Often in 50 cards, they will identify 3 or 4 that seem stupid now.  Maybe this 30 seems a lot bigger than the other 30′s.  Maybe that 70 seems too high now.  The person identifying can ask the experts to re-vote.  In general, we would expect them to re-vote on a few. After all, now that they have discussed them all, they are probably smarter now about business value than when they started.

Timing: Priority Poker takes some time, but is worth it.  Understanding Business Value is very, well, valuable.  Of course, one person in your group may talk too much.  So, the facilitator must monitor that.

We find a time box of 1.5 to 3 hours is usually quite sufficient for 50 cards.  But again, if the discussion is deemed valuable by most of the participants, it is unlikely that 4 hours would be too long.

Comments:
We like them to think more and more that no two things have exactly the same business value.  Yes, for example, we may have to do 5 steps in a business process, but steps 2 and 5 are exciting.  The others are just chores that must happen. Steps 2 and 5, when we deliver them to the business and deliver them well, that’s when the big smiles come out.  Or that’s when the big money is made.

Often new stories are identified. Or a few existing stories are deemed so big, that they must be sliced and diced into smaller stories.  This is normal.

Sometimes an expert may feel he does not know how to vote on a specific story. He should take his best guess anyway. And learn from how the others vote.

Averaging: Apparently there are many who have been taught Planning Poker and told to force the team to consensus on one Fibonacci card. This is incorrect for Planning Poker.  The research shows that averaging is more accurate and faster. (If not too fast.)  And the same applies to Priority Poker.

Accuracy: Are all the cards perfectly accurately assigned BVP?  No!
Have we learned a lot more about our different ideas about business value and shared that throughout the group?  Yes!
Did the numbers help? Yes!
Can we change the BVPs later, once someone becomes ‘sure’ that one or more is wrong?  Of course, by team vote.
Will we change some? I absolutely expect it. We want you to get smarter and smarter about business value, in multiple ways. This should in part be reflected in changes to the BV points.

Epics: If an epic is worth 100 BVP, does that mean that when it is broken into 5 stories, then each of the 5 is worth 20 BVP?  No, we don’t assume that. In fact, along with Pareto, we assume that there are more vital parts of the 100 story, as well as less vital parts.  In the simplest world, one of the smaller stories would be worth 80 BVP and the other 4 stories would total 20 BVP together (the 80-20 rules).  But life is not always that simple, either.

***

Results: One clear result is that we have a BVP number on every PBI (or user story).  This is remarkable.  And no one in the group thinks any of the numbers totally suck.

More importantly (IMHO), the whole team starts to share a bunch of ideas about how the BV is distributed amongst the features.  Every feature is not equal.  This is a great thing.

Typically new stories are identified. And typically the MMFS (minimum marketable feature set) is starting to emerge.

But the main thing, to me, is that the whole group starts to share relatively specific tacit knowledge about the relative business value of each story.  Specific down to the user story.  Not hand waving at the vision level.

This work changes motivation. And it changes the behavior. Of everyone.  The business guys start to respect that the geeks understand them a little. And the geeks now understand better why business-side work is so hard.

***
The real value of all this work is getting closer.  And will be revealed soon.  Just a few more steps….

The Team and Introverts

Posted on by

I have several friends who are introverts.  And, as I get older, I recognize my own introvert side. And I appreciate it more, and accept it more. (The MBTI says I am an extrovert.)  It is to one introvert friend that I dedicate this post, a friend who has given me so many insights into people, and is the person I know who is most insightful about people.

One of the issues with Scrum is that the people in the “team” do not feel and act as a Team.
This lack of a sense of being a real Team is often key to why a Scrum implementation may be mediocre.

(And let me go further. One of the great values of Scrum is that allows people, if they want to, to have great working relationships, honest and productive ones, with a small group of people. In a very satisfying way. Srum won’t make it happen, but Scrum tries to facilitate it happening. And it happens often. Better relationships with more fun. So, we are also in search of this.)

There are many root causes for this (for a lack of a sense of being in a real Team).

One of the root causes is that the team members may include both extroverts and introverts.   Now, as such, having both introverts and extroverts on a Team is not the real problem. But let me discuss….

A good discussion of these two types is here.

As I typically see it, extroversion is dominant in North American society, and perhaps yet more so in US society.  Business managers tend to be extroverts, for example.

Fairly often, in a Scrum team, both the Product Owner and the ScrumMaster are extroverts.  And fairly often, most of the other team members are introverts.  At work in software development, introversion tends to mean being quiet, slower to explain, less interruptive in conversational style, and not explaining or sharing many things that one is thinking or feeling.

So, just from what I have said, you can see that extroverts and introverts have a good chance to see the Team differently.  Of course, any two people can see the Team differently, but an extrovert and an introvert, being less likely to explicitly talk about it, are more likely to remain with differences after some time. Or more differences.

Now, contrary to what some people think, introverts do not always like to be alone.  But they tend to want to manage their ‘together’ time and their ‘alone’ time in a different way than an extrovert would.

Similarly, introverts tend to take longer to ‘get to know’ the other team members (if they didn’t before). And tend to not ‘open up’ in the Team until they have ‘gotten to know’ them.

Also, some strong introverts are more likely never to have been on a good Team before. For example, they may not have been on a successful sports team.  This can of course happen with an extrovert too, but I think it is somewhat less likely.  If you do not have the tacit knowledge of a good Team, it is harder to assist in forming a good Team.

***

My conclusions from experience:
* Both extroverts and introverts can form good teams.  And can do so together.
* Introverts tend to form as a Team more slowly.  This delay is not a hugely significant factor, except that it must be respected.
* Extroverts tend not to understand the dynamics of team formation for introverts.
* Extroverts tend to not appreciate that their own talkative qualities are felt as intrusive and impolite by introverts. (Similarly, introverts may fail to appreciate how their behavior or quietness can be perceived by extroverts.)
* Some of the Scrum and agile ideas and practices can seem intrusive to introverts, especially if forced too much and not explained well. And if no accommodations are considered for introverts.
* Addressing these issues may take some time and effort, but it is well worth it. When extroverts and introverts appreciate each others’ qualities, it can lead to a much stronger Team very quickly.

***
Again, people who have been in a good Team can appreciate that there is something magical about it. Joyful, fun, fulfilling. In part, it is the satisfaction of doing good work together. However you describe it, it is a good thing. And we want everyone, of whatever type, to experience this part of life in a better way. We think it is possible for almost everyone.

Agile Principles and Values

Posted on by

Jeff Sutherland recently wrote, apropos the Agile Manifesto, a bunch of things about some key Agile values and principles.  Excellent stuff.

As some of you know, I think it is essential for people doing agile or scrum to know and be in sync with the values and principles. What I call “the music.”  Otherwise, the dance steps of agile or scrum, without the music….they just always dance them ugly.  Well, anyone would, without the music.

See here for Jeff’s thoughts.

And here is one quote:

Commitment to work together happens only when people agree on common goals and then struggle to improve both personally and as a team.
Enjoy.