Teaming up and moving onto the happy path

This is a story I think all developers know. A new team, starting a greenfield project under seemingly perfect conditions. An agile coach, an organisation ready for change and another team paving the way with a similar solution. And still, a few months down the line; a complex solution, broken deadlines and a feeling that things weren't moving in the right direction.

Not that things were going badly, they just didn't go as smooth as we hoped. And the team was very aware of what the problem was. We had inherited an architecture that we didn't feel comfortable with. Too much code was shared between applications and the complexity of the solution made us uncomfortable. We tried to solve our tasks the best way we could. But we did it alone, since the stress of missed deadlines kept us away from pair programming.

So. What to do to fix this situation before things went too far? We decided to change things around and break some patterns.

Shared responsibility

When the team started up, I got the inofficial title of architect. This is a title I don't like, for many reasons. The architect gets called to all the meetings, never have time to do anything else and sits on all the information that the team needs. A bit harsh, maybe, but this is my experience after having had this title the last 3-4 years. The way I see it, the more people who knows what we're supposed to build, the better. And with 6 experienced and informed developers in a team, the architecture will improve in every little corner of and around the solution.

So we discussed this in the team and came to an easy decision: we informed the organisation that our team no longer had an appointed architect. Meeting requests could be sent to the team as a whole and we promised that one or more of us would attend. Most of the times, at least two of us go to those meetings, one who knows the area and one who wants to learn. This has resulted in a situation where the team as a whole is informed of everything. Really, everything!

New project - new ideas

After the summer vacation, the team was supposed to start a new project and build a third website. The project kicked off with a hack week. During that week, we decided to sit together and get the foundation of the new site up and running. We wanted to simplify our solution and build something that we all felt comfortable with.

This turned out to be the real turnaround for us as a team. The result of that week was so good, so when the next week came, we decided to keep on sitting together. At first, we didn't really have a place to sit, so each day we found available conference rooms and booked them. We set a timer for 20 minutes and took turns at the keyboard. We as a development team made good progress, but we were practically invisible for the rest of the project team and organisation. So the next step was to make it official.

Mob programming

So one morning, we got an OK from our manager to use a couple of the tables in the middle of the office landscape. We put them together and installed a mob programming station. One big TV, a smaller screen and the dock for the laptop where the mob programming timer is displayed. A wireless mouse and keyboard together with all our mobile test devices completed the equipment. And there we've been ever since.

What is mobprogramming?

All the brilliant people working on the same thing,
at the same time,
in the same space,
and on the same computer.

Or in short, one driver at the keyboard and many navigators.

A normal day

• Who's here today?
• Dock one of our laptops at the mob station.
• Set the timer on 12 minutes each, we use the handy Agility Timer.
• Quick summary, where did we leave off yesterday?
• Start coding!

And the navigators do what?

• Real time code reviewing.
• Googling.
• Testing on mobile devices.
• Looking at upcoming tasks so we're not missing strategic decisions.
• Discussing design and architecture.
• Making decisions together with the driver.

But how can that be efficient?!

It's not... If we're looking to maximize lines of code written. But we should all be beyond thinking that is a good thing by now, right? However, if we want to deliver working features with good quality and short lead times, this might be the way to go.

Short lead times?

Yes. If we have a working setup for continuous delivery, and everyone is working on the same feature, when we have no pull requests or merge issues, a feature can go from idea to production in the shortest possible time.

Good quality?

This section could go on forever. The positive effect we've seen in this area is huge. :)

• The team is coding, reviewing, analyzing, designing and testing simultaneously.
• We constantly learn together and from each other; technically, domain wise and valuable tips and tricks regarding tools and processes.
• Knowledge sharing. Everyone does everything, from CSS to build scripts. If we don't know the area or feel comfortable, we lessen the time at the keyboard or just pass it over. But we still learn and become better developers.
• The team considers more design options than a coder working alone would do. This typically results in less complex code.
• The amount of unused, duplicated, unnecessary code is at a minimum. 
• We now have an architecture that's alive, flexible and thought through on all levels of our solution.

What have we gained?

• Focus! No context switching. We do one task at the time.
• Continuity! We're not dependent on any one individual. No one has to work from home when they're ill to make a deadline.
• Communication! With each other and others. Everyone is welcome to come over and talk to us at our table. It's easier for others, since they now only have one place to come to.
• Fewer meetings! One or two of us goes to a meeting, the rest keep on working. The team still gets all the info when the meeting attendees get back.
• No setup time for new team members! Productivity from day one.
• No idle time! We never get stuck, we can always keep on moving.
• Teambuilding 101! Coding together 9 - 5 builds a team in a way no AW can do...
• More fun! Which means more motivating. Which means we're more productive.

How can we make it work?

Some basic things are needed in this process. They might not be there from the beginning, but to be successful I think you need to get there.

• Trust. Within the team and from the organisation.
• A shared objective. Agree on what you want to achieve by working this way.
• Respect for the competence and experiences of your team mates.
• Humility. We all know it, right? "There's no I in team". ;)

Do I miss coding alone?

No. And I don't want to go back to that. When I code at home, I code alone. But I never do work stuff at home anymore, just coding for fun.

Changed team - changed organisation

This is actually the amazing part of our team's transition. The organisation changes with us. The project we are setting out to do next was originally set up as a traditional IT-project. Now we're changing it so the whole team, including business analysis, design and UX will work much more closely.

Instead of being 2 months ahead of development, we'll all be working on the same feature. The ideas from last week will be put in production next week. We'll eliminate waste and go directly to what we do best, code it, test it, tweak it. It's going to be a very interesting journey. :)