After completing the first sprint since the training I feel I need to have sort of retrospective for myself on how I handled it.
What I did well
Always difficult to toot your own horn, but here goes:
- I believe I explained the process reasonably well to anyone that asked.
- The (improvised) Scrum Board I created was pretty good and effective I think, I’ll post a picture for comment, I specifically asked total strangers to come in and ask them if, by glancing at the board, they got a decent idea of what was happening, most people answered “Yes”, some people didn’t care, and others asked me to stop harassing them… go figure 😉
- I evangelized Scrum so well that I’ve had a few requests from people to meet one on one with them and explain in detail what it’s about.
- I protected the team well, they were relaxed throughout the sprint and were, for the most part, uninterrupted (managers sneak in when you’re not around, note to self: investigate Tesla Coil option…)
- I assisted the Product Owner effectively in generating a prioritized Product Backlog.
Where I can improve
Ok, here goes with the places to improve (that I can think of)
- I interfered too much, often guiding the thoughts of the team. This one was difficult to avoid because of my (prior) senior technical role, and I don’t think it had a bad impact, although it did not give the team the opportunity to become a fully autonomous unit.
- I ended up prompting people during the daily scrums, not good, the team needs to run these.
- I updated the Scrum Board and managed the burn-down chart, again, not good, I believe the team must run this.
- I allowed the daily scrums to degenerate into a problem solving session.
- I did not manage the time-boxing of meetings well.
- People missed meetings, or were late, without any form of “reprimand”. Not sure how to fix this though?
- Did not hold a review at the end of the sprint, bad! Must have this in future, perhaps pre-schedule the meetings at the beginning of the sprint.
- The retrospective needs improvement, again I prompted alot of the talking, perhaps the team wasn’t comfortable with opening up?
- I need to understand the finer details of Scrum better, especially around estimation.
- The team did not define DONE, I should have encouraged this.
- I allowed the sprint backlog to be changed during the sprint! Very bad.
- I did not include all the necessary people into the “team”. Important people were excluded initially (like testers) without realizing it. This contributed to the sprint “failing”(coming in 2 days late, features could not be removed) due to test tasks not being included initially.
Ok, first of all I’m a strong advocate of NOT using tools and applications to run Scrum, and that Scrum is about people, communication, visibility and transparency and that the best way to achieve this is to scream it out to the world on a nice white board, after all, you should have nothing to hide.
A colleague of mine, however, raised the idea of having a set of tools or “things” specific for a ScrumMaster to use? Along the lines loading something like a PDA with a sort of ScrumMaster Toolbox that he could carry around (like your traditional Project Manager’s with their clipboards 😉 ) that would aid and facilitate him in doing a better job? Then I got to thinking what this “toolbox” would include, I guess something along the lines of:
- Contact details and roles of all the people involved in the project (PO, Team, Management, Users, BA’s, Pizza Delivery etc), essentially everyone that can prove useful in aiding the team in completing the sprint successfully.
- A way to manage and record progress on current impediments.
- A kind of stopwatch / countdown tool to manage the time-boxing, preloaded with the predefined times for different meetings.
- A few core documents defining Scrum, or core principles, a sort of “suggested reading” list. An example here would be the Agile Manifesto.
- A place to easily jot down notes during meetings.
- Perhaps a list of “games” that can be played to aid in understanding the benefit of Scrum?
- A list of personal and blackmail information on various team members to use against them to force them to…. oh wait a minute, that would be old style management 😉
Not sure if any of this would be useful but I think it might, and I could always improve on the tool set as I go along, perhaps I’ll give it a try and see how useful it proves to be…
Without realizing it I’ve become too involved in the team, almost interfering in the Daily Scrums I suppose. It’s difficult coming from a technical background not to want to interject and comment on what people are saying. How do you approach the scenario where you have information that may be of value to the team but you do not want to dictate to the team what to do? Right now I take the route of subtle suggestions, trying my utmost not to dictate, but inevitably I’m seen as a more senior person with experience so people will tend to go with what I say, and is this not pretty much the same as dictating? But then, in the end, its about delivery, and if you can assist the team to delivery quality shippable products (without too much interference), is this necessarily bad? Or should you let the team “fail” and learn from that?
Today I sat watching my daughter sleeping and thought about just how similar the role of ScrumMaster is to that of (what I consider proper) parenting, more so from a father’s point of view. A team is like a child, you don’t interfere with their exploration and understanding of the project but rather give guidance, protecting them from the impediments that may come up, letting them grow and achieve all that they are capable of, essentially arming them with the information and skills and trusting that they can and will make the right decisions.
Now how about the role of the traditional waterfall based Project Manager? I equate that to a typical “bad” parent, interfering in the teams exploration and growing up, trying to micro-manage and force people to do without thinking if they really WANT to do it, not trusting in capabilities but trusting only in ones ability to force the team to comply to what you believe is the right way of doing things, forcing them into a mold and ruining any chance of greatness
An interesting analogy I guess…
The Certified ScrumMaster course in itself was extremely interesting and I’d recommend it to anyone who can get to it. It was also extremely difficult to find in South Africa but I finally stumbled on a course given by Boris Gloger (hosted by Peter Hundermark) and managed to get into it. If you’re thinking of going Scrum, or any agile approach for that matter, this is a definite must have on your list, not so much for the “certification”, but for the sheer volume of knowledge you’ll take away from it. Be prepared to be overwhelmed, but in a nice way…