Category

You’re a manager. You recently helped implement Scrum in your organization. You have received praise for this, because quality of work is now steadily improving and customers are delighted by the steady stream of product improvements. Your Scrum teams are now self-organizing. ...continue reading

As we discussed in “Specialists Are Overrated,” developing cross-skills and “T-Shaped” people in a team has many benefits – for the team/organization itself, the customer, and the individual. That’s all fine and good to say, but how do you figure out where to start? There ...continue reading

“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.” – Agile Manifesto “Watch the baton, not the runner.” – D. Reinertsen, 2007[1] Traditionally, notions of efficiency have been to minimize cost by utilizing experts (i.e. ...continue reading

(This article is part of the Beyond Scrum series) We’ve all experienced the pain of having someone impose a change on us – it doesn’t work. Forcing change conflicts with the essential human need for autonomy – No one likes being told what to do (if they didn’t ask to be). ...continue reading

(This article is part of the Beyond Scrum series) I’m frequently asked if a Tester, Business Analyst, User Experience (UX) person, Database Analyst, or Security Expert is part of the Scrum team? Short answer: Yes. Long answer: many people misunderstand the Scrum Guide. Scrum ...continue reading

… and soon to be book. We’ve had requests for a single page that lists all the ongoing Beyond Scrum blog posts in one handy spot, at least until the book that they will become is released. We’re happy to oblige! The below list will be updated as new posts are ...continue reading

(Continued from Agile Change or Adoption Always Starts with Why : 1 , 2 , 3 , 4 , 5 ) Seeing an organizational change map with seven to eight proposed major changes can feel daunting and discouraging. It’s even worse when we realize that list will keep growing as new ...continue reading

Nearly every client I work with asks me this question at some point during consulting: How large should the Development Team be? How many doers (i.e. exclusive of ScrumMaster and Product Owner) per team? The Scrum Guide offers very limited guidance, suggesting 3-9, without giving ...continue reading

We’ve seen the risks of assuming that everything is normal distribution, and also the problem with reporting a single number. What else do we need to be aware of? What can we usefully measure? Risks in Measurement Many important things can’t be measured using formal measurement ...continue reading

We’ve previously seen that our mental models often make false assumptions due to cognitive bias. Giving a Single number in a report has a similar problem. The classic Agile number is ‘Velocity’: the average rate at which your team delivers work. It is often shared as just one ...continue reading