So here’s my idea of a Digital Scrumboard – som parts of it is a little out in the future, but bear with me.

The Scrumboard consist of four main parts:

1. A huge touch screen
2. A camera
3. A 3D-projecter (here’s where I get a little out there…)
4. Speakers.

Lets do the obvious components fist: Camera and speakers a self explaining.  Point is to record for streaming images and projections to other locations as well as the for video and audio documentation. Speakers a bi to get the highest possible quality – I probably overdid a tad…

For the screen – the actual scrum board – it can be seen as a huge iPad, you interact by touch. This will make it possible to give it the traditional whiteboard-feel, just with digital enhancements. I’ll make this the next post, to keep this one short.

Stay tuned.

Thomas Erickson and Wendy A. Kellogg describes social translucence as: making team members and their activities visible to one another. Lets take an example from their text:

We have a door between the stairwell into the hallway. The door has one design problem, when opened quickly into the hallway it’s likely you might slam into someone on the other side. To solve the problem a sign was put on the door reading “Please open slowly” – not the most effective solution. If we build a socially translucent system into the door by putting a glass window it’s obvious it will have the desired effect of people not slamming doors into each other.

• As humans we rely on our ability to see – we react on the preset of other people.
• Through the glass I see the person on the other side, hence as a normal human being I don’t slam the door into you.
• And the ‘I know that you know I know’-reason from the earlier post: You know I can see you through the glass so if I for one reason or another choose to slam the door into you, you will know i did it deliberately – hence I get into trouble.

So, I talked about scrum as a framework in the last post, now to the next step – scrum as a framework for distributed collaboration.

As discussed one of the key elements when working with scrum is the sharing of information, not only related to  a specific task but everything you communicate on a daily basis with the people around you. It’s all the ‘Hey, is this colour to bright?’ or ‘Can you remember how to make jQuery do this?’. But for now let’s stick to the information that’s directly linked to tasks in the project – in other words knowledge sharing and collective interaction.

Let’s divide or scrum process into three main situations we’ll look into in this post.

1. The sprint
2. The Daily Stand up
3. The Sprint Meeting

The three situations have different things to take into account but on the other hand share a lot of the same challenges. Lets go into further detail.

3. The Sprint Meeting

If we start fra the back – 3. the sprint meeting – in the case I’m looking at it’s the only part that’s held face to face. Team members and the product owner is present as well as the scrum master. I covered this in the post on scrum so for now I’ll keep it at that.

2.  The Daily Stand Up

How do we support the daily stand up? It’s not just a ‘I did, I do and I’m gonna do.’, it’s more complex than so. It’s about letting others know where you are in your process of getting the tasks done in order for them to act accordingly. And vice versa. And furthermore for you to know that they know – and no, it’s not a quote from some comedy. We can take this concept to our final point nr. 1.

At the daily stand up the team gather around the scrum board to get the big picture on how far they have come with the tasks they committed to in the sprint. Post its – or similar – describing each task it moved from todo -> in progress -> in test -> done as the task it self moves through this process. The scrum board gives a simple and visually easy to understand ‘progress bar’  as well as informing all team members on where their collogues are and what they do. When distributed  the team looses the advantages of having this meeting face to face. When mediated through technology like text messaging, phone or conference information gets lost. Not only task related information but all the (ore or less) subtle signals you catch from your colleagues during a face to face meeting.

1. The Sprint

During the sprint team members need to communicate, tasks are send back and forth and knowledge needs to bare shared within the team. When describing and discussing technology later on I’ll go much further into why and how it’s so crucial to virtual teams to share this information.

So, this would be the frame for our groupware technology for distributed scrum teams.

Everybody’s talking about scrum. So what is it and why should we use it – if at all. Honestly, it’s a discussion I don’t want to get into, as with any other project process framework, it has it’s pros and cons. For this project I’m just gonna conclude it’s what’s used .

If you’re dying to know more about scrum check out the following links:

• Hamid Shojaee video about scurm on Youtube
• All knowing Wikipedia

Scrum in practical use

Scrum is a framework providing some work practices and artifacts to support the process and is implemented differently in different companies and teams. I’m gonna skip the theoretical discussion on where it’s used “right” and wrong” and just present how the process is being carried out in the context of this project.

It will look something like his.

To run through the steps quickly:

1. Some workshops to determine what it is we’re making.
2. If possible a small pilot project.
3. Specifications written as user stories
4. Test and fail fast – better and cheaper to fail now than later
5. Sprints and sprint meetings – as may as you need
6. Feature Freeze – no more new features
7. Code Freeze – no more coding…in theory
8. Performance test – may lead to more coding.
9. Grand opening of the project
10. Hypercare – users will break it!
11. Let’s see how e can improve in the next phase

In this project I’m gonna focus on the sprints and how to facilitate the work process when the team is geographically distributed. Scrum is made for in-house teams sitting next to each other being able ti communicate whenever they need. This is ont possible to the same extend when distributed.

What this project is about is how we can facilitate the daily stand up meetings through IT-system(s) and how to incorporate artifacts like the scrum board and the burndown charts. It’s about knowledge sharing, about bing up to date on other team members and about keeping them in the loop.