Scaling issues
I spent the last month living in a different world. Far away from web development and the ability to understand the entire application, I have plenty to learn from. The first thing I realized was that nothing really is the same. With a code base counted in millions of lines, compiling it all just to make a test does not make any sense. Luckily, the version control system used automatically fetches precompiled binaries from the network when available. Plugged on a gigabit network, compile time drops from several hours to a few minutes of linking. In situations like this, tools don’t only help, they are a prerequisite to development.
The team I work in has been moving towards agile methodologies for quite a few months, but the transition isn’t all that easy. Daily stand-up meetings with everyone involved from product designers to QA and documentation does help. It keeps the team together and focused. Issues are better understood and collaboration is better. Communication is probably the most appreciated aspect of agile methodologies in a group that used to be guided by heavy processes. These meetings should be considered as a tool. I think it’s one of those that really scales from small projects to larger ones, as long as there are enough individuals to perform a meeting.
Other techniques part of the agile bundle don’t scale so well. The entire idea of writing user stories is completely ridiculous. In most applications, it makes sense to think of the end user objective of the development. Those requirements can be written in stories and keep the team focused on achieving their goals. My team works on low level implementation issues. The only story that the end user would care about is the one the entire team was put in place for. Cards written on the wall will certainly not be about something the user cares about.
In order to solve some issues related to the transition to agile, a consultant was invited to discuss with the team. No questions asked, the guy knew what he was talking about. The problem was that he knew nothing of the business. It probably wasn’t part of his mendate to spend time with the team to see the issues for himself, so he can’t be blamed for it. The nature of the work done at Autodesk was probably very different from anything he saw before. Repeating the concepts of user stories and breaking them up made no sense to anyone.
One of the major complaints the team had was that meetings were too long. Too many technical issues were discussed. Fair enough. The consultant’s proposition was to move the meeting time from 11 to 11:45. This way, people would be in a hurry to finish the meeting in order to go eat. I had seen that advice before. I actually thought about it before. The reason I didn’t mention it was that I knew that no one actually ate at the same time.
How good can your advices be if you don’t know who you give them to?
The agile methods contain quite a lot of good elements. There are too many methodologies. They all come packaged in a book. I would actually need to read a few of them, but I am almost certain that 80% of everything they contain is in every book. It would be much easier if everyone would simply select practices they want to use from pros and cons. There is no real need for a package-deal method. Iterative development, white board, stand-up meetings, customer involvement, multidisciplinary teams, continuous integration, … all these things can be used by themselves. They all bring something to the development, but if you did everything that is good for projects in general, you wouldn’t have much progress to track. Just include practices that solve a problem you are facing, remove those that bring less value than the effort they take and you will soon have a methodology of your own, and it will evolve over time to suit your needs. All you need is to stay up to date on available practices and know the problems you are facing.