2 Week Sprints!

Both of our applications that use the Scrum development framework have now halved their iteration cycles from 4 weeks to 2 weeks.

This felt rather daunting at first. I was worried that there just wouldn't be enough time to actually develop something of billable, business value for our customers. However, I have been pleasantly surprised by the universal acceptance of this change. Developers, analysts and managers all report to less confusion about the relevant content of the Product Backlog - this has many cross-overs with some Getting Things Done principles regarding removing clutter.

With this one simple process change we now feel much more 'sprinty': able to really focus on a smaller number of work items. We have also doubled the amount of feedback measured and adaption possible; velocity is also more meaningful.

So, highly recommended. I wonder if we'll move to a one week sprint as Ken Schwaber currently recommends? Xtreme sprinting!

Can Distributed Teams be Truly Creative?

As I've mentioned before, I lead a distributed, UK-based development team. We have been using this model for a number of years now and have produced and shipped a number of quality, profitable products.

I spent all of yesterday in the same room as another developer as we blue-sky-brain-stormed-out-of-the-box (!) some solutions for an ongoing problem. What I noticed most was how easily ideas started to flow when we were both just walking around the same home office, sipping coffee, tossing a rugby ball and occasionally glancing at the same screen.

Now, we are an Agile company - and I'm not just paying lip-service to this morning's most fashionable meme. We ship regularly and often, we Scrum every morning and we hold retrospectives after every 4 week sprint. However, are we missing something? Are we missing an environment that creates those sparks of genius that turn a profitable product into a remarkable product?

Working from home has some enormous advantages:

• No daily commute.
• Perfect, individual working environment.
• Flexible hours (being home for the delivery or boiler service).
• No overtime barrier. It's easy to stop at 6pm, put the kids to bed, walk the dog and dine with your wife then carry on with work immediately after.
• ... the list goes on.

How, then, do we combine the benefits of home-working with those of being in the same room? My understanding is that teleportation is still some way off. There is also the issue of cost. Do we rent more office space that we can sporadically utilise? That would seem like an unwarranted overhead.

I apologise if you've now read all this way, made a temporal investment in this article and are just waiting for the payback answer... cos there isn't one! Sorry.

In my defence I think my development team will be meeting more regularly and we'll see what that spawns. I will update this post as and when I discover new solutions. Alternatively, contact me with your ideas and we can start building a list of suggestions.

"We Don't Have Time to Implement Scrum!"

This is a statement I hear frequently in my company from POs and managers. Ken Schwaber recommends that, when starting out with Scrum, not to implement it on a low risk, manageable project 'cos everyone will say "So what? It was gonna work anyway!". Much better to pick a project that is critical and is just about to fail.

Problem with that is that it's nearly impossible to convince the PO to allocate any time to setting up even one sprint. Today I was on the receiving end of "We just need to get it done!". "Well", I said, "when's that gonna be?". "I don't know, but we don't have time for all this planning and stuff.".

On one hand I do understand where the PO is coming from but at what point do you stop and make some space to implement something that should reap massive benefits?

Slightly disappointing, but how can you argue with the PO?

Separation of Responsibilities in a Scrum Team

We are now halfway through our second 2 week exploratory sprint. The team consists of 4 pigs:

1. Team Member, Developer, Scrum Master (myself)
2. Team Member, Tester, Product Owner
3. Team Member, Developer
4. Team Member, Tester

Both developers have fully embraced the methodology and the associated tools (TFS); however, the other 2 team members have greeted it with a less-than-enthusiastic attitude. Both seem to view it as an unnecessary overhead.

2 specific problems have arisen...

1. Product Ownership

The Product Owner (PO) has a very relaxed attitude to who can add items into the Scrum. To him this is sensible as we should all have an understanding of priorities. To me it makes everyone's job harder. I think I wanted the PO to have total responsibility for this area so that the Team Members (TMs) are free to just develop what's in front of them. This also removes any burden of 'why did you do that?' from the TMs.

2. Time Boxing

The PO is quite unwilling to defer tasks even though it is clear from the Scrum Burndown Chart that we are not going to finish all the work items in this sprint. Does this matter? I have tried to explain that one of the benefits of time-boxing and this trend data is that we can make decisions early and inform stakeholders and customers that certain deliverables will be delayed. This can now be done weeks in advance of the deadline (as opposed to the morning of the delivery!).

Hopefully, these issues can be addressed more fully in the retrospective.