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?

Teams will always find whatever tools work best for them but the ASG can highlight what's available and the pros/cons of those tools that teams have standardized on Tfinc (talk) 21:14, 4 March 2014 (UTC)

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)

That's the exact reason why their specialists first and scrum masters second. A team should be free to work in whatever Agile discipline makes sense to them Tfinc (talk) 21:14, 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.

Between Arthur and me we've run three team trainings for Flow, Zero, and Mobile Apps. Their usually 2-3 full days and take another 1-3 days to prep depending on much new curriculum has to be generated. Outside of that we've been asked by other teams like Language Engineering and Fundraising to do similar trainings but have had to decline to having existing commitments from our actual jobs. All of the training has been from our spare time that we've scrounged to find because each group has told us they the need help. Outside of that I get adhoc questions from teams wanting to retool their practices on a regular basis with the common frustration being that their is no direct resource besides Arthur's and my time Tfinc (talk) 21:35, 4 March 2014 (UTC)

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.

Each team will always pick their own destiny. We want that. Not enforcing a prescriptive norm of all scrum all the time is very important to us. Tfinc (talk) 21:35, 4 March 2014 (UTC)

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.

If i look at the formation of the mobile web team it took almost 100% of a scrum masters time to get things started for at least six months. Then it dropped down to roughly 50%. I believe each scrum master to me should be able to handle 2 teams individually. Thus far we've had the following team approach us for dedicated support: Zero, Fundraising, Mobile Web, Mobile App, Growth and we've heard a need from Platform. Splitting at 50% for 3 Agile specialists would barely get us there but we want to be conservative in our estimate as each team is different. 21:35, 4 March 2014 (UTC)

As for tools. I've never even thought about that as an issue for the App team. Trello just works and never gets in our way. If your not using Trello then i do recommend it. Tfinc (talk) 21:35, 4 March 2014 (UTC)

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)

@Eloquence: I'd point out that we don't have a full-time SM in VE (with the work shared between me as PdM and Roan as one of the tech leads), and that we find sharing the responsibility makes for a much smoother team environment. We would actively dislike adding yet another body to an already large team if they weren't going to be responsible for delivery (in the cutesy terminology, a chicken). Jdforrester (WMF) (talk) 18:59, 4 March 2014 (UTC)

Thats great. Other teams aren't at this stage and want the help. We shouldn't short change them just because their not at the same level as VE. Would you be willing to document and share your practices with the team practices mailing list? I'd love to know what they are like Tfinc (talk) 21:46, 4 March 2014 (UTC)

Interns

Is it possible for this group to provide training to our GSoC/OPW interns during their rampup period? Sharihareswara (WMF) (talk) 12:46, 4 March 2014 (UTC)

The group will be available for teams who request help in refining their practices. These teams tend to be 2+ in size and generally around the 4-5 person mark. As far as I know GSoC/OPW is a 1:1 mapping with only 1 dev working on a task. Is that assessment right? Tfinc (talk) 21:11, 4 March 2014 (UTC)

It varies, but we usually have 2 mentors and one intern working together for each GSoC or OPW engagement -- so, three-person teams, with the mentors participating via design, code review, pairing, and so on. We're also starting to try Facebook Open Academy engagements which have teams of a few student developers. Quim Gil can speak a bit more to this. Sharihareswara (WMF) (talk) 22:56, 4 March 2014 (UTC)