In the midst of transitioning to a new job, I felt it would be wise to take a minute to reflect on some of the lessons learned working with the talented team of developers at the North Carolina Housing Finance Agency.
When I joined this team in August of 2009, they had recently gone through the departure of their department manager, and in response were adopting Agile as a development methodology. They faced the uphill battle of reestablishing trust among the other business units, and were in the process of migrating a legacy system in preparation for adding new features.
In 16 months time, we completed the system migration, and delivered on two major business initiatives, earning high praise from both the end users and organization’s leadership. Additionally, we implemented and migrated our work to Team Foundation Server, conducted a pretty significant architectural overhaul, and doubled the size of our team as new work emerged.
I feel proud to have been part of the team at NCHFA, and it is in their honor that I share these lessons learned. I hope to be able to apply these lessons as necessary with the team I am joining.
1. Planning and prioritization is a daily discipline. Nearly every activity our team spent time on fell in to one of the following categories of planned work:
- In-Sprint project work – tasks specifically contained in our Agile sprint.
- Helpdesk items – end user support of our production systems, under 40 hours
- Pipeline items – projects in excess of 40 hours of work
- BPI (Business Process Initiatives) – multi-project initiatives in excess of 100 hours of work.
Every week, in a standing, Monday at 10am meeting, our entire team would provide status and updates on all work across these categories. This simple practice of routinely reviewing, re-prioritizing and re-assigning work as necessary allowed every member of our team, as well as our management to have a complete picture of the entire team’s workload and progress.
2. Trust the process of debating an issue. During our sprint planning, and especially during the lead up to re-architecting our systems, there were many instances when we as a team didn’t always see eye to eye. More than any other team I have been a member of, the level of honest and respectful debate that we had was significant to our success.
3. Start manually, then automate. There is no lack of tools to help teams manage the Agile software development process. But for nearly the first year of working together, our team relied on index cards and sticky notes. By adhering to a fully manual process, it allowed our team to work out the necessary adaptations and adjustments to our usage of Agile and become experts both individually and collectively of the methodology. At the point in time when we elected to implement a project management tool, in our case Microsoft Team Foundation Server 2010, we knew how to run our sprints and manage our stories so well that adopting the tool was nearly effortless. The result is that our usage now of TFS was able to take full advantage of its features for planning, reporting and tracking our progress.
4. Demonstrate your results across the organization. With few exceptions, we provided an open invitation to the entire organization to attend our end of sprint product demonstration. In these meetings, we used a few Powerpoint slides to review all our previous sprints, which reminded the business groups of the overall project progress and decision points along the way. We then gave a full, live demonstration of the new functionality we delivered in the last sprint. By showing our progress along the larger project timeline on a routine basis, our team established a significant level of trust from the business groups. We simply let our delivered, working code speak for itself.
It was my pleasure to be part of the team at NCHFA, and I look forward to hearing from them about the results they will continue to produce in the months to come. Congratulations to Joe, Tim, Dan, Eric, Steve, Dev and Jaime for all you’ve achieved over the last year.
Leave a Reply