Tag Archives: scrum

Our Scrum Masters

Recently, I was asked by the Human Capital Management team at work for a list of specific requirements for our scrum master role. I obliged, and at the top of my head wrote the following:

A scrum master is someone who –

  • has great written and verbal communication skills
  • understands the software development process, has experience working with product managers and programmers; preferably with customers too
  • well-versed in the practice of software testing, enjoys exploring systems, thinking in various perspectives, and putting on different sorts of hats
  • delights in shouldering a support role to the software development team
  • is a self-starter, regularly updates himself/herself on what’s happening in the software development and testing industry
  • someone who takes pleasure in a bit of scripting / programming is a plus (Webdriver, Watir, Cypress)

It’s not an extensive list, and I may have gotten some of the details wrong about what skills scrum masters are supposed to have based on the ideal definitions that’s out there in the web, but it’s alright. These are just the things I initially thought would suffice, in the context of what I and my team does and experience most days. Our testers are scrum masters too, and I’m proud that so far we’ve been able to make stuff work on our end.

Scrum masters in other places probably need a dissimilar set of requirements, because those are what allows their systems and processes to be effective, and that’s just fine.

A Daily Standup Reminder

The programmers are the usual suspects in a daily stand-up ritual. Each of them take turns talking about what they did yesterday, what they will be taking on today, and what problems or successes they’ve encountered. It is a must that their voices are heard clearly by the scrum master and the product owner, who are there to monitor the project’s progress, and their co-developers, who most need to be in sync with code changes.

I hope the team scrum master and tester are sharing the things they’ve been busy doing too; as far as I know, they work towards the same goal as the people who write the code. Maybe tasks are not yet ready to be tested, maybe the team is cruising well on the development iteration, still their thoughts and opinions are valued – about ongoing tasks, about current processes, about possible ways of moving the team forward as awesome as possible. Share tests scripts and important use cases, honestly tell the group where they’re at, ask clarifying questions whenever needed, show test results, suggest process changes that could deliver more fun and creativity, say thanks to everyone who’s been working hard.

About Sprint Data Gathering

Looking at a sprint document I designed a few years back (and updated by my scrum master colleagues), what I see are all sorts of data: planned total story points, actual finished story points, planned total task hours, actual finished task hours (total, per developer, team per day), burndown chart, attendance records, retrospective notes, tickets notes, returned tasks, unplanned tasks, underestimated tasks. So many information being gathered and compiled every sprint iteration; it’s not really too difficult to document but it does kind of takes away a good chunk of time to manage. Back then when we were new to scrum I thought that crunching numbers will provide insights as to how we can improve estimates and productivity, I thought that maybe we’d become faster and better at what we do after performing some mathematics.

It turns out that it doesn’t work that way. It turns out that estimates and productive behavior is a lot more complicated than it seems. It turns out that personalities and preferences and work environment and team dynamics and other small stuff we don’t pay attention much to play big roles in being good at software development as a team. Data about these things are not shown in the sprint document, and I don’t have the slightest idea how to measure them. So, looking back at all these stuff we’re trying to analyze, I’m haunted by questions: Which data are important enough to keep taking notes of, sprint after sprint, to keep reviewing? Why are they important? How do these data help me define how my team improves in succeeding iterations? Are they just pointing out problems but no solutions in sight? What if I stop documenting these data, would that help me focus my energy towards other possibly more important to-dos?

Takeaways From Godjko Adzic & David Evan’s “50 Quick Ideas To Improve Your User Stories”

Actively seeking and reading interesting blogs related to the work that I do leads me to interesting places. This time around, I ended up purchasing a copy of Godjko Adzic & David Evan’s 50 Quick Ideas To Improve Your User Stories e-book because I was looking for ideas to implement better software development at the office. I knew there are ways we could be more effective in shipping software (we’re good, but we’re still far behind bigger companies in terms of project releases) and it looks like the lessons in this book will definitely help us improve our agility, one small step at a time.

Here are some of my favorite lessons:

  • Always ask if a story improves the current business goal.
  • Impact maps can help organizations (and teams involved in a project) in understanding why a story needs to be developed and released in Production or why it may only be a pet feature and doesn’t need to be considered right now.
  • Measuring team velocity and creating burn-down charts only tell us how well members of a team is working with each other. It is a negative metric, like blood pressure, and is great for finding out problems, if those are what we’re looking for. It is bad for estimating how far we are from achieving a goal, because the team can be moving at good speed but going in the wrong direction.
  • Instead of waiting months to finish a project (and accomplishing a goal), why not find ways of shipping to customers piece by piece by piece in much less time and get feedback? There are many ways of splitting stories.
  • Stop using numeric story sizes for estimation. Use ‘too big’, ‘too small’, and ‘just right’ instead. This way, teams will be forced to make each story into something they can manage and they can go ahead in implementing them. Stories that are ‘too big’ often needs more discussion and planning, which can be started in later sprints. As for estimating how many stories can be squeezed in for next iterations, just use the running average number of stories the team was able to finish for the past few iterations.
  • To determine if a project is a successful experiment, test the stories with real end-users after release. See if the expected change in behavior (goal of the story) occurs by measuring changes. If the goal is reached, great. If not, revisit the assumptions that were set for the story. Successfully providing a feature to users doesn’t mean that the business goal is achieved.

Godjko Adzic also writes about impact maps in more detail in his other book, Impact Mapping, if you’re interested.

Five People and Their Thoughts (Part I)

From time to time I stumble on really interesting articles and videos about software testing and software development practices being carefully thought out and analyzed by great testers and developers. I’d like to share five of them to you today.

The Not Too Obvious Goal

For every new software project or system feature created during the scrum development process, product managers, developers, and software testers all toil to make things work as they should and could be. The goal to satisfy the client’s needs, the need to meet the requirements before the deadline, motivates everyone to produce remarkable work. This is great.

In between great works of software development, meanwhile, there’s another goal that’s not too obvious to everybody. After every sprint, in retrospective meetings, people share whatever it is that went well and issues that they thought delayed their progress. Possible strategies to improve processes are discussed. The aim is to be better at what they do in the long-term, to setup systems that pushes for growth after each project, to become eventual masters, not to settle for anything less excellent.

A Survey On Scrum

My boss recently decided to survey the team about the team’s outlook on the scrum process, asking for comments and/or suggestions. Here’s what I was able to say:

The good thing about having the scrum in the current development process is that it forces everyone in the team to plan and really think about their goals for the next few weeks. This is definitely better than just reacting to desired software modifications from clients all at the same time. What it gives is the time to work on the most important issues first, with focus.

As such, the scrum process, the sprints, will really work well for everyone if the teams (ideally) are able to work on their respective projects with focus, with no or very minimal unplanned side requests. Estimations are easier to assess in this case as well; it is very hard to properly estimate the amount of work a team can finish if they are continuously disrupted by issues outside of the current project.

Other things:
1. Most, if not all, dependencies should be finished before the sprint starts.
2. No overtime work.
3. Add a day or two in the sprint duration, for regression testing and bug fixing. OR reduce the amount of estimated work to be completed in each sprint in order to fill in the tests.
4. Consider enough additional time in developer estimation for proper code reviews.