Back to agility

This week we are back to agility and agile software development. It is so important and it saves you as a developer so many headaches and your client so much money that it's almost like a must to talk a little bit more about it.

Today I would like to focus on two items: technologies that help agility and results driven behavior.

(1) There are actually technologies that help an agile process

I've been trying to discuss this topic during some agile events in town. I got little feed-back to it and I believe the reason is that most of the attendance is not technical- they are mainly projects managers.

I'll make a case there are actually technologies that help, if not even drive, agility.

Some of the them are Object Oriented Databases as opposed to tabular databases. By definition inserting a new field in an OO database will be more agile and easier to pivot with than when using a tabular database. OO databases, such as Mongo DB or Postgres, embrace late requirements changes, eliminate read locks and ensure atomicity and consistency in an efficient manner.

I won't assess for example that Ruby is "more agile" than Java or .NET because that won't make sense. But I will say that architect-ing a solution the right way can tremendously help your agile process. An example is building a framework that generates full stack marketing websites. Instead of writing each individual site as a separate solution (let's say on a Microsoft stack) you can make an xml that will define the behavior of each site in different market verticals. Such a framework will be much easier to maintain, adjust, change and re-test even with late / unforeseen requirements changes.

That is why I always say that the greatest agile teams I worked with are usually the greatest programmers too. Because they can write things in a smart way.

(2) Do results really drive behavior?

There is a lot of talk in the community about the business results that are supposed to drive an agile behavior. In other words if an agile teams shows better results in an Organization, other teams who are not doing agile are going to adopt that. Hence an agile culture will spread around your Organization.

I tend to disagree. My experience with agile teams is that they are either agile or not. They either have an agile culture / approach as part of their internal human structure or not. Of course you can educate people, you can train and draw guidelines but it just happens that most of the time "people who write code from right to left" are the most agile ones too.

So in my Organization I stress on recruiting the right people: the ones who kind of see agility as a natural, self driven behavior in software development rather than as a process or a set of rules.

I agree it is harder in larger Organizations where you have all kinds of teams and you have to deal with all kinds of people: many of them who you did not recruit to begin with. Showing some of them the carrot may not work. Showing some of them the stick may or may not work.

But what do you do when the customer is not interested in being agile? Then you are really stuck. Because you cannot impose it on your customer. Educating the customer many times works but financial analysis and bottom lines with $ signs will get you better results. Some customers just need to understand that working agile is in their own interest as well.

Make it a great day!

Adrian
Miami Beach, FL
http://wittywebnow.com