My manager had a great interest in various development theories. He would spend hours mapping out ideas while trying to wrap his head around the latest methodology he had read about. When he began to introduce agile practices to our team I was skeptical. I tended towards a conservative approach to my development, preferring tools and methods which have a proven track record or at least the status quo until value can be shown. A poor tool or method could yield many times the initial effort to replace or even discontinue. Introducing what amounted to overhead in our near constant fire fighting stance seemed like it would only slow down the team.
Stand up meetings were our first foray into agile practices. The manager sent us a couple articles to review on stand up meetings and told us a story about pigs and chickens. What was supposed to be a quick ten minute daily meeting quickly ballooned to thirty minutes or more. Minutiae of each team member's work would be discussed at length and it was rarely pertinent to more than a single member. For quite a while our stand ups amounted micro management voyeurism. Improvement occurred as the team started feeling empowered (through additional agile practices) and holding each other accountable to follow standard stand up procedures. Stand ups became a useful tool to increase transparency throughout the team and allowed members to assist each other on blocking issues. Despite our early problems we were able to bring value to the team by persisting.
As a team we had some false starts with test driven development. Our initial attempts still haunt us today. Large, fragile, and poorly conceived tests which were written after the production code usually testing only success paths and took minutes to fire up and execute. The code which was covered by these tests became rigid and the supposed benefits were not realized. Unit testing waxed and waned at the developer's whim since there was little accountability. Occasionally one of the team members would add a new tool to our belt which would get everyone excited. Database fixtures allowed us stop depending on a fragile example database when testing. The first GLSEC the team attended together was when we really turned the corner and made TDD useful for us. A handful of us attended a session on mock frameworks which opened our eyes to isolating our tests. Another session on clean code helped us practically apply TDD by showing how writing the test first was supposed to guide development. With these lessons the team was able to truly begin TDD and reap the benefits. We added a code coverage report which we then began reviewing excitedly during our sprint review meetings. In addition when a new team member begins we spent a large portion of our time teaching this skill.
At the time of the same GLSEC we were working with month long iterations. Our planning meetings took several days time to complete between writing stories, planning poker, and finally assembling stories into the iteration plan. The overhead seemed too large to even entertain the idea of shorter iterations and developing a complete feature took about that long anyways. At GLSEC a couple of presenters from Menlo sat with our team during lunch. The whole meal we discussed some of the topics we had heard that day and the progressions of our agile transformation. One of the Menlo women continually challenged us during the meal to consider week long iterations and see if things changed for the better. Uncertain there would be any improvement we decided to give it a try. Just as promised improvements in estimation, transparency, and flow occurred. Our epic stories were forced to be broken down into much smaller stories to fit within a week's time and we wound up with more spike oriented stories. We were able to more accurately judge the rate we would deliver features, produce usable features earlier, and trim feature sets in accordance to delivery time. At the next year's GLSEC I was delighted to find the same woman from Menlo and thank her for her suggestion and told her of our success with single week iterations.
In retrospect our manager did a great job in leading the team to pick up a number agile practices. Rather than forcefully push immediate compliance with the defined agile practices he sought team buy in and to empowered team members to direct our implementation. Despite my concerns I earnestly attempted to do my part to follow through in the implementation of various agile practices. I was pleasantly surprised when the practices my manager introduced helped improve our team. After the manager left the company the team continued the agile practices which he had started and we have extended our toolbox to include other practices. Seeing the success of many of the agile practices I am more willing to seek out new ideas which will help deliver better software quickly to the customer.
No comments:
Post a Comment