I have been subjected to a few so-called agile development methodologies over the years. Most recently, Scrum was the one in question. Well, it was kinda-sorta-almost Scrummish, which means it was not really Scrum at all, but we will ignore that for now.
All in all, the use of stories and a Wiki to keep track of development, testing, etc. was a really good thing. It kept developers (er, me) focused on what needed to be done, keep straight how it was gonna get done, and identify any problems that would prevent it from getting done.
Add to that the daily 10 minute standup meetings, which was the place to specify to everyone else on the team what you were going to be working on today, and what, if anything, was standing in your way.
However…
There were also some things that got in the way of using all of these tools, and those things tended to be the immediate (and sometimes upper) management, and the business side people. Here are the three biggest problems we (I) had with things.
Problem 1 – everyone needs to use the Wiki!
More often than not, stories were written by our immediate supervisor/manager after getting verbal(!) information from our business side person. The resulting stories were usually spot-on for what the business side had in mind, but not always. When they did not jive with the expectations of the business side person, the developers were to blame, even though we were just following the story! The supervisor rarely took direct responsibility for any miscommunication. This would not have been a problem if the business side (and any other interested parties) used the Wiki for its intended purpose. At a minimum, they should have looked at the stories written by the supervisor to make sure that everything was kosher.
Problem 2 – everyone needs to use the Wiki!
The Wiki was used for just about everything development-related. What needed to be done, how it was going to get done, how it was going to be tested (the QA team members would also use the same Wiki), and, most importantly, show the progress of a story and its tasks. This was good.
What was bad, is that developers often would get contacted directly by either our supervisor or our business side person to check on the status of things, or get details on what was being done or how it was being done. We just spent 10 minutes updating our stories so that anyone could find out what is going on just by clicking a few links. Now we get to spend more time updating this person or that person. It is not that the time taken is a big deal. It is the act of being distracted away from whatever we were working on. Having to switch gears throughout the day to answer questions that have already been answered on the Wiki is not just a waste of our time, it shows a lack of respect for our time and what we do.
Problem 3 – Everyone… Needs… To… Use… The… Wiki!!!
Meetings further exacerbated this problem. Sometimes, questions would be asked during the standup meeting that were already answered on the Wiki. Sometimes, hours prior to the standup. Not only does this show a lack of respect for the developers, it shows a lack of respect for other people in the meeting as well — their time is being wasted here, too. It also shows a lack of respect for the development process — we have the Wiki there for a reason. Use It! If our examples (anyone above us in the food chain) do not respect the system, then why should we?
Standups were not the only problem. If any meetings were called that involved other people (like the business side), we would often get stuck answering information that was not just recently on the Wiki, but stuff that may have been answered at the start of the iteration, which may have been more than a week ago! This is not just disrespectful, but it is a waste of money as well.
Assume that we have a 7-member team that has 5 developers, one supervisor and one business side person. Assume an average salary of $100K for each developer, $175 for the supervisor and $200 for the business side person. If the business side person takes up 15 minutes of a meeting asking a question (and getting answers) for something that was already on the Wiki, that costs the company $$$ (remember: time is money). How much money? Well, going by contractor’s math, a salaried person’s corresponding hourly rate is ~salary * .0005. Examples:
$100,000/year ~= $50/hour. Rational: assume ~250 working days in a year (including 2 weeks vacation), at 8 hours a day, that comes out to 2000 hours. So, 2000 hours * $50/hr = $100,000/yr.
If the business person spent 15 minutes reading the Wiki, that would only be 15 minutes of their time, so that would cost the company $25. By wasting 15 minutes of time in a meeting with the developers and the supervisor, this costs the company $109.37. ($84.37 of everyone else’s time plus the $25 for the business person’s time.) Check the math yourself if you do not believe me – more than 4 times as much time and money is wasted! Big difference, eh? Even by calling a single developer, and chatting for 15 minutes, this costs the company more than necessary – it costs the business person’s time, the developer’s time, and the time for them to switch gears back to whatever they were doing before the unnecessary interruption. At a minimum, this is $37.50, and 15 minutes of developer time where they were doing something other than development.
A simple way to avoid this problem – everyone in a meeting should assume that everyone else’s time is at least as valuable/important as their own. Once you start thinking like this, you may stop wasting other people’s time as easily as you once did.
Conclusion: using any agile development methodology and its tools is probably a good thing. But you must get everyone involved to buy-in and use the system. Having anyone (including those higher up on the food chain) refuse to use the system can make others wonder why. If anyone is too good for the system, then why are we saddled with the burden of using it? If there is a senior-level manager that thinks that they are too important to click a few links on a web page, then fine. But this should be handled by a lower manager, not by the developers themselves.
The developers have a job to do – let them do it.