Your Maturing Team

Posted by I'm in o-HI-o on November 15, 2012

[REVISED 20121116 due to invaluable editing from a colleague. I’m a poor writer.]

My high school offensive line coach always told us:

You are either getting better or getting worse. You never stay the same.

This is so true. The moment you stop learning and examining yourself for growth, the decline begins. Often, a break is needed in order to get better as it’s hard to improve while going at such as fast pace.

You never get better at your job simply by doing your job.

This is particularly true for teams. Teams often go ‘pedal to the metal’ for months on end and do not take the time to self-examine. In my world, we try to take time to periodically assess success in our retrospective meetings. Too often, however, these meetings end up focusing on the tactual and big ideas do not bubble up as often as they should.

Periodically, we need to take measure of ourselves versus our ideal or our next set of goals. We need to see what our team looks like at the next level. We need to mature.

####We Still Have Pain Room for improvement always exists. For instance, in software, we sometimes add features without removing others, which could lead to testing and maintenance issues down the road. We also might need to scale up our teams in some cases, which could trigger other changes as well. Something we changed in our last retrospective could have surfaced another problem or inefficiency.

On our current team environment, we just shipped. We quickly started working on another large bag of work, but it is also the perfect time to self-examine and find ways to get better.

####Maturity process I believe our team has done a great job. I feel there are few in our area of expertise that have adopted agile practices to the level and scale that we have been able to accomplish. Of course, there are areas where our team could mature, While each team has unique ares in which to grow, the exercise of self-examination for improvement is always a good idea. Below are a few examples of how our own team can grow.

True Test Driven Design

We have dramatically improved our testing practices and test coverage, but that was not our ultimate goal. Our goal was to use tests to drive design. We will have some areas of the application that are hard to test, but we shouldn’t let this deter us from testing first all the time.

Better Engineering/Design

Improving our test-driven development (TDD) practice should lead us to better object-oriented design. We have a major component that is a God Object and tighly coupled to multiple application layers. This is a nightmare to test and there is redundancy. To mature as a team, we need to improve our design approach that embraces good test-driven, object-oriented practices.

Better Craftsmanship

We have done a very good job creating features that work as the customer expects. To take this one step further, we need to create easier to read, maintainable code. We need to evolve our practices to think about the person who will maintain the code.

Roll in Reporting to Show Emphasis

We currently have very little visibility into the effects (positive or negative) of our approaches. Much of our decision making is based on anecdotal evidence. We already generate a large amount of data as part of our practices and should use this reporting more to make better informed decisions.

More Automation vs. Manual testing

We do quite a bit of automation, but we need to do more. Manual regression is expensive. The larger the program, the more expensive the manual testing. We need to find ways to automate more processes so our manual testers can better utilize their vast domain experience, such as exploratory testing.

Test the Mainframe (all systems in ecosystem)

It is a fact of life that mainframes still exist in all their 1970s glory. We have a mainframe in our world. We send data to the mainframe, process things on the mainframe and look at the output…manually. This is expensive. We need to automate the manual examination of this process output.

More pairing/less code review

The teams have adopted a process of pairing OR code review. We often do not perform our code review when we don’t pair and that has caused problems. I am convinced that if we collaborate better, certain mistakes won’t be made and less shortcuts will be taken.

By taking the time for self-assessemnt and making improvements, I that our team will only get better.