In agile/scrum teams who is responsible for the choice of agile planning tools [closed]
This question does not appear to be about programming within the scope defined in the help center.
Closed 5 years ago.
Improve this questionWhat is your experience from real-life, who should be responsible for a choice of agile planning tools to be used by the agile开发者_JAVA技巧/scrum team?
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.
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.
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.
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.
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.
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)
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.
加载中,请稍侯......
精彩评论