Leading the pack – 1st full agile sprint

Yesterday I started my first sprint with a full team of developers and boy is it exciting.

Last week, I was given one of the lead developers to spend a week prepping our application for the work we are embarking on for the next 2 weeks.

The sprint itself is one that players of Dungeons And Dragons would love CoD players fear. It is a code re factoring project which ultimately means a hellalot of grind.

With the documents, wireframes and basic page examples we had created last week the team set off, assigning themselves tasks from the planning board and getting themselves up to speed.

The first few hours were interesting, lots of questions were asked and I sat down with each of my team to pick up their queries. Then unknowns started to appear. They were of course expected, we weren’t going to be able to cover an entire applications layout in just one week but this is where the agile methodology really stands its ground.

As we come across unknown screens, they’re noted, the issues highlighted in the task notes and the developer can then move onto the next screen. I can then pick up the flagged screens, analyse them for similarities and quickly construct basic classes to resolve layout issues. The team is notified of the new class, the guide is updated and I am left to make the changes to the screen where the issue was raised so it can be used as a reference doc for future screens.

This way nobody is ever held up by incomplete styles or layouts.

The burn down is looking ok, it’s spiked a few times where we have added new tasks to resolve coding issues which hadn’t been factored into the original scope, there will always be a few and this is why you hold¬†contingency¬†time on the end of your sprint.

Once again, I cannot help but wonder why other companies don’t embrace the agile methods more, even if it is only a 70% effort – you can’t run an efficient scrum without a minimum of 5 members.