His Scrum Master's Voice

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

One of the aspects of scrum that is often poorly executed despite its simple nature is the daily stand up meeting. The daily stand up meeting is a brief stand up meeting designed so   team   member s can provide progress updates to the team in a quick, efficient manner. Here is the basic format: Daily, 10-15 minute status meeting – keep it short and sweet Same place and time every day – encourages routine and rhythm Standing up – encourages people to keep it succinct The meeting is usually f acilitated  by Scrum Master, but in practice it can and should be facilitated by any team member It is not a meeting to report progress to the scrum master – people should report progress to the team. Chickens and pigs allowed (Guests are welcome to observe but if you’re not invested in the outcome, then please stay silent) Do's Focus on these three questions –       What did you do yesterday? –    ...

As a ... developer I want ...  well written requirements with clear acceptance criteria So that ...  I understand the functionality I am being asked to build, I understand the value of building it & I know when I am finished building it. When an organisation switches to using agile methodologies, one of the most often asked questions by analysts and developers is “ Why do we have to write user stories for everything? ”  I’m sure that nothing irks a business analyst more than having to convert their beautifully crafted requirements document into a backlog of user stories. Even when teams are in the flow of using stories as currency and have accepted that all functionality needs to be specified in user story format,  the tendency to disregard or misinterpret the INVEST principles is ubiquitous. Having a ‘bad’ user story can result in confusion, waste and inefficiency. In general you’ll find scrum masters espousing the I...