All About Agile | Agile Development Made Easy!
SCRUM for Large (3 month multi system) Projects
I currently work at a company and there is a misconception that Agile S/W Development cannot be used for large projects but only for small development (1-2 developers, 1-2 month proj est, affects only a single system, etc...) projects.
They refuse to try out Agile S/W development on larger projects even though the Agile projects used for smaller scale work has proven to work MOST effectively!
What are some tools, or examples, or data sets that I can use to present actual results of large scale projects using Agile/SCRUM that have worked successfully?
They refuse to try out Agile S/W development on larger projects even though the Agile projects used for smaller scale work has proven to work MOST effectively!
What are some tools, or examples, or data sets that I can use to present actual results of large scale projects using Agile/SCRUM that have worked successfully?
Views: 2
Replies to This Discussion
-
Permalink Reply by Kelly Waters on -
Hi Cory. You might want to take a look through Scott Ambler's blog. Scott works at IBM and his blog is all about scaling agile. He has some whitepapers etc. I'm not sure how much of it is evidence based, but you might find some things of interest there:
https://www.ibm.com/developerworks/mydeveloperworks/blogs/ambler
Kelly.
-
Permalink Reply by Manfred Lange on -
How large is "large"? I can give you three data points.
Between March 2005 and August 2007 I worked with a 24 people team, cross-functional. In this time frame and after some experimentation at the beginning we used release cycles of three months and weekly sprints. The methodology used was a mix of Scrum and Extreme Programming (XP). Some people call this combination "XBreed" (cross breed). This was a green-house project.
From August 2007 to October 2008 I worked with a cross-functional team consisting of 45+ developers, business analysts, testers, build master, user interface expert, performance engineer etc. on a large enterprise system. We split this team up into 3 to 5 teams, had release cycles of 3 months, and sprints of 1 week. We used Scrum combined with XP. The team delivered four releases on time and fit for purpose. This project was a mix of green-house development and work on the legacy system.
Since December 2008 I have been working with a 20+ people cross-functional team developing a large enterprise application (MIS) that has been on the market for over 10 years. Since March 2009 we've moved to monthly release cycles which has been very well received by the customer base. The shorter release cycles were very challenging at the beginning and we missed some release dates by a couple of days. The last four releases were on time, however, as we improved our planning and in particular our release management processes. The methodology we use - you probably can guess it by now - is a combination of Scrum and XP.
So it certainly scales beyond just a couple of developers as these three real-world examples demonstrate. And Scott might have information about even larger teams (see Kelly's reply for a link).
Manfred.
---
My blog on Agile Leadership
-
Permalink Reply by Hubert on -
Manfred,
Like others say: many blogs have metrics for large projects, showing that it works. I've done 100+ developer projects, have participated in 500+ developer projects, it just works. But throwing numbers at the problem may or may not work. What is the objection your management uses to say "It doesn't work"?
--Hubert
-
Permalink Reply by Cory James on -
Says that to devise a list of tasks for Sprints and plan out a larger project it would take "too long" to plan up front and that having dedicated resources for a longer term project is just not doable (or they do not want to put in that type of effort at the moment!)
-
Permalink Reply by Ilja Preuß on -
Sounds to me like they are misunderstanding how planning works for an Agile project. How do you plan for a "large" project in a non-Agile way?
Not having dedicated resources for a longer term project "not being doable" basically means that they can't do a long term project in an effective way, whether they are doing Agile or not.
If they wanted to give it a serious chance, I would highly recommend getting an experienced coach on the boat.
http://www.jeckstein.com/agilebook/ might be interesting to you.
-
Permalink Reply by Cory James on
-
Thanks everybody for the advice! I will regroup and try to convince again for a single larger scale pilot project in Q2...
© 2012 Created by Kelly Waters.
