The Agile Architect

Yes, with Agile There Is Time To Think!

There is a misconception about Agile that the team is so focused on development that there is no time to think about how to solve complex problems. The reality couldn't be more different.

• By Mark J. Balbes, Ph.D.
• June 5, 2013

I was talking with a friend of mine who works for a high-end software consulting firm. He was describing to me the frustrations that one of their consultants was having at a client site adapting to the client's agile environment.  The consultant was highly skilled technically and had a long career of project successes. Yet he wasn't succeeding in the agile environment because he couldn't keep up with the breakneck speed of the team and couldn't slow down because he was always pair programming.

As we discussed this further and I looked into my friend's eyes, I could see in his mind's eye the picture he had built up of an agile environment; Of breakneck speed with pair programmers typing away furiously at the keyboard, slamming out code; of quick, superficial discussions about stories, design and architecture; and of a team so engrossed in development that no one has time to think.

My friend's conclusion was that the agile environment wasn't right for everyone and that highly-skilled deep thinkers that solve the really, really hard problems need a different environment. That, of course, is pure poppycock.

There absolutely is time to think deeply, but sometimes in the heat of development, teams forget to take the time to do it. The failure here is both that of the individual and of the team to take into account the needs of the different personalities on the team and create a shared process where the team can succeed.

When Do I Get To Think?
The short answer is: Always! The longer answer requires more explanation.

Thinking Before Doing...
Here's the situation. You and your pair are about to embark on something new. It could be something small like a new story. It could be something large like the first story in a new feature. It could be the start of an enterprise-scale system. Your pair jumps to the keyboard and says, "Let's write the first test!" You respond, "Whoa there. We don't even know where we are going with this yet!" Your pair counters, "We're agile, let's just write the first test and see where it takes us." This is, of course, elusively attractive and seductively tantalizing.

At this point, your pair is ready to go and you aren't. Why? Maybe he already knows where he wants to take the code. Maybe he has more experience with the code base. Or maybe, he's just one of those personalities that always wants to dive in head first.

Luckily, you've got options:

1. Ask him to explain where he's planning on heading. Quick UML diagrams can help facilitate the discussion as well as looking at existing code. At that point, you can discuss the merits of different solutions and decide on an initial direction. Note that the length of this conversation is somewhat proportionate to the complexity of work to be done. If you are starting a story, this could take just a few minutes. If you are starting a new feature, you may want to take longer and bring in other members of your team.
   
   It's important to recognize the point of diminishing returns with this kind of discussion. The purpose is to get your head in the game and pick a direction. It's not to solve every problem that is going to come up.
   
   
2. Go with the flow and have your pair write the first test. At that point, he's either going to realize that he doesn't have the knowledge to do it, or you are going to learn something by implementing that test.
   
   
3. Tell your pair that you want some time alone to get your head in the game. Yes, this is really okay to do. Some people just need a little time to think on their own without the pressure of someone looking over their shoulder. But make sure you are being effective. Try a small spike to see if you can get the code to do what you want. Look at other code examples of similar functionality.  Draw a few design diagrams to discuss with your pair.

Thinking While Doing...
If you are doing your work test-driven, then you also have the opportunity to think while you are writing the code. The small refactorings you make along the way drive your system to a good design.

In addition, there's nothing wrong with a bit of traditional thinking about design. I like to keep a small white board near me so I can discuss design ideas with my pair, usually by drawing out some simple UML diagrams.

And, of course, all of the options above are still available to you including stepping away for some alone time, or spending some time writing some spikes to better understand possible implementations.

Thinking After Doing...
Even after you've written your code, if you have automated tests, you have the opportunity after the fact to refactor to a better design. This gives you the opportunity to take everything you've learned by building a working system, consider different design alternatives, and then craft the system to a better design.

If you haven't written automated tests, you're pretty much up the creek without a paddle.

What About Enterprise Architects?
At this point in the column, my friend whom I had been talking to in the story above has read this column and it has only reinforced his opinion of agile. "Well that's all just fine for application development," he's thinking, "but my people are enterprise architects! The fact that Mark's options all revolve around application development proves that agile isn't for those harder enterprise scale problems!"

As someone who used to have the title "System-Of-Systems Software Architect," I can assure you that the same advice applies when working on enterprise-scale systems.

Regardless of the scale of the system or problem you are working on, here are some simple rules:

1. Take the time you need to think, whether it is alone, with a pair, or in a group.
2. Don't take too long before you vet your thoughts by writing some code.
3. Despite what you think, delay decisions until the last responsible moment.

Don't get confused between the need to think early about a problem and the benefit of postponing a decision until the last responsible moment. Thinking early followed up by writing real, working code allows you to explore different solutions while continuing to learn. Delaying decisions until the last responsible moment ensures that you make your decisions with all the information available to you.

And my final advice, as it is with all things agile: Do what makes sense for you and your project, not what you think some rule book or agile guru is telling you to do.