I’ve blogged before on the role of being a designer in a Scrum Team. I thought it would be interesting to micro-blog my actual experiences of participating in the Sprint.

Day 1
First day of being back in the Sprint with the developers. I’m feeling the subtle pressure (or is that motivation?) to get my tasks done on time. We are working on a high-profile project and I can’t afford to hold up development by not having the design work completed.

Day 2
The wireframes have been created but the layouts are all wrong, so I need to pull my finger out! The 960.gs CSS framework is a great help in the creation of the wireframes.

Day 3
I forgot to update my tasks before I left last night. Consequently we are behind on our Burndown Chart. I have to confess to the team that I didn’t practice what I preach. A humbling experience and I will definitely remember tonight and also cut some slack to my team in the future if this happens on the odd occasion.

Day 4
Chris Brogan recently said that “doing is more fun than planning”. Turns out he’s right. I’m enjoying keeping track of my tasks and having the opportunity to move my post-its across the board to ‘Done’. I think if you haven’t been in the Scrum you are losing a vital perspective on how the Sprint dynamic encourages a feeling of success.

Day 5
The post-its that have been bought from a local supermarket keep falling off the board. I had heard the team mentioning this, but hadn’t completed appreciated how annoying it is. The next purchase of post-it’s will be the genuine thing.

Day 6
I’ve cheated and added some additional screens to an existing task. I can’t decide whether this is utilising Scrum in a flexible way or I’m committing a Scrum sin. I’ll pick up the issue in the retrospective with the team.

Day 7
The Sprint has blipped. We have a developer unexpectedly out for two days. That’s a lot of ground to make up and we may need to take something out of the Sprint to compensate.

Day 8
In the Pre- Sprint Planning Meeting with our Product Owner we discussed a new design for a Blog Template. I promptly forgot to include that in the task so now I have to make up the time. In this situation wireframes are a great solution. Wireframes provide the developers with the information they need to get going whilst buying some time to complete the design.

Day 9
Being more physically involved in the Sprint has made me realise that the whiteboard could do with an overhaul. The board should be at the centre of the team, radiating information out to the wider business.

Day 10
I’ve gained final approval the last of my design work so my active tasks in the Sprint are set to Done. I’m back to the role of Scrum Master but I’ve learned a lot and been reminded of how it feels to be ‘in the Sprint’.

Day 11
I was reading ‘Agile Coaching’  and came across the following link:
http://www.xqa.com.ar/visualmanagement/2009/02/visual-management-for-agile-teams/
Combined with my recent interest in visual thinking, this opened my mind to the possibilities of expanding the purpose of the current whiteboard. The current board is simply a ‘task board’ and there is a clear opportunity to make it a ‘team board’.  We are shortly transitioning to VS 2010 Agile 5.0 templates. After that change has been completed I’ll talk to the team about shaking up the whiteboard.

Day 12
It’s the last day of the Sprint and we managed to bring it in on-time. This is a great achievement as we lost some resource and velocity mid-sprint. I will be including my work in future Sprints, as it’s been a great reality check.

Are you a designer in a Scrum Team? Should design work be included in the Sprint? Let me know what you think.

Advertisements