His Scrum Master's Voice

Part time scrum master? Many software teams who claim to be "doing scrum" have people “stepping into” the role of scrum master. I frequently see project managers, development managers, testers, developers taking the reins with varying degrees of success. Often, willing team members take on the role of scrum master in addition  to their development or testing responsibilities! I also see a lot of teams going solo, i.e. doing scrum without a scrum master. This is a practice that I think ultimately prevents a team from improving and getting full benefit from the scrum process. Even if someone possesses all of the soft skills to the do the role, they still need to have the core skills and knowledge required to be an effective scrum master. The scrum master responsibilities Be the Guardian of the scrum process Be a servant-leader to the team Be an impediment remover Be an interference shield for the team Be a coach Be an agent of change I don't think tha...

What's the problem? As scrum teams, we always look to the Product Owner as the fountain of all knowledge and requirements with respect to our supply of work. Yet, I've found that often the big ideas or concepts for projects are so light on detail that POs are desperately in need of a way to translate the high level idea into a backlog of stories to get the dev team up and running We've all been part of projects where the BAs and POs lock themselves away for a few weeks with a high level understanding of a project and come back with a list of user stories for the dev team to work on. By the time the devs see the requirements, its hard to see the wood for the trees. We get bogged down in the details, the stories are sliced poorly & are not delivering vertical slices of functionality. Often there's no wiggle room. Its all MMF. We cant cut anything out. Additionally, defining an entire release worth of stories in advance which, ultimately, require change or m...

Let's face it.... estimates are always going to be estimates! Not actuals. No matter how much time we dedicate to getting the estimates "RIGHT", chances are they will still be wrong. They don't take into account the proverbial " unknown, unknowns " and in software development any item of work can contain unknowns or complexity that blow the estimates right out of the water! In traditional project management the tendency is to chase reasons for "wrong" estimates and track actuals against estimates in some kind of attempt to get "better" at estimating. As a result, teams spend a lot of time putting hourly estimates on user stories, which still have a very high chance of being incorrect, so why bother? What a waste! Instead, spend a little bit of time estimating and be just as wrong/ right in the end! I suggest a "mature" attitude to estimating.  assume that the work will take as long as it takes assume that everyone wil...