4 Things to Improve on Today

Here are four ideas about ways to get better results with Agile and Scrum.  We try to talk about these in the initial course.  But basically always they are not heard well enough — I have gotten used to this being normal, part of human nature and the cultures we live in.

Higher Quality

“Bad news does not get better with age.”

“You have to slow down to go fast.”

“It ain’t over ’till it’s over.”

Your DOD needs to be clear that no story is done until all the bugs for that story (at least that) have been fixed, the code is clean and the PO thinks the customer will like that small feature. That is, you haven’t made progress until you’ve really made progress.

In Lean, there are many ideas around this. The Poppendiecks, as I recall, use this phrase: “Build quality in from the start.”

Yes, I know it seems like it is slowing you down to fix all the bugs, but by going slow, your team will actually go faster.

Also, remember how you feel as a customer getting a ‘crappy’ product. Do to your customers what you want done to yourself.

Sustainable Pace

This is actually a complex idea that takes a long time to unpack, but let’s start with the basics.

In the Sprint, you must commit only to what you can do as a team, and you must learn how to become fairly reliable in getting all 8+ stories that you commit to done-done by the end of the Sprint.

Learning to be reliable in this way will make you face and address key impediments that keep you from becoming reliable.

On the “other side” of this moon, we have people who expect perfect reliability each and every sprint. IMO, that is not possible with our kind of innovation work, and that search for that much “perfection” would hold back our innovation. We must have some “fail fast” (and learning).

Ready-Ready Criteria

The team (including especially the PO and also the wider “situation”) must insist that the stories going into the Sprint are ready-ready. So, the team must have good ready-ready criteria, and they must insist that ONLY those eight small stories that are ready-ready are allowed to come into the Sprint. No more “GIGO” — garbage in, garbage out.

The doers must feel by the Sprint Planning Meeting that they have all the information they need to be successful in that Sprint.

To be fair, in real life that always means they will later identify more questions.

The PO must lead the “situation” (usually largely with “chickens”) to produce the information the team needs for those 8+ stories in the Sprint we are about to start. (Obviously, right? We are building out these details iterative and incrementally as we progress from one Sprint to the next.)

I hope it is also obvious that it becoming reliable is partly dependent on having information (details on the stories) to be successful.

Having that information does NOT mean reverting to reams and reams of upfront documentation. Examples: pictures and conversation are key in this, and some documentation (e.g. lists).

Impediment List

Of course everyone knows that we should be relentlessly pursuing perfection. Or that we need continuous improvement (to me, the same thing).

In Scrum, one key way we do this is by identifying the top 20 impediments (things slowing the team down) and remove them or mitigate each one, one at a time.

So, of course the team (all of the team) must help make and prioritize a list of these top 20 impediments. Then the team can help the SM put together a Business Case for some, to get support from a manager, and then the SM can “drive” them (one at a time) toward completion.

Everyone can take satisfaction as all the key KPIs go up, because impediments were fixed or mitigated.

So, the team has a whole professional culture, with one part of it maybe called working the impediment list every Sprint.

 

---

 

One can see that all four of these areas for improvement are related.

One can also see the importance, in many or most of these, in having a good (and becoming better in all the meanings of better) Velocity for the team. We can also see the importance of everyone believing in these and trying to improve, but while not working any more hours (usually fewer) and also having more fun.

It bears repeating: As Jeff Sutherland says, “If the team isn’t having more fun, they aren’t doing Scrum right.”

Let me be honest, even after everything I have said, some people will feel like this video.

This is not what we want (well, we actually do want eu-stress, but…). So, more to explain in another blog post.

 

« « What happens to Project Managers? || Executive’s Guide to Scrum » »