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…
This is always a highly contentious and relative subject, what does a team mean when it’s DONE? This sort of popped into my head a while ago when I was contemplating how a person would go about making sure a team is actually performing as best they could, without interfering. My question was this, because Scrum is essentially a management process (and yes I know, its not only a process but also a “way of life” and a “mind shift”), and not an engineering process, a “green” team may not realize that a solid engineering process was missing from their way of working? Would it be your responsibility to point this out and prevent future technical debt building up, or should you leave it to the team to inevitably “fail” and attempt to fix the problem then?
Based on the input I had to this question I believe that part of the ScrumMasters role of ensuring process was being adhered to was to make sure the team had a well defined definition of “DONE”, and not only that they adhered to it but that they attempted to improve on it during retrospectives. “DONE” then becomes the instrument by which the team improves HOW they do things and can include good engineering practices like continuous integration, unit testing and essentially anything the team believes will improve the quality of their shippable product.
Along these lines I found a great article on the Scrum Alliance website by Mitch Lacey titled “How Do We Know When We Are Done“, which includes an exercise a team can go through to help them define their “DONE” list. I haven’t tried this yet, so I cannot speak from experience, but in principal it sounds good and I’m hoping to try it at the next available opportunity.
Ran the first retrospective today, the team seemed a bit apprehensive but eventually started talking, but only after alot of coaxing, which for me bordered on interfering again, but what else could be done? I explained the point behind a retrospective, to see what we did well, and where we could improve; I tried to set a relaxed mood but I don’t think it worked too well, people were very quiet for the most part. I still struggle with this part, how to get people to open up and talk about things. Eventually though we did hammer out some potential improvement areas and put those up on our impediments list for me to deals with. I guess there was some value gained from it, although I’m wondering how the team will fair once I’ve left…
I found this interesting article by James Shore:The Decline and Fall of Agile which essentially talks along the subject of people claiming to be “agile” but are not really and having this potentially destroying the true “agile” drive. People should be careful that they don’t just grab at buzzwords and ideas without realizing what they’re getting in to, especially with Scrum:
“But because Scrum works in short cycles and doesn’t include any engineering practices, it’s very easy for teams using Scrum to throw out design. Up-front design doesn’t work when you’re using short cycles, and Scrum doesn’t provide a replacement. Without continuous, incremental design, Scrum teams quickly dig themselves a gigantic hole of technical debt”
Read the full article, it was an eye-opener for me, and be careful, Scrum alone does NOT make you fully agile, it’s only a small step towards agility.
Boris has a particularly interesting and funny video on his blog post: 5 min on Scrum | The 4. Question in a Daily Scrum showing how NOT to run a Daily Scrum. I found it particulary amusing because of the similartities between it and our own Daily Scrums. I highly recommend viewing it.
Someone told me something interesting the other day…”Silo’s destroy Scrum”, which I found interesting but never fully understood the impact until today. We’re approaching the end of our sprint and only one of the stories has been completed, a severe bottleneck was building up with the test work and when the team approached the “tester” within the team that was assigned to us with the offer to have them help out with testing, they were told that only she is allowed to “sign off” testing. I explained that this would cause the sprint to fail because there’s no way she could sign everything off in the remaining time but they were not interested, I guess they’re more interested in sticking to their silo’s than the project succeeding. There’s not much more I can do about this other than to point out that the sprint will fail and just let them fail…
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…
I found a nice, concise, description of SCRUM here:
Scrum – a knol by Dan R Greening
I found particularly interesting the first comment made that clarified my questions regarding the fundamental difference of the feature/story point estimation vs the task/hours estimation techniques. It appears that the reason is pretty much around the comfort of the team and their willingness to participate effectively in the estimation process. I strongly suggest reading it…