Category: Agile

Agile stuff, the stuff I like

Next Sprint…

A new sprint has started, with a better duration (30 days, as recommended) and with proper resource allocation. We did Sprint Planning I today and the team has committed (on their own) to a Sprint Backlog that they feel they can accomplish. Had good Product Owner involvement again which seemed to help alot. Sprint Planning II went quite well as well and lasted about 2 hours, the team has laid out the tasks they must perform and are now ready to proceed with the sprint. All in all I think today was a success, the team feels so too, they appear a lot happier anyway.

Some interesting things I noticed today:

  • As much as you read how good empowering people is, it’s a totally different experience to see it in action. The general morale of people seems to be up and everyone appears a whole lot more relaxed and open, communicating freely with one another.
  • The previous scrum, during sprint planning 1, I made the mistake of being the person that physically moved stories from the product backlog to the sprint backlog (based on team commitment). It’s amazing how much different the attitude of the team was when I said that one of them had to move it, suddenly people seemed to take the commitment far more seriously. Funny how a small thing like that can have such a massive result. I think I now understand why the TEAM must update the board and no-one else.
  • Our Product Owner tried to introduce a story into the top of the Product Backlog that there was no detail for, saying that the detail would only be available 3 days before the END of the sprint, before I could step in to say that this was bad, and should probably be moved to a follow up sprint, the team members themselves raised the objection! This was pretty amazing for me to see the team defending themselves as a team, if it were 2 months earlier people would have just sat there quietly and accepted their fate.

Thoughts on the Sprint…

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.

Tools…

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…

Done?

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.

Retrospective

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…

Are you really Agile?

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.

Silos

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…

Too involved….

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?

ScrumMaster and Parenting

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…