The Agile Architect

Welcome to The Agile Architect: 3 Agile Misconceptions

Mark J. Balbes, Ph.D., shares what you can expect in his new ADTmag.com column, and talks about three common misconceptions about agile that he'll address further in the coming months.

• By Mark J. Balbes, Ph.D.
• September 20, 2011

Hello and welcome to the first installment the The Agile Architect, a new column here on ADTmag.com. Some of you may have read my previous article "What Does an Architect Do in an Agile Shop? An Agile Architect Explains all…." The response to the article was so positive that I've been asked to turn it into a regular column --- in fact, that article is now retroactively the first article in this column. (Hey, agile even makes time travel possible!)

Given that the premise of the original article was that the traditional architect role was at odds with agile philosophies and practices, what the heck are we going to talk about here?

I'm actually very excited about this column. I've worked with agile practices for many years and seen a lot of companies attempt (and mostly fail) at it. At my current company (no, I'm not the owner, just an employee), we have been very successful in creating great software using agile practices. This column gives me a chance to share my experiences with the agile community.

But why listen to me? There are plenty of books and articles out there on the various agile practices and how to do them. 

Here's why.

I'm a scientist by training. I like to deal in facts and truths. I'm not interested in pushing an agenda or selling you on something. I am in the trenches with an agile team every day. In addition, I coach and mentor other teams in my company and teach agile classes.

In this column I'm going to tell you what works, what doesn't work and why. Of course, it will be colored by my experiences, but I will tell you my biases, too. That is, when I recognize them in myself.

So let me start out by telling you some of my stronger biases and opinions about agile development.

First, to do agile software development successfully, it's not just about project management. When I hear people talking about doing agile and all they can talk about are Scrum and sprints, I feel like someone is grating their fingernails on a chalkboard. While Scrum is fine for managing an agile team (I'm guessing here because I've never personally been on a project using Scrum), it is not enough. Nor are XP iterations or lean manufacturing Kanban. In order to really be agile, in order to be able to change direction on a dime, in order to create high quality software that meets the customer needs at the time they need it, in order to deliver on time and on budget, your software engineers must follow very disciplined software engineering practices that have been developed as part of the agile movement. What are these practices? Keep reading my column!

Second, no one is doing agile "right," including me. Agile development requires constant reflection on how your team is working. If you aren't changing and improving your processes, you'll never get faster at delivering high-quality software. In addition, every project has different needs. Practices that work well on one project may not translate to another project. Don't be afraid to experiment and innovate, although it's always good to start with the basics. I'll talk about continuous improvement in a future column, too.

Third, to really understand agile practices, you have to see them in action. Reading a book or article may give you the flavor of it, but until you see a team really doing it, it's hard to imagine how to handle all of the day-to-day issues that come up on a project, regardless of the processes you are using. We recently transitioned another company from waterfall to agile by creating a combined team of its developers and our experienced agile developers. We worked side by side with them for about six months in our offices. By that time, we had recreated our war room on its premises. We extracted our people, and the company's  team kept going. We were able to overcome the objections of its technical team and managers simply by working shoulder-to-shoulder with its developers to get the work done. (Gosh, I'm going to be writing a column about this, too!)

So that's my plan. In the coming weeks and months, I'll give you the straightforward, unvarnished truth about my successes and failures on agile projects. I know that by sharing my experience, I'll get to learn from yours as well. And that's where the fun will really begin.

See you next time!