{"id":96,"date":"2010-07-26T01:41:24","date_gmt":"2010-07-25T21:41:24","guid":{"rendered":"http:\/\/www.jrtwine.com\/blog\/?p=96"},"modified":"2010-07-26T01:43:05","modified_gmt":"2010-07-25T21:43:05","slug":"agile-development-scrum-pitfalls","status":"publish","type":"post","link":"https:\/\/jrtwine.com\/blog\/agile-development-scrum-pitfalls\/","title":{"rendered":"Agile Development – Scrum Pitfalls"},"content":{"rendered":"

I have been subjected to a few so-called agile development methodologies over the years.\u00a0 Most recently, <\/span>Scrum<\/span><\/a> was the one in question.\u00a0 Well, it was kinda-sorta-almost Scrummish<\/em>, which means it was not really Scrum at all, but we will ignore that for now.<\/span><\/p>\n

All in all, the use of stories and a Wiki to keep track of development, testing, etc. was a really good thing.\u00a0 It kept developers (er, me<\/em>) 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.<\/span><\/p>\n

Add to that the daily 10 minute standup<\/em> meetings,\u00a0which 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.<\/span><\/p>\n

However…<\/span><\/span><\/span><\/em><\/strong><\/p>\n

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.\u00a0 Here are the three biggest problems we (I) had with things.<\/span><\/p>\n

Problem 1<\/strong> – everyone needs to use the Wiki!<\/span><\/span><\/p>\n

More often than not, stories were written by our immediate supervisor\/manager after getting verbal<\/strong>(!) information from our business side person.\u00a0 The resulting stories were usually spot-on for what the business side had in mind, but not always.\u00a0 When they did not jive with the expectations of the business side person, the developers<\/em> were to blame, even though we were just following the story!\u00a0 The supervisor rarely took direct responsibility for any miscommunication.\u00a0 This would not have been a problem if the business side (and any other interested parties) used the Wiki for its intended purpose.\u00a0 At a minimum, they should have looked at the stories written by the supervisor to make sure that everything was kosher.<\/span><\/p>\n

Problem\u00a02<\/strong> – everyone<\/em> needs to use the Wiki!<\/span><\/span><\/p>\n

The Wiki was used for just about everything development-related.\u00a0 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.\u00a0 This was good.<\/span><\/p>\n

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.\u00a0 We just spent 10 minutes updating our stories so that anyone could find out what is going on just by clicking a few links.\u00a0 Now we get to spend more time updating this person or that person.\u00a0 It is not that the time taken is a big deal.\u00a0 It is the act of being distracted away from whatever we were working on.\u00a0 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.<\/span><\/p>\n

Problem\u00a03<\/strong> – Everyone…\u00a0 Needs…\u00a0 To…\u00a0 Use…\u00a0 The…\u00a0 Wiki!!!<\/span><\/em><\/strong><\/span><\/span><\/p>\n

Meetings further exacerbated this problem.\u00a0 Sometimes, questions would be asked during the standup meeting that were already answered on the Wiki.\u00a0 Sometimes, hours prior to the standup.\u00a0 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.\u00a0 It also shows a lack of respect for the development process — we have the Wiki there for a reason.\u00a0 Use It!<\/em><\/strong>\u00a0 If our examples (anyone above us in the food chain) do not respect the system, then why should we?<\/span><\/p>\n

Standups were not the only problem.\u00a0 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!\u00a0 This is not just disrespectful, but it is a waste of money as well.<\/span><\/p>\n

Assume that we have a 7-member team that has 5 developers, one supervisor and one business side person.\u00a0 Assume an average salary of $100K for each developer, $175 for the supervisor and $200 for the business side person.\u00a0 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\u00a0costs the company\u00a0$$$<\/span><\/span><\/strong> (remember: time is<\/em> money).\u00a0 How much money?\u00a0 Well, going by contractor’s math, a salaried person’s corresponding hourly rate is ~salary * .0005<\/span><\/strong>.\u00a0 Examples:<\/span><\/p>\n

$100,000\/year ~=\u00a0 $50\/hour.\u00a0\u00a0 Rational: assume ~250 working days in a year (including 2 weeks vacation), at 8 hours a day, that comes out to 2000 hours.\u00a0 So, 2000 hours * $50\/hr = $100,000\/yr.<\/span><\/p>\n

If the business person spent 15 minutes reading the Wiki, that would only be 15 minutes of their<\/em> time, so that would cost the company $25<\/strong>.\u00a0 By wasting 15 minutes of time in a meeting with the developers and the supervisor, this costs the company $109.37<\/strong>.\u00a0 ($84.37<\/strong> of everyone else’s time plus the $25<\/strong> for the business person’s time.)\u00a0 Check the math yourself if you do not believe me – more than 4 times as much time and money is wasted!<\/strong>\u00a0 Big difference, eh?\u00a0 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.\u00a0 At a minimum, this is $37.50<\/strong>, and 15 minutes of developer time where they were doing something other than development.<\/span><\/p>\n

A simple way to avoid this problem – everyone in a meeting should assume that everyone else’s time is at least<\/em><\/strong> as valuable\/important as their own.\u00a0 Once you start thinking like this, you may stop wasting other people’s time as easily as you once did.<\/span><\/p>\n

Conclusion: using any agile development methodology and its tools is probably a good thing<\/em>.\u00a0 But you must get everyone involved to buy-in and use the system.\u00a0 Having\u00a0anyone (including those higher up on the food chain) refuse to use the system can make others wonder why.\u00a0 If\u00a0anyone is too good for the system, then why are we\u00a0saddled with the burden of using it?\u00a0 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.\u00a0 But this should be handled by a lower manager, not by the developers themselves.<\/span><\/p>\n

The developers have a job to do – let them do it.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

I have been subjected to a few so-called agile development methodologies over the years.\u00a0 Most recently, Scrum was the one in question.\u00a0 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 […]<\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[54,6],"tags":[],"class_list":["post-96","post","type-post","status-publish","format-standard","hentry","category-agile","category-james"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t