Category

(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

(Continued from Agile Change or Adoption Always Starts with Why : 1 , 2 , 3 , 4 ) We’re already familiar with how Story Maps are an excellent way to help development teams visualize the work involved in building a large product. They act as stepping-stones between the initial ...continue reading

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2, Part 3) Most organizational change effort starts with a vision. But problems arise if the vision was created by a few executives who went off-site, as that can result in a vision that doesn’t address ...continue reading

(Continued from Agile Change or Adoption Always Starts with Why: Part 1, Part 2) Sense Your Current Culture To understand the culture you’re attempting to change in your organization, you need to measure (or sense) the current state and then map that state to a model. The model ...continue reading