3 C's of Agile

10 January 2014


When you think of Agile, there are a couple of questions -- myths, in fact -- that repeat frequently with just a verbiage change. It is important not only to know about the Agile framework but also to resolve open questions in order to embrace it fully. This article is based on questions I heard during my Agile trainings and mentoring. The 3 C’s of Agile provide clarity on the Agile framework. The better the understanding, the better the results are.

The Agile Manifesto is based on 12 principles. I tried organizing the myths under each principle to make them clearer. (Source: http://agilemanifesto.org/principles.html)
  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
    • Myth: Agile can deliver the entire project scope in a short span.
    • Myth: Agile means quick delivery.
    • Myth: Agile means no documentation, no planning.
  2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
    • Myth: Agile means frequent changes.
    • Myth: Agile means taking new requirements at any time and still delivering the project without impacting earlier timelines.
    • Myth: Agile means no design.
  3. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
    • Myth: Agile means no design.
    • Myth: Agile means no documentation.
    • Myth: Agile means quick delivery.
    • Myth: Agile projects can start at any time.
  4. Business people and developers must work together daily throughout the project.
    • Myth: Agile can be done without commitment from the business group.
    • Myth: Agile means business engagement at the beginning, and then you're all set as in Waterfall.
  5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
    • Myth: Any resource (person) can be added in the middle of the project.
    • Myth: It's OK if someone is not educated on Agile framework.
    • Myth: Resources can be exchanged in the middle of the project.
    • Myth: Resources can be allocated on multiple projects running at the same time and still complete the sprint.
  6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
    • Myth: It is OK if all project teams/peer groups are not educated on Agile project; as long as the core team is aware of Agile, projects can be kicked off.
  7. Working software is the primary measure of progress.
    • Myth: Working software means delivering the entire scope as discussed at the beginning of the project.
  8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
    • Myth: Agile means flexibility; the project pace can be increased to deliver early.
  9. Continuous attention to technical excellence and good design enhances agility.
    • Myth: Agile does not need any up-front design.
    • Myth: Development can be done on the go.
    • Myth: Agile means no documentation.
  10. Simplicity -- the art of maximizing the amount of work not done -- is essential.
    • Myth: Adding more resources in the middle of planned work helps complete the project early.
    • Myth: Large scope and short duration make it an Agile project.
    • Myth: Agile projects deliver in less time.
  11. The best architectures, requirements, and designs emerge from self-organizing teams.
    • Myth: Agile can start overnight; no prep or training is required.
    • Myth: It's very easy to run Agile projects.
    • Myth: Agile project teams learn on the job; no prep or training is required.
  12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
    • Myth: Agile is very flexible and teams can change the project course when and as needed.
There may be many more myths about Agile. Of all of these, I would consider that the three below are the basic ones that teams need to understand before trying Agile rollouts.

Customized Agile

Did you ever run across questions like, "Agile is too rigid a process and I have to follow it to the T. Can I use Agile and Waterfall together?" If so, you are in the right place. Simplicity is one of the principles of Agile. For software development companies, it is easy to adopt Agile from A to Z. The process is flexible and suits the product development groups well. They can have Agile projects for each of the feature deliveries until the product is ready. However, what about companies where software development is not the core area but they would still like to use Agile? It's easy to customize the projects based on the needs into Waterfall and/or Agile. For example, a typical software project has both the software development component and a hardware component. Typically, hardware requirements come with solid SLA dates. One can consider this to fall under Waterfall. In case of application delivery, where coding and testing are involved, try using Agile. I may have made this sound easy, but my intention is to point out that customization can still be done using the two superpowers (Waterfall and Agile). Customization may depend on the projects' complexity, and the organization's requirements, but it is still achievable.

One needs to be aware of the pros and cons of both methods and figure out where to use which framework to get the most out of each. Knowing how to combine both methods on the projects and running them is what I call "Customized Agile."

I'd always recommend trying a specific component or feature in a sprint or two before delving into full-fledged customization. At the beginning of the project, perform due diligence to understand what components can be customized. This initial strong analysis will not only save the time but also dollars, so make the decision upfront before the project kicks off.

Customization of Agile is good for service-oriented companies that maintain IT departments to run businesses smoothly.

Corrupted Agile

A couple of times I've heard people complaining that Agile did not work when they shifted from Waterfall to Agile. Wait a minute, let's take a step back to really understand. The situation usually translates as, "The project was following Waterfall methods and got delayed and now the team wants to try Agile -- taking a U-turn to expedite the delivery." This is what I call "Corrupted Agile." Knowing the scenario, trust me, it will surely go south -- and don’t blame it on Agile. The misconception is that Agile projects are fast and can deliver in less time, and that there is no prep work needed. Do not attempt to change the course of the project overnight from one method to another. If management decides to go with Agile, and if you would like to follow Agile delivery model, then scrap the current project. Start afresh with a new Agile project and follow the framework to track your progress and success. Do not interlink the methods in the middle of a project and then assign bad credit to Agile for the failures.

Confused Agile

Another myth about Agile is that it can start at any time. Yes and no. Yes, companies can start embracing Agile any time, in addition to long-standing Waterfall methods. No, it cannot be done in a snap. If your management says, "Let's go Agile starting tomorrow," it certainly is a good joke, but realistically one cannot start projects the very next day. Not knowing understanding the method or its prerequisites and starting off Agile projects in great excitement is what I call "Confused Agile." It is important that management and the team understand the Agile framework well and commit to it. If the teams involved are not in sync, then there is great confusion in expectations and deliverables. Self-organization, regular adaptation to changing needs, and responding quickly are the keys to successful projects. This doesn't happen overnight. Teams need to be empowered and made accountable for their deliverables, for which good homework and understanding of the process are required.

It is important that before starting any Agile project, teams should be educated well enough about the framework and a sample -- small -- project should be done to test the waters. Especially in companies where Waterfall is mostly in use, embracing Agile is a culture shift and a big change. Therefore, teams need to be engaged to clear confusion and gain clarity for better delivery results. Once the core teams -- business, development, testers, BAs, etc. -- are in sync, the stage is set for larger Agile projects.

Once you get over these 3 C's, you can have consensus to walk on the Agile path. If you still run across big myths that are not listed here, feel free to provide your feedback. It's all about learning and growing together in Agile community.

Article Rating

Current rating: 5 (1 ratings)

Comments

Arijit Sarbagna, CSP,CSM, 1/12/2014 1:07:32 AM
Good article Savitha! Confused state is one big challenge that we face day in day out & incidentally, this state is getting more complex by each passing day. :)
Murugan Govindan, CSM, 1/15/2014 1:03:17 PM
Good one Savvy.. Recommend Agile Transformation for Corrupted and Confused Agile.
Kamal Hasan Kotapati, CSM, 1/20/2014 10:50:33 PM
Nice article Savitha! Yes. I agree with you on myths as I heard most of myths mentioned by you
Bharadwaj Velamakanni, CSP,CSM, 3/23/2014 2:22:59 PM
Good one! However one thing should be kept in mind .. The focus should be on "agile" with a small a and not "Agile" with a capital A.
Bharadwaj Velamakanni, CSP,CSM, 3/23/2014 2:25:56 PM
I would add a 4th C as one of the anti-patterns - "Concrete Agile" with excessive focus on ceremonies and practices as opposed to the customer value :)
Sémi TAOFIFENUA, CSM,CSPO, 3/24/2014 12:36:50 AM
Nice Article

You must Login or Signup to comment.