Yuval Yeret shared his Scrumban - taking Scrum out of its comfort zone slides from the Israeli Scrum User Group event this week. It's great to see this. I think Yuval shows great courage and I hope his audience are open-minded enough to give his thoughts a fair hearing.

development

Doubling velocity (story points done-done in each sprint) usually means we must improve several things:

a clearer definition of done

no [known] bugs escape the Sprint

Helicopter Managers – who step in too soon to rescue thereby depriving the team to think and solve problems together.

Absentee Managers – who would not step in at all irrespective of whether the team has all the necessary skills to tackle the problem.

If the team has sufficient skills to solve the problem then give them space else ask questions to help them get unstuck. This would help in building the skills eventually.

Has the team made changes that make a difference to them as a result of the retrospective?

Has the team explored a variety of different topics/areas, or do they stick to pretty much the same agenda around continuous improvement? What is the balance of change/improvement work vs. working on the product?

For example, try looking at technical practices, teamwork, or customer relationships... choose what ever seems most relevant to bound the discussion. That might help the team dig deeper and find issues that have more significance for them (now...I'm sure the other changes were significant at the time).

Second getting them to understand Story Points, a seemingly meaningless measurement, seemed to be a non-starter for them.

deal hours first This is where ideal hours came to the rescue. They were far more able to wrap their heads around ideal hours i.e. if you lock the developers and testers in a room with zero interruptions, how long would it take. I figured that once they got their initial stories estimated in ideal hours down, switching to Story points will be easy as they would have established a scale of reference to compare against. This approach worked really well. They're now into their 3rd Sprint and now that they have an existing scale, whether the number is in ideal hours or story points or dog points for that matter, it really doesn't matter any more. If you're new to agile estimating, and you're having trouble coming to terms with Story Points try this first and then make the switch later.

Identify the technical leaders within projects; those that are “self-driven to produce quality results on time … combine technical ability with enough people skills …are trusted and respected by both their managers and fellow developers, are determined to make the team succeed, and usually live the work.” (Chief programmers, Chapter 2:  A Practical Guide to FDD).

Sell them the vision: if you cannot sell these people on the benefits to them, their colleagues and the organization of the new way of working then something is wrong

Provide in-depth training and on-going coaching. It is better to have a single lead person trained in-depth who can coach his teammates through the basics than to have the whole team trained on the basics with no-one on the team to turn to when the basics are not enough.

RFPs the Agile Way -- or -- Fear and Loathing in the Procurement Department