Closed kdflint closed 10 years ago
Usually in Agile, when a new member starts in a team. The team velocity dips a bit, due to the learning curve. So technically the new member learns on the team he/she will be on.
My thoughts on the focus for this team:
The project focus for this team for the rest of the year will be to support the Nexus pilot rollout, with user stories that will open up involvement in things like digesting feature feedback, product design, data importing, development and/or testing work (incl. automated testing), UI design, etc. All of this depends on the skills on the team from sprint to sprint (see below)
My vision for the skills focus for this team is a little different than other teams in that I would like this team to serve as the entry point and training ground for new NorthBridge volunteers. (Other teams will be focused on more specific skill sets). So, the vision is that this team serves as the model of NorthBridge agile practice while sprinting on less technical, more generic sorts of tasks. I guess the real skills focus for this team would be agile practice itself. Almost like a boot camp experience...
Then, once a volunteer puts in at least two sprints on this team, they would (usually) move out to another team more in line with their skills and professional goals.
My question to the team is this: While it sounds kind of good on a high level, is it possible to have a team whose main skill focus is training? What are the pitfalls?
The advantages are (in my mind) that
1) we offer a consistent training experience for volunteers 2) a couple sprints on this team will weed out folks who don't really want to stick in for a longer haul. (I'd rather have that kind of thrash here, and be prepared for it, then across all the teams.)
One pitfall I can think of is that the technical skills on this team are in constant flux from sprint to sprint. How do you groom a backlog with a transient skill set??
What else? Other thoughts?
I think we need to clarify the purpose of the sprints performed by the team. My concern is If the purpose is mostly to train new people, is there potential for the sprints to be demotivating? This could occur either through misalignment of skills or because the sprints could be viewed as not impactful.
On that same vein, for volunteers who are programming oriented, would be it possible to give out low level / minimal time requirement assignments (done in the agile methodology) as a initial weed out for these type of volunteers?
OK, killing the idea of making this team (or any team) be a training team. We will address any training/vetting/orientation needs another way.
So, that just leaves us with needing to pick a skills focus for this team.
But, we're in a little bit of a funny place because this is a decentralized group at the moment in terms of skills (that's my perception anyway.)
Let me throw out this idea. NorthBridge's most urgent high level skill set right now is User Experience. We need traditional user interface design and graphic work. But we also need User Experience work in a very broad sense - generation of Help materials, for instance, and manual data validation of imported organizations.
Why don't we focus this team on User Experience, defined very broadly at least for the time being. For the next couple sprints I'll throw several stories on the backlog that range from very general testing or tech. writing sorts of things to specific hands-on javascript/css/interaction design and implementation tasks.
In the meantime, other teams will emerge and we will start to stand up other teams that are more skill-centric right from the start. People on this team may wish to migrate to something more specific. Or may wish to Coach or Mentor a team of "their own". Or, this team might find cohesion around some aspect of User Experience and stick together. Who knows.
Thoughts?
Sounds good. End of Sprint 2, we'll be able to demo a working product.
Mostly looking for comments about the viability of a "training" team.
See below for my original writeup.