Our Room
Early on our team was moved into what used to be a meeting room, which is fantastic as it has provided an isolated area where we can focus and get on with the work. Also we can have our stand-ups and planning sessions right next to our scrum wall with minimal impact to the rest of the floor. I don't even mind the fact that they removed the door (which has been a source of amusement since it happened), as we already had an 'open door' policy which is central to an agile process (although we now tend to book a real meeting room for our retrospectives, as these can get quite personal).
However, due to a reduction in the team size we had a couple of spare desks in the room, and they have now been given to people who are working for another team. They moved in today and didn't mind the fact that we were in the middle of our stand-up - they simply walked through us as though we weren't there, and talked over us so they could be heard. It wasn't really their fault as they were just doing as they were told, and are likely to be friendly (they are external contractors, so we don't know them yet), but it was an annoying distraction. It also doesn't help that they are on the other side of the room, and have constant visitors to help them with their work.
I anticipate that this will have a fairly strong impact on our velocity until we get used to the interruptions.
The Team
For each sprint over the past few sprints the team has changed (although in one sprint a team member left to work for another company, so that couldn't really be helped). Mike Cohn has stated in his new book Succeeding with Agile that it is not ideal to constantly change the team size, and that it can take several sprints to regain the velocity. His recommendation is:
Stop changing the team. Teams benefit tremendously from having a stable membership. Of course, team composition will change over the long term, but try not to exacerbate the problem by moving people back and forth between teams as is common in many organisations.
We have some additional work with tight time lines coming up within the next few sprints, and apparently the solution is to add another person to the team. Although they have some experience in the application, we have to take time to set them up and get them operational again, as well as deal with yet another change in the team dynamics. By the time we're running at an optimal velocity again, the deadlines will have passed.
Multi Tasking
You know how, no matter how hard you work, study, research, and generally improve yourself, there is always someone who is still better than you? Well for me at the moment that is one of my teammates. He knows everything about anything, all he touches turns to gold, and I have to constantly struggle to at least try to understand what he is talking about at times.
This person is at his happiest when he is getting his hands dirty writing code, yet he has been assigned the following responsibilities for the team:
- Team Member
- Technical Lead
- ScrumMaster
- Product Owner
- Project Manager
Mikes comment in his book about the ScrumMaster also being the Product Owner is
No. In the vast majority of times I've seen this done, the results have been disappointing. Not only does combining these roles put a lot of power in one person's hands, but it also creates confusion for both team members and the ScrumMaster / product owner hybrid.
He goes on to explain that "a certain amount of tension should exist between these roles" as product owners continually want more features, and the ScrumMaster helps to protect the team. Not only does this person have both these responsibilities, he has had no project management training and no desire to do it.
Additionally, this person is not 100% on this project as he has other responsibilities for other applications. In fact, just last night he completed a bunch of work in his own time for another project so that he could spend the day working on our application.
Yet he still turns up to work with a smile, is still fairly sane, and can still tolerate my (slightly) bizarre sense of humour. I have no idea how he does it - I would have been committed a long time ago if I were in his position.
Performance Reviews
I have recently completed my annual performance review where I was asked questions such as "How have I helped improve the company financially". For most of the questions, all I could answer was that I helped contribute when the team completed a particular goal. I can remember times when the team excelled, or delivered something particularly amazing, but not really my individual contribution to that amazing feat (although this could just mean that I generally sleep when in the office).
It seems contradictory to me that a department that is supposed to be pushing agile and teamwork, still has performance reviews at the individual level. I would like to see more focus on teamwork in the reviews, but this kind of thing is way above my skills and pay grade.
Conclusion
I still love agile and hope to keep doing for a long time, but I think some corporations have a long way to go before they adjust to this new "radical" way of doing things.
Tuesday, September 21, 2010
Update 1
Over the past couple of weeks I have been reassessing the role of the Project Manager in Scrum, and have come to realise that this role is now shared between the ScrumMaster and Product Owner. We've had it pretty soft until now as we had managed to retain a Project Manager who dealt with all the slightly more boring work. But those days are now over. Therefore even though we almighty developers don't like to get our hands dirty with petty management and financial concerns (and don't we have enough pain already with having to now - heaven forbid - test our work!), we have to accept the fact that it has now become a small part of our daily work lives.
Mike said in his book Succeeding with Agile:
On Scrum projects we acknowledge the untenable role of the project manager and eliminate it.
For example, without a project manager to assign tasks to individuals, team members assume the responsibility of selecting tasks themselves. Other responsibilities shift to the ScrumMaster or product owner
Update 2
My colleague who I mentioned above has now been off work for a couple of weeks with fairly severe RSI. I guess the stress finally caught up with him... :(
Posts
