One iteration at a time: Introducing our newest team of developers

by Elizabeth Jenike, IT Services

For our IT Services staff profile this month, we’ve got a treat. Two Solution Delivery teams have merged into one mega-team: the Iterators. Let’s meet them!

Do it once, do it twice, do it three times (with feeling)

In early December, the “Pirates” merged with the “while (sprint) doWork();” team to form the Iterators. One of the first things they did when moving into their team room (the former Pirates’ haven, which they affectionately named “Davy Jones Locker”) was to conduct some relationship building activities to solidify their status as teammates.

Group of developers

One of those activities was to take quizzes based on the Myers-Briggs personality inventory. Here are the team’s results:

They also decided on several team mottos, including:

  • “Get the work done in iterations.”
  • “Better today than yesterday; better tomorrow than today.”
  • “Iterations, iterations, iterations…”
  • “One iteration at a time.”
  • “Get better in iterations.”

There’s a theme here, huh? The team’s logo, a dragon eating its own tail, is an homage to the mythical Ouroboros. It was selected as a representation of iterations, as well—the idea that it’s important to undertake the development cycle as just that: a cycle. Developers deliver business value in smaller chunks to get feedback in an ongoing cycle until projects are complete. This is one of the key tenets of agile development.

Dragon eating its own tail

Agile vocab lesson: Pair programming

Now that there are multiple team members from whom to learn, the Iterators have an easier time doing pair programming or swarming, which is when developers work on the same parts of a feature at the same time. They work through it together—one person types while the other watches over their shoulder or talks through concepts.

Two brains—or several!—are better than one any time.

Will Mundy in front of a screen while swarming

Method to the merger

Another thing the Iterators did right away when they hung their hats on the same rack was to determine some shared definitions. Programmers live by code—both literally and figuratively, as it turns out. In order to ensure everyone is on the same page as far as what “good work” is and what it means to deliver a project successfully, the team had to decide on their definitions of “ready” and “done” for the units of work they take on (otherwise known as “user stories”). They also agreed on several core values, including: commitment, focus, openness, respect, and courage.

Iterators definitions of done and definitions of ready

The purpose of creating these working agreements is to establish a common language by which the team can communicate—keeping everyone honest and in line from the beginning.

“Combining the teams brought additional skills and experience to both teams,” Scrum Master Mary Brooks said. “The Iterators team is naturally working together and learning new skills and approaches from each other.”


Why "courage"?

You may be wondering why “courage” is one of the maxims that the Iterators chose. Courage is one of the core values of Scrum. It’s important to have courage to do the right thing and work on tough problems together. The team members agree to be open about the challenges of their work.

Teamwork makes the dream work

Why the shift from two teams (“while (sprint) doWork();” and the “Pirates”) down to one larger group?

Dan Johnson, interim director of application development, oversees half the team (the half that used to be the Pirates). He explained that one of the biggest reasons for the combination is that small teams aren’t exactly optimal development size. Putting two three-person (sometimes two-person) teams together into one five-or-six-person team would create the kind of environment necessary for optimal programming efficiency.

He also cited the benefit of having an ever-present Scrum Master as one of the biggest draws of merging the teams.

“Having a full-time Scrum Master in there has helped them follow the scrum rules better,” he said. “And having other team members to pair up with has broadened their skills and improved their ability to work with different people.”

Mary echoed Dan’s sentiment, as well.

“Before the combination, I was coaching both teams a small amount of time every day and during sprint activities,” she explained. “The sprint activities had to be scheduled for both teams so that there were no overlaps, which caused logistical problems at times for me and the engaged product owners of each team. Combining the two teams allowed me to serve as the dedicated Scrum Master to both.”

Mary also mentioned that fewer teams are better supported by internal staff members - so it simplifies the lives of everyone in IT.

While the merge means that we’ll have fewer reasons to engage in “Ninjas vs. Pirates” debates, we’re glad the Iterators make a cohesive team ready to tackle client projects and support one another.

Developers looking at a screen of code