grant me the serenity to accept the things I cannot change, courage to change the things I can, and wisdom to know the difference
The role of scrum master exists to ensure the scrum process can flow smoothly. The role handles the administrative burden of the process, and provides a dedicated resource to ensure the process runs smoothly.
It goes without saying the wider environment the development takes place in is beyond the control of the team itself. It may affect the team's efficacy, but it will do no good to try to fight against it.
Similarly, a scrum master is not HR. Interpersonal issues may be getting in the way of the process, but a scrum master isn't the person to deal with them.
And the scrum master is not the product owner. The responsibility of what the product will be doesn't rest with the scrum master, even though that vision directs the process.
Injecting oneself into the totality of the process is a surefire path to stress and futility in the wider process. There are plenty of things the scrum master can influence, and knowing that is vital for successful delivery.
Showing posts with label scrum master. Show all posts
Showing posts with label scrum master. Show all posts
Tuesday, November 8, 2016
Friday, October 28, 2016
Burnout
I describe the agile process as sustainable development. The idea is that development should be able to be continued indefinitely. This is a big change from the usual development approach of big pushes and lulls.
It's a old habit, and old habits die hard. We know we can push harder at times to get over a line. And as individuals, we suffer for doing that. We run the risk of burnout.
We recently jumped deep into a problem that was complex and time sensitive. It required a big effort to get it over the line. At the end of it we made it, but it came at a cost. The following sprint has been deflated, with tired developers, a lack of enthusiasm and focus, and inevitably more mistakes.
The scrum process is set up to avoid this. That we agree to take in what we can handle, and base what we take in future sprints from past performance. We learn what we can achieve from what we have achieved. So those moments we go above and beyond throws that out.
It's an achievement to deliver 4 weeks of work in 2. But if the cost is tired unmotivated developers, there had better have been a very good reason for doing so.
It's a old habit, and old habits die hard. We know we can push harder at times to get over a line. And as individuals, we suffer for doing that. We run the risk of burnout.
We recently jumped deep into a problem that was complex and time sensitive. It required a big effort to get it over the line. At the end of it we made it, but it came at a cost. The following sprint has been deflated, with tired developers, a lack of enthusiasm and focus, and inevitably more mistakes.
The scrum process is set up to avoid this. That we agree to take in what we can handle, and base what we take in future sprints from past performance. We learn what we can achieve from what we have achieved. So those moments we go above and beyond throws that out.
It's an achievement to deliver 4 weeks of work in 2. But if the cost is tired unmotivated developers, there had better have been a very good reason for doing so.
Tuesday, September 27, 2016
The Heisenberg Product Owner
"We're done when I say we're done" - Heisenberg
From the development's team perspective, product owner sign off is the one stage of the development process they can't control. Ideally, this should a minimal step - all the work has been done before this point. But the product owner can always say no.
As scrum masters, our job is to try to sort this out, as this is indicative of failure somewhere along the way. The product owner is a part of the team, and thus involved in the day-to-day delivery of the project. So the question is where the failure is taking place.
There are many reasons within the team this could happen, and many ways a team could deal with it. One thing to watch out for, however, is a product owner who simply cannot make up their mind.
If this is the case, it's up to the scrum master to intervene. Simply acquiescing to the product owner is not a good idea as it breaks the flow of development. It also erases the trust and enthusiasm of the development, as their work is undermined.
If new aspects of a user story are required, they are to be turned into new user stories, prioritised, and put on the backlog. This gives a path to improvement that ensures those features are added, while not holding up the flow of development. The development team then doesn't have to worry about moving targets or feature creep.
Similarly, if user stories aren't being fleshed out enough, then there's grounds for spending more time in backlog refinement. Or, perhaps, the developers can swarm with the product owner during development.
As scrum masters, it's our job to ensure the process is running smoothly, and that includes how the product owner works with the team.
From the development's team perspective, product owner sign off is the one stage of the development process they can't control. Ideally, this should a minimal step - all the work has been done before this point. But the product owner can always say no.
As scrum masters, our job is to try to sort this out, as this is indicative of failure somewhere along the way. The product owner is a part of the team, and thus involved in the day-to-day delivery of the project. So the question is where the failure is taking place.
There are many reasons within the team this could happen, and many ways a team could deal with it. One thing to watch out for, however, is a product owner who simply cannot make up their mind.
If this is the case, it's up to the scrum master to intervene. Simply acquiescing to the product owner is not a good idea as it breaks the flow of development. It also erases the trust and enthusiasm of the development, as their work is undermined.
If new aspects of a user story are required, they are to be turned into new user stories, prioritised, and put on the backlog. This gives a path to improvement that ensures those features are added, while not holding up the flow of development. The development team then doesn't have to worry about moving targets or feature creep.
Similarly, if user stories aren't being fleshed out enough, then there's grounds for spending more time in backlog refinement. Or, perhaps, the developers can swarm with the product owner during development.
As scrum masters, it's our job to ensure the process is running smoothly, and that includes how the product owner works with the team.
Wednesday, September 21, 2016
Our Training Sprint
I suppose there's never a good way to start an agile project. On the project I was put on, almost everyone was new to the codebase, new to the project, and new to each other. So I called the first sprint Sprint 0 - our training sprint.
The difficulty was to ramp up with learning the existing product, learning the business rules, and learning to work with the tools and processes provided. With this sprint complete, here are some of the lessons I came away with:
The difficulty was to ramp up with learning the existing product, learning the business rules, and learning to work with the tools and processes provided. With this sprint complete, here are some of the lessons I came away with:
- Being on the project doesn't mean buy-in - The standard way to illustrate commitment in agile is the fable of the chicken and the pig. As a development team, the ideal is to get collective commitment, where all individuals work together to get the product over the line. It was clear when individuals were merely involved rather than committed, be it some or most of the time.
- The daily scrum is important - Perhaps the daily stand-up felt too much like a status meeting, but it was really useful for the team to know what was going on with the project as a whole. When information was shared outside of this, it didn't always get to everyone.
- Intervention should be done early - We had one member who only ever turned up for some of the meetings, and missed a lot of the daily stand-ups. Intervention about what was expected as a team member came too late in the sprint to rectify the problem. And even then, it did little to change things.
- Business As Usual consumes time and energy - We had two issues with BAU. First, when production issues arose, it took time out of the sprint to deal with them. Second, there were non-sprint activities for nearly all members dealing with that took focus away from making progress.
- It's easy to revert into a management-like demeanour - The ideal of the scrum master being a servant-leader is really difficult to achieve in practice. At times, it felt like I was driving the process too much, rather than simply guiding a self-organising team.
- The day-to-day can obfuscate accumulated achievement - At times, it felt like the sprint moved really slow. Yet when I added up what we had built by the end of the sprint, we had made quite a number of improvements. And that wasn't including some of the background tasks we did, like setting up automated deployments or getting better code coverage tools.
Wednesday, September 14, 2016
What does a Scrum Master do?
As a developer, it's always been really easy to know what my responsibilities are (and what they aren't). I do tech-related stuff, answer tech related questions, and try to be as articulate as possible at the intersection of the technical stuff and the wider business processes.
With moving into the scrum master role, this has shifted. I'm still developing, but developing nowhere near as much as before. Rather, my standard tool has switched from RAD to JIRA. I'm even finding that RAD remains unopened until time during the day.
I also find myself doing a lot of coordination tasks. The documentation about scrum masters repeatedly use the word 'facilitator', but it seems like coordinator is more appropriate. Perhaps that's indicative of less-than-complete buy in among the team, or simply the teething issues that come with trying to start from scratch. Either way, a lot of time is trying to get the right information from the right people.
The final big thing for me is the sense of responsibility. On the last project where I was purely in a development role, I had the collective commitment attitude, but I knew a lot of what was being done by my Scrum Master was obscured from me. It's a big step up - I have to be the one to make all the things happen that I took for granted when my focus was purely development.
With moving into the scrum master role, this has shifted. I'm still developing, but developing nowhere near as much as before. Rather, my standard tool has switched from RAD to JIRA. I'm even finding that RAD remains unopened until time during the day.
I also find myself doing a lot of coordination tasks. The documentation about scrum masters repeatedly use the word 'facilitator', but it seems like coordinator is more appropriate. Perhaps that's indicative of less-than-complete buy in among the team, or simply the teething issues that come with trying to start from scratch. Either way, a lot of time is trying to get the right information from the right people.
The final big thing for me is the sense of responsibility. On the last project where I was purely in a development role, I had the collective commitment attitude, but I knew a lot of what was being done by my Scrum Master was obscured from me. It's a big step up - I have to be the one to make all the things happen that I took for granted when my focus was purely development.
Friday, September 9, 2016
Busier Than Ever
One thing I'll lament to anyone who is in earshot is how little I get done. What I mean by that is that the Java tasks I've pulled into the development queue.
On the other hand, I now need to remind myself to get water. I haven't even made tea since I started in this role. And it's a deliberate and rare act to go get a coffee with a coworker from the café just outside.
So the rules of inference suggest that I must be doing something. And the most obvious answer is dealing with people.
However autistic I feel at times, dealing with people is natural in a way that development has never been. The years of developed intuitions and heuristics I have about coding don't surmount the weirdness of the task cognitively. We're evolved social interactors, not programmers.
The point I'm getting at is that it doesn't feel like work to communicate. Having a coding task interrupted by a conversation never requires much effort to switch context, but it's very difficult to break free from a conversation to do coding.
The feeling of being busy is not being able to set aside time for the tasks I want to be doing, as what I need to be doing is something that doesn't feel like work. It is work, and it is necessary work, and it sure is time-consuming work.
On the other hand, I now need to remind myself to get water. I haven't even made tea since I started in this role. And it's a deliberate and rare act to go get a coffee with a coworker from the café just outside.
So the rules of inference suggest that I must be doing something. And the most obvious answer is dealing with people.
However autistic I feel at times, dealing with people is natural in a way that development has never been. The years of developed intuitions and heuristics I have about coding don't surmount the weirdness of the task cognitively. We're evolved social interactors, not programmers.
The point I'm getting at is that it doesn't feel like work to communicate. Having a coding task interrupted by a conversation never requires much effort to switch context, but it's very difficult to break free from a conversation to do coding.
The feeling of being busy is not being able to set aside time for the tasks I want to be doing, as what I need to be doing is something that doesn't feel like work. It is work, and it is necessary work, and it sure is time-consuming work.
Subscribe to:
Posts (Atom)