Agile, eXtreme Programming (XP), Scrum, and collaborative development are all hot topics. Everyone wants in. “The old, archaic ways are all wrong; you must embrace modern methods” is the cry, especially from our younger IT professionals. You know what? Maybe they are right! There’s a lot to like about Agile. What started back in 2001 with the Agile Manifesto has flourished into a movement that has increasing mindshare. I’ve read many articles and books. We have moved from experimenting with Agile to having it become our default “methodology” on most major projects – we’ve even brought in some third party experts to help us “see the light”. I liked a lot of what I experienced.
Here are some observations and things I like and don’t like about Agile:
1. There are lots of opinions on Agile (and non-Agile).
There is great ambiguity about the term Agile (capital A, a noun abbreviating “Agile Software development”) and agile (small a, an adjective describing an assortment of techniques that improve IT agility). There are fanboys and haters on both sides of the ledger. If you’re an experienced IT professional, you’ve seen many battles like this before (databases, operating systems, Object Oriented,
etc). Agile software development, at its foundation, is comprised of principles and techniques, many of which appear in other methodologies. My key takeaway has been to pay attention to the principles of agile and decide which ones can have the most impact to our IT organization. Since the focus is on the principles, I don’t care if we call it agile (or XP or Scrum or hybridized waterfall (Water-Scrum-Fall)), or if someone says “You have to do X” to be considered agile. I do care about improving our outcomes as an IT function.
2. Iterative development
I believe iterative development to be general goodness. While I believe it does not apply well to ALL projects, it certainly seems like it applies pretty well to most. I’d say easily 90% of the projects I’ve done in my career could have been executed better if done more iteratively. There is clearly a negative correlation between delivery success and length of time it takes the first release to be completed. The feedback gained by having software to show early and often can dramatically improve the end product.
3. Design is a process, not a deliverable.
Accenture is known for its strong methodology and focus on deliverables. While I believe deliverables are important (some more than others), working software is more important than comprehensive documentation (documentation for support purposes is way overrated, in my opinion – walk around your support teams and get a sense for how often they are pulling out a 3 year old design document).
During design we must learn, adapt and translate. Martin Fowler’s Is Design Dead? article should be required reading for all involved with building software.
4. Requirements is a highly collaborative process, not just an IT process.
User stories (similar to use cases, but simpler) are where things start. Have the users actually write the stories. IT can work side by side with them, but I love the idea of the business users writing down what they want over IT writing down what they thought they heard. User stories should have acceptance
criteria so we can know when “good is good enough” and we can move to the next one. Also, turn the requirements into something visual as quickly as possible. Visual requirements are much more easily consumed and processed than a 14 page, 168 bullet point word document.
5. Change is not the enemy, bad software is.
Change control/scope control processes are often designed very explicitly to limit change during the
lifecycle. Yes, we have to manage budgets. Yes, we have to get the right people to make the right decisions as early as possible. But the reality is that we make mistakes or the business changes. We must design our change control process to allow change, perhaps even to encourage it where it improves the business outcome we are pursuing. Many times in non-agile development we reject change simply because our processes are designed such that change, especially late change, is prohibitively costly. “We must freeze requirements/design/code” is and shortsighted phrase.
6. Automate testing and deployment.
Early. Agile often gets mischaracterized as “cowboy” development (i.e. code, deploy, everything else later or never). In fact, agile projects often utilize Test Driven Development where you actually write the test before you write the code. Automation of testing (even unit testing) and deployment (install scripts, conversion) are also items that should be done during the development cycle, not the week before go live.
Continuous integration of the software, where software is tested end to end earlier, is also a significant change from traditional waterfall development.
7. Real-time, daily collaboration between the business and IT greatly increases success.
I look at the most successful projects that I have been part of and they involved daytoday working with business teams, often even colocating.
However, in a global company like Accenture, getting people together physically on a daily basis is often not practical. Our developers are spread around the world as our most of our business functions. We have worked hard to overcome this with many collaboration communication tools at our disposal such as Telepresence, Skype, and, of course, the dreaded teleconference.
I’m a big fan of desktop VOIP with video as it makes visual communication cheap and easy. I believe communication with video leads to much more engaged meetings (no cruising Facebook during the meeting!).
8. Technical excellence has excellent ROI.
If we are to adapt to change more efficiently, we must design more thoughtfully. This approach can conflict somewhat with the expectations of agile to just “slam things in”. The risk here is to embrace RDD, which is Résumé Driven Development – where technologies and architectures are chosen in order to enhance the resumes of those developing them.
9. Use simple tools and techniques.
I’ve never been a big fan of complex modeling tools. Documenting user stories on 3×5 cards, daily standup meetings, burn down charts, post it prioritization, Google docs, etc. are the types of tools that agile teams are finding useful. “Everything should be made as simple as possible, but not one bit simpler.” – Albert Einstein
10. An empowered team comprised of motivated individuals has a huge impact.
This one sounds like it would be good for any approach, not just agile. I think the empowered team is a critical notion. Again, empowered teams are always good, but I think they can unleash a productivity multiplier on an agile project. Especially in big companies, layers, slow decisionmaking, and lots of signoff can cancel some of the benefits of agile practices. While a quality software product is the goal, I do believe that with agile practices, you can sometimes get it wrong, find it, and fix it faster than you can get it right in the first pass (I realize this is near blasphemy to some). The team is the dominant force in
agile, not an individual. Many developers can (and should) work on the same piece of code – the old problem of “Dave is the only guy who knows anything about that program” should never happen.
11. Commercial elements
Commercial elements (i.e. using 3rd party IT providers) can place an additional complexity on agile development. Many times when working with a 3rd party IT services company, the commercial arrangement calls for a “fixed price for a fixed scope”. While this can be managed in an agile project, there are some inherent conflicts. I would recommend using an IT provider where you have a track record of trust and have a time and materials commercial arrangement.