Good development teams strive to become mature. Organizations like Software Engineering Institute have useful definitions of Mature (see the CMMI specification) for us. CMMI for Developers does give a model of the practices mature development teams must master. Do not take these specifications as gospel, but do look at them to help expand your knowledge on industry expectations.

A mature team, according to CMMI V1.3 examples, includes practices like Object Oriented Design, Design Patterns, Test Scenarios among other practices. For our purposes these practices can tell us if a team understands what maturity is. How can a team tell it is mature?

The Software Craftsmanship movement gives another aspect of software maturity. Robert (Uncle Bob) Martin gave these points as tells for teams pursuing craftsmanship:

What we will do from now on:

• We will meet our schedules by knowing that the only way to go fast is to go well.
• We will delight our customers by writing the best code we can.
• We will honor our employers by creating the best designs we can.
• We will honor our team by testing everything that can be tested.
• We will be humble enough to write those tests first.
• We will practice so that we become better at our craft.

We will remember what our grandmothers and grandfathers told us:

• Anything worth doing is worth doing well.
• Slow and steady wins the race.
• Measure twice cut once.
• Practice, Practice, Practice.

Use these definitions to measure your team’s maturity. If your team develops using Object Oriented programming, does test driven development, uses continuous Integration with quick feedback loops, you have mature tendencies. Heck, your team can probably walk and chew gum at the same time also!

With a team at this level, use a different branching and merging strategy. The team uses a minimal amount of branches, because of minimal risks when checking code in. That maturity level engenders trust and solid code from the team.

This team utilizes one main branch, and uses labels and comments to allow for rollbacks. Since needing rollbacks pose low risk to this team, the team can use one main branch with frequent integration points allowing for quick small testing points for integration.

For our mature team, we have two teams, one in Dallas and the other in London. Each team consists of five developer roles, one testing role and one Project Manager role over both teams. In this case team members have met face to face a few times, and one of the developers from London transferred to the Dallas team. Both teams occasionally practices coding Katas together to hone their craft. Each team performs Katas regularly within the team for more practice.

Each team has code coverage of 90%, giving the testers comfort that the developers actually do test their code. Testers understand that the developers don’t test everything, so they collaborate with developers before working on a story. Both developers and testers review the testing scenario and strategy with the Product Owner so all team members involved understand the tests for that story. This gives developers understanding towards what they develop for and product owners opportunity to clarify their intent.

Mature Teams Branching Strategy

When working on the story, other team members from both teams IM or email when checking in a completed story. If a story is not completed, the developer will shelve the story and not check in. Since the story takes one to two days to complete, this works. Usually the developer finishes development and unit tests pass. Then code is checked in with a label indicating it is test ready. A team member adds a label indicating code complete, once the test scenarios pass.

In most decent version control systems teams can use these labels to roll back to previous versions. This works for code developed in a stable manner, checked in quick feedback cycles.

The team should branch off releases from main to allow for easy hot fix and service pack changes. That allows the team to utilize the main branch for feature work, and the release branch for maintenance work.

What Should My Team Do?

Hopefully, this mature Agile team scenario has some similarity to your team and you can determine where your team is. Then strive to continuously improve and aim to become a highly mature team!