Thoughts from a Thirsty Bear

So - you have invested in transforming to an agile development process. Your teams have honed their processes until it runs like clockwork, and are resilient to changing needs. Software is being produced cleanly and efficiently with minimal fuss. But there is still something missing. The software simply doesn’t do what you expect. The customers don’t like it, and won’t use it. It has annoying quirks and foibles that put people off. It simply isn’t right. What’s going on? Congratulations! You have discovered the Achilles Heel of all software development. It has to have an undamaged brain. A well disciplined agile team will deliver whatever its business brain asks of it. The team is only as good as its inputs and subsequent feedback on its deliveries. Or to put it another way, so-called ‘agile’, and all other software delivery processes for that matter, rely on sound business thinking. Make Abby Normal your customer/Product Owner, and you will be in serious trouble. At

As an experienced developer/coach, once in a while you get asked a truly fantastic question by a client who has actually done her homework, and you're absolutely stumped by it. I love it when this happens since it is a fantastic opportunity to not only learn, but also to teach the client how to solve similar questions themselves next time. This particular team had been attempting to implement Scrum for some time, with a degree of success. But one thing was bugging them in particular. How to control stories in-sprint. The advice they had been given (and the way I understand Scrum to work) was that sprints are immutable. During the plannig game, the team sets the sprint backlog, populating it with the subset of backlog stories that the team believe they can fit into the timebox. That's it - only a major event causes that to change, in which case the sprint is terminated, replanned and restarted. So when the Scrum Master asked about the 2016 edition of the Scrum Guide