His Scrum Master's Voice

Agile software development is a team sport. I see so many issues when working with software teams that I have also come across in a sports team context.  Teams are collections of people and to get a collection of individuals motivated and organised to achieve a common goal is not easy. I am convinced there is much we can learn from  the sporting arena to help us perform better as software teams. One example is the concept of  Individual efficiency vs group efficiency. Individual v team efficiency A lot of what is important for the success of sports teams is also valuable for software teams. We create teams with a view to the Team achieving more together than the individuals would on their own or because the task/ deadline before us is unachievable without extra man power.  Example : Amazing footballers like Lionel Messi, Cristiano Ronaldo, Diego Maradona could not  achieve anything on their own, they need to operate within a team structure...

  When should you split a user story? Think "when would you slice a fruit?" A banana is big but manageable you'll probably eat it whole. You might want to slice it in certain circumstances. A peach could get messy so i'd rather slice it A kiwi is small but its hairy, i'm definitely slicing that! Deciding when to slice a user story is not always easy. Often its difficult to apply hard rules. Its usually a balance of size and complexity. In the above examples, a banana represents a big story that isn't complex, should size alone determine whether to split it?  The kiwi represents a story that is small but highly complex, we know its hairy, we know we shouldn't bite straight into it but how to slice it is not obvious either? peel first? slice first? The peach represents the story I see most often. It represents uncertainty. Once you bite into a peach you discover if it is hard, soft, juicy, extremely juicy! If you slice it up first then yo...

One of the most common agile anti-patterns I witness is a compulsion towards breaking user stories into tasks. Tasks take focus away from stories The problem with tasks is that they take the focus away from user stories. Teams that focus on completing tasks risk losing sight of the real value which lies in the stories. They are often unable to see the wood for the trees. How often have you seen sprints that are? •             On day 9 of 10, but <30% of story points are complete •             On day 5 of 10, but <10% of story points are complete •             On day 9 of 10, with 90% of tasks complete, but still <30% of story points complete I firmly believe this is a by-product of too much focus on tasks and not enough focus on stories. Tasks themselves add little or no value on the...

About 6 months ago my team embarked on an initiative to upgrade our Continuous Integration (CI) & Automation pipeline. As an iOS team, the fact we already had a comprehensive suite of automated functional tests hooked up to Jenkins was impressive and gave us a solid foundation. However, our setup had started to creak at the seams. Inexplicable test failures, brittle tests, failing tests that miraculously worked if we gave them a swift kick in the nether regions and ran them again! We decided to evolve to a CI 2.0, which would be a lot more stable, massively reduce the amount of time we spent nursing our tests and ultimately give us better confidence in our system. We are not done yet but we have re-learned a number of basics along the way Lesson 1: with CI & automation, fast feedback is king Our monolithic test suites took hours to run. This discouraged developers from running them on every check-in, which is counter productive. Not running them means you increase the chan...

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...