2

We are currently in the process of implementing Scrum. I would like to let us started with a tool to help the team get along with it (see here about this point), but after a presentation I made where I spoke about the agile manifesto, our CEO is arguing that it's against the agile principles ("Individuals and interactions over processes and tools"). Problem is: we are not going any further without some formalisation of the organisation, and a tool to organise our backlog and our sprints would be the right thing to do now, in my opinion. Did you meet such resistance when you started with agile methods? How have you overcome them?

3
  • I have the feeling I didn't made the situation clear enough. In our company, good ideas go to waste because nothing like a backlog is maintained. Actually, the teamwork is kind of chaotic. Introducing Scrum is a way to obtain a more rational and effective organisation. Now, our CEO is using this point of the agile manifesto as a reason to not change anything. So it's not cardboards and pencils vs. sophisticated softawre, it's any tool vs. nothing! Commented May 17, 2011 at 9:02
  • 2
    Traroth, two things: First, maybe remind your boss that it is "Individuals & interactions -over- processes and tools" not -instead of- People need help to persist information. Second, start with Excel or a Google spreadsheet (they are free enough) then show the value of using this. You may also want to re-post the question as "interpreting the Agile Manifesto: different perspectives" instead of tool oriented...
    – Al Biglan
    Commented May 17, 2011 at 13:20
  • I'm not sure my question is generic enough, and mainly, it wouldn't help me to find a solution to my specific problem, which is the purpose of this site... Commented May 17, 2011 at 15:39

3 Answers 3

3

Interesting discussion. First I need to issue a disclaimer, I work for Rally but I am not on StackExchange to promote our company or our product.

I agree with your CEO that individuals and interactions come first and Ben makes a good proposal for a co-located team.

I would disagree with the suggestion to use Excel, it is a lousy tool for collaboration and it is a manager's tool not a team's tool and this is a cultural impediment. If you are determined to explore this option try Google Docs vs. MS Office, it has much better collaborative support. Maybe you can't create pivot tables but perhaps this is a good thing :-)

If you are determined to use a tool, there are plenty of teams that succeed with a tool however bear in mind that it may not solve your problems.

I would also advise against "formalism", a basic tenet of our agile approach is continuous improvement, there is no standard to formalise just core principles to adhere to.

1
  • Good point. Google Docs can be interesting for collaborative work, agreed. Thank you! Commented May 24, 2011 at 13:31
4

I kinda agree with your CEO! If you've got a co-located team, I'd stick with whiteboard, index cards and sharpies.

If you have a distributed team, make the point that everyone needs visibility of progress for Scrum to really work - we aim to encourage individual decision making and interactions with others and an important trigger for that is the wallboard. For a distributed team, that means having a tool of some kind is useful.

3

Honestly, it sounds like you are expecting a tool to help you out with Scrum, and your questions both here and in the link you gave seem like you haven't yet arrived at the understanding required to assess and select a tool yourself. My suggestion is until you can write down some expectations and selection/evaluation criteria for a tool, you might be expecting too much from a tool and aren't ready for one.

When I (as a Director) brought Scrum into our organization, I first got my managers and technical leads on board and bought into the change (it was a biggie). Then sold the idea upward and outward to get buyin. (sounds like you have this already) Then, I offered to buy the teams four tools to assist them: Dry erase boards, sticky cards, projectors and Excel. I wanted them to be -very- close the to the data they were managing. Then needed to calculate velocity and understand how to work with User Stories without the framework/constraints of a tool to force them into an interaction. They are smart people and would learn and adapt. We also got an Agile coach to help with the transition.

Once we understood the process and really made it our own, then we looked for a tool that fit into the way we worked. We had enough experience to know what we needed help with managing and what we just didn't need to bother with.

Tool suggestions:

  • Keep your backlog in Excel. It sorts well and has more than enough capacity to deal with the data you need.
  • Portable board or dedicated wall to persist important information
  • Sticky poster paper for Retrospectives (allows you to write on the fly then transcribe notes later)
  • Projector for demos and projecting Backlogs
  • Dry erase board that you can draw your burn-up and burn-down charts onto (draw the axes with a Sharpie)
  • An agile coach, or (if you can't afford it) an open brainstorming/improvement/review time that operates above the Sprint Retrospectives. Have a meeting once a month to deal with the strategic improvement ideas for Scrum. When this team begs for a tool, you can then drive the selection criteria and select from the very large list of free and commercial tools.

If you are already 9 months into this process and your teams are frustrated with the data they are managing, then build a budget. If Scrum is achieving value (more predictable schedules? shorter delivery schedules? improved quality?) then you should have no problem getting the money needed to buy a tool. If Scrum isn't providing this business value, then a tool isn't going to help at all.

my 2cents...

2
  • 1
    +1 to @Al. First you need to get familiar with the process itself. Afterwards you will be able to choose the tool more wisely as you will already know what you need to improve in the mechanics of your process (as tools usually help with the mechanics not with the process itself). Otherwise your process may be easily dominated by the tool which is usually not what you want. Commented May 17, 2011 at 7:19
  • Exactly. Looking for a tool while implementing an agile methodology may give the impression that the tool is the result self contained, which is far from reality. Assuming that the team is co-located, go for the quickest and cheapest approach as possible. Commented May 4, 2016 at 18:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.