In order to produce agile software there are really two components that have to stay agile: the people and the code (which is ultimately the product). If either one doesn’t stay agile the other one is doomed. If the people don’t stay agile then there is no motivation to change the code. If the code is not agile then it doesn’t matter how much the people want to change it – it is very difficult. Both are required for an agile software company.
How do we go about making sure that our people stay agile? The more time they are able to think (and code), the more agile they become. Developers work best “in the zone.” It takes about 10-15 minutes of uninterrupted time to get there. One way to keep interruptions from occurring is to hold fewer meetings. There are three fundamental practices that should be instilled in all called meetings.
- Identify the required people and include an agenda in the invite.
- If those required people are not present within 5 minutes of the meeting’s start time, cancel the meeting.
- Finally, the person who called the meeting should always summarize the meeting appropriately. They should also somehow publish the notes and/or action items from the meeting (Sharepoint? in the bug tracking system?).
If that seems like a lot of work, it is. That’s really the point. Because you shouldn’t interrupt people’s valuable time without a clear important goal. If it is worth calling a meeting, it is worth doing it right. If that serves to deter the number of people that call meetings, then that is a positive side effect.
Another great way to keep people agile is by pairing them together, and encouraging them to discuss possible solutions to complicated problems. Pairing has a number of benefits involving skills transfer as well as offering two different viewpoints on the problem.
Agile people have versatile skill sets. They are generalists. They work hard to learn new skills and apply those skills until they end up with multiple specialties. Over time of course a skill might be forgotten, but they could pick it up if need be . One of the best ways to encourage this is by rotating people throughout the department. Instead of keeping your web developers and your database engineers segregated and fixed, shake them up! Training and conferences also help give people versatile skill sets. Basically trained people make less mistakes.
How can we keep the code agile? Agile code is healthy code. It is easy to change. Unit tests are the best way that you can assure that your code is healthy, and refactoring is the best way to assure that your code is easy to change. When you have good well-trained people working on code making lots of changes, it becomes easier and easier to change over time. As you have new people or poorly trained people working on the code it tends to get more and more difficult to change or fragile over time. As people are able to take their time and make sure they do the job right (have only 2-3 things to deal with at any given time) the code tends to improve, and as people are harried by deadlines and release dates they tend to do a poorer job. Peer reviews can also help balance this effect. The person peer reviewing the change has nothing on their plate right now except for looking at this code. If they do a poor job and let lots of stuff go, it might affect the other things they have on their plate later. If they do an excellent job, it’s not going to take that much longer than the poor review, and there is a positive impact to future tasks. So they are motivated to make sure they catch items and get them addressed.
I think one of the key things to push for is a lightweight framework that always makes sure that developers are doing the right thing. Any rule worth stating is worth enforcing. Also, program managers should be setting aside time to make sure that their code base is agile enough to support the changes that are bound to take place. To keep the code agile you need a person or in the case of a ton of code maybe even a group of people that go around looking for ways to eliminate code and make it simpler. This person(s) can spend their time trolling through the code looking for inefficiencies and areas to make common. Over time this will pay off in a sub-linear rather than exponential increase in complexity.