Agile in Plain English (part 2)

Posted on: April 19, 2010

Agile principles and practices

In the first part of this agile series, I explained that there is no such thing as the agile method, but rather a set of principles or values. Specific methods do exist, and they support the agile philosophy. Two of the most popular methods include Scrum and XP. Having only worked in Scrum, I will describe how the practices in Scrum directly support and uphold the principles.

Co-Location: The entire project team sits together in one physical location, rather than being separated into departments.
Supporting Principle: Individuals and interactions over processes and tools
The agile philosophy centers on cohesive, trusting team. That kind of trust can only be build overtime through constant exposure to fellow team members, the demystifying of jobs and daily activities, and just hanging out together. There is also a great deal more cross-pollination of ideas, which leads to a blurring of roles and true teamwork.

Story Creation: Defining the requirements together
Supporting Principle: Working software over comprehensive documentation
The entire team will write stories, which are short requirements statements, versus tomes of requirements documents. They force the entire team to articulate the audience, purpose, and value of each feature.

Customer Demos: Present functioning software at the end of each sprint
Supporting Principle:Customer collaboration over contract negotiation
In Scrum, a “customer” is not a customer is not someone who is external to the product team who purchases or uses the product. A customer is a role filled by one or more members of the product team, whose duties include acting as the voice of the end-use for the development team, and helping to prioritize and plan. UX folks fit perfectly into the customer role!

Stand-Up Meetings: Daily meetings where each team member lets everyone know 1) what they did yesterday; 2) what they are going to do today; 3) anything standing in their way
Supporting Principle: Responding to change over following a plan
This allows the team to gauge progress as well as address any obstacles preventing the team from moving forward.

Retrospectives: A team meeting at the end of every iteration where each team member lets everyone know 1) what went well; 2) what didn’t go well; 3) areas for improvement
Supporting Principle: Responding to change over following a plan & Continuous improvement
Although not stated as an explicit principle, continuous improvement is one of the core values of agile. A team does not need to follow a process dogmatically, but rather learn from each experience, improvise, and improve.

The above represent just a hand-full of the practices that go into a Scrum process. For a much more complete explanation, I would sincerely suggest getting Mike Cohn’s Succeeding with Agile.

Also, check out my full presentation on Slideshare:

Tags: ,

1 Response to "Agile in Plain English (part 2)"

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Alla Zollers

I design products and services that just. make. sense.

When products make sense, customers are happy.

If customer are happy, they sign-up, stay on site, engage, share, and buy your product or service.

Happy customers allow companies to profit in both senses of the word.

I provide the following services:

• Heuristic Evaluations
• Discovery Research
• Strategy and Vision Development
• Information Architecture
• User Experience Design
• Usability Testing

You can find me on:

Twitter Updates

Error: Please make sure the Twitter account is public.


%d bloggers like this: