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

Re: [scrumdevelopment] Re: Freeware/open source SCRUM tool

Expand Messages
  • Daniel Wildt
    I have used Scrum Works basic for some projects, it is great and easy to use. Now I m using spreadsheets. I m not using boards and cards cause currently I
    Message 1 of 25 , Mar 8, 2008
    • 0 Attachment
      I have used Scrum Works basic for some projects, it is great and easy to use.

      Now I'm using spreadsheets. I'm not using boards and cards cause currently I don't have environment for that  and I'm working with distributed teams. The spreadsheet is going well and it is an easy point of contact for the whole team.

      The software must help your team. But the team must be able to run a sprint without the tool.
      Try not to use a software tool to control your sprint if you are able to do that in the beginning.
      Just to make sure that the team is aware about how to work with the mechanics.

      Regards,
      Daniel Wildt
      http://danielwildt.blogspot.com
      http://weblogs.java.net/blog/dwildt/

      On Sat, Mar 8, 2008 at 7:01 AM, Michael Yang <michael.cy.yang@...> wrote:

      Well,
       
      We use Spackle as our scrum tool.
       
      regards,
       
      -Michael

      On Thu, Mar 6, 2008 at 7:17 PM, Murali Yelamanchili <murali_yelamanchili@...> wrote:

      Hi,

      We use ScrumWorks Basic for our Scrum tool, which is still free. I won't say that it is the only tool we use. We use a combination of ScrumWorks, JIRA and Excel.

      As for whether to use tools or not here is my take on it -

      Let us not forget the reality today. In India, where I work, we don't often have the luxury of large office spaces with large meeting rooms. Sometimes we make do by just huddling at the Scrummaster's desk and finish the standup. It is next to impossible to get a physical taskboard, because the office space comes at a premium.
      It is not ideal, but the best we can do under these conditions. Just to give you an idea, our floor are seats 70 engineers, and we have only 1 room that can accomodate 10 members at best at a time. And there are 11 teams doing Scrum, and if we all want a taskboard in there, and all try to dash into the room for a meeting.
      As Manager and Scrummaster, I don't particularly like what I have to do here.
      Similarly, post-it notes are rationed, and not in full supply as and when we want them.

      We use a distributed tool (ScrumWorks) because our Product Owner works out of Australia. It works most of the time, except for when the PO is off the grid - I mean when he is on the flight or is not able to connect to the Internet (on the beach or a coffee shop :-) )
      When he is not connected, he finds it very difficult to record his ideas into the Product backlog, because he cannot access Scrumworks, and uses an Excel spreadsheet to record his ideas, and then syncs it with the backlog inside Scrumworks when he is back on the VPN again. This is a manual task, because Scrumworks is not really good with export/import of information. But we don't waste time trying to fix it, but get along with it, the best we can, and work around it.

      Above all this, I am required to produce an executive summary for my bosses once a Sprint ends, and the Scrum tool makes it easy for me as it generates most of the information I require for the report.
      Do I like it? No - not really, but I have to do it.

      My point is that tools are useful to those who really need them. I think most of us are sane enough not to use a tool just because it is fashionable, or makes us feel good.

      The reality is a bit different than we would like it to be - In my case this means - no physical taskboards, no post-it notes (sorry no supply), shortage of markers and certainly no meeting rooms. And a PO, who needs  offline access, combined with upper management who want executive summaries of Sprints.
      Using tools makes my life as a manager and scrummaster easier to certain extent, and helps me concentrate more on what I else can do for the team. So I would certainly advocate using them, but also would state, like others have done here, we be judicious in our use of these tools and not think that they offer a solution to all our problems.

      Regards,
      Murali

      ----- Original Message ----
      From: Ken Schwaber <ken.schwaber@...>
      To: scrumdevelopment@yahoogroups.com
      Sent: Tuesday, March 4, 2008 4:08:41 AM
      Subject: RE: [scrumdevelopment] Re: Freeware/open source SCRUM tool

      Excellent, Pete. Another problem I run into is that enterprises using a Scrum tool mistake that for doing Scrum.

      Ken

       


      From: scrumdevelopment@ yahoogroups. com [mailto: scrumdevelopment@ yahoogroups. com ] On Behalf Of Pete Deemer
      Sent: Monday, March 03, 2008 7:23 AM
      To: scrumdevelopment@ yahoogroups. com
      Subject: Re: [scrumdevelopment] Re: Freeware/open source SCRUM tool

       


      let me share a story. I once knew a team that was doing scrum quite
      happily, using pencils and paper and post-it notes and not much else.
      but it felt very low tech and old-fashioned to them. as one of them put
      it: this is how my grand-dad used to do things back in his day! so they
      decided to come up with a better approach. they set up a database to
      store all the info that previously was living on paper, and they built a
      bunch of nice web pages for entering and viewing the data. with each
      week that passed, they added more and more features, to the point where
      the tool was getting quite complicated. unfortunately, they found
      themselves spending more and more fixing and extending the tool, which
      took time away from other things. but it was very powerful. instead of
      just one simple burndown chart for the whole team, they now could look
      at individual burndown charts for every member of the team, and they
      could see who was ahead and who was behind. and someone added a wiki
      page that allowed everyone to type in their daily update and blocks,
      which allowed the team to stop doing the daily scrum meeting in person.
      and someone else built a clever tool that automatically create a task
      queue for each team member, so that they always knew exactly what to
      work on; they didn't need to even think about it, the system just told
      them what to do. and management learned about the tool (the team showed
      it off during a sprint review), and asked for the team to create a
      single page for the exec team to look at, which showed the burndown
      chart for every single person in the department, and anyone who was
      behind on their tasks, or on their "delivered versus predicted task
      hours per day" (a new metric someone suggested they monitor, since the
      data was all there in the tool) would show up with a bright red blinking
      flag next to their name. The execs liked this dashboard so much they
      asked for a wap version of the page, so they could check it via their
      blackberry from the car, train, etc., a couple times a day if they
      wanted. Over the course of about two months, what had been a happy and
      productive team somehow evolved into a group of stressed out, unhappy
      individuals all constantly looking over their shoulder, and none of them
      had the faintest idea how they were doing during the sprint, which led
      to missed goals and even closer executive monitoring. Getting them back
      on track was very costly and painful, and it was doubly disappointing
      because the whole detour occurred for no good reason.

      I'm not saying that tools are wrong, by any means; for larger projects
      and multi-location teams, they can be helpful. But before going that
      route, I would get very clear on the problem you're trying to solve, and
      be certain that your tool is going to address the underlying issue, and
      not simply disguise it.

      ------------ --------- --------- -------
      Pete Deemer
      GoodAgile
      CSM in Delhi (Gurgaon), March 5-6 - seats still available - full details
      at goodagile.com

      poojawandile wrote:
      >
      >
      > I am looking for a tool to manage spint backlog, product backlog,
      > issues, risks, burndown chart, etc. Though this can be acheived
      > through an excel also, I just thought a tool may offer some more
      > features which may not be exactly and easily possible through an
      > excel spreadsheet, for delegating activities to team emmebers and
      > allowing them to update their tasks on their own. With my limited
      > knowledge on Scrum, yes, I would be interested in knowing the pros
      > and cons of using a tool against an excel sheet or the need of a
      > tool itself.
      >
      > Thanks,
      > Pooja
      >
      > --- In scrumdevelopment@ yahoogroups. com
      > <mailto:scrumdevelo pment%40yahoogro ups.com>, Pete Deemer

      > <petedeemer@ ...> wrote:
      > >
      > > Hi Pooja, I get this quite often. My first question is always:
      > What are
      > > the problems you're having that you'd like the tool to solve?
      > >
      > >
      > > ------------ --------- --------- -------
      > > Pete Deemer
      > > GoodAgile
      > > CSM in Delhi (Gurgaon), March 5-6 - seats still available - full
      > details
      > > at goodagile.com
      > >
      > >
      > >
      > >
      > > poojawandile wrote:
      > > >
      > > >
      > > > Hi,
      > > > Could you please suggest any freeware SCRUM tool?
      > > >
      > > > Thanks,
      > > > Pooja
      > > >
      > > >
      > >
      >
      >




      Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now.





      --

    Your message has been successfully submitted and would be delivered to recipients shortly.