Team

In Scrum, a basic principle is to deliver working software at the end of the sprint. For a webapplication, it is often obvious what this entails. Other than the functionality to be delivered, it also includes such things as text labels, error messages, help texts and user documentation. But for content-oriented websites (such as company sites), this is more challenging. After all, many websites feature sections for news, maybe a portfolio of projects or customers, a profile and a list of services or products. Traditionally, many (smaller) webdesign shops approach these projects by first completing the website with dummy content…

Some teams treat their Sprint Backlog as a 'Sprint specification document'. When they start a sprint, they begin by exhaustively identifying and estimating all the individual tasks that are necessary to complete a user story. This results in Sprint Backlogs with overly specific tasks such as 'write stored procedure for X', 'set up class design for Y', or 'implement and style button Z'. Sometimes, tasks are also distributed within the team, before any work has actually been done. Although this approach gives the team a (theoretical) sense of understanding what needs to be done, it also means that they are…

I recently received an interesting scientific article from Gunther Verheyen titled "Getting Things Done: The Science Behind Stress-Free Productivity" (Heylighen & Vidal, 2007). The article discusses possible scientific explanations for the success of a personal productivity approach called "Getting Things Done" (GTD; Allen, 2001). The authors apply insights from cognitive psychology and cybernetics to better understand why this approach is so effective. Although GTD is focussed on individual time management, the authors mention the potential for collaborative work. Although the authors are probably not aware of Scrum (a framework for collaborative software development), their paper provides useful insights…

We've recently had to merge a version branch of a codebase back into the trunk. You see, two teams had been working on mostly separate parts of a system for three months. The result was quite painful. We lost several days on cursing, fixing merging- and tree conflicts, testing the code and working through new bugs. This bothered me quite a bit, not in the first place because I was the one cursing as I did most of the merge. But also because I felt that as a team, we were wasting precious time and money. I am quite…

Recently, there's been a lot of discussion in the Agile world on measuring happiness in Agile Teams. Jeff Sutherland, one of Scrum's creators, is a strong proponent of such an approach, as evidenced by his posts on the subject (see this and this post, for example). In this blog, I will explore the use of a happiness metric in Scrum and explain why - although it's a good start - it provides only a very limited understanding of a team's perception of it's well-being. I will also present an alternative measure that borrows heavily from research done by occupational-…