My thinking about Agile

My thinking about Agile

 

---share range: Avid ODC team, ScrumAlliance community, my friends, my blog

---last updated at July 28, 2010, by Rafael Gu (Gu Xiaoqun)

 

 

It's the first time I got an official training of Agile/SCRUM by ScrumAlliance since I applied Agile methods under a Silicon Valley's software manager's help at 2007, and then I got my ScrumAlliance CSM Certificate a couple days ago.  I have to say, our coach, Peter, gave us a perfect training, and I profited a lot from it.

 

According to my experience and understanding, let me share my thinking about Agile for you.  If you have some better ideas and different thinking, please share with me.

 

About Agile & Waterfall

========================================

Agile and Waterfall are all good things.  I don't think Agile is always better than Waterfall.  Agile is some kinds of lightweight software development/team management methods, which responses changes quickly (Agile VS. Waterfall, something like J2EE Spring or EJB3 VS. EJB2).  Sometimes, Agile works better, especially in Internet/3G epoch, a lot of things change often; sometimes Waterfall works also fine; sometimes, Agile and Waterfall can work together well.

 

For example, from 2008.5 to 2009.2, I led a team (6 persons) to develop a website project (www.valuelinker.com).  At the beginning, the boss and I figured out the detailed website plan and design, it was very Waterfall.  And on development level, I split the design into several modules, one or more persons will be responsible one or more modules, it was also very Waterfall.  I split the development process into several sprints, every sprint lasts 2 weeks, first week we focused on development, second week we focused on testing and improve UX (User Experience), and it was very XP (Extreme Programming).  In fact, we had an explicit done defined (Like Definition Done) that means we need to complete some features in the sprint.  At the whole beginning Because most of team members were juniors, so I dispatched the modules and goals directly to team members, they worked under my instructions, it's very Waterfall;  After several sprints, these members became more senior, they could almost think and work independently, so they could decide how to complete the sprint, it's very Agile/SCRUM (XP).  This process worked well, and all of us like it.

 

Agile or Waterfall, which methods you choose depends on your team and project context.

 

Goal, Goal, Goal

========================================

The Goal of software development is to meet the delivery.

 

The Goal of these methods, like Agile, Waterfall, or more, is meeting the better software development process.

 

So, the ultimate goal of Agile is meeting the better delivery, instead of the strict or standard process.

 

So we should learn how to use Agile to make a better delivery, instead of how to make Agile process stricter or more beautiful. 

 

We drive Agile instead of let Agile drive us.

 

People, people, people, and then methods

========================================

 

I don't think Agile or Waterfall is some kinds of bible or law, they are just some methods collection (like Story, Sprint Review/Demo, Sprint Retrospective,  Pair Programming, Automation Testing, etc) or suggested processes (like Sprint, TDD, , etc) used by people, you can decide how to use them, different people, different ways.  I mean the key of these methods is people instead of methods.  Actually there are only suitable people or unsuitable people instead of good methods or bad methods.  Suitable people choose suitable methods.

 

One difference is people get enlarged in Agile process.  And Agile requires higher quality team members which have self-organization & self-driven abilities.  If most of team members have not these abilities, it's difficult to make Agile running, or it's just an Agile on the skin instead of real Agile.  How to make team members get these abilities, it's a challenge for Agile leaders (like SCRUM Master).

 

About Leader/SCRUM Master

========================================

Agile requires higher quality team members, especially leaders.  Why?  We need these leaders have high communication skills, so that he can get the team work together, and understand every members, and then know how to encourage them, improve them and push them.  We also need these leaders can support team members; let them focus on the development. 

 

The leading roles of SCRUM process is team members, instead of SCRUM Master, SCRUM Master should be behind the scenes.  Let team members to present the sprint review/demo is a good idea, why not?  They complete the tasks, they present the result to PO, they will fill themselves more passion and then improve the self-organization & self-driven abilities, and then we got the higher productivity.

 

Rome was not built in a day

========================================

In fact, for some developers, self-organization & self-driven abilities are not enough to make them run an SCRUM process.  But yes, we can run SCRUM process (not very pure SCRUM), and at the same time, we can push these members to improve their self-organization & self-driven abilities step by step.  It's one primary reason why a successful Agile process need at least 6~12 months evolution.

 

Some suggestions

========================================

1. Leaders (SCRUM Masters) need to learn more knowledge about how to manage and communicate, other than technical things.

2. SCRUM team is all team members' team, instead of a private team of SCRUM Master.  Every member has fair chances to show.

3. SCRUM Masters is the role to provide supports and service, let team members to charge.

4. SCRUM Master should not be a SCRUM limited master, SCRUM Team should be a SCRUM limited team.

5. Let SCRUM methods serve for software development.