What An Ideal Agile Team Looks Like?
After a few years experiences of Agile development, I rethink profoundly what I got from my experiences and what will an ideal agile development team look like?
My experiences
Begin to learn and use FDD in six years ago- people around me are not really understand it but they want something like that, something non-RUP but more restrict than XP.
- sometimes we will fail into the discussions like what's a feature will look like, how long an iteration should take, etc.
- we finally failed to follow FDD after several break and undefined iteration duration and lacking of domain expert
Using iteration development in mobile game development- project are small and you will need to work with game designer, UI designer and end user, and they are all young
- users require a frequently release and UI changes for their requirements
- no requirement from your boss
Using a mixed XP/Scrum development model in an enterprise environment
- most of my people are really experienced, but most of them already had experiences of RUP or other model
- some of them are really senior but some of them are just graduate from school
- after two years of development, people already knew Agile well, but they think Agile is just a process
- we have a user lead who represents for our customer, but finally found they have different understanding on the requirements
Issues of an Agile team
So, let's look at a little bit detail inside my experiences on what kind of issues I found:
- People are too junior to know development and how to cooperation with people during development
- People are two senior that they already fixed in RUP liked development model, and some of them don't want to change, or even don't want to learn
- People are in the middle level, they want to learn and try, but they are more focus on development model than customer centric
- People are easily to fight with each other for the concepts or processes of Agile, because nobody can tell the FINAL answer and manager/Scrum Master has to make decision, and this hurt people in the discussion
- When technical issues like architecture or whether we need a new tool/technology happened, everyone want to make the decision, but we can just use one, so we have to discuss a lot, but actually sometimes they mean the same thing to user
- People have different understanding on each best practice of XP or Scrum or Lean, so they will follow their own style and sometimes this cause communication problem, even if we have a pretty good nightly build system and it will do integration test for all the codes. The changes just faster than the understanding of codes
- The manager don't know who should talk to when an important issue found, because everybody changed the same codes
- The Agile model is okay, but people don't feel excited, it just a normal model, so they just follow it, lacking of energy to empower it
My Ideal Agile Team Model
As you can see, we have so much troubles while using all different kind of Agile model/practices. And I think the key is people in the team.
Well, I don't worry about the size of the team, don't worry about whether they are distributed, and don't worry about their ages, and don't worry about whether they have a good experiences, and don't worry about whether they are good at refactoring.
What kind of people we need in an Agile team?
I think at first we need a group of people who are really easy to accept others.
When talking about acceptance, I mean the acceptances of
- different style of people
- different skill set
- different speed of doing things
- different document style or code style
- different/similar ideas, just accept them, don't try to argue and be a hero
- change, we are an agile team, right. So, don't complaint about borabora... to the manager again and again
This will solve the issue:1,2,3
I need the people to really understand what's role they should play
- they play the first level cooperation cordinator
- they are developer, but they should put customer in the top priority while doing their work, not their own work, it's the work from customer, the value of work directly come from customer
- they are manager to they own work, each/each pair of developer is the owner of a user story/feature, they need to learn how to write document, talk to customer, do overall estimation, paint UI, do test and fix bug. Their deliverables are not only codes, but also other important artifacts. So, our developers really need to manage their small project -- user story.
- most of people are developers, not architect. So, contribute your ideas/suggestions/comments to the people who is title as architect, instead of provide a new solution
After these two points, I think I got the perfect Agile team, but we know that's not an easy way to success! I'm just trying.
Cheers with all people who met the same issues.
