My mind wonders…

I was impressed today when, having been away from the team for some time, I came back to the office where we’re currently located and found them deep in conversation around a whiteboard. Nothing noteable about that you say? Agreed. What I found impressive was that they had identified between themselves that they needed to start doing analysis for next week’s Sprint and had allocated a time (and for any future Sprints) where they would carry out that task.

This ties in very nicely with what I mentioned in my first Lessons Learned post about the Development Stream needing to be front loaded with an Analysis Stream. How analysis and Scrum fitted together had been bothering me for a little while, I’ve actually been constructing a longer post on the subject as I thought that it was worthy of a separate post. The team have chosen to do the Analysis Session on a Wednesday afternoon allowing the Analyst to then have 2 days to produce something for the Sprint Planning session at the end of the week, it also allows them Thursday morning to carry on if they need to overrun.

This means that the Analysis Stream would, in my mind, work ahead of the Development Stream (Similarly, if we had a test resource on the project I think they would work one behind the Development Stream), how far ahead is a little unclear to me though, too far and you could loose the feedback loop which I think is one of the main benefits of an Agile approach and not far enough would slow the developers down, I guess it relates to the timescales that you are operating under, 2 or 3 days suits us at the moment, on another project that may differ.

Anyway, I continue to be encouraged by the way the team have taken to the approach that we have adopted, so much so that I am going to try and introduce something else, at the planning session this week, I intend to take the work items that will be carried out and add them to a Kanban system (I’ll post a picture of ours at some point – it seems to be the done thing). I’m doing this for 2 reasons, my old boss always said that I should try and implement it and, up until now I have never found a team that I thought would take to it and secondly, we have another developer starting in the team and it will aid my tracking of who is working on what and the estimates. I’ll report back on how it works out.

Following on from my post last week, here’s what I noted as lessons learned from Sprint 2.

• Having a Proposition Up Front Will Aid the First Week of Planning (Pt. 2): I said last week that this would aid planning, I should have added requirements gathering too. I think the real lesson though is that I need to understand what the idea is and how far advanced it is. I had initially thought that if, like this project there was no clear idea / proposition that the project should be given an additional week to go through a rapid ideas generation period. On reflection though, where does that end? Will I eventually be prescribing that we put together a proposal and then go in to a design phase and then in to a develop phase and then in to testing? Frightening. The answer, well, I’m still unsure, my current thinking is that I need to consider any future projects like this thoroughly before the first week and tailor that week accordingly.
• A Small Self Organising Team Can React To Change Quickly and Effectively: This one sounds quite obvious, and it is, to see it happen in front of you or at least to hear somebody suggest that the team switch tack completely is quite something to witness. This brings a number of other lessons yet to be learned I am sure, for example, controlling the frequency of change.

There are a couple of other things which I haven’t mentioned, I’m currently composing a couple of articles one of which I intend to post soon about Analysis and Scrum.