Loading ...
Sorry, an error occurred while loading the content.

24930RE: SV: [scrumdevelopment] To SCRUM or not

Expand Messages
  • Roy Morien
    Nov 2, 2007
    • 0 Attachment
      I supervised nearly 60 student industrial experience projects during 2003 - 2004. I insisted on the student project groups doing these projects in an iterative fashion, at least. Whether they could really be said to be doing it in an agile manner is another matter, given that they had no clue whatever about what agile development meant.  My thoughts on the outcome of these projects were variously published, but perhaps the most complete is in the paper that was published in the IS Education Journal in 2005 (which I have attached for those who may be interested in reading it).

      I started with a cohort of students who had no information whatever about agile development, iterative development, Scrum. In fact, they had been inculcated in the waterfall approach, with heavy emphasis on documentation as the measure of project success (and academic success). I met even overt hostility at the start, and significant disbelief that the iterative approach, without full up-front analysis activity, was even viable, practical, allowable etc.
       
      However, even just requiring the students to get started and actually deliver small components of their system, able to be demonstrated to their client, very quickly caught their attention. They quickly realised that there were many beneficial outcomes. A happy client who could see progress almost immediately, greater confidence in themselves as being abe to deliver useable software quickly, greater satisfaction at seeing the client's delighted response etc etc.

      And this came about from very humble beginnings of using an iterative approach. There were no daily stand up meetings. The students had no idea about user stories. It was all very informal and not in accordance with any known agile approach; except iterative development, with real, useable results very early in the project activity. The niceties of Scrum or DSDM etc. would hopefully follow.

      Perhaps, Banibrata, you could follow this approach to get started. Softly, softly. Small successes building into bigger successes.
       
      Regards,
      Roy Morien

      To: scrumdevelopment@yahoogroups.com
      From: mj@...
      Date: Tue, 30 Oct 2007 11:59:21 +0000
      Subject: SV: [scrumdevelopment] To SCRUM or not

      Banibrata,
       
       
      Even if you don't want to change entirely to Scrum I would at least take a few of the practises:
       
      First, I would introduce iterative development driven by business value - implement the most business-valuable features first, and deliver production-ready, running, tested software in small increments, say bi-weekly. Since you are on a tight deadline this takes a lot of the risk out of the project - or rather, moves the risk to the lowest-value features rather than any feature.
       
      Also, even if management does not think there will be much change my experience is that they get inspired at the demos of working software and see all the missing features and the features in the spec that are not really needed.
       
      Inside an iteration make sure that you are not doing a mini-waterfall (see my post Iterative Development Gone Wrong about the Mini-Waterfall http://community.ative.dk/blogs/ative/archive/2007/03/18/Iterative-Development-Gone-Wrong-_2D00_-The-Mini_2D00_Waterfall-Anti_2D00_Pattern.aspx). Rather, try to teach people to complete the application feature-by-feature.
       
      Using a daily stand-up meeting to talk project and a status indicator such as a burndown chart is really useful, too. If you are used to estimating in hours you can use this - you don't need to learn user stories to get benefit. Just track the total estimated-time-remaining for the tasks in the iteration every day and you will have good visibility into you status.
       
      Also, if you have to deliver frequently you will see all the impediments in your organisation - so even if you don't call your project manager a Scrum Master, listen to the team and try to help the team work around the dysfunctions of the organisation - or change it for the better if possible.
       
      I realize the above has most of Scrum in it, albeit with other wording, so I guess it is kind of a Trojan Horse approach to implementing Scrum - or at read it as an advice to get the "frequent delivery of valuable business functionality" cycle going and then take it from there.
       
       
      Best regards,
      Martin
       
       
       
      ________________________________________
      Martin Jul, partner                        A|T|I|V|E|
      www.ative.dk | mj@... | +45 21 63 34 72|
       
      Lav bedre software hurtigere!
       


      Fra: scrumdevelopment@yahoogroups.com på vegne af Banibrata Dutta
      Sendt: ti 30-10-2007 11:01
      Til: scrumdevelopment@yahoogroups.com
      Emne: [scrumdevelopment] To SCRUM or not

      Hi,
       
      I've been following this group's posts for a while, and also have read some bit of material on Scrum etc., however, in everyother way, my experience with Scrum is "theoretical". Given a situation description, I'd request the practitioners and experts to kindly comment, if Scrum would be appropriate in the given situation or not.
       
      1) Product in question (objective of development) , as we understand it currently, has 15% UI/presentation, 70% application (business) logic, 15% support utilities/tools.
      2) Development team is a mix of people with varying skill-sets and expertise. Some actually are fairly good already, and some need some (infrequent) hand-holding. Team though is a lot more comfortable with waterfall model.
      3) No one with real Scrum experience (no purists), however, people have some exposure to Scrum-like methodologies. There is no certified Scrum master, and most of all, no budget to hire an expert to tutor / hand-hold this team (or Scrum master).
      4) Development schedule is quite tight.
      5) 75% of product requirements are known upfront (right now). Only 25% is expected to evolve / change in next 3-4 months. Real-customer (external) doesn't care about Agility, and doesn't need to / expect-to see snapshots periodically (well they'd be happy to see monthly or every-other- monthly milestone based progress). However, considering our management as an internal customer, they'd like to see more frequent milestones being met.
       
      To me, it looks like something with which Scrum would be too much of a risk (at the moment), and might be simpler to stick to waterfall. Comments and suggestions are more than welcome.
       
      thanks & regards,
      Banibrata
       
       




      Join Lavalife for free. What are you waiting for?
    • Show all 8 messages in this topic