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:

1. People are too junior to know development and how to cooperation with people during development
   
2. 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
   
3. People are in the middle level, they want to learn and try, but they are more focus on development model than customer centric
   
4. 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
   
5. 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
   
6. 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
   
7. The manager don't know who should talk to when an important issue found, because everybody changed the same codes
   
8. 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.

happy for 3 new features of GWT 1.6

Enhancements for server side application development:

1. WAR generation and RPC configuration easier

This is always a problem for all server side application developers. While doing the server side application, you must handle all this configuration by yourself (at least most of them). And the RPC codes are really hard to handle, I met many issues at the beginning.

2. Hosted mode enhancement

It provides a restart button which can restart the web container, instead of close the console and completely rerun everything again. But I'm wondering why they change the web server to Jetty, why we can use tomcat for this feature? Well, Jetty is good too, but I like Tomcat more than Jetty.

3. New event handling system.

I haven't checked all of them yet, but this one looks nice -- each event handler only handle one method, you don't need to create empty method for it anymore. The codes will be more clear now.

There are also many other new features, check this link below for details:

http://groups.google.com/group/Google-Web-Toolkit/browse_thread/thread/3e7e6cc3b35ad98a

Cheers.

10-promising-free-web-analytics-tools

Check link below for details:

http://sixrevisions.com/usabilityaccessibility/10-promising-free-web-analytics-tools/

I think Yahoo does the best work comparing with others.

The data analyze and web data mining will be the next generation of data base revolution. MOre and more business come from Web.

Websites like http://www.ohloh.net/ are doing analysis for more detail level of industry/application. Searching by business/type of user and bring more useful data for these users are more and more important for people. Data grows like rolling snow ball, something like Google but more specific and useful is needed.

It's time to do something.

Official Google Blog: Project 10^100

Official Google Blog: Project 10^100

I few hours ago, I posted an idea to Google's project 10^100.

It's a simple idea but I think it's hard to turn to reality:

1. build a web community
2. people can come to this community and write down what they like and what's their style.
3. Match via following ways
a. System match the people together via their style and their preferences.
b. People can write down their style and where they will show up in which day
4. System can give them some symbols to those people who might meet together(in the subway or shopping mall, etc)
5. People takes photos or leave messages for their meets.

Source of idea: more and more people feel alone in the modern cities, we found a way for them to meet similar people and make friends each other, or each just for funs.

Imaging:
100 cars will meet together in a weekend 3 PM at Wangfujing Street, and they wear the same color clothes or wear same brand hats.

Give people a chance to know you, give people a chance to talk to new face friends. And then keep in touch in a community.
I think this will solve many social or mentality problems of people.

Hope project 1-^100 can find more funny ideas from people.

Ajaxian » What if we didn’t lump all “accessibility” requirements together?

Ajaxian » What if we didn’t lump all “accessibility” requirements together?

This is the similar question with my last post.
What if we didn't have all "accessibility, usability and availability, etc" requirements?

Using prototypes to demostrate your design is okay, but it may need more involvement of user.

It's easy to demo or create a new page, but it's hard to define the BEST.

80/20 policy is used here. And we need user's agreement on the requirements defined.
This is the key.

InfoQ: How to Handle Unfinished Stories?

InfoQ: How to Handle Unfinished Stories?
In Chris Sims' post, he summarized the experiences of David Starr of dealing with unfinished Stories.

One way to track progress is to give 80% of the point value of the story to the team for the current sprint. At first blush, this approach seems to accurately reflect the state of things, and may help keep the team's recorded velocity from varying up and down, sprint to sprint. It also has a certain amount 'feel good' value for the team. However, this approach has significant risk. The story is not verifiably done and the amount of time and effort that will be needed to get to 'done' isn't really known.

A second possibility is to split the story into smaller stories and take credit for the ones that can be considered done. To the extent that some of the smaller stories are truly 'done', this can reduce the risk associated with the 'partial credit' approach. It also allows the product owner to make some decisions about the relative importance of the unfinished stories.

In our projects, we seldom met the same issue. Most of the time, we can finish the stories on time, but sometimes we will also find that we were getting trouble on a certain user story. Most of the time, the issue is, the user story is developed, but it's not the same as expected of user. It's a common issue that user doesn't really aware of what they need. But in a formal development team, we must count our efforts so that we can really know our TRUE velocity in a certain cycle. In this case, usually we will adopt the second approach of David. We will split the user story into smaller user stories, and keep higher priority for unfinished user story in the next iteration.

But here comes my question, if the user story is finished, but we found it's not perfect enough for user, what should we do?

To satisfy user is one of the most important thing we should be aware of in an agile project. But most of the time, user only say "I need something but I don't know what it exactly looks like, I need your help". You can not exactly define what's the final quality requirement of user. So, you will get the feedback like "Yes, it works, but I think there are something we can improve, but I don't know where they are...".

How you deal with this in your experiences?

我的9型人格

做了一个测试，感觉自己各方面都很平均啊

九型人格分析

第三型	成就者、事業型、成就型、實踐型 14%
第八型	領袖型、能力型、挑戰者、保護者、權威型 13%
第七型	快樂主義型、豐富型、活躍型、創造可能者、享樂型 12%
第二型	助人者、全愛型、助人型、成就他人者、博愛型 12%
第五型	智慧型、觀察者、思想型、理性分析者、思考型 11%
第六型	忠誠型、忠誠型、尋找安全者、謹慎型 11%
第一型	完美主義者、完美型、改革者、改進型、秩序大使 10%
第九型	和平型、和平者、和諧型、維持和諧者 10%
第四型	藝術型、浪漫者、自我型、憑感覺者 8%

我的九型人格分析？

1. 第一型
2. 第二型
3. 第三型
4. 第四型
5. 第五型
6. 第六型
7. 第七型
8. 第八型
9. 第九型

你精力充沛，總是動力過人，因為你有很強的爭勝慾望。你喜歡接受挑戰，會把你自己的價值與成就連成一線。成就型的你會全心全意去追求一個目標，因為你相信「天下沒有不可能的事」。動力十足的你，適合做領袖帶領其他人。

主要特徵：

• 看重自己的表現和成就。
• 講究效率。
• 喜歡競爭，避免失敗。
• 相信愛情來自你能提供甚麼，而不在於你是誰。
• 只關注事物積極的方面，不理會消極負面的信息。
• 重視效率、比賽、贏。
• 難以瞭解個人的感覺。在工作的時候把感情放到了一邊。
• 為爭取認可而打造有利形象。公眾形象屬於社會高層人物。
• 在真正自我和工作角色之間會產生困惑。
• 通過集合思維的方式集中注意力，通過多渠道來尋找問題的答案。
• 能夠下意識地調整自我形象，以為調整地形象就是個人的真我。

代表人物：克林頓、貓王

資料來源：
http://www.potential.hk/jiuxingrenge.pdf
http://www.moways.com.sg/glcb_image/dsh/qxrg.pdf