The Organization of our Scrum Course - 1

Why is our Scrum course organized in the way that it is?

***

Is a Scrum Team organized?

Well, a good Scrum is usually described more as adaptive than organized.  Of course, we can debate the meaning of these words, during a day or during a sprint, or during a release.  I would rather that the Team be adaptive, than follow an organized plan, as one example.

This is one small reason our Scrum course is not organized in a strictly logical way.

Second, why do Scrum Teams fail?

Well, there are many reasons.  Do Scrum have a problem because Scrum is too complex?  No.

The attendees have no problem with the explicit knowledge around the bare framework of Scrum. But, they do often have problems ‘getting it.’

In fact, the bare framework of Scrum is very very simple. (On purpose.)  Understanding the explicit knowledge around that is quite easy.

Hence, I am not worried that I need to organize the course so that the attendees build in their minds ‘complexities upon complexities’ about Scrum.  If Scrum were complex, for example, like Calculus, then we would have to organize the course a different way.

Again, Scrum is ‘holistic’ or interdependent.  One cannot understand one part of Scrum without understanding how it works or plays with another part.  ‘No man is an island’ as John Donne famously said.  So, I like to continually weave from one thing to another, so this weaving becomes embedded in the ‘back’ minds of the attendees.

So, one of the key problems is tacit knowledge. Getting the tacit knowledge and all that it means into their heads.  Honestly, not just into their heads, but their hearts, their souls, their guts, their bodies.

Continues in part 2, tomorrow…

Agile Manifesto - History

As you know, the Agile Manifesto and the Agile Principles define agile, to many of us.

These statements were written and agreed to in 2001. There has been some debate about them, but they provide some excellent principles to remember as you are doing agile.  If your practice embodies these principles, then I think your agile will be much more effective.

So, we do well to remind ourselves of these and think through what they really mean.

In this regard, there was a recent discussion…what were the original writers thinking when they wrote these words.  In a google group discussion, Jeff Sutherland said quickly ….

They evolved in about 15 minutes in the order described.

The first one had data from Bell Labs showing a 50x increase in performance by getting individuals and interactions right. Martin Fowler was writing on the white board and proposed we say OVER processes and tools so we did not rule out their use, but focused on what added more value.

The second one I think was brought up immediately by Ron Jeffries. We have seen in Silicon Valley and in Europe for complex development that failure to test and fix inside the sprint fully integrated can take 24x [more] time to test and fix in the next sprint. So you can go 24 times faster with working software.

The third one I was the most passionate advocate as I was CTO of what is now GE Healthcare at the time with 3000 screaming hospitals on my case. We know now that a good Product Owner can generate a 4x increase in production.

The final one was the mantra of the XP folks in the room so we all agreed it had to be there. 65% of features are never or rarely used and waterfall builds them instead of letting new requests into the plan.

You should read Jeff Sutherland’s blog post on this: The Agile Manifesto, Elaborated.  There is also a link there to a yet longer discussion.

'Teams That Finish Early Accelerate Faster'

This is an excellent article: Teams That Finish Early Accelerate Faster.  It is by Jeff Sutherland and others.

It addresses a key issue:  How do we get Scrum teams to be more successful?

One answer is that ‘scrum’ teams are not always doing Scrum. More likely, they are not doing all of Scrum.  And we know from experience that not doing all of Scrum (which is a bare framework) is often the key reason for the reduced success.

But there are also things to ‘add’ to the bare framework of Scrum.  And here are the key ideas mentioned in Dr. Sutherland’s article.

• Stable Teams

We need the Scrum Team to be stable.  It is hard to improve if the people are changing.  Key to success.

• Yesterday’s Weather

This is a well-known agile/scrum pattern.  Knowing your velocity, only ‘commit’ in the sprint to the same velocity that you succeed in finishing last Sprint.

Note that you can get better, increase your velocity, by removing impediments and then by completing additional (small) stories at the end of the Sprint.

• Swarming

This is a less well known pattern, one where there is less understanding about how to do it well. There is also general discussion in the community about ‘swarming’ but it is not about this pattern…at least not directly about this pattern.

The idea is that each story in the Sprint has a Captain. If a story is in trouble, then everyone in the Team should offer to help the Captain, and in general the Captain must be open to help. The Captain can decide how much help is needed, will be useful…although he/she may get feedback from the Team on his/her decisions.

This is similar to ‘single piece continuous flow’ in Lean.

• Interrupt Pattern

Implement a simple process to minimize and handle urgent, high-priority interrupt work during the Sprint.

• Daily Clean Code

Fix all bugs in less than a day. Aim to have a completely clean base of code at the end of every day.

• Emergency Procedure

If the Team gets behind in a Sprint, have an identified ’emergency procedure’ to execute to get back into a good position quickly.  (Specific steps are proposed.)

• Scrumming the Scrum

Identify the single most important impediment in the Sprint Retrospective and remove it before the end of the next sprint.

• Happiness Metric

Ask 2 questions on a 1-5 scale.  If the Team average drops, gather the Team to identify the root cause and address it.

• Teams that Finish Early Accelerate Faster

The Team should only ‘commit’ to what they know they can accomplish ‘reliably’ (70+% of the time).  Once they become reliable, then they can use the other patterns to accelerate more (increase the Velocity).

Apparently we must repeat: We are accelerating without working any harder (any more hours).  And only working reasonable hours.  How? By working more cleverly and with greater automation, via fixing impediments.

***

I summarized some of the key points of paper, sometimes loosely, with some of my ideas.

There are many other great ideas and further explanation in the paper itself.

Enjoy!  And help you Team get better, and help your customers have a better life!

***

Comments welcome!

Automate Testing!

Dear Joe,

In the course you emphasized how important it is to do may things….seemingly from the start.  One of the ones was automated testing.  This will be very hard for us to do, I think, at my company.  Were you really serious that we must have automated testing immediately?!?!?

Thanks, Janet

****

Dear Janet,

[First, I must confess that I made up this email or letter.  I did have a student who I think had this question, but she did not phrase it to me this way.]

Glad you asked.

First, in many places it is almost impossible to do all of Scrum on Day One.  So, I am not upset and you are not terrible (if you thought you might be) if you do not do all of Scrum on Day One.

We do expect you to implement change continuously, so that eventually you can do al of Scrum with you team.  Never never give up on that.  And do not think that you have done Scrum until you have done all of it (all of the bare framework) with the right attitude.  This is important, we think, because it will give you better results (almost every time).

Then, automated testing is beyond the bare framework of Scrum (as are many other great agile ideas).

Again, we are not upset that you cannot get ‘full’ automated testing to happen on Day One.  Again, that is not possible for many people in many situations.

And, again, we expect you to change things at your place, and start implementing some automated testing soon.  As I said, you are not really agile in software development without automated testing (and continuous integration, etc).

How long will it take you to do that?  Well, that depends on many factors.  But, mainly, you have to start something now.  Something perhaps very basic.  Such as, have the coders or developers automated (or more fully automate) their unit tests.  Get a good unit test tool for your situation (eg, JUnit) and start building.

It may take a long while before your automated testing is truly professional. You can do Scrum before you get there, but the real power of Scrum expands significantly as you automate the testing.

You may have to convince managers to spend money  This may take time.  You may need to access the Scrum community to get evidence to convince the manager(s).  But you will get there eventually.

Hope that helps.

***

Comments please.