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.)