Talk:Team Practices Group/Proposal for formation

I think this is a great proposal! There are two small suggestions that I would like to make:

1) What do you think should the role of the ACO be regarding thought leadership around tools?

2) Maybe it's worth mentioning and explaining some other agile methodologies like Kanban which is more suited for DevOps work.

Looking very much forward to see this come to realization! Drdee (talk) 00:09, 1 March 2014 (UTC)


 * I too would love to see the framing broadened a bit in terms of methodologies - Scrum and the assumption that there is a ScrumMaster makes sense for certain teams, and it makes sense to highlight it as a core competency, but there are other tools and methods that are important in our context. Kanban is an example, practices like TDD or pair programming are worth exploring, and optimizing how a WMF team interacts with the larger community is a need specific to our context.--Eloquence (talk) 09:02, 4 March 2014 (UTC)

Need
Do we really need a dedicated team for this?

The way I see it, different teams have needed different amounts of advice-giving - from my perspective I've taken up maybe 30 minutes of User:awjrichards's time, if that. And now that we've had advice from him on the subject, we're good. We're self-sufficient with respect to agile and scrum and others. And I imagine most teams will have that experience - the problem has been that loads of teams are just starting up now. Once they're settled, and there are teams busy working on things, probably the need for training will dwindle. I imagine it already is.

Even if there are more teams formed, maybe they won't want to be trained. Maybe they'll pick things up on their own. Maybe they'll come up with their own system.

And even if none of that happens, I cannot see this taking three people. That seems just...totally unnecessary. I see you have them acting as scrummasters as well, but people within the team will almost certainly do a better job of knowing what's happening around them, and even if not, the amount of work surrounding scrummastering should either not be that great or should be reduced by fixing the crappy software we use instead of throwing resources at the problem.

That's all. --MarkTraceur (talk) 00:25, 4 March 2014 (UTC)


 * Hey Mark,


 * FWIW, here's my take. First, being ScrumMaster on a large team (like Mobile or VE) truly is a full-time job, and not just because of tooling. (We always hate our tools, and I know you will hate them 1000% more if they're proprietary. I can relate although in my case it's more like 50%. ;-) Here are some of the ways that high performing teams continuously improve:

 
 * always refining practices to optimize for our environment. Are remote team members being included effectively? Are we transparent to the community? Are we good at reviewing outside contributions? Etc.
 * truly understanding the team's velocity. Whether you utilize storypoints, burndown charts, etc. or not, helping build the team's understanding of how much work it can take on is critical for recognizing and diagnosing obstacles and internal issues and avoiding overcommitment
 * ensuring new team members are effectively on-boarded. Both new and existing teams have to deal with this - there's always some amount of turnover, and a fairly normal 10% turnover rate in a 100 person organizations translates to 10 people leaving over the course of a year.
 * improving cross-functional work. Do designers produce too much or too little work? Are artifacts shared in a manner that makes sense? Are decisions adequately data-supported? Are senior engineers outside the team consulted when needed?


 * When you're doing well, it's very easy to get stuck just doing the same thing from week to week and being content with it. But I have yet to see a team that can't improve, and the highest performing teams - in my experience - tend to be the ones that are the most dedicated to continuously improving how they work, constantly on the lookout for small tweaks that help them do better. A great ScrumMaster can help with this, as can someone who attends the team's planning meetings, retrospectives, and provides 1:1 coaching -- even by just simply sharing lessons from other teams and across the organization.


 * In the context of a 100+ engineering/product organization, 3 FTEs just dedicated to those responsibilities is really not a lot, and the hunger expressed in the listserv discussion for e.g. more dedicated ScrumMaster support IMO attests to that. With all that said - it pleases me greatly that you're happy with how e.g. the MM team is functioning (tooling aside), I too think you guys are doing really well and am glad the process, by and large, is working for you. :-) --Eloquence (talk) 08:11, 4 March 2014 (UTC)