Agile is the popular process du jour these days. Every time I hear "Yeah, we do Agile" or "I know Agile, been doing it for years" I cringe. These statements are spoken with the idea that Agile is this steadfast, unchanging, unalterable, single process that everyone is following. It is often spoken without any knowledge of the history of Agile, the people who signed the manifesto, or what the true ideal of Agile is.
Agile is always changing, will always be changing, and we'll most likely all be new to it all the time. Agile is something that flows differently for each group that tries it, but there are core tenants that must be met. These tenants aren't part of a "process", but could be, they aren't part of a "method", but might be a result. The point is, nobody really knows Agile, they know their team.
…or maybe they don't know their team if they think they know Agile?
That is something to seriously ponder. So how does one know when they're talking to someone who really does adhere to the Agile Manifesto. This is actually the simple part. Generally they won't even mention Agile at first, but instead they discuss processes almost immediately. Things they do to enable the developers, things they do to maintain velocity and keep things upbeat and positive.
Some of the first signs that a shop is truly Agile can be summarized by the answers to a few questions.
1. Does the team always have working software?
2. Can you regress and refactor quickly?
3. Do iterations ending or burn down charts stop velocity?
4. How many hours a week is the average?
5. How often does the team have to work excess hours?
…and one of the most important questions of all…
6. How often does your team get to speak with customers?
Does the team have working software? If it doesn't, it's probable that they are not Agile, or not quit Agile yet. A team needs to have working software. The only lgeitimate excuse I've ever heard is, "we started yesterday and are a few days away from working software". But even then, there should at least be some paper prototypes, or discussion notes with the customer about the proposed working software.
Once there is working software, how fast can the team regress and make changes? How fast can the team refactor? How often is the technical debt paid down? This is a major sticking point that I hear a lot. Teams must maintain testing, regression, and the ability to refactor. The team must refactor regularly and keep the debt paid down, if not, there isn't a reserve entity out there to pay down the technical debt or provide a stimulus! Without these things a team is running rough of Agile.
At the end of iterations does the team stop completely, take a breath of fresh air, and prepare for the hike up the mound of progress again? If this happens, something is definitely wrong. Iterations aren't supposed to break progress, merely reflect and maintain veloctiy. This is where I've become more and more a fan of lean style or kanban style. The hard stop that iterations often incur is very detrimental to velocity and sometimes even to morale.
Speaking of iterations and mounds of progress, how many hours are worked for that progress? Are the hours consistent and maintainable? If not, they should be. Beware the other inconsistency of trying to apply 40hr work weeks to everyone. Some people can do 40 and some can do 50, the key is to maintain velocity and maintain morale. If one person does 50 hrs per week, great, make sure they're not burning themselves out. Make it easy for them to maintain that.
The customer? "What, we have to pay attention to the customer?", is a statement I heard recently. I can't help but just look down whenever I hear this, at least when it is spoken seriously. The development process and software process should NEVER get disconnected from the customer. The industry as a whole learns this lesson over and over and over again each year. We should all now know, we must stay in communication with the customer.
With all those thoughts, I leave this entry with a question for everyone, "Is your team really Agile?"
In my humble opinion, as long as a team is working on acheiving and getting these key points in place, all is good. If not, the team should probably reflect a bit on what the end goal is.
