Lessons from the Field : Small Team implementing Agile and Visual Studio Online (Part 1)

Recently I was asked to sit in the observation deck on a development project. It looked like a great opportunity to observe a small development team implement agile into their project from the very beginning. Because the team was small and the project was using MVC, it was the perfect candidate for Visual Studio Online.

Everyone on the team was experienced with development projects in one capacity or another. It was a mix of two veteran developers, experienced Scrum Master/Project Manager (a.k.a Product Owner), and a UX Designer. After a 2 hour crash course on product planning and sprint planning in Visual Studio Online the team was ready to begin. These are a few of the lessons learned during the process.

Anticipate the Culture Change // 

Even with a small team expect to be injected with some level chaos and culture change at the front end. Everyone brings their own baggage to the project and you need to spend the time with each other to agree on the process and ensure everyone understands the implementation of that process. The first 2 to 3 sprints on this project had more challenges because expectations where not in tune with each other. Once that got resolved things went much smoother.

Easy on the Detailed Requirements // 

As the Product Owner, and in this case the business owner, it was a challenge to refrain from detailed requirements up front as they are trying to keep scope under control with the customer. However it presented an issue as the details in the requirements do not take into account all the little changes that creep up during the normal development cycle. The Product Owner had to then go back and make changes to the details as stories made their way to the top of the backlog. So the Product Owner went back to the customer and the customer agreed to review the work one sprint at a time. Now they focus on just putting in the story title and quick description and worry about details as the story gets closer to development. This worked a lot better.

Sneaky Bugs and Changes // 

Part of developing an agile project is the understanding that changes in requirements are going to happen. It is best to add those changes into the backlog for prioritization in a future iteration. At first this concept was difficult to understand and implement because the customer and product owner would create changes hidden as bugs to them get resolved as part of the current iteration. This created unplanned work and as a result prevented the stories from being completed on time. Bugs are bugs and should be fixed in the current iteration. Changes should be added as a new story and put into the backlog.

Avoid Managing Lists and Complete the Iteration Review // 

As the team moved through the iterations I noticed the list of resolved work items kept piling up. Resolved bugs and stories sat in a queue iteration after iteration. At best this told me that the Product Owner was not closing out the work items. At worst the Product Owner was not completing any of the testing (we will cover testing in part 2). Of course the impacts would be testing the application all at once at the end and realizing they have mess load of bugs or issues to deal with. Something they needed to avoid. Make sure you complete the iteration review and the testing team or product owner is closing out resolved work items.

 

That's it for now. In my next post I will discuss testing and product quality. 

What is your experience with running a small development team through Visual Studio Online?

Comments

• Anonymous
  March 31, 2015
  Very useful guidance, thanks Dan!