My inferences about Agile from Sanjiv Augustine's workshop at Xebia India

Last weekend, I had the privilege of attending and interacting with Sanjiv Augustine in his workshop on “Transitioning to Agile project management”. Sanjiv is a well known thought leader in the field of Agile and Scrum. He is an author of the book called “Managing Agile Projects”. I felt he was very practical and Agile in the way he conducted the session. Although the workshop was designed to help project managers make a smooth transition from traditional methodologies (typically waterfall) to Agile project management, I felt there was a lot in it for everybody.

To do justice with the title of the session, he did address different roles, responsibilities, phases and associated processes of Agile software development using Scrum. He compared Scrum and Waterfall with a focus on planning, execution, monitoring and adapting phases of software development from project management point of view.

However I am trying to present the session from traditional vs Agile perspective. The blog has been divided in the following three sections.


A case for transition to Agile (Scrum and XP)

I think we are all aware of low success rate, high costs and superficial business value of waterfall projects. Hence there is a need for processes and methods that can eliminate waste, deliver quality and business value early enough to increase the return on investment. Agile(Scrum and XP) are trying to address these.

Benefits of the practicing Agile

First of all, software development process will become small, simple, fast and flexible for the customer and the team alike. It involves short meetings, delivering in small batches , simple process, simple design, fast delivery, early feedback, adapt and change cycles.

Another important thing here is the satisfaction level of the customer and the team is bound to increase due to open and transparent communication, collaboration and team work. The early feedback mechanism helps finding the problems early and hence it’s less expensive to fix the same. It in turn helps creating the environment of trust and reciprocity. Metrics showing how much needs to be done give the true indication of actual progress and helps in creating transparency and discipline. The fact that Agile is built on passion, transparency, trust, discipline, liberty, opportunity, reciprocity and equality helps in creating a great and highly productive working environment.

Finally the productivity for the customer as well as the team will improve a lot. Waste gets reduced by using lean development processes in which we maintain a constant flow throughout the work queue rather than blocking the work queue at different places. Allowing the team members to decide rather than imposing the decisions increases the throughput in general. We actually did two gaming activities in the workshop which gave empirical evidences to prove that lean development and team empowerment can increase the productivity and reduced waste.

Things that have changed

I felt in Agile, processes as activities are more important than just a mechanism of producing a document or non working artifact. The activity is more important than the document. For example planning as activity is more important than producing a planning document. Similarly design, coding and testing as activity become more important than the various traditional artifacts and documents produced by it.

Divide and conquer has given way to conquer and divide. Start with a small team, do the project initiation, make something workable and shippable and then divide and expand the team and keep building working feature with each new team instead of creating a number of teams and keep them waiting or working with non working artifacts or documents only.

Plan the work and work the plan is not the way to go anymore. Reality is not plan based. Plan, do, check and act is the key behind Agile. Inspect and adapt, respond to change are essential for success. Do planning in small parts and on small time intervals.

Trust and collaboration is very important. Keep the process visible, transparent to all the stakeholders including customer. Collaborate early with the customer to deliver business value early.

Small is beautiful. Keeping everything small increases the chances of success for sure. Do a feature driven development with small team and small sprints using iterative and incremental approach.

If you need it, you do it and do it just sufficient to purpose. Do what works for you. Create non working artifacts or documents sufficient to purpose depending on the needs of the project.

We all cannot be masters and it is sufficient to be ordinary. You do not have to be a genius who does not make mistakes. Instead Agile brings forward the mistakes early and encourages the team to be innovative without being afraid of mistakes.

In the end I would say that Agile has made software development much democratic, socialistic and very effective. In other words, a true value addition for customer and fulfillment of business goals set by all stakeholders.

Comments (4)

  1. Josh Nankivel - Reply

    November 22, 2008 at 1:36 pm

    Thanks for the post. I just wanted to add a little more to your comments about the planning that is still required with Agile. This is what I have used in the past and have found works well. The moral of the story is that you don't get away with less planning when you do Agile right, in my opinion. You are just spreading out your planning across the sprints, and so you have more information with each one...and your planning gets better and better. You STILL plan the work, and work the plan.

    1) Develop a high-level plan up front. This is much less rigorous than traditional waterfall planning, but gives you a high-level WBS structure, major deliverables/list of features, engineering approach, architecture, etc. You plan how many sprints the project should take and roughly how many features will get developed each sprint.
    2) Plan each sprint in detail regarding the features that will be developed, and stick to that plan for the duration of the sprint.
    3) After each sprint review, you have better information to adjust the high-level project plan, and make the next sprint plan more accurate.

    Josh Nankivel
    http://pmStudent.com

  2. Abhinav Kumar - Reply

    November 22, 2008 at 8:35 pm

    Thanks for reading the post and adding your invaluable comments. It is immaculate. I could not have agreed more. Perhaps I could have been more explicit by saying that plan the work ONCE and work that plan FOREVER is not the way to go anymore. And thanks for showing the way to go in no implicit terms.

  3. Anurag Shrivastava - Reply

    November 23, 2008 at 8:47 am

    "The fact that Agile is built on passion, transparency, trust, discipline, liberty, opportunity, reciprocity and equality helps in creating a great and highly productive working environment."

    Many people ask how they can build an Agile team in a company. Passion,....,equality are the first things to be looked at. Teams may falter at times. Managers should play a crucial role in keeping the Agile spirit alive.

  4. Serge Beaumont - Reply

    November 23, 2008 at 11:08 am

    @Josh: I rephrase the WBS part. A backlog is a list of outcomes, not work. So it is a Product Breakdown Structure, not a WBS. One of the traps of planning based on activity is the belief that executing all activities will automatically achieve the end results. Of course this is not the case, and everybody should have the outcome in mind at all times. This is what allows a team to identify the need for different work than was originally planned to reach the outcome.

Add a Comment