Child pages
  • Tools and agile software development - a contradiction?
Skip to end of metadata
Go to start of metadata

Arguments for and against using tools in agile software development

Arguments for using tools in agile software development 

    • JIRA for bug tracking (indicated by a paper advocate)
    • Participants produce process control software themselves so using the software is natural
    •  Simple allocation of tasks, e.g. when there are queries. Everything is traceable via the ticket history
    •  Simple documentation of external feedback
    •  Specification, etc. can be recorded easily
    •  Teams distributed around the world
    •  Cross-team coordination is simplified (e.g. for a quick status update)
    •  Hours are booked on tickets in the tool for billing
    •  Evaluations via expenditure
    •  Positive experience of one participant with very large screen, JIRA+Greenhopper. "Does it work well?" --> "Excellent!"

Arguments against using tools

    •  Good experiences from using story cards as backlog
    •  Index cards on the table can be handled quickly and easily in the backlog management
    •  "Comment and go" instead of real exchange when additional information is added to the tool
    •  Information recorded on the cards should be limited because the communication between the team and PO is the main focus
    •  Limited space is therefore an advantage
    •  GUI-intensive items can be printed out and brought as hard copies to meetings.
    •  Sufficient metrics can also be determined on paper: e.g. story burn-down or task burn-down
    •  Many metrics are not used at all
    •  Planning on paper demands participation. PO must be able to present the story this way, too. Estimate game, etc. is possible.
    •  Prioritizing the backlog is even a challenge when using tools with greater backlogs. Paper reduces complexity
    •  System performance can be a hassle when every click takes up time
    •  First agree on the process rather than struggling with tools from the start
    •  Lack of transparency, things are more likely to get lost (version not assigned...)
    •  Task board is located in the office and is highly visible. Everyone sees the current status, often more than once a day (when getting coffee....)
    •  One participant reported that teamwork declined after introducing a tool for a trial run

 Or both?

  • Screenshots, URLs, etc. in the tool, but the "reminder" for the story stays up on the board
  •  Possible/worthwhile using plugins
  •  Hybrid solutions are also difficult. Having the big picture on the board but the details on paper (e.g. task break-down) may help.

Diese Seite auf Deutsch sehen.