Bradley D. Brown

Yesterday’s blog entry was a great segway for Agile.  Let’s talk about the agile-based development methodology.  Keep in mind, Agile can be part of the entire cycle – not really just development.  In other words, it’s part of the design process, testing, everything.

Agile Provides QUICK Results

The advantage of Agile is that it provides quick results.  A release is a group of iterations.  An iteration is a short period in which you’ll complete an entire cycle of design to development.  Many things occur concurrently rather than in serial.  This is part of the power of Agile.  Additionally, the cycles are short.  Internally we initially did 1 week iterations.  We later moved from 1 week to 2 week iterations.  So every 2 weeks we’re determining which features we’re going to get into our product and at the end of the 2 weeks, we have an official release of the product.  We do bi-daily builds of the entire product.  If you break the build, you buy the donuts or bagels for the team!  One build is for the US developers and the other is for our team in India.  But…since we tend to be developing nearly 24×7, the builds are really for everyone – anything that’s checked in, gets built.  The build is automatically checked to make sure the primary functionality is working.  Good  builds are automatically deployed to all test servers.  Each day the test team gets to work on the latest and greatest build!  If you have a new feature that MUST make it into the product, how long will it be before you actually get to see it?  For us, it’s 4 weeks at the most…2 weeks at the least.  I guess technically it could be within 12 hour…i.e. in the next build.  With our Agile methodology, you can produce results quickly!  Agile is not for the weak or meek.  It will accentuate your flaws.

In the construction industry, we say we “stacked the deck” with contractors – i.e. when you bring in the drywall, paint, carpet and other trades in all on top of each other.  That is pretty much what Agile does too.  The product management team is determining the priorities (i.e. for specific stories) for the next iteration, while the design team is estimating stories in Small, Medium and Large (shirt size) chunks.  The teams then meet to determine which stories will be included in the iteration…and the process goes on from there.

If a develop runs out of things to do – there is a constant backlog of stories – i.e. what we should work on next, etc.  This is powerful!  You don’t see results like this in a waterfall project.

Again, quick iterations are key – there’s still design – unlike RAD or XP.  You’re stacking the deck like in contracting.

Agile is:

·                     Short iterations allow your customer to see what they are asking for quickly

·                     It does not imply a lack of design, rather it’s more like stacking the deck

·                     Agile provides a constant backlog of “ready to develop” tasks

The Agile Scrum

“Two Pillars” of Scrum

There are 2 pillars of the scrum - team empowerment and adaptability.  I’ve worked on projects where the project manager said “you have 16 hours to complete the task.”  And I’ve thought – huh?  That’s not possible…or there’s more than you think is here…or the more I dig, the more I find.  You can read the bullets here.  The beauty of this process is that you can adapt to changes when they occur.

Empowerment, changing with the business…that’s what Agile does…it does not fix the issues – it highlights them in a HUGE way!

Team empowerment

·                     Once teams are given work to do, they are responsible for figuring out how to do it.

·                     The team does the best it can during each increment.

·                     While a team works, their only interaction with management is to tell management what is getting in their way and needs to be removed to improve their productivity.

Adaptability

·                     Scrum uses “punctuated equilibrium”.

·                     The team maintains an equilibrium during each increment, insulated from outside disturbance.

·                     Increments are punctuated at the end of every sprint so that the team and management can evaluate what should be done during the next increment; this decision is based on what the team has accomplished and what the environment dictates is the next most important thing to do.

 Once Scrum is underway, teams and management find it easy to focus.  Every request is easily evaluated by, “What’s that got to do with delivering the code?”

Sprinting

I’ve provided a sample sprint planning meeting agenda below.  On the left, you can see how detailed the “chunks” of work are based on the stage it’s in.  For example, you will likely know chunks of items that you want to accomplish in the next release – for example, rework UI.  You might have huge undertaking that are past the next release – such as develop end user workbench.  From there, you can see that the closer the stories are to the current sprint, the smaller the items are.  For the current sprint, every task needs to be outlined – i.e. it must be VERY detailed!

This graphic shows how things go from concepts down to tasks.  But the design is constant.  We spend an entire day or 2 at the beginning of every iteration / sprint.

 Sample Sprint Agenda

·                     Opening, Welcome, Intros, Agenda

·                     Product Vision & Roadmap

·                     Development Status, Architecture, Previous Sprint

·                     Velocity In Previous Sprints

·                     Team – Availability and Capacity

·                     “Done” Review Definition

·                     Product Backlog:  Review and Select

·                     Tasking Out – Estimates – Ownership

·                     Challenges – Dependencies – Risks

·                     Review:  Capacity Required

·                     Review:  Risks & Mitigations

·                     COMMIT!

·                     Parking Lot, Action Items

·                     Close

Bradley D. Brown agile, soa agile, soa