The Agile Architect

Agile TBD

What is our Agile Architect writing about today? We're not quite sure but it may have something to do with responsibility and his own lack-there-of.

• By Mark J. Balbes, Ph.D.
• June 16, 2014

I have a real problem. I backed myself into a corner and now I have to extricate myself. Here's the situation.

Every month I have to write one of these Agile Architect columns. Now, being the responsible person that I am, I usually wait until the very last minute before deciding on a topic and writing the column. Sometimes, I don't decide on the topic until I have to submit my invoice to my editor so I can get paid.

Only this time, I waited a bit too long. I was on vacation with my family and my editor reminded me I owed her an invoice. Oh, and a column that she could publish would be nice too. Not having a clue as to what the actual topic would be, I sent her an invoice for a column with a placeholder title "Agile TBD."

And, of course, now the gamester in me really wants to write an actual column with that title. But what the heck does it mean?

Being ever resourceful, I turned to my family while we were in the car driving to our next vacation activity and asked what I should do? "How should we know?" they all responded. But they did.

This seemed like a great idea and certainly in line with the title. After all, why wouldn't a software company want to be agile? Big projects or small, start-ups or large enterprises, agile can improve performance, speed software delivery, and delight their customers and users.

And being agile doesn't necessarily imply being Agile. In other words, you don't have to buy into one of the agile frameworks (eXtreme Programming, Scrum, Scaled Agile ...) that's been created by others. You can adopt and adapt agile to your business in a way that makes sense for you. As I always tell my teams, my cardinal rule for decision making is, "Don't be stupid." By which I mean, don't blindly apply agile (or other) rules, processes or practices to your situation when you know it's the wrong thing to do.

So of course, if you haven't started being agile, you should start right away. The much harder question is how to start.

Agile TBD, the Second: How Do We Stack Up?
My wife Lisa (a Ph.D. chemist and owner of Balbes Consultants), also in the back of the minivan, came up with her own suggestion. She said that I should compare how the company that I work for, Asynchrony Solutions, does agile versus other companies. Thinking about what that means, I realized that there are at least two aspects to this.

The first is to discuss the depth of agile being practiced and the commitment to those practices. I wrote about this in a previous column, Project Management Is Not Enough: 4 Crucial Agile Techniques.

The other interesting comparison is to look at the differences between companies doing agile versus companies selling agile. To sell something to someone else, by its nature, you have to package it up, make its value understandable to others, and teach others how to use the product. With any process, this means codifying the processes, practices and techniques so there is a consistent, repeatable methodology. There are many companies in the market doing this today with Agile.

However, that's the very antithesis of agile, which is in fact not a process, practice nor methodology, but simply a way to think about problems and how to solve them. By its very nature, packaging up agile into a repeatable, static process violates agile principles. On the other hand, trying to teach people how to think about problems in an agile way without giving them rules is nearly impossible. It comes back to Shu-Ha-Ri which I described in my article "Agile Expressionism 101."

At Asynchrony, we've found the best way to teach people about agile is to do it with them. We train them on current agile best practices and then work with them side-by-side until they understand the rhythm, flow, and dynamism of an agile environment all while helping them adapt everything to the realities of their business.

Agile TBD, the Third: The Last Responsible Moment
For me, Mark, (Ph.D physicist and The Agile Architect), sitting in the passenger seat of the minivan, TBD implied a discussion of the Last Responsible Moment, which is that last moment where, if you waited any longer, not making a decision would be detrimental. By waiting until the last responsible moment, you maximize the amount of information and learning before making the decision.

For example, suppose you are starting a brand new project and standing up a new team. What is the last responsible moment for choosing the programming language you are going to use? It could be that it's the moment right before the first line of code is written. Up until that point, there's no investment in any specific language. But maybe that's not right. If you get to pick your team, the skills of the people on the team may determine the language. So the last responsible moment might be right before you decide on your team members. Picking the language will determine which team members you choose.

What's the last responsible moment for deciding a release date for your software? If you are building a Web application where you can make frequent releases with little overhead, it may be that the last responsible moment to decide to release is when the team says that the release is ready. On the other hand, to determine the release date for an enterprise product with a big price tag and contracts with penalties for tardy releases, it may require setting release dates very early in the development process. In my experience with healthcare, it can take 18 months to two years to complete the sales cycle. This means that the sales team has to be selling features for a release that, not only do the features not exist, but the development team hasn't even started on.

Whatever decision you have to make, waiting until the last responsible moment can vastly increase the probability that you make the right decision. Just don't wait too long and let the last responsible moment segue into the least responsible moment. Kind of like what I did with this column. (Editors Note: O.K., Mark. I let you squeak by on this one. Don't get cocky about your deadlines or you may find it's your last employable moment! :-))

Agile TBD, the Fourth: Indecision as Inspiration
My father Ray (Retired math professor and digital artist) suggested from the driver's seat that I write a column about not deciding on what to write for the column.

This is, of course, a nonsense suggestion. How could I ever do that?

Final Thoughts...
My older son Jack (23, a graduate from Washington University in St. Louis and now a software developer in his own right) was in the back seat of the car asleep. You see, he knew that I wasn't going to be able to write the column in the car so he had time to make a decision later, when he had learned from what everyone else had to say and could take the time to think about possible solutions.