Agile Estimation - The East Agile Way

0

Posted by Anonymous on 04 Nov 2010 at 06:19

Agile Estimation Of Iterations

If you haven’t done so already, take a moment to read the blog on Reliable Estimates Using Agile.

In this blog, I will talk about the actual process of estimating an iteration and specifically how we do it at East Agile. I had the chance to take a class with Mike Cohn (right) and he is really good at explaining the estimation process. His book on estimation can be found on Amazon.

Estimating against a project that hasn’t been accepted (bidding, ROI analysis, etc.) is left for another blog.

Agile Estimation

Before You Start

Once again, lets make sure that you have everything you need to start estimation. So:

  • You are a member of the team.

  • You know your availability and all your team members availability.

  • You’ve studied and understand the...

East Agile and Agile Tools

0

Posted by Anonymous on 21 Jul 2010 at 13:01

One of the great aspects of Agile is that it can be continually reviewed and improved through retrospection. At East Agile, we apply Scrum, an Agile management process, but with a few changes. Agile itself is a collection of tools that are available to Agile users (Pair Programming, Standup meetings, Retrospective Meetings, Test Driven Development, etc.). XP (http://www.agilealliance.org/), Scrum (http://www.scrumalliance.org/ ) and Crystal (http://alistair.cockburn.us/Crystal+methodologies ) are examples of branded systems that draw from the set of Agile tools available. As such, there is nothing wrong, and it is quite Agile, to draw the best from these branded Agile systems (just as the founders of Agile did when they choose which tools were most Agile when engineering).

Scrum, as it...

East Agile Extreme Programming

0

Posted by Lawrence Sinclair on 02 Dec 2008 at 02:59

At Barcamp Saigon last weekend, we presented our eXtreme Programming (XP) approach at the Barcamp technology conference in Ho Chi Minh City, Vietnam.

We follow a pure approach to XP:

(1) Code review, collaboration, and teamwork are good. So we do them continuously by pair programming. Our developers work in pairs, with two mice, keyboards and monitors connected to the same machine, allowing a constant exchange of ideas throughout each day.

(2) Testing by developers is good. So we do testing continuously through test driven development (TDD).  Before we write any code, we first write tests that define what it should do. As we expand and refactor our code, we expand and refactor its associated tests.

(3) Responsiveness to clients, starting sooner and going live quickly are good....