In agile/scrum teams who is responsible for the choice of agile planning tools [closed]

Question

What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?

Sprinkle

This question is off-topic because it's not within the scope for this site, as defined in What topics can I ask about here? Also see: What types of questions should I avoid asking? You may be able to ask on another Stack Exchange site, for example Project Management or Software Engineering. Be sure to read the on-topic page in the help center for any site on which you intend to post a question. – Baklava

Answer 1

Team should decide whether a tool is to be used; but I think suggestion most commonly comes from the Scrum Master as (s)he is most likely to have experience using tools. Any team member can suggest tools of course.

Anyway, my feeling is that given Scrum philosophy, the whole team needs to agree on this in my opinion. Usually things start with "let's try this, see if it works", and is refined along the way, just like anything else in Scrum. It should not be top-down enforcement, same way as using Scrum methodology should be team decision, not handed down from top.

Cheongsam

"When in doubt, ask the team" – Cushiony

@qntmfred I think it is more important to have the "let's try this, see if it works" attitude with a lot of common sense, than leave it totally to the Team and ask them. Scrum is so transparent that, if you form a cross functional team of idiots who know nothing about software development, they will choose a crappy tool, make idiotic decisions, and produce crappy software, Scrum would make the management aware of this after 1 iteration (2 weeks or a month) and then some inspect and adapt will change things. – Outsole

My point is that decisions should be made using common sense. An organisation should not just blindly go by the Teams decision, especially in a case of an inexperienced team. What if the Team does not have enough experience in that field? They will most probably choose a crappy tool and waste a month figuring it out. So be it, but why waste a month when you can get suggestions from someone who has more experience in that field? Instead, the Team should be open and take suggestions if required, and make a decision based on that. A good person to take suggestions from is an experienced ScrumMas. – Outsole

sjt: your comments seem somewhat conflicting; on one saying it's ok to make mistakes since you feel the pain yourself, but then saying it's bad for the same reason. I think that team should indeed be trusted to try out things, and possibly making mistakes. But good developers and teams should not insist on making their own mistakes; they should learn from others. And I fully distrust any organizations to "know better". But maybe that's just me. – Cheongsam

@Cheongsam My comments are not conflicting at all, they were perceived as being conflicting. I'll take a crack at it again. An example: There could be a Cross functional Scrum Team working together to get a user story 'done', but they might realize after getting a little bit into it that a particular area of expertise knowledge is needed for implementation which is not present in the Team, in that situation the Team should not make non expert decisions just for the heck of it, common sense should be used, the Scrum Master must be informed about the need for resource for the iteration (contd) – Outsole

If the SM does not have the power, the organisation should help find one. On the contrary (in this particular situation) if the Team is asked to do whatever it can just because they are self managed, just for the sake of it, would not be using common sense. My example is just pertaining to a Team which may be inexperienced in a particular area. All I am saying is, experts (within or outside the Team) should be consulted for solutions in their area of expertise when required, keeping in mind that they are a part of a cross functional Team, with no particular job titles other than "Team Member" – Outsole

Answer 2

Great question. There is a lot of value to embracing the self organization of agile and allow the teams to choose their tools. However, there are usually constraints imposed by the business. For instance, the business may not be able to support/want each scrum team rolling its own scm solution. The more established the business, the more constraints and push back. Even established businesses can change. Don't be afraid to question a constraint if the team can justify the change.

Agile planning tools will follow these same rules. The business may have a full software life cycle management solution in place. This solution may or may not have an agile module. However the business may have reasons (regulated industries for example) to require that design inputs / outputs are documented in the life cycle management software solution they have. The business usually needs to balance keeping the teams happy / productive with staying in business.

I don't think there will be a black or white solution (unless you are one of the first devs at a start up). Agile teams will need to embrace the open communication. If the tools are impediments the business needs to know.

Consuetudinary

Answer 3

I'm going to make simple answer, because I actually think this is a simple question.

The WHOLE team is responsible of that.

Let me explain a little bit. We first have to accept that every context is different, so this is not a biblical answer.

Let's say you start your project. I always love starting my projects/products with nothing. NOTHING. Sometimes, just a task board, with todo, in process, done.

That's it. And I fill the todo column.

And that's all my point: I build my agile process incrementally and iteratively. Why should I have to create a Burndown Chart? Because literacy tells me so?

Hell no, because, maybe, eventually, at some point, I might need to have some visibility for my planning.

Same with everything. And never forget, Agile tools serve as a support for the process.

So, you're a PO, and you're tired of the simple todo list, and fell the need to do a Backlog? 2 Solutions: -- you're already in a highly mature team, you just have to tell everybody during stand up meeting that you're taking the lead on it. Eventually it'll need a retrospective to accept that. -- you're migrating from a V, W or whatever product management model. Then, wait the retrospective and ask everybody and explain your pain. Give solution (here the backlog), and ask for a shot.

So, you're a scrum master, and you find a "systemic bug" in your process, let's take the classic one: Too many bugs. Then take the lead to promote TDD, or systematic testing.

So, you're tech lead and feel... Well, you understood me.

My point is: never over tool your process at the beginning. Build the process slowly, add tools slowly, when you need them. And by doing so, don't worry, people will take reponsability to create the tool and add it to the process, to lobby it to the rest of the team.

Hope this helps.

Hellbender

Answer 4

What is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile/scrum team?

Well my experience from real life is that, certain "Agile Planning Tools" tools were handed to the Scrum Teams before they even started their Sprints, fortunately the Teams liked it, but we were free to inspect and adapt to using something else if it did not work out for us.

I think it should be in the Teams power to use, accept or reject a tool in a completely transparent way. They could very well take suggestions from the Scrum Master or an Agile Coach because (s)he may have more knowledge in the Agile Tools area. Secondly, the Team should be courageous enough to have a collective discussion and decide on using a tool based on the Agile Coach's suggestions, and see how it works for them, and adapt and adjust from using it if it does not work for them (productivity-wise)

The bigger question which you did not ask is, how do you manage the differing tool set chaos when the company scales into having multiple Scrum Teams who use their own Agile Planning tools?. Well, I think realistically, in a scaling agile software company, a little bit of uniformity in tool usage across Scrum Teams can be beneficial and productive but that may be directed by the self organised enterprise project Team instead of each Team having their own tools. Off course there can be exceptions, where certain teams are working on completely different features and they need a totally different tool set, but the benefit of using common Agile tools will help scaling projects view their Teams progress without much of change in gear.

The above can be done by having a Technical, Infrastructure and Process Tools Story which not many companies use or create. This EPIC story can be the starting point for discussion of what Agile tools and other tools can be used, to have a little uniformity within the project. While deriving the EPIC story the whole project team could be involved around project kick off, if it is too big then 1 - 2 members can represent each of the Teams. The story could be broken down exactly like business user stories, and modified accordingly and calibrated, estimated and prioritized through out the project from an infrastructure and tools stand point. Let me know if you want me to go in more detail about this.

Outsole

Answer 5

Ideally the scrum master, but they may inherit some legacy which needs some evolution.

If the organisation is new to Scrum, then an experienced Scrum Master should be able to advise the best tools for the maturity of the team.

Typically, if a team already has some tools, a scrum master can adapt what is already there, regardless of the organisational choice. Some of the best boards are on Excel Spreadsheets and work just as well as a purpose built system. Every technology creates 'constraint'. So, it is up to the scrum master to support the business in ensuring the tools are fit for purpose and delivering the value the team needs.

Civilized

Answer 6

Typical mistake I experienced as a coach was decision made by managers or even senior management according some study done by 'specialist' or even external consultant. Those people are many times not aware about what, how and who will yse the tool. In this case I see dissapointed people once they should use chosen tool.

You have to consider who is going to use the tool for most of the day. Team members are better target community. Tool must support ScrumMaster role due to daily work she needs to done. Include experienced product owners into selection of the tool as tools have different support for planning that is necessary to be usable.

Consider your organization (complexity of products, projects, number of locations)

Dissatisfaction

Answer 7

The responsibility (and authority) of choosing a planning tool should be with the team. Often the surrounding organization will have a stake in terms of licensing costs and consistency across teams. Depending on how autonomous your teams are it should be OK for them to chose their own tool, though.

Within the team, the product owner usually has the highest stake in the decision, since he will be the one who is going to use it the most for continuous refinement and prioritizing. The rest of the team often only interacts with the planning tool during refinement and planning sessions once or twice each sprint. So he is usually the one driving the decision-making, but should definitely involve the team.

If the chosen tool also includes a board that the team uses daily to track their work, they will want to have more of a say in the choice.

Unburden