Today we will get back to agility as it is such a hot topic. Agility is often seen as a technique or a "different way of running projects" however I believe that in fact agility is much more than just that. Agility is a life style. And agility heavily relies on mentalities.
Organizations nowadays jumped the wagon of agility. Some of them genuinely see and appreciate the business value. Some others are doing it just because it's "new and cool". Some others are not really agile but they think they are and are very successful in ... messing up the concept and their own projects. The ones who do it right see tremendous ROI.
Here at Witty Mobile Apps we are big advocates of agility in software development. We believe in its philosophy and, due to the nature of this business (a business with a great deal of variables, churn and ever changing business requirements), we practice it every day.
Many times we face resistance in implementing agility especially in larger scale organizations or in certain industries. Highly regulated organizations for example have a harder time implementing agility than others (and not that you can't do it in these environments but it's also like I said the mentality).
Here are some miss conceptions about agility:
(1) Agility does not follow a structured process
This is not the case. Agility does not mean no process. It just means a more dynamic process. Defects and requirements inconsistencies are brought up early in the development cycle. The stakeholders are very involved and in constant dialogue. The customer is involved and in constant dialogue. Requirements changes are welcome no matter how late they come in the process (because the software is written that way to embrace late requirements changes).
(2) Agility does not provide documentation
That is not true either. Your ability of documenting your solution does not depend on that. While it is true that most agile groups follow relatively informal approaches to draft requirements and share them with the developers (and they can range from white board schematics to wikis, e-mails and Word docs), the quality and quantity of your documentation is up to you. The agile philosophy does not tell you not to document things: not at all. It just tells you document fast and document right so you can quickly get going.
As a side note here: I've seen "agile" self declared groups where project managers were strolling around through cubicles with notepads, randomly talking to developers requirements of xyz client, scribbling things or drawing nondescript diagrams on a white board then taking digital pictures and e-mailing them around. That is not agility: it's just a mess.
(3) Our product has many dependencies on third parties
Larger organizations acquire components, products or niche solutions to integrate them into their own products. That is fine as it works out for their organization but it may create the perception that projects with integrated third party components could not be run agile. The main reason being that, should a change be required in the third party's code, it is usually hard to convince that third party organization to deliver it in rapid development.
There are ways it though. One of them is to work with open source software and depend less on third party code. Another one is to educate the vendor to work agile as well: it is in their best interest. And there are many organizations that will actually be interested to deliver you a customization of a proprietary software component fast: choose one of those (we actually found that for example some off shore organizations that develop proprietary APIs for real estate are very agile and can deliver you new code in no time).
(4) Our teams are large
If your teams are too large, you did not structure your project well. The average size of a team at Google for example is five people. No matter how big your project is you can always split it up and assign components to small teams. The teams can always be aligned with the product's architecture and you can always "divide and conquer".
And even if let's say the Management does not allow you to split a bigger team, you can do agile with larger teams too. I did agile with teams of up to 40 people. It is just a matter of coordination and a matter of the quality of the people you have in your team. If you have good people, it won't be hard to do agile with them. If you don't have good people nothing will work anyways, not even waterfall.
(5) Our teams are geographically dispersed
Actually some of our off shore teams are the most agile teams we have. They are always the first ones on the video call. They always communicate status on time and ask the right questions during our meetings. They always help out the customer, the project managers and the qa teams. They are just terrific.
Same thing with the people on shore: no matter where they are they attend the meeting and start writing code fast and clean. Addressing customers concerns is straight forward as well.
Technology is definitely there: we use Skype, Google Hangouts, e-mail, Google Docs and Wikis.
Time zones do matter: it is harder to do agile if you have teams in three or four different time zones: US East Coast, US West Coast, Eastern Europe and India for example is a tough combination for a unified global agile approach. You can still do a scrum of scrums though. With two time zones for example it's a no brainer: for example India and the US East Coast or the US East Coast and Eastern Europe.
I used to kid around and say "Hey, I've just fixed my daughter an agile omelet this morning". But it is actually not kidding: my daughter frequently changes her requirements.
Keep an eye on agility. Wherever you are. Whatever you do.
Make it a great day!
Adrian Corbuleanu
Miami Beach, FL
http://wittywebnow.com
Witty Web Solutions (http://wittywebnow.com) is a Miami Beach based software development company. Our code is lean, small foot print, easy to read, reliable and fast. We have excellent tech support. We save development costs by implementing agile project management techniques.
