Last week I attended my first VSTS (Visual Studio Team System) user group in Minneapolis with Adam, the product manager of my team. It was a very small group. There were only about 5-7 people and 4 pizzas. There was definitely enough to go around. I think the group was just small because the topic was very niche. The presentation showed how to leverage TFS when you have an agile team that specifically is using the Scrum methodology. A demonstration was given using Conchango product, Scrum for Team System. It looks like a very useful product, yet very simple. Currently we are more concerned with getting all of our code into TFS from SVN, Continuous Integration and unit testing setup. Hopefully, we will revisit Scrum for Team System as it may be a better solution for project management (backlog management to task completion) than what we are currently using.
More time was spent on Scrum principals than what I was expecting, but it was nice. It was nice to see companies doing things similar to the way we do things. One interesting thing that did happen is that after hearing people talk about ranking stories using time (vs story points), the product manager and I got more on the same page. Another thing that other companies due is have a demo for the business. For some stories this is not applicable but for others I think it would be very beneficial. I think that the reason I like both of these ideas is because they hold people accountable. Since we have started agile at my place of employment I have seen extreme benefits (communication, project ownership, sprints with a consistent velocity just to name a few). I like the team emphasis that Agile brings and I think it is very valuable, however, there is a downside. I think accountability is sometimes lacking because people can hide behind the team. On the other hand I also think the visibility is lacking for people that work hard on a team. For people to enjoy working on the team they need to feel like they aren’t pulling all the weight and for a successful team, every member needs to feel that they have a commitment to the team. When ranking stories with story points it is easy for a developer to say they will be done with a story of size “3″ tomorrow because it doesn’t mean that much. However, if they had a story that was a size of “8 hours” they need to explain why it is taking longer. On the other hand, if they finish that story in one hour, they would need to explain to the team why it took so much less. Did they write unit tests? Or worse yet, did they just code and check in? Of course, ranking with hours still can be inaccurate as is any prediction, however, flags would be raised if someone is consistently under or over.
I also like the idea of providing demonstrations to the business. For larger stories, I would like to see the primary developer for that story demonstrate it to the business. This has many benefits. It encourages the developer to have a high level of quality. This reminds me Bill Gates getting a blue screen during a presentation. No developer would want to demonstrate their work and have it fail. It is possible in an agile environment for developers to become disconnected from the business. I think that this demonstration would alleviate some of that disconnection and allow the developer to get direct feedback, instead of feedback from the business to the product manager to the team lead and finally to the developer. Last, but not least, the business gets to see how their requested software works. Win-win situation.
Leave a Reply