Now the title might be a bit mis-leading, but rather than discuss one issue or observation at a time, I wanted to touch on all topics in the same post.
Recently I have been delving deeper and deeper into the issues that I have seen first hand and heard / read about with regards to Scrum and I raise them here as a point of discussion and as a reminder to myself in the future when I wonder just what the heck was I thinking about?
Multi-tasking
First and foremost, something close to home that is the subject of simian (human) multi-tasking. Often when I broach this subject with my peers there is a lot of references to “Jamie hours” and being the inhuman way of doing things – i.e. my long hours of work and investigation. In other words – get a life, turn off the laptop and go to bed! There is a really good article in Time magazine that discusses the human capacity of multi-tasking.
I say this in jest but the topic is quite serious; should a Scrum Master take on tasks in a Scrum team in as much as being in the trenches with the team whilst at the same time as being the facilitator? I asked this question recently on LinkedIn and the few replies that I got are more or less what I had expected; “of course they can” and in some cases, should. And for the most part I do agree. It would appear to make common sense that someone who is on a Scrum Team as Scrum Master would need to take on a few non-critical tasks to at least lessen the burden on the team as well as “feel the pain” that the team goes through. This is made easier when the Scrum Master is a technical lead, a senior developer or SQ lead, someone who is accustomed to the typical tasks of the team.
However, when the role is filled by someone that is traditionally Project Management based, would they be able to jump in and out of the role? I would say that it depends on the Scrum experience of the individual – someone that is new to Scrum who is re-tooling as a Scrum Master from a Project Management position, would need time to settle in to the role and go through several sprints before even entertaining the idea of rolling up their sleeves and getting stuck in with the team. On the other hand it could depend entirely on the environment that the development is taking place. If it is a highly regulatory environment (Petro-chemical industry, aviation, military, healthcare) then the Scrum Master will probably be inundated with the various QA documents that are required.
Multi-project
Leading on from the discussion of a Multi-tasking Scrum Master, the context was set for a one to one correlation of Scrum Master to team. Something completely different is a one to many mapping of Scrum Master to two or more teams. In this scenario I would imagine that the traditional Project Manager role would be better suited to swapping between teams in a given time frame – although I could also foresee there being a decrease in efficiency on the part of the Scrum Master; what would happen if the Sprint Planning for one team collided with another important ceremony of the other team, such as a Sprint Retrospective. I would say that this would probably be more problematic than the first scenario and could lead to the failure of two or more teams, not just one. There again, it does depend on the individual and the teams that they are working with.
If I can do it; so can you.
Dangerous phrase that; many have lost their shirt or worse on such a challenge. However it does raise a valid point and should serve as a glimmer of hope to those that are embarking on the path to agility.
True, it is documented that many projects that have attempted to adopt agile methodologies have fallen by the wayside because of a plethora of reasons; but it only takes one team to pull it off in a company to be able to “inspire” other teams to follow suit. The main issue I can envisage is the fact that all too often people have the belief that if team X did it and it worked for them, then let’s take that model and apply it to team Y. They often overlook some of the dynamics that permitted team X to adopt and fly with agility. A small, close-knit, co-located team, bonding from the beginning across the disciplines; cannot be compared to teams that are dysfunctional from the outset (Ken Schwaber recently gave a great presentation on “Flaccid Scrum” and Martin Fowler blogged on this very issue). Also there are teams that feel it cannot be done because they have not been through the motions of Scrum to realize that it is capable of helping them to improve their process. The important point for those individuals to realize is that Scrum is not the silver bullet – it is the de-fogger of the windscreen, blowing away all the mist and shrouded activity that goes on in other styles of software development. With the tight feedback loop, it will highlight the issues of the development process faster and with more clarity than before – providing a much needed view of the issues well before it is too late.
Many un-initiated see a well oiled fully functional Scrum team as a bunch of hippy-tree-huggers because of their bonding and team work; however, few realize that this is a result of being immersed in a routine that requires each one of them to have faith in their colleagues and to be able to self-organize. In my experience it was not a pre-requisite to joining the team, it was a by-product of agility.
So then we come back to the title statement “If I can do it; so can you”. Although this is not entirely true, there is some smidgen of truth in it. After all, what is a Product Backlog? Isn’t it a list of requirements (stories) or defects (remember – bugs are now first class citizens). What is a Sprint backlog? It’s a set of tasks to complete within a given time. The main difference are the roles of the Product Owner and the Scrum Master and the fact that the team is central to the development process and take part in the estimation and sizing of the stories. For those of us doing Scrum it makes so much sense and can often be a sticking point when talking to our non-Scrum colleagues.
An important fact to bear in mind, covered in books and presentations, is that no two projects are alike; what works for one team might not work for another. For certain types of development a one or two week sprint is more manageable because of the nature of the work being done; or a more traditional three or four week sprint is necessary because of the type of stories being dealt with. With Scrum the Sprint Retrospective is fundamental for providing the necessary feedback to be able to make adjustments and fine tune the process – without it there is no feedback loop and the system is running un-controlled.
