Courses Coming Up

We have several courses coming up.Certified ScrumMaster (CSM) course – This is the basic course, which we recommend for everyone and for teams. We are now almost always including a 1-Day workshop (on Agile Release Planning). Strongly recommended. And, occasionally, a 2-Day workshop.Places: New York, Toronto, Nashville, Montreal, Charlotte, Durham, Charleston, etc.
Intermediate Certified Scrum Product Owner (CSPO) course – In this course we want people who are experienced with Scrum — either notable experience or a CSM plus some experience. And it deals with more advanced topics. And we also include a workshop (on Agile Release Planning).

Places: Charlotte, etc.

Scrum 201 – This is an intermediate course for any team member or manager. We must have a CSM and some good experience with Scrum. With a workshop.  (With the workshop, it gives you 22 SEUs toward the CSP certification.)  The purpose is to help you move to the next level. And to try to answer (or help you answer) all the detailed questions that come up when you implement Scrum.

Places: Atlanta.

For more details (dates, etc.) see: LeanAgileTraining.com

We like to do in-house courses, and we could do any of these courses at your firm.
And we have other courses in the works.

Some of these courses are co-taught with my colleague, David Muldoon. He brings a different viewpoint and a wealth of experience leading an agile transition at a large corporation.

And don’t be shy about asking me or Cassandra Wagner (cassandra.wagner@leanagiletraining.com) questions.

Scaling Workshop

We have added a 1 day workshop to many of our courses.  It includes 1/2 day on Story Splitting and 1/2 Day on Scaling.  Dave Muldoon and I will do the Workshop.  Dave has years of experience scaling in a large multinational corporation.

What: The workshop reviews quickly the several approaches to scaling out in the community now: SAFe, LeSS, DAD, and the ‘scaling’ ideas at ScrumPLOP.org.  And then we lead a workshop to help you devise solutions to your specific problems.  In general, we focus on scaling per se — what to do when multiple teams must work together.  Which patterns to use.

To a lesser degree, we also may address, as the group needs, issues such as agile transformation, extending agile to more teams, distributed scrum, cultural change, etc.

Value: First, we want you to keep the focus on ‘the Team’.  But the realities of many large projects are that multiple teams must often work together.  For these big projects, the messiness of scaling is inevitable.  And so the goal is to get more done in faster time. But still maintain the quality of the end product and have it deliver what the customer really needs when we deliver it.

In other words, despite all the problems of scaling, we want to be more successful than other competition. And more successful than we have ever been before.

Doing this well and professional can bring huge value. To the individuals involved, to the Teams (and the group of teams), to the firm, and to the customers.

For more information, look here.  For where and when we are doing the next workshop, look here.

A song for the season

In the western world, we call this the season of peace.

One of my favorite hymns from this time of year is ‘O come o come Emmanuel’. And Emmanuel of course means ‘God with us.’

Here is a version by Linda Ronstadt:
http://www.youtube.com/watch?v=Fsqk9FOBtuo

And below are two verses from the lyrics:

O come, Thou Dayspring from on high,
and cheer us by thy drawing nigh;
disperse the gloomy clouds of night
and death’s dark shadow put to flight. R.

O come, Desire of the nations, bind
in one the hearts of all mankind;
bid every strife and quarrel cease
and fill the world with heaven’s peace. R

***

The world is not yet the peaceful and cheerful place of our dreams. We have much still to yearn for.

But we do not lose hope. There remain men of good will. The good earth abides, and the sun rises on
a new day.
***

If asked how these words relate to Agile & Business, I would say this.

Scrum, in its simple way, wishes to release us from our chains of bondage.

Agile wishes to enable the Team to help satisfy, in their small way, the needs of humanity.

Agile wishes to see us united and cheerful.  Maybe much more than that, but at least united and cheerful.

Agile is about beauty and the soul as much as the works and days of hands. (Cf Hesiod)

We work for high purposes, although we fathom them not in every moment. Perhaps you do not agree with the purposes I suggest, but let us agree that we work for more than today’s mere wage.

Impediments – Charlotte Dec course

I am an advocate of a public impediment list.  The ScrumMaster must always be working on the top impediment. Until the Team is perfect (and it is never perfect).

And the value of that can be seen when the Team has doubled (or increased) their productivity or velocity.

The Team must be creative and aggressive in identifying all the things that can be improved.  Anything anything can be slowing the Team down.  Usually it is something slowing us down now, but it can be something Big that is likely to slow us down tomorrow.  And, again, often the Team does not mention things that they think will never change (and yet could actually change now).

In Charlotte this week, this is what the class identified:

1. Lack of (the right) people
2. Failure to include business (end users)
3. No stand-up
4. (Lack of) funding
5. People dependencies
6. Process dependencies
7. Poor time management
8. Vague / ambiguous requirements
9. Missed milestones
10. Lack of buy-in
11. No leadership
12. No management support
13. No team commitment
14. Poor attitude
15. Lack of collaboration
16. Under direction
17. Lack of decisions
18. Lack of understanding
19. Squeaky wheels (getting too much attention)
20. No compromise
21. Defensiveness
22. Keep moving the line in the sand
23. Fingerpointing
24. Unrealistic expectations
25. People who cannot say ‘no’
26. No ownership
27. Unstated assumptions
28. Poor education of process
29. No Buy-in (dup?)
30. Personality conflict
31. Management or leadership changes
32. Late delivery of artifacts by client
33. Lack of test planning
34. No clear vision
35. No failover plan
36. Direction change
37. No ‘circular’ communication
38. No fun
39. Unclear on Sprint Goal
40. Release doesn’t meet ‘minimum needs’
41. PO and SM are same person
42. Insufficient quality
43. Scope creep
44. Technical incompetency
45. Improper user acceptance criteria
46. Lack of correct skill sets (dup?)
47. Turnover (team)
48. Lack of management support (dup?)
49. Lack of business partner support
50. Poor or unorganized testing
51. Market conditions
52. Inability to make decisions
53. Old requirements (no longer current)
54. Multitasking (team members doing too many different things)
55. Crap code (technical debt)
56. Lack of career progression
57. High defects / errors
58. LONG Hours
59. Impediments not removed
60. Poor PM
61. Collaboration (lack of)
62. Poor or no backlog
63. (Lack of) LOB / PO involvement
64. No fundamental structure
65. Not enough time
66. Lack of people (dup?)

The question was broad, with no time constraint and not necessarily about Agile: ‘what are the root causes of project failure?’  So, some of the answers are from a waterfall viewpoint.  But I think most people can translate them to an agile context (where necessary).

Hopefully these help your team learn.

Agile Contracts

Jeff Sutherland did a presentation at Agile 2013 that I think everyone should read and think about.  And read and think about again.

Here is the slide deck:

http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

Agile Contracts – Question 1

Adela asks this question: Imagine we have a brand new project. And we must bid on it, and we want to use the agile-scrum method.  How should that work?

This is a good and a hard question.  I will answer it quickly here. Too quickly.  I have partly answered it in my book, Joe’s Agile Release Planning. And partly elsewhere.

Why is it a hard question?  Because business and life itself wants us to do what is impossible.  To perfectly predict the future. And to know everything in advance.  And, while we all forever will wish those two statements were true (well, at least part of each of us will), they never will be true.

So, let’s make the case fairly simple.  Imagine that the project (the work) is about what one Team can do in 6 months.

Then I recommend Agile Release Planning (as explained fully in my book).

The Team (including the right ‘business stakeholders’ or SMEs or customer reps or whatever you call them) do the following:

1. Clarify the vision. Quickly
2. Build the product backlog. In user story format. Roughly all that work divided into about 50 stories.  Not to large, not too small.
3. Identify business value on each story.  Via priority poker. Using the best BV people we can find (about 5 of them).  In about 1 hour.
4. Identify the Effort for each story.  Using planning poker. Again, using the right people for this (namely, the people who will do the real work).
5. Identify the R Factor (BVP/SP).  For each story.  Make the benefit-cost ratios more explicit.  Order the work now by R Factor.
6. Consider Risks, Dependencies, Learning, Min Marketable Feature Set, and other issues. Re-order the work as needed.
7. Do the scope-date trade-offs. In other words, identify the ‘release’ cut-offs.
8. Estimate the velocity of the team. And identify when each release will happen.
9. Do a communications ‘plan’ and add appropriate buffer (aka padding, contingency, etc.)
10. Identify the ‘fix it plan’ to fix the biggest imperfections in the plan first.
11. Start ‘release plan refactoring’ — where we refactor the release plan every sprint based on new learning.

Ok, let’s imagine further that the client asks for a fixed price.  So, after Step 10, we have to give a price to the external customer.

Now, the first time you do Agile Release Planning, I think you will get a better (slightly more accurate) scope-date-budget than you do using your current method.  Still, for the first or second time, I do recommend doing it both ways. And comparing the results, and learning from that.

By the third time, I predict that you will be happier with this agile approach than your current approach.

Will the agile approach on day zero ever be ‘perfect’?  No.

Always we guess at the buffer or padding. And always that guess can be too much (not a big problem if the customer agrees) or too little (a big problem if it causes us to go bankrupt). Notice that we as a vendor are biased to want to win contracts, and hence often ‘close our eyes’ and go with too little ‘padding’.  Often.

In any case, once we get a signed contract, I recommend running the project in an agile way.  Again, this cannot guarantee success, but it will enable us to manage the effort to better success (or a lower loss).

That’s the summary of my answer in one short blog post. I am sure I left many questions unanswered.

What if Scrum is not working for you?

I was speaking to a smart guy who had taken (some while ago) my CSM course.  We were both waiting at the Cluj airport. He made me think about this problem.

The first thing to say is that Scrum is not a panacea.  It requires hard work. Often people expect Scrum to magically make things better.  And it can have a huge impact.  But it requires a lot of effort in several ways.

One advantage of Scrum is that a manager (and the Team itself) can quickly see if a Team is not doing well.  If they are willing to look and they know where and how to look.

Here are some of the things Scrum requires to be successful.

1. A good-enough Team.  A real Team that is stable, at least for the duration of the project or the Release.  And a Team that has the ability to get the job done.
   
2. A good-enough Product Owner.  Often the Product Owner is not good enough.  The person may have been great at his or her prior job, but is not suitable for Product Owner.  There can be many problems, such as insufficient time allocation to be Product Owner, or insufficient knowledge of the role, or insufficient knowledge of Scrum. Some POs are indecisive, and some just can not organize the User Stories (or PBIs) fast enough and well enough.
   
3. A Team that understands and wants to play Scrum.  Many Teams are never given good training on Scrum.  In our opinion, that means 3 good days at a minimum.  It is true that a few (very few) really good ScrumMasters can explain Scrum to the Team, and they can do it pretty well with that ‘start’.  But it is rare.  Usually the whole Team needs direct training. Often some Team members have heard about Scrum or even played ‘scrum-butt’, and have decided they do not like it.  (Indeed one can understand that certain personality types would not like real Scrum, although most people do, if the Team makes a reasonable accommodation to the personality type.)  If a Team has 2 people (or more) who do not want to do Scrum, they can make it fail.
   
4. A willingness to engage and to improve.  In general, Business and Technology must be willing to work together (collaborate).  In general, the people in the Team must be willing to engage with each other and for the project. Often the people come from a place of distrust that does not fostered engagement.  These experiences could have happened some years ago.  So while Scrum in many ways supports and encourages engagement, Scrum alone may not be able to overcome the forces of disengagement.   Also, some firms and some people do not have the spirit for continuous improvement.  If so, leaders can possibly encourage and develop it, but this can take time. And might never happen. One version of this is that firms will not fix impediments fast enough (to enable project success).
   
5. A reasonable business situation.  Two parts to this: (a) The eventual scope, date, budget and quality constraints – as they turn out to be – are suitable for success vis-a-vis the situation of the Team.   Knowledge work is a process of continuous learning. So, for example, we must expect the Product Backlog to evolve and emerge over time. We must all sorts of things to change.  So, asking for a ‘reasonable business situation’ to include almost no change is not on.  But equally, expecting to succeed in a totally wild situation is not possible.(b) The situation includes also the Team’s suitability to the work. You can have a Team that is great for one project, and not right for the new work. The Team can be just missing one key skill set, and that can lead to failure.  Note that (b) is similar to #1 above. But perhaps by now, you see it a different way.
   
6. Adding the needed things to Scrum.  Many people seem to think that Scrum by itself, if we think of Scrum simply as Process, that Scrum itself is enough. But any Team needs more than Scrum to be successful. Often people add things to Scrum, but without even noticing.  Sometimes this is enough. Others talk explicitly about adding XP and Lean and other practices. So, not adding sufficient good engineering practices can be a problem, for example. We recommend XP engineering practices, such as adding automated Functional Testing, A-TDD, and Continuous Integration.  These often can be key to real success, or to releasing much more value from Scrum.As another example, the Team must add a technique (or 5) for reaching decisions quickly, but still with usually correct decisions. Scrum assumes that these things come up and are dealt with as part of impediment removal, but not all Teams figure this out.

These are 6 key factors for success. Usually that is 5 more than I can deal with today.  If you can get one or more of these fixed, perhaps it will ‘work for you.’

Hope they help you or a friend. I am curious as to your first 5 or 6 guesses as to why others may feel ‘scrum is not working for me.’  Or more, what could they do about it?

Another way of looking at this issue is the Scrum-Butt Test. Which I have already written about extensively.

And hello to my friend and all my friends in Cluj.

Impediments – Charleston

We just completed a CSM course and Agile Release Planning workshop in Charleston.  Here are some of the impediments they identified. They are somewhat duplicative and they are not in any particular order.  In my opinion, the list should also include automating the testing, better continuous integration, and better automated integration/regression testing.  These were issues that were discussed later in the course.

1. Untrained in Scrum
2. Imposed deadlines
3. Conflicting, competing priorities
4. Software tools are down (Env. Issues)
5. Waiting on Service Contract completion (3rd party)
6. Lacking skills
7. Scope creep
8. Lack of dedicated people
9. Not considering all that’s involved with project, like testing and deployment
10. Unreasonable timelines
11. Learning curve of AngularJS
12. Micro-management
13. Unplanned work gets added to sprint so you can never effectively plan
14. Fragmentation
15. Uninformed clients
16. Technology stack
17. Team & Organization new to Scrum
18. Diverse data sets
19. Failing to set client expectations
20. Unfunded
21. Misalignment of Work v. Strategy
22. Poorly managed; no checkpoints, milestones
23. Culture / language barriers
24. Poor or lack of requirements
25. Bad communication
26. Not sticking to agreed time table
27. Lack of technical knowledge
28. Outside development
29. Lack of knowledge in particular tech
30. Lack of customer commitment
31. Client knowledge (lack of?)
32. Lack of infrastructure
33. Less than 100% commitment from team
34. Lack of budget
35. Design conflict
36. Unmet dependencies
37. Changing requirements
38. Unclear success criteria
39. Dysfunctional development teams
40. Unclear roles and responsibilities of Teams / Members
41. Lack of project support
42. Unrealistic expectations

CSP… in demand…

We have a problem in Scrum.

First, we do well to call it more an opportunity than a problem.  We have a lot more opportunity sitting on the table that we have not grabbed yet.  Scrum, in general, can help us get a LOT more improvement than we have gotten. Yet

There are many root causes behind this problem (opportunity).

And many possible solutions also.

But I think the biggest solution is more education (more coaching is maybe next).

By more education, I mean of the whole man, or the whole team.  Not just explicit knowledge, but tacit knowledge.  Not just of rational things but also of more squishy things (that’s the technical terms for them – smile).

Which leads me to discussing the new SEU path to the CSP.  SEU means Scrum Educational Units. CSP means Certified Scrum Professional.

So, I am a big advocate of a well-rounded education.  Scrum education is what we are talking right now.

The SEU path to the CSP allows you to choose the ‘education’ that fits your specific needs. And it requires that you show significant related experience that at least indicates you have attained, both via education and action, a ‘professional’ level in Scrum.

Our specific contribution (more to come) is a Scrum 201 course.  This 2-day course plus the 1 day workshop gives you 22 SEUs towards the CSP certification.  But, more importantly, I think the Scrum 201 gives you essential information that will take your Scrum to the next level.

Next: I just received today a request from a headhunter for a CSP person in Charlotte.  A scrum-agile coach, and they want the person to be ‘good’, so they are asking for that person to gave a CSP.  Umm.  Start of a trend, I think.

What is really important?  Well, results.  Real results for real people.  What is next most important?  The ability to regularly achieve results.  (And, down the list, …does the person have a meaningful certification — and in the process of getting it, might have improved his abilities.)

ScrumButt Test (6): Estimates created by the Team

Another installment on the ScrumButt Test.

 

So, the next item on the test says: “The Product Backlog has estimates created by the Team.”

Why is this important and what does it mean? Meaning first.

So, normally in Scrum estimates mean estimates of relative size/complexity in Story Points. See Mike Cohn’s book:

Each story (or at least any story in a Release Plan or Product Roadmap) needs a story point estimate. You can’t bring into Sprint Planning any stories without Story Points. No, no, no. (If the Story is discovered in Sprint Planning, that’s a bit different.)

And these estimates are created by the Team of implementors. Those who will do the real work.

Why?

Well, estimating my own work gives me much more motivation. And responsibility. And another reason to appreciate how my work interacts with the work of others. If the Story Points come from some other person or group, they don’t have the same feeling.  The same impact.

Yes, there is a downside. Not every Team is equally good at estimating. Yes, it’s true. But we are convinced that the negatives are more than offset by the positives.

Usually, though, only the Team knows what they really can or can’t do very well.  So, only the Team can do relative estimating.

Another key reason for this item on the test is how we will, later, use Story Points to know velocity. And how we will use velocity for many things, from which I will highlight three:

• Tell some managers: “Look at our velocity. We are going at 20 work units per Sprint. Stop hoping and dreaming that we will go at 40 work units just because you want that. It’s magical thinking and it ain’t happening. And your trying to make it happen is just making things worse.”
• Tell ourselves: “Folks, we’re going at 20 Story Points, but we need to do better. Let’s identify a top impediment and FIX IT. So that we can go 22 or 25. Now! (But not by working harder (more hours).) “
• Face the truth. Velocity is a way to help us all face the truth. And take action. (Ex: With our impediments, the velocity is only 20 — someone is going to ask: “Ok, what do we do about it?”)

OK. That’s some commentary to start with. Now put your thoughts into action.

What does it mean to be 'Ready'?

Jeffry Hesse wrote this blog post. And it inspired me to write the post below.

The new Scrum Guide says that PBIs (product backlog items) must be well-understood and granular enough (just before going into) for Sprint Planning.  And that PB Refinement is the process we use to get them to Ready.

Those are not quotes, but that is how I read it.  I think accurately.

Jeff Sutherland and I and others advocate the 'ready, ready criteria'.  Roman Pichler and others call it the Definition of Ready.  I am ok with either phrase.

So, what is it?

Well, like the DOD (definition of done), it must be specific to each Team.  Each Team must define one for themselves.  And they vary some, depending on many factors.

We want the User Stories (or PBIs) to be more defined than they often are for some 'agile' teams.  But this does not necessarily mean the voluminous documentation that many waterfall 'teams' have. (I put 'team' in quotes here because I never find that waterfall teams have anything close to the team feeling of agile teams, especially a good agile team. Nor the productivity.)

So, 'ready' is kind of a Goldilocks concept (like most things in life): not too little, not too much, just right. A balance.  We definitely want to leave some room for the Team to be creative during the Sprint.

The ready, ready criteria are similar to the concept of GIGO.  Garbage In, Garbage Out. Or rather, obviously, the opposite. We want 'good stuff' going into the Sprint, so that 'good stuff' can be completed at the end of the Sprint.

I conduct courses and workshops all the time, and I ask people: what do you want in your 'ready, ready criteria'?  The context is: Imagine we are having a short meeting about 1.5 days before the Sprint Planning Meeting. What are the things you want to review to be sure the 'top items' are ready, ready?  And we assume a 2 week sprint, with about 8 small PBIs (stories) about to go into the next sprint.  (Yes, I am making lots of assumptions that may not apply to you...)

Here are some of the things they say.  This is a super-set.  First, any list would not apply to 'every' user story you have.  Second, for your specific team, you might make this list longer, shorter or just different.  Suitable for your specific situation.

So, here are some of the things I recall them saying (that I agreed with):

1. Is the US (user story) phrased well and completely (eg, the 3 parts)?  Do not forget the 'so that' clause.
2. Does it match the INVEST criteria well?  (You remember them: Independent, Negotiable, Valuable, Estimable, Sized Appropriately, Testable.)
3. Small enough? (Sized appropriately should have done that, but let's emphasize that one. A key issue for most teams -- stories are not small enough yet very often.)
4. Acceptance criteria good? (These should cover the tests well enough.  If not, add another item.)
5. Story points still good?
6. Business value points still good?  (Relative business value points.  Explained elsewhere.)
7. Questions answered? (Reasonable questions from the Doers.)
8. Tech Issues addressed?  (One simple example: Android, iPhone, Windows Phone or all 3?)
9. Enabling Spec good enough?  (A whole other discussion. Not for now. The blog has a post on this.)
10. People-work match?  (Sometimes the PB has all Java stories for this sprint, but there is only one Java guy in the Team, and he is going on vacation for a week. Yikes!  Mis-match!)
11. We still agree this is the best work for the next Sprint?  (Best considering everything, but especially business value.)
12. Team Thumbs Up?  (I want everyone on the Team to give each story a thumbs up. This is a catch-all; if something is amiss that is not covered above, hopefully someone's thumb catches the issue.)

This of course is more work if we have just identified a new story (which should happen sometimes in real life).

If a couple of stories get rejected, the PO has another day to 'get his stuff together' to get them ready for the SPM (sprint planning meeting).

This meeting is one of the two meeting I like to have to do Release Plan Refactoring. This one is short-term focused. The other is 'long-term' focused. These two meeting go together.  We do not have one without the other.  We plan longer-term so that Sprints go better.  We do Sprints to fulfill the longer-term Vision. They go together.

This meeting (just before SPM)  requires that the PO 'get his stuff together' beforehand. For example, the acceptance criteria should already have been defined, and the question is: does the Team think they work?

And not all that work is done by him (or her) alone. But the PO is responsible.  It is expected that a few issues will be found.  The POs work is expected to be good, but not perfect. (Again, it is not solely the POs work; many others could have contributed.)

We have the assumption that every day we are learning, and every day things can change. Both for the good and for the bad, and for the 'bad' (eg, maybe good for the customer, but harder for us as a Team to deliver).  Hence, we have to have this meeting at the last responsible moment.  (Cf. the Poppendiecks.)  Just before the next sprint planning meeting, leaving some time for the PO to recover from some issues.

Are some of the issues or concerns above being addressed on other days during the Sprint?  YES!  By the PO.  In some one-off quick meetings.  In some pairings, maybe with business stakeholders.  Etc. Etc. Etc.  But this is the last time where the whole Team (together) reviews the stories about to go into the Sprint. It should be a fairly short meeting (about 1 hour).

Or, so I coach for most teams.

Are there other ways to do it?  Surely.  Are they more or less successful?  I don't really know -- I have not tried all the million other ways.  I see my teams having more success with my approach.  But honestly I do not have double-blind independent studies.  Do you?

***

Two points additional points:

The Team must be motivated to do this. And I would try to include some business stakeholders. By giving the Team the 'thumbs up?' vote, that tends to get their attention.

In a 2 week Sprint, I also like to do another meeting, in the first week, that addresses the Release Planning for the longer-term. That meeting is also typically about 1 hour. More on that later.

***

I hope you will give feedback. I hope you will try some of these ideas, and that they help you. And then give feedback again.

Impediment List - Charlotte Class Nov 2013

Here are the impediments that the Charlotte class identified:

1. Too little transparency
2. No finalized requirements
3. No communication
4. SME Availability
5. Missing Required Technology
6. Resistance to a common goal
7. Unrealistic expectations
8. Outside pressures
9. Vague requirements
10. Lack of resources
11. Lack of money
12. Bad estimates
13. Hiding problems
14. Not crying wolf soon enough!!
15. Conflict (interpersonal)
16. Lack of knowledge
17. Technical debt
18. External estimates
19. Poor QA
20. No Buy-in from Team
21. Poor communication
22. Organizational structure
23. Dissatisfied Team members
24. NOT collocated

Maybe these give you ideas about your Team.

Impediment List - Montreal Class

Here are the top impediments identified by the recent Montreal class.  There may be some things that are similar (a different person might be trying to say essentially the same thing, but for his team).  Maybe your Team will recognize some good things to work on:

1. Team too small
2. Under-staffed
3. Loss of communication (with) customer, stakeholders
4. Not dedicated teams
5. Tech Debt / Bug creep
6. Scope too big
7. Too many discussions without action
8. Short deadline
9. No scope / (no) clear requirements
10. Bad estimates
11. Lack of time
12. (Lack of) product definition
13. No internet connection
14. Communication issues (Team)
15. Time zones
16. Priorities / specifications [I'm not quite not sure - ??]
17. Interference (Other tasks / projects)
18. Lost ownership
19. Constant team changes
20. Lack of support from Execs
21. Unrealistic schedule
22. Bad risk management
23. Bad change management
24. Scope is changing
25. Scope creep
26. Needs evolved (team not aware)
27. Changing scope
28. Constantly changing requirements
29. Unrealistic amount of time
30. No team communication
31. No teamwork
32. Lack of knowledge / skills
33. No communication with client
34. No feedback
35. Short deadlines
36. Imposed deadlines
37. Micro-managing
38. Lack of interests
39. Limited budget
40. Budget too small
41. Unrealistic schedule
42. Lack of tools
43. Lack of communication
44. Didn't stick to method
45. No methodology
46. Scope too big
47. Scope change

A couple of things that I noticed.
First, I asked them to identify the key root causes that lead to project failure. From their real experience.
Second, I asked "What are the biggest 1 or 2 impediments for your team now?"  Sometimes that identified new things that came out with the first question.
Now, this can happen for many reasons.  But one thing this tells me -- if you ask the question a different way, you get different answers.
They hear it differently each of these ways:

• what are the possible root causes for our failure (if we were to fail in this project)?
• what are our biggest impediments now?
• what do we need to change to double our velocity (without working any harder, no more hours)?  Assuming we could change anything around here.

You may mean the same thing, but they hear it differently. And respond differently.
Fix the most useful one thing first.  Usually small incremental steps of improvement.

Scaling, Part 2

Here are some additional patterns to consider when Scaling.

For now, consider that I am using a narrow definition of scaling, to mean only, collocated teams working together on one product in a fairly tight way.

1. Upfront Work.

To over-simplify, if we create any product, we plan, we build, we release.  That is the simplest pattern.

And, often, especially with 'greenfield' products, we have to do some 'upfront work' along with the planning.  This is true even with one Team.  I call that work I-A-D.  Infrastructure, Architecture, and Design.  There are many names for it, and the exact nature of the work can vary a lot depending on the nature of the product. And god knows, there are lots and lots and lots of variations for how people are doing this work currently.

There is so much to say about I-A-D.  Let me say only a few things here, today.

One, we must keep it small, but which now I mean mainly small in duration. It is so easy to 'take-off' 6 months to do a perfect architecture, as an example.

Two, it must be tested incrementally.  All knowledge work should be tested quickly after the knowledge is created.  And re-tested and re-tested.

Three, as we scale, we must accept that, ceteris paribus, we usually need more of it than with a
smaller effort.  Or an effort with fewer people.  It, for example, has to be documented somewhat more.

Four, we want 'everyone' in the 3 scaling teams to know 'everything' about the I-A-D.  Well, as soon as I say that, you see our dilemma.  Getting all 21 people on the same page about the I-A-D is a 'knowledge management' nightmare.  But, as soon as we have scaling, that's what we want.  So, using common sense, we do things to help the knowledge appropriately spread throughout the Group (the 3 Teams).

Ok, for today I feel I have said enough.  Good people, with common sense, can execute on those ideas.  But it is true that many of us need more detailed patterns, even for only 3 teams.  More on that later.

2. Coordination of Sprint start and end dates

In general, it appears to be a good pattern to have all Teams in a scaled group start and end their sprints on the same day (or days).

Why?  Well, they have to be coordinated together.  In part, this means that they must receive feedback together.  And then use this feedback together.

Yes, I entirely understand that this pattern, as much as it helps, also presents problems. How do you actually do it?  What is the same person needs to be in 3 meetings at the same time?  Etc, etc.  Still, it seems to be the better pattern.

Both in theory and in practice. If it makes you feel better, think of it this way: this pattern sucks the
least.

3. Changes to Sprint Planning Meeting

As soon as you scale, you want all 3 Teams in your Group to be at one Sprint Planning Meeting. But then you have roughly 25-30 people in one meeting, and a meeting that size always sucks.

So, what to do?

Clearly (from experience) you cannot have each Team working alone, in their own Sprint Planning Meeting with no 'outside' influences.  Also, clearly, having a whole day meeting with 25-30 people is very very hard.

The usual solution is to compromise.  That is, spend part of the day as a Group.  And part in individual Teams.  I like starting as a whole Group.  And ending as a whole Group.  And maybe a middle whole Group meeting where you review the stories selected for each Team.

4. Changes to Sprint Review

As soon as we scale, and we want to have the Sprint Reviews for each Team on the same day, someone says: "How can we do that?  We need the same people, or many of the same people in every Sprint Review?"  Which usually is a correct observation.

So, we use common sense.  There are many similar answers, but I'll suggest what my colleague Catherine Louis calls the Science Fair approach.  You probably did this as a kid.  Each kid or team had a table in a large room, maybe the cafeteria.  And all the parents would file in over 2 hours, and the judges too, and look at each of the 'exhibits' or 'experiments'. And go back and forth.

And that is the idea.

So, each Team continuously demos its features.  At a separate table.  And the CPO (chief product owner) and the POs (the product owner for each of the 3 teams) and the BSHs (the business stakeholders for all 3 teams) all move from table to table, trying to see what has been done, how it fits together (or doesn't), and deciding how to give the best feedback.

And in fact, team members also shuttle amongst the tables, trying to see what has been done by our Team and the other Teams, and how it all fits together and what it 'means'.

As you can see, doing this well requires some skill and experience.  And you can imagine the self-organization that also takes place each time.  And in ways that cannot be predicted.  People will see issues and identify inter-relationships that could not have been anticipated beforehand.

In any case, hard as it is (and in some ways, it is easy), we recommend the Science Fair approach.  It takes somewhat longer, but it pays dividends.

We also recommend that each Team have a short 'review' discussion. And that the whole Group have a 'review' discussion. Probably a short Group review at the beginning, and then again, at the end, to review the overall feedback and its implications.

If only scaling were simpler!   For that matter, people!  You know, if we could only get rid of those pesky customers, things would get a lot better real quick!

That reminds me of the most important advice about scaling: KISS.  Or, as Einstein perfectly expressed it: "All things should be made as simple as possible, and not simpler."

Lean-Agile Resources

We have put together some Lean-Agile Resources on this page. Please give us your feedback and suggestions.

Scrum Values

All of you should be aware of the Agile Manifesto and the Agile Principles.

To me, they are not perfect, but they are an excellent expression of many of the key ideas behind Agile.  And we should be thinking about them every day.  They require thought and common sense to consider how they should be applied on a day-to-day basis.  And explanation.  Yes, I meant every day.  In part because we humans so easily forget, and in part because the opposite ideas are also quite deeply embedded in us.

Now we come to something that I have not been discussing nearly as much.  The Scrum Values.  They are here.  Rather than being ideas about how Scrum or Agile works, they are more guiding ethical 'laws'.  A bit more like the 10 commandments from Judaism.

I guess in theory Ken Schwaber, their author, wants you do follow these while you are doing Scrum.  But really, as you read them, if you believe them, you should be doing them 'all the time.'

Let's list the key words: Commitment and Focus, Openness, Respect, and Courage.

To me, for most humans, they seem like great things to strive toward.  And things about which I will always be making mistakes.  If I am honest.

I encourage you, at least while you are doing Scrum, to consider them, and to try to follow them to the best of your ability.  And to help your colleagues follow them.

To err is divine, to forgive human. So, encourage your colleagues to follow them. And don't forget, also, to forgive yourself for your own failures.

***

Ken Schwaber, in a recent blog post here, compares the Scrum Values to the values (and also principles) articulated by Kent Beck, in his book Extreme Programming Explained.  I definitely recommend Kent Beck's book, and its chapters on Values and Principles.

ALN RDU: Joe’s Agile Release Planning

I had the pleasure of talking with the Agile Leadership Network group in RDU tonight.

First, there were a lot of smart people there and I enjoyed it.

Here are some things I forgot to say or did not emphasize enough.

1. I have different goals that many have for what we call agile release planning. With different goals, we have different methods.

2. To me, the main goals include…

Increase the motivation of the Team (fingerprints, part of the creation)
Get everyone on the same page, seeing the same elephant.
Get alignment.
Sharing the tacit knowledge
Team building
Who knew the people were most important?

Yes, there are other important goals, but these are the primary ones, in my view.

3. I am NOT proposing a ‘one size fits all solution.’

I feel confident that my ideas for Agile Release Planning work in many situations, at least common situations that I meet commonly.

But I do not feel that these ideas fit all situations.

If they work for you, fine. If not, I am ok with that.  You should use what you think will work in your situation.

4. We need to keep it simple, as simple as possible.  This helps many things.

So, I have described it simply, perhaps too simply for some. And more simply than it really is in real life.

But if your team needs to add things or make it more complex, please do. It may be useful and necessary for you.

Again, what I am proposing may also not work for you.  It has not been tried in anything close to ‘every situation’.  Use judgment.

5. The hip bone is connected to the thigh bone.

Meaning: Everything we do is, to some degree, connected to everything else. For example, to deal with some issues, one can talk about a solution as part of ‘agile release planning’ or as part of Pareto-izing the work in the course of the Sprints.  To fully understand ‘agile release planning’ one must really understand ‘everything else.’ And yet, we never have time to describe ‘everything else.’

Perhaps the biggest things I want to add are these:

We hope the conversation helped us all to think more and better.  And that that, in some way, leads to better results.
We hope we mentioned some ideas that you try to do, and that some of them are useful.
Thank you!

SAFe, LeSS, DAD, and ScrumPLOP

First, I wanted to say that I feel each ‘large scale agile’ situation is different.  The key problems are different.  And therefore, the solution(s) should be different.

And I like the idea of patterns. This is the patterns idea: “Here are some things (patterns) that others have found useful, and maybe I can steal from them, and maybe even these things (patterns) will be useful for me.”

One of the nice things about patterns is that they start modestly.  They do not boast “oh, I am sure you MUST have this tool.”  They simply suggest: “Oh, you might find this tool useful.”

Here are some places where you can steal (in a nice way).  Because I like patterns, perhaps I like ScrumPLOP best.

SAFe.  Scaled Agile Framework, associated with Dean Leffingwell. See here.  Notice the lengthy glossary.  And you will notice a whole bunch of Scrum words that have been redefined.  Or slightly redefined.  There is quite a lot there.

LeSS.  Large Scale Scrum.  See Scaling Lean and Agile Development by Craig Larman and Bas Vodde.  I really like that book.  Here is some info on the web.  You will notice both similarities and important differences with what “Scaled Agile Framework” is suggesting.

DAD. Disciplined Agile Delivery, associated with Scott Ambler.  In some sense Scott has been talking about these issues for years. But now he and others have this site. Again, some similarities and some important differences as compared to SAFe and LeSS.

ScrumPLOP. The Scrum Pattern Language group.  The two key people behind this (in my opinion) are Jeff Sutherland and Jim Coplien.  I have already said I like the patterns idea.  And I have worked with Jeff Sutherland fairly extensively, and I have only the highest regard for him. This repository covers many things, and is not just addressed to the issue of ‘scaling’, however one might define scaling.  But, it has a number of ‘scaling’ patterns.  Some of the scaling patterns include: Chief Product Owner, Product Owner Group, Scrum of Scrums, Impediment Removal Team, Organizational Sprint Pulse, etc.  You will notice that some of the groups mentioned above use these same patterns, although they may call them something different.

I hope these resources are useful to you.

Again, I wish to remind you and caution you: Do not forget the individual team(s).

If you have great scaling and bad teams, you have almost nothing. If you have great teams, and fairly weak scaling, you still have something quite powerful.  Don’t lose focus on what is important.

Why I prefer ‘Release Plan Refactoring’ to ‘grooming’

I was just doing a course with Dave Muldoon in Canada. One of the workshops was scaling. In that context, we discussed release plan refactoring or product backlog grooming.

To me, the Scrum community has many definitions of ‘product backlog grooming.’ In fact, the community has many different words for it. And it is confusing, especially to beginners.

I like to use the phrase ‘release plan refactoring’ instead.

Today, briefly, I wanted to explain why.

But first, why is this question even important?  Because ideas affect actions. If we do the action without a deep understanding of the intent, we are very likely to do the action in an ugly way.

Basics

The bare framework of Scrum does not define ‘release planning.’ Nor does it define ‘backlog grooming.’ The latest Scrum Guide does have a few vague phrases like this: “Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process….”

My understanding is that Jeff Sutherland and Ken Schwaber are not against doing specific things and using specific words in specific situations. They just feel that they don’t want to include those things in the bare framework of Scrum. Why? Well, that’s a lengthy conversation for another day.

Probably not all teams need what I call ‘release planning’ — the short, quick up-front activity of defining a product backlog and guessing at what the next release or 2 or 3 might look like.  And maybe some other things. Not all teams need release planning I guess, but in my personal experience, virtually all teams the teams I have worked with have needed some short quick up-front release planning.

In any case, we have some sort of product backlog. And, clearly in real life and clearly according to the Scrum Guide, that product backlog must ‘evolve.’

What to call it

So, what should we call that activity that makes the product backlog evolve?  (Well, the true root cause of course is ‘change’ very broadly speaking.  But you know what I mean…)

PB Grooming:

To me that connotes two chimps grooming each other. I visualize grooming my face, or a man grooming his beard, or a beautiful woman putting on make-up, or grooming my toenails.
When I see ‘regular’ teams do what they call grooming, it is mostly these things:

• breaking down stories (or PBIs) into smaller stories (or PBIs)
• Identifying new stories
• adding Story Points to the new stories
• adding acceptance criteria
• more broadly: getting the top stories ready for the next sprint

And this is great. Very important. Useful, good.

BUT…incomplete.

Usually they are not doing, or not doing effectively, the longer-term activity of managing the product
backlog toward success in the release (and here I am assuming that it takes 3 to 10 sprints to build the release).

PB refinement (the term in the Scrum Guide), when people use that term and you watch what they do, they usually do (and say) about the same things as for PB grooming.

Note: There are many exceptions, of course, to how people use these terms. I am saying what I generally hear and see.

Release Plan Refactoring (RPR) – Why I like it

First, RPR suggests that the ‘whole’ release plan needs to be refactored.  In every way.

In software development, the word ‘refactoring’ has a set of strong connotations. Of professionalism, of robustness, of having to be on top of it all the time. But also of balance and cost-benefit approach and other things. Almost all of these things apply, at least by analogy, to Release Plan Refactoring.

Also, to me, RPR helps express, to people in the Team and people outside the Team, one key idea.

The initial release plan is never ‘good enough’, and we are always trying to make Release Plan closer to what we will do to make the release successful.  So they can say tp themselves: ‘yes we have initial release planning… but immediately we embark on continuous release plan refactoring to make the RELEASE successful.’

Release Plan Refactoring also includes the ‘getting ready for the next sprint planning meeting’ stuff too. It include the ‘short-term’ stuff as well.

To me, one of the key advantages of RPR is that it connects
(a) the longer-term thinking around ‘what does the release need to look like’ and
(b) the short-term thinking around ‘what will we do next sprint’.
To use two words, it connects tactics with strategy.  And both are required to be successful.

And my feeling is…
(a) we could try to re-define PB grooming or PB refinement to include those ideas of connection, so that the community ‘gets it’ better, or
(b) we can start using a different word (well, 3 words, RPR) to express that idea.

Clearly, I think (b) is the better approach.  Am I right? (You decide.)

Now, really, the words per se are not important. What is important is that people have the right ‘tacit knowledge’ when they take an action.  They need to know, when they try to ‘improve’ the product backlog (the release plan), why they are trying to do it, and how all the different things inter-connect.  For example, how the short-term stuff connects to the long-term stuff.  How tactics connects to strategy, if I may use those words in this context.

***

If you are interested, I discuss the practices more in my new booklet “Joe’s Agile Release Planning”.  Available here.

Basic Agile ‘scaling’ terms

Below are several key terms used often when we discuss ‘Agile Scaling.’ And we want to discuss them.

Why?

Our experience is that when the community talks about these issues, they use these words in a very loose way.  The problems behind these words are quite real. And can at least be somewhat improved if we work hard and use the best ideas.  But the lack of clarity in the word usage gets in the way of good communication and good thinking.  And then the actions are muddled.

Let’s review these terms:

• Scaling
• Broader Agile Adoption
• Agile Transformation
• Cultural Change
• Distributed Agile or Scrum

What do each mean?  While the issues often overlap or come at you at the same time in the real world, I think each is different.  And that being clear about the differences can help us think and act in a more useful way.

Here are my definitions.

Scaling: Means having multiple [Scrum] teams work together on one Product.  In some sense, they are ‘in the same code base’ if it is a software product.  Two teams working together is one kind of problem. 3-7 teams is one kind of problem.  8+ teams is another kind of problem.

Broader agile adoption:
Means  to have more and more teams using Agile. Or new departments or divisions using Agile.  For purposes of this idea, assume that each team is working completely independently.  Note however: If your group is say 100 people, usually you also will be having some scaling as defined above (ie, here and there, at least, several teams are working together).  Very common.

Agile Transformation:
Means mainly having the whole organization become truly agile, in values, principles, and practices.  Not just the ‘development’ department (or whatever name your firm uses for that group).  This often covers many different kinds of issues.  However, it is fair to say that just introducing Scrum to a few teams almost inevitably leads to a kind of ‘transformation’.  It tends to affect, as we say, ‘everything.’
It can be said that even a small company with one Scrum team will have a kind of Agile Transformation. And then a company of 100 people people will have a more complex Agile Transformation. And then a company of 300,000 people might have a far more complex Agile Transformation.

Often this term is used to encompass ‘everything’.  Meaning, all the changes needed in a big company ‘going agile’.  ‘This is our Agile Transformation initiative’ is a sentence one could hear.  OK, but then those two words many lots of different things to different people.  Even with my relatively narrow definition, it starts to mean too many disparate things, in my opinion.

Cultural Change: This is where the culture of your group (team, department, company) must change because of Agile, or to make Agile more successful.  This is almost always needed to some degree with most any of these other changes.

Again, cultural change is often assumed in the phrase ‘agile transformation’.  And in a way, that is fair, almost always.

But at least in theory one can imagine a situation in which no cultural change is really required — the firm though could still need an Agile Transformation in terms of hierarchy, incentives, HR things, ways of managing, etc.  I think it is useful to think of the culture change as a separate issue.  Yes, as we are seeing, all these different things interrelate.  This is in part why the words have been mushed together.

Distributed Agile or Scrum:
Covers two situations:
(a) one team has members in more than one location.  In fact, if people are on two different floors, that is a ‘distributed’ team. Often distributed also means that at least one person is in a different time zone than another person on the team.  And, typically, the wider the time zone split, the worse the problems.
(b) two or more teams must work together, and each Team is in a different location.

You might want to call (a) distributed team and (b) distributed agile.

I also use the term ‘disbursed agile’ to mean a team where no two people on the team are in the same place.  I find this to be particularly hard to deal with. Typically.
Many people assume that ‘distributed’ is the biggest problem in scaling (or agile transformation — whichever their favorite word is). And yet many firms can be doing scaling or agile transformation without doing any distributed agile at all.

***

Maybe there are more terms to add to this list.  And maybe these definitions can be improved. But it is one set of eyes on these ideas.

This post does not try to provide any solutions. In fact, it barely hints at what the real problems are. The only purpose is to give you some basic tools (ie, words) to start to think about what the problems really are.  If we identify the problems better, then we have a better chance to fix them properly.

I have mentioned these ideas to a few other people. Some have been, at least I thought, rather cynical.  And with some reason, I think.  They see lots of consultants and others running around using words for marketing, and the feeling of these people is that consultants running around throwing around words is not helping. I have some sympathy with that concern.  But I have not become cynical.

Second, I think they feel that these words and issues have become hopelessly muddled. I think their feeling is that talking about them publicly is a waste.  Or, at least, humorous in a cynical way.  (Maybe talking about these words in one room with 7 people is useful, but not in public.)  Again, I do agree that getting many people to agree on common definitions of these words is almost hopeless.
Still, I obviously think that discussion in public is not hopeless. Although it is difficult.

Key Impediments – Toronto

I am a big advocate of a public impediment list.  (Yes, for some of you, I am saying this again.  I think in general it bears repeating and repeating in a company.)

There is some discussion to explain skeptics WHY I recommend this. I will not attempt that discussion here (but maybe I should soon in another post … I have in the past, just search).

By the way, I recommend only ONE list of all impediments.  Some people are tempted to have several lists. One for org impediments, one for agile adoption issues, one for Blockers (things that block a story from getting done, is the usual definition), one for impediments (however they define that term).  To me, ALL these things (and more) are just different types of impediments. We we need only ONE list.  And work from the top.

In the Toronto class this week, the group identified these impediments.  They are not in any specific order.

• Poor skill Team (skill sets are weak)
• Non Formed Teams
• Source Availability Planning
• Under estimate scope by Prod Owner
• Lack of investment (don’t remember what kind of investment the person wanted)
• Lack of requirements
• No product road-map (vision)
• Scope creep
• Lack of Comms
• Final product quality was poor
• Project team over-worked
• Senior leadership commitment & mission
• No clear product owner
• Unrealistic Time/Scope commitment
• Low accountability
• Project over budget
• Lack of ownership individuals
• Business down – layoff of developers / teams
• Ownership to one person
• Technology hurdles (ie, infrastructure)
• Too Bossy, No Teamwork
• Not able to remove impediments
• Low communication
• Not doing demo (sprint fail)
• No connection between Dev & Business

Pretty good list.

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.

What is culture? And do we start to change it?

Some of us in the Agile community think:  an organization's culture needs to change before agile can be fully adopted.

This certainly seems to be true.

Let's define this more precisely.  The idea is this:

Before a company can realize the full and extreme benefits

 of lean-agile-scrum, it must change its corporate culture to 

be consistent with lean-agile-scrum values and principles.

 This can seem a daunting task.

But, first, what is culture?

To me, it is that air in which we live and breathe and have our being.  Well, not exactly that.  But is the culture of the main group or groups within which we live.  It is what is in our heads, as a group. It is values and norms and common behaviors.

So, it includes the idea that we are not individuals (so much), but rather we are more 'groups', and that the key ideas or values or principles or norms of the group 'control' to a large extent, our behavior.  Without our even thinking about it.

Now, from our point of view in terms of the change, in many ways, the new behavior is more important than new thoughts (or subconscious thoughts or feelings).  But we want the people to be autonomous, and 'do it on their own', so we want the thoughts or feelings to be there, so they naturally do it, naturally act agile, on their own.

Moreover, we want the broader culture to be consistent with agile.  With lean-agile-scrum.  People typically find, if they do things consistent with the culture, they seem relatively easy. And, if you do things counter to the culture, it usually is hard or harder.  So, having an agile culture should mean that agile will be more successful. Other things being equal.

Ways of changing

Asking people to change their culture is difficult.

Well, clearly to ask itself is not difficult. But to ask, and then expect results, and then to know if results actually occurred...that is difficult.

Let's consider 3 days to make cultural change happen:

1. Talk to them.

Depending on your point of view, this is either remarkably successful or remarkably unsuccessful.

I mean this: My expectation is that normally this should have almost no impact.  And yet, for a few people, it can have an impact.  Sometimes.  For a period of time. So, compared to my expectations, this can be remarkably successful, sometimes.

There are many ways to talk to them, or with them. Many different contexts, different people who can do it, frequency, etc, etc. A lot more to discuss than we will discuss here today.

From another point of view, many people expect this approach to be very successful. And it is remarkably unsuccessful.

2. Get them to act and 'reward' their good behavior.

Pretty close to classic behaviorist theory.  Maybe it works. It is not tried often.  And, it seems, it must be tried a lot to have it start to replace the old culture with the new culture.

 Actions come in many shapes and sizes, including speaking original words.  And rewards come in many types.  Rewards must be close in time to the action.

Frankly, this is treating people like monkeys. I don't want to believe in this theory. But it is there.

3. Have them experience something

What you want to do is get them to help you create the new culture.  You teach them a bit, and then they become self-acting.  By teaching themselves things, by building the culture themselves.

And it turns out that if you are clever, you can start to build this self-reinforcing system.

But, according to Kotter, it starts with a gut experience. An experience that is fairly profound. And that gets them to commit to changing themselves. Kotter calls it 'a sense of urgency.'

Let me say again.  Changing the culture is the work of many months (or more) for a group of people, and then the new culture will start to replace the old culture (or, ultimately, be overwhelmed by the old culture). So, it takes many months and many people before it starts to be self-sustaining.

So, given the likely counter-action by the original culture, what you need it not one experience per person, but multiple experiences.  Over several months (or longer).

Then, once the new culture is established, it must be sustained.

If it is a culture of mediocrity, then sustaining it is less of a problem. But if it is a culture of high achievement and difficult tasks, it can take extra energy to maintain it at a high level.  (I think this is the case for lean-agile-scrum.  It has many pleasures, but it is demanding in terms of energy commitment and overcoming of obstacles.)  Now, focus on the successes and pleasures can clearly be part of sustaining the new culture.

Let me make clearer what we are doing with this last method.  We are not just asking them to change. We are asking them to join us in changing the culture. Maybe quickly, maybe little-by-little.  But we are asking them to participate in 'making it happen'.  Over time.

Here is where we start to bring in the word ritual.

***

So far I have over-simplified. To explain some key basics.  Much that I dd not say, but a start in setting out a basic framework.

One tip bears repeating: It is easy to start out to 'change the culture' and end up accomplishing nothing.  Be careful.  Pick your battles.  Prioritize. Get small wins.  Build on progress.

It is, in many ways, a battle in the air over ideas. But make it concrete and tangible too. Show the new culture in actions.  Then others can help you.

Lastly, let people tell you the truth.  As one example: If they can't explain well why we do a specific thing in Scrum, do not punish them for being human. And give them some support.  Maybe a local person in their location to support the change.  Changing the culture is not easy.

Scaling: How about the “Don’t do it!” option?

There is a lot of talk lately about scaling. And, to some degree, scaling is necessary and good.

They say that only truly professional Teams try complicated plays.  Or should try complicated plays.  Most ‘lesser’ Teams do well to stick to basic blocking and tackling.  I think this is wise advice for most teams.

Scaling by its nature is complicated. It is attempting the impossible. To keep a large ‘blob’ of people fully informed about what each other is doing.  No, not 100% informed about every detail, of course, but ‘fully.’  Meaning: I, as a member of the blob, know everything I need to know to be effective (and to not be counter-productive) about anything that anyone else in the blob is doing.

Impossible.  Human communication is very difficult in a Team of 7. Just about impossible in a blob. Unless it is extremely slow moving. Which of course is what blobs naturally do.

So, how about this?  Instead of 50 people in 7 teams, let’s take the ‘best people’ from that blob, and make one Super Team.  The hard part is finding ‘super’ team players.  Or maybe better to say: The hard part is appreciating the value of being a team player over having a so-called ‘extraordinary skill-set’ (usually a specific skill or knowledge domain in our business).  We all have seen that a bunch of high-ego people often won’t work together well.

Still, form your Super Team.

Maybe the other people can be useful, but the first rule is ‘do no harm.’  Get them the heck out of the way!!  And let the Super Team run.

Can these other people doing anything?  Well, yes: mow the grass.  Honestly….they can do some ‘spade work’ that never gets in the way of the Super Team.  They can do things that enable the Super Team to go faster. They can prepare things. But the key thing is to optimize the speed of the Super Team. (Ceteris Paribus.)

It’s an alternate idea.  From a business point of view, often faster, cheaper and higher quality.  And higher innovation.

Will this approach work well every time?  Is it the best option available?  Not sure; probably not.  But often it is the best option available.

Deliver Faster

Why do we want to deliver fast, and then faster?

Well, the first reason is...that's what the customer wants. The customer is thirsty. They want a drink now. She does not want to wait for 3 months to get a major delivery of 200 water bottles. A drink now, please.

The second reason: time to market.  In this context, I mean we need a good poduct to market before the opportunity goes away.  Before the competition beats us there, or before the most important problem has changed.

Third.  More and more my clients are having re-organizations rather frequently, so someone in an Agile class quipped "we need to deliver faster than the next re-org". This meant within the next 3 months.

So, yet another reason to deliver fast. If managers change, then you can deliver what the outgoing manager wanted (with a bit of luck), and then start marching forward with what the new manager wants.

But there is more. We need to deliver faster because we get more feedback.  In this way, we have a smaller release, but learn more quickly whether it is on target or not. And, taking that feedback, we can modify the next release. Or perhaps have no more releases at all.

This minimizes risk. This minimizes WIP, whose value...if we wait long enough...will always eventually go to zero.  So, we have minimized the potential loss in value of the WIP, the work-in-progress.  We have reduced the risk.

All the reasons that make us want to deliver something faster.

Yes, it must be a minimum marketable feature set.  But we are learning that 'minimum' is smaller than we thought.

Deliver faster.  This is our goal as a Team. It is not a goal that the managers stupidly foisted upon us. It is a real need in business.

Then the question becomes: how do we do that?

4 Announcements

We are happy to announce 4 things.

1. New LeanPub Book: Joe’s Agile Release Planning.

Some of you may have seen a prior draft. It is revised now. And published. I expect to have some further revisions.  I seek your feedback.
You can see it here.

2. New Workshop: Story Splitting (Feature Decomposition)

This is a 1/2 day workshop, with David Muldoon. We are doing this workshop first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

3. New Workshop: Scaling

This is also a 1/2 day workshop, with David Muldoon. We are doing it first in Toronto, Oct 11, in conjunction with a CSM Course (Oct 8-11).  (This and the Story Splitting workshop form a 1 day workshop offering.)   We will be doing it at other locations soon.  See Courses at LeanAgileTraining.com.  See here for details about the workshop content.

4. Lean Agile Training page on LinkedIn

We have started a Lean Agile Training page on LinkedIn, here. Please visit and follow us. And please tell us what you think we should provide there.  What do you like?  What should we add?  What should we subtract?

More success with Scrum - How to get it

Fernando Cuenca has an excellent blog post, here.  He discusses what he learned at Agile 2013.

I will summarize his learnings in my words.

1. The ultimate question is: how to have a better life for yourself, your Team, and your Customers.  And then, specifically at work, using Scrum.
2. Measure velocity. And specifically, look for increases in velocity. Otherwise known as: acceleration.  Measure velocity in Story Points.  But don't become obsessed by a number -- look at the bigger picture.
3. Get the user stories 'ready, ready' before the Sprint Planning Meeting.  It will increase velocity. In part by reducing churn in the sprint.
4. Have a clear DOD.  Definition of Done.  Being ready, ready will help you get to done, done.
5. Do a better Daily Stand-up.  Who knew the Daily Scrum was for the Team to self-organize and self-manage?  (I am teasing all of us -- not teasing Fernando at all.) I like this formulation:  'what did I complete yesterday that helps the Team achieve our sprint goal?'  The Team focus is important.
6. Measure Team happiness. (See Jeff Sutherland's Scrum Log.)  If they aren't happier, you aren't doing Scrum right.
7. Focus on fixing the top impediment.  By the ScrumMaster (who is driving it), by the Team, by people outside the Team. Non-trivial work.  You have a biggest impediment until you are perfect.  And even after you win the Super Bowl, you are not perfect. (20 push-ups for imagining that your Team won the 'Super Bowl of Scrum' when you have never even compared your Team to a 'best in my city' Scrum team.)
8. No bugs (use XP practices, etc). Ok, 'no identified bug survives the sprint'. May seem impossible to some of you, but it is not. (Yes, some few bugs will still be identified in production.)
9. Clean, well-refactored code base. (use XP practices, etc). Makes it almost easy to change.
10. Develop a 'continuous delivery' capability. (By removing impediments over time.) Almost always, this pays tremendous dividends, even if you almost never deploy after each sprint.  At least you will be able to decide when to deploy (when you have a Minimum Marketable Feature Set) and then deploy 'instantly'. One reason: The bad news doesn't get better with age.

This is a great list of 10 'things to do.'

Fernando adds some comments about the cost of implementing the XP practices. To me, these costs seem too high and the benefits are delayed too much.  In my experience, at least.  But, he is right to say that the costs are significant. Still, the benefits are far more significant!

Hope these ideas help you, your Team, your Customers.  You can get a lot better (we all can).

Story Splitting (Feature Decomposition)

We have added a 1 day Workshop to our course in Toronto. And will add this to courses in some other cities.  The one day is composed of 1/2 Day on Story Splitting. And 1/2 Day on Scaling.

What.  Story Splitting is always required. We always need smaller stories in the Sprint. Some experienced Teams do this regularly and quite effectively, but lots of less experienced Teams struggle with this. So, the immediate purpose of the workshop is to move them beyond the 'struggle' stage more quickly.

Value. Story Splitting is not the only factor that can assist your Team to achieve the following benefits, but it is important, and often key.

• More reliability. When they 'commit' to 20 story points, with the smaller stories, they are more likely to hit 20 story points.
• Faster velocity. It seems paradoxical, but by taking the effort to get to smaller stories, the Team can get more done. If they do it professionally and cleverly.  Many reasons for this. One of my favorites is: "The bad news doesn't get better with age."  Also, the Lean community explains this well.
• Fewer and smaller failures. Sometimes a Team will not get a story completed in a Sprint, as they 'committed.'  To some degree, this is normal in innovation work. Unexpected things come up.  If we have small stories, first the likelihood of failure goes down.  Second, the degree of failure is smaller. We don't fail on 50% of the work, but rather on only 13% of the work (as an example).
• Team Morale is better. For the reasons stated above. Sometimes the Team will not at first understand the value of small stories; and it may seem like extra work to them at first. This must be explained. But once they are over that hurdle, Team morale should go up.
• The sense of 'traction' is better. As suggested above. Almost every day we can see a small story being completed.

See here for a fuller description of the Workshop.

Impediments - From the Charlotte Class in Sept.

Here are some impediments identified in an exercise by the Charlotte CSM Class in September.

Some duplicates (or very close to), some overlaps.

May this list make your Team more creative about identifying impediments. May it lead to your Team fixing the highest priority impediment first.  Which might be: making a public impediment list.  And then working on the top item each day.

The List:

• Personal Agenda
• Hierarchical approach
• Understand tasks (tasks not understood, I think)
• Structure (too much)
• Micro Mgmt
• Pressure & Stress (too much)
• Over-communication
• Mtgs (too many)
• Priorities all-over (...the place)
• Undefined requirements
• Complexity
• Synergy issues (dysfunctional team)
• Skill sets (Engineers & DBAs)
• Focus
• Resource Constraint
• Customer Sat.
• People and Resource Availability
• Lack of stakeholder buy-in
• Waterfall
• Too many priorities
• No business value
• Multi-tasking
• Lack of Mgmt Support
• Lack of communication
• Conflicting Priorities
• Out of Scope
• Limited Resources & People
• Lack of Resources & People
• Over-budget
• Mgmt Disagreement
• Unclear Requirements
• Lack of Requirements (in some areas)
• Inaccurate requirements
• Ego
• Leadership
• Lack of Buy-in (by Team)
• Lack of budget

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.

Scaling: Don't forget the Team

What do you have if you have good scaling but all the Teams are terrible?  Nothing.

What do you have if you have lame scaling, but all the Teams are good?  Something that is still pretty darn powerful.

***

What often happens when 'everyone' is talking about scaling?  They forget about the Teams.  And the Teams often feel "we're not important anymore -- we don't do anything important".

As Tolstoy described well in War & Peace, the HQ people in the military always think that 'they' really fight the war.  It is the natural and inevitable tendency of these people to think they are important.

When in fact the battle is won or lost in the trenches.  By the small units on the field.  Or so Tolstoy thought (or at least Prince Andrei thought).

Another problem: When we scale we put really smart, overly-clever people in charge of 'figure out the scaling'. Well, it does feel like a complex problem.

But guess what?  The biggest thing we need in scaling is... Simplicity!  A simple clear way of communicating between the Teams.  Something where everyone knows 'how the machinery basically works'.

And guess what the clever guys do: They make it so complex, that only they understand it. And everyone in the Teams feels lost.

So, my advice is simple. No matter what I say, many of you will still do scaling and too much 'scaling'.

So: Remember to put (keep) most of the focus on the individual Teams.

***

This is not to say I am against all scaling. If Napoleon is invading, I will get as big an army as I can get to fight him.  (And there is a rough analogy to our work.)  But God, watch out for the law of unintended consequences.  Focus on the small units. And build your Seal Team 6... and 1, 2, 3, 4, 5, 7, 8, 9....  Loose, self-organizing units that can self-organize (a lot) how to interact with each other.

Frameworks to Scale Agile – Some comments

First, here is a page that starts to explain SAFe.  SAFe is one of the better known ‘scaling agile’ frameworks.  http://scaledagileframework.com/

You should also look at Larman and Vodde’s book: Scaling Lean and Agile Development.  See also their LeSS (Large-Scale Scrum) framework, here.

Next, Jeff Sutherland and Jim Coplien and others have worked hard on ScrumPLOP.  This is the patterns around Scrum.  This deals with more than scaling, but includes many scaling patterns.  See here. As one example, see the Chief Product Owner pattern.

Next, here is a blog post by Ken Schwaber.  Many of you know that Mr. Schwaber is one of the co-creators of Scrum.
http://kenschwaber.wordpress.com/2013/08/06/unsafe-at-any-speed/#!

Next, here is a longer blog post by David Anderson.  Many of you know that Mr. Anderson is the main advocate behind the agile “Kanban” method. (I say it that way because I think of kanban first as the ‘signcard’ idea that Lean uses.  Which is notably different.)
http://www.djaa.com/kanban-anti-safe-almost-decade-already#!

A few comments by me:

First, I think Dean Leffingwell is a good guy who is trying to help.  Some want to paint him as the devil, which seems silly. But whether all our ideas that ‘wish’ to help are, in the end, truly helpful…. that is another question.

There are a lot of ideas in SAFe that I know and love. What troubles me more is the ‘weight’ of the whole framework, not individual things in it.  The implications of the whole thing.

In general, I think Anderson and Schwaber don’t agree very much on ‘things’ in general. Hence, I am struck by is how much they agree about SAFe.  Their concerns to me are very similar.

I simplify their shared concern as this: ‘SAFe has some good ideas within it — maybe even all the individual ideas are good — , but the strong bias will be to implement it as a single big turn-key heavy almost ‘waterfall’ solution. No matter what the stated ‘intention’.  And no matter what the particular situation. And this is likely, in several ways, to be unhelpful.’

I want to note that I understand Dean Leffingwell has said that he does not want SAFe implemented that way.  To which Schwaber and Anderson might say: ‘Well, he may say that, but de facto something else happens. I’d rather discuss the reality than his words.’

My general biases are these:
* some scaling in some situations is inevitable.
* In general, some scaling is not really necessary or useful. The answer should often be: “One real Team, one really good Team, would be better for this.”  How much is ‘some scaling’?
* in general, all scaling is ‘ugly’ (my technical term for it, which I need to explain more).  Mainly because communication across more than 7 people is really hard.  No amount of lipstick on the pig will make it less ugly. Still, some things might make it ‘more effective’.
* in general, all scaling would benefit by a KISS approach — keep it absolutely even more simple than you can possibly imagine.
* all talk of scaling inevitably mis-directs attention away from the core engine of activity: the Team.  This is not good; minimize it!!!
* inevitably, ‘smart people’ involved in ‘the scaling part’ want to assume more importance and more control than they should.  Greater importance and control should be given to the Teams.
* in the end, there are trade-offs.  OK, you must decide your trade-offs in your situation. BUT: KISS. KISS! KISS!!!

Some notes:
* I think that the term scaling should be restricted to having multiple [Scrum] teams work together.

* I think ‘broader agile adoption’ should be used when you want to have more and more teams use Agile. Perhaps all teams.

* I think Agile Transformation should mainly mean having the whole organization become truly agile, in values, principles, and practices.  Not just the ‘development’ department (or whatever your firm calls it).  However, it is fair to say that just introducing Scrum to a few teams almost inevitably leads to a kind of ‘transformation’.  It tends to affect, as we say, ‘everything.’

* I think Distributed Agile or Scrum should be restricted to these two situations: (a) one team has members in more than one location (ideally only two locations and only one time zone), or (b) two+ teams must work together, and each Team is in a different location.  I would prefer that (a) was called ‘distributed team’ only.

* As it is now, all these terms are used quite loosely.  So that real communication is low and mis-understanding is likely high.

* In general, many firms attempt (a) Scaling, (b) broader agile adoption, (c) Agile transformation, (d) distributed agile (both versions) — all at once. As soon as one recognizes this, the benefits of KISS are apparent. (One hopes the benefits are apparent.)  As if by magic, the word cluster-bomb comes to mind.

What does Scrum do?

To be honest, Scrum doesn’t ‘do’ anything.  Scrum is just a basic framework (which includes some values and principles).  It depends completely on the people on the field.

In a similar way, Bill Belichick doesn’t do anything.  (Belichick is the coach for the New England Patriots, which while he has been there, has been a very successful football team. Someone thinks he is worth a couple of million per year.)  He does not play football. He does not win any games. Himself.  His teams, on the field, executing his ideas and following his program and his coaches, they win the games. (Or lose. They have lost some Superbowl games, even.)

Scrum is just a bare framework.

You and your team must add things to it.

You and your team must execute well.
You and your team must remove impediments (ex: big fierce burly enemy linemen).
You and your team must run up the middle.
You are your team must risk an interception.
You and your team must recover from mistakes on the field.

But Scrum helps.

What can be said for Scrum?

Well, it replaced all the “stupid, in the way, bothering-us” stuff with a fairly light framework.

This is actually a huge improvement. At least with Scrum we are no longer held back by all the stupid stuff that was waterfall (or maybe the chaos of our homegrown ‘no-process’). That is actually a huge plus. But that part is only a win in the sense of removing a huge negative.

Scrum is mostly ‘not in the way’.  Helps us see.  And, if we agree to see the truth, Scrum will help us see the real situation we are in each day, and at the end of each Sprint.

In other words, Scrum sets up a basic learning process.

You and your team must actually see, learn, improve.  And then win.
You and your team must use the tool well.

***

To be honest, I see some people who expect Scrum to magically fix everything. It does not.

Scrum helps you see (and mire than just see), …but still you and the Team must do the hard work of fixing, one thing at a time, all the impediments. For example.