Are you really agile ? A free assessment here…

A free assessment for you to benchmark the maturity of your agile practices

The whole world is now claiming to be ‘agile’ !

Definitely its a good shift for the software community and the clients. Aspirations are rising, it is looked upon as prestigious to be agile. The difficulty now is how do you benchmark your own agility ? Are you agile enough ? Who is, and who is not ?

Traditionally there was the waterfall, and then many schools of thought evolved. XP focused on engineering practices and scrum focused on behavioral practices, FDD, Kanban, DSDM, all with specific and very good objectives and reasoning.

The latest school of thought is ‘we are going back to the basics’. There were the days when the developer was sitting next to the business guy and coding what he wanted and push it in production and getting instant feedback, and the business is instantly happy. With the factory model of software development in the last 15 years, we somehow lost touch with business. Everything had to be integrated, functionally tested, regressiuon tested, UATed, bug-fixed, tested again, certified, and waiting in the line for weeks or months for salvation – to see the light of production ! How agile is that for business ? not very much we all agree.

Now comes the ‘agile brigade’.  We break the requirements into backlogs, plan iterations, deliver working software, give demos, retrospect !

Wow, we have come a long way, havnt we, we are able to produce sooo fast !!! we are agile, and we are just GREAT heroes! We are here to save the business from the waterfall.

But hey, has the business really got what they wanted yet ? They are asking for that high priority feature X. And they want it today! Oh wait ! That feature X is going into our next ‘monthly realease’. How dare they ask a feature in production that is obviously planned beautifully to reach them in few weeks! They know we are agile, they have seen the working feature, isnt that enough ? We still need to finish the regression test, performance test, UATs, and any residual bug fixes etc before we can confidently release it to production.

oh oh !  yeah we thought we were agile. We just didnt know we were only ‘iterative’. But if what we did 20 years ago was agile, what was the need to invent all these processes, and how is it possible to be really agile and yet be very stable and confident about deliveries ?

This is a classic situation. Iterative is definitely much better than waterfall. But please dont delude yourself thinking that you know it all and you have done it all. The danger is that, you stop learning, you stop improving.. You can definitely take the next steps and evolve your team to be truly agile, if you know what you are ‘not doing’ and what are the next possibilities.

I am trying to map out here the classic patterns of practices that differentiate an ‘iterative’ team from a tryly ‘agile’ team. Please read through and identify in which section you relate to most. I would request your comments and thoughts here as I would love to make this an evolving list based on your constructive feedback.

Do you relate more to Team A or Team B ? If you are taking this assessment, please mark 1 point each against A or B as you relate to each sections under them. There is overall 24 questions, hence 24 points. Mark them against A or B, wherever your team’s current situation relates to.  Lets begin:

Team A

Team B

Engineering practices

Constant   check-ins
It is a habit,   I have to be confident that my code works We have to police people to do   that, or have not implemented it yet
Continuous   Integration
Way of life,   what kind of question is that :do you breathe air ? hmm.. Maybe, its not as   continuous , or we are thinking about it
It itches if I   cant fix that code smell; cant sleep Who has time for fixing   somebody’s bad code, its not assigned to me
Build   frequency
we don’t count,   must be every few minutes, the way we check-in we didn’t realise the build   server was broken for days, or we don’t have it yet
Development   branches
We don’t branch   out, all of us work on same branch; we use feature toggles to manage the   features that wont be deployed How can everyone work on the   same branch ??? How do you manage versions and releases ?
Deployment   pipeline
We know hudson,   jenkins etc and we love those… it excites us to have an automated pipeline   ready to be pushed to production what pipeline? Our business demands regression tests, UATs, approvals, certifications, bug trackers, planned releases.. We are not comfortable doing risky releases on the fly, are you nuts?


Powerful   workstations
We need it as   we have to be really fast to call ourselves agile and we run our automated   tests many times a day We may or may not have powerful   machines, but what difference does it make , we are just writing code most of   the time anyway
Open   workspace
we don’t like   barriers, why would you need privacy ? I am part of a pair and I want to move   around freely… I am more comfortable in my   cubicle space. And why would I need to move around so much, I have specific   tasks allocated, and I have to concentrate and finish it.
Server   usage
We create   environments, virtualise, configure, drop, rebuild as and when we need…   servers are our slaves and we are not afraid to touch them we are very careful with   servers, if we mess up some configurations, our life is difficult, moreover,   we have different configurations between environments

Project management practices

Visual   Management
we use visuals   a lot for ideating, design, story progress etc.. We don’t care so much for   beauty, it has meaningful information It’s a great achievement that we   have great looking boards decorated with post-its. It makes us feel like we   are really agile !
Scrum   master role
Anyone in the   team can be a scrum master, we rotate the role. Project manager conducts the   scrum, and oh boy ! But the managers are very proud of the scrums; it’s the   biggest indicator that we are agile !
Requirements   definition
We go by epics,   and stories with defined acceptance criteria We go by use cases, or sometimes   stories, but whats the difference
We size the   stories in story points and we are quite comfortable in that. We don’t bother   doing task breakdown or task level estimations we use effort estimation in   person days. We might have tried sizing, but its confusing, and doesn’t seem   to work always. We also estimate at task level
Project   manager role
More of a   facilitatior, coach, enabler Manager is a manager – if he   conducts the scrum, its more like a status update session
Work   allocation
Team members   pair up and pick a story stories or features are broken   down into tasks and allocated by the manager / scrum master
Pair   programming
We love working   in pairs; it makes us confident learners Prefer to work alone on assigned   tasks

Testing practices

Test   Driven development
We write unit   tests before we write the functional code, again it’s the only way we work We might have Xunits, but most   of the time they are not great; lot of time we write these tests post the   release
Automated   Acceptance tests
We use   behavioral driven development; tools that automate most of the acceptance   tests ; done either by developers or QA Acceptance tests are manually   executed by the so called QA
Automated   smoke tests
Exists and run   as part of our deployment pipeline Never heard of them or not   applicable for us
Automated   undeploys
We do undeploy   checks as part of our deployment pipeline. Rollbacks are scripts that go   along with the release package; and we hope and pray it never has to be used
Performance   tests
Are part of   development. NFRs are treated as stories and taken up much ahead in the   development chain We normally do this (if at all   we do) post integration and not much automation here.
Tester’s   role
Main role is to   automate behavioral and performace tests Test repeated UI based tests   manually by pushing in test data

Continuous improvement

Metrics are   defined and measured from the developer tools. Measure meaningful things like   cycle time, productivity, code quality, compliance, coverage… We still measure stuff like   schedule variance, defect density, defect removal efficiency… though we may   have burn-down charts implemented !
Are excitng and   we always have healthy debates withing the team. We decide to do things   differently as the situation demands Its just another agile chore, we   tend to have the same action items over and over again.

How many points have you won against A and how many against B ? Obviously some of your practices would fall under A, and some under B. But predominantly where ?

Do post your A and B scores here.

Any guesses as to which of these teams is ‘truly agile’ and which team is ‘just iterative’ ?


Never miss a story!

Sign up for our newsletter and get the best stories delivered to your inbox.

Co-founder of People10, a 'total agile' software development and consulting company


  1. Andrew CordovaReplyFebruary 20, 2012 at 12:54 pm 

    Please put me on your e-mail list Ithink both approaches can work.

  2. VicenteReplyFebruary 22, 2012 at 3:28 am 

    This is exactly a little something I need to find more information about, thank you for the article.

    • Nisha ShoukathReplyFebruary 22, 2012 at 4:12 am 

      Glad to know it helped you, Vincente !

  3. what is a serverReplyFebruary 26, 2012 at 6:30 am 

    I have been exploring for a little for any high quality articles or weblog posts in this kind of space . Exploring in Yahoo I ultimately stumbled upon this website. Studying this info So i’m glad to show that I’ve a very good uncanny feeling I found out exactly what I needed. I most undoubtedly will make sure to do not forget this site and give it a look regularly.

  4. Naveed MuzzafarReplyMarch 2, 2012 at 3:40 am 

    Interesting questions. Thanks for posting this.

    While going through the list, I could picture my team nodding at times for TeamA and at time for TeamB. Though my primary focus is to make my team ‘comfortable’ in anything and everything we do, there are times when I have to use that little push to get them cross that comfort line. It works, but not without some negative effetcs.

    I could classify Agile practices in my company as somewhere between these two teams.

    Score –
    TeamA = 12
    TeamB = 8
    Others = 4

    • Nisha ShoukathReplyMarch 2, 2012 at 5:07 am 

      Thats interesting, Naveed.
      I would be really interested to know a bit more about the ‘Others = 4’ and which practices they are…

      • Naveed MuzzafarReplyMarch 8, 2012 at 3:26 am 

        Points in Other account for me:

        Deployment Pipeline: We follow manual deployment for some reason. We have two separate teams (different locations) so it helps to have all code deployed and verified in one branch and then pushed to production and later to our client.

        Visual Management: Somehow I am not able to add ‘visuals’ to our Scrum.

        Scrum Master Role: More towards B but not totally. I as a PM/Scrum Master mostly behaving as one.

        Work Allocation: Team members review, analyze and understand requirements during planning meeting. They pick their own tasks and to be done individually.
        A few more things in QA process but let me leave it at that for now.

        I dont like ‘it works this way’ quotes. Scrum gives me freedom to do things in a different way. I have hit big roadblocks (more to do with communication/language/culture) and I try at times to walk around them or walk over them. I would never stop and say ‘hey, Scrum is not done this way’ and add to the confusion. I dont treat Scrum as a map to achieve my goal but rather as a guide to help me figure out the best of the available paths.

  5. Tarun SapraReplyMarch 2, 2012 at 3:50 am 

    Very well written article indeed, it elucidates all the important points that constitute a team following Scrum as a delivery model and XP for engineering practices. It also rightly points out that many companies under the pretext of following Agile are actually following Slow iterative development mode. I think managers in behemoth of companies are apprehensive about true agile, as they have become habitual of holding all the power in the their hands. Since true Agile is all about empowerment of the developer thus adopting Agile is caveat for most manager driven companies.

    • Nisha ShoukathReplyMarch 5, 2012 at 1:16 pm 

      Thanks Tarun. yes, right engineering practices is the key to a good product and a truly empowered agile team.

  6. Stephen NorburyReplyMarch 2, 2012 at 1:36 pm 

    Enjoyed the article, very witty and informational. I’m in Team B (with a bit of A) but at least I escaped from Team C.

  7. AlanaReplyMarch 5, 2012 at 3:44 am 

    Important information and facts! I have been previously trying to find something such as this for some time now. Thanks!

  8. Siva KandasamyReplyMarch 5, 2012 at 4:14 pm 

    We are using Agile!

    Mostly our tasks are falling on Team A. (Other than IT controlled production server: changing server config protocols supposed to follow FDA/ISO standards).

    Our score:
    Team A – 19
    Team B – 1 (Server configs)

    Nice article! Made me feel, we are not doing something crazy!


  9. Ruth VitekReplyMarch 6, 2012 at 5:51 am 

    Great article Nisha! Many think they are Agile but are they? And yes – a Scrum Master is a totally seperate role from a Project Manager!

  10. Pierre NeisReplyMarch 8, 2012 at 1:00 pm 

    Congratulations for this very interesting article.
    It’s very focused on best practices and engineering (i.e. XP) but is it really agile?

    Some suggestion for improvement (if you agree)
    . how engaged is my end user?
    – do we consider the management as a partner? and vice versa?
    – is the job delivering value to the team or to the end user?
    – is Agile not facing the evolution of OOD according to empowered stakeholders?
    – are we delivering a product or a service?
    – is Agile either hard nor soft skills?

    Agile virtue or value?

    • Naveed MuzzafarReplyMarch 9, 2012 at 1:38 am 

      Very good points, Pierre. Agile is not only relevant to the team but each and every stakeholder associated with it. End-user/client needs know as much about being Agile as a programmer does.

      I never look at Agile methodology to help me do things faster or make a better product, but only to ensure that my client gets a good service and will return for more. All other benefits come as perks. 🙂

      • Nisha ShoukathReplyMarch 9, 2012 at 3:27 am 

        Unfortunately, I have to disagree with both of you. If your house is not in order, you cannot invite guests in 🙂 the service and food will be of poor quality.

        Wheras, if you are confident of your product (the food), and your chefs (the team), and their recipe( the engineering and other practices) , you can invite people to experience the service, and they will be happy, engaged, and will come back for more.

        If the foundations are not right, the structure will fall apart. There is only so much sustainability in onboarding only behavioral practices.

        Behavioral practices are equally important provided the team is equipped for ‘real agility’. Otherwise it just becomes a decoration or a make-up that will wash-off.

        We have been involved in evangelising scrum for 7 years and led the transformation of hundreds of people. I have been a coach myself coaching teams on the floor teaching sizing, scrum, retrospective, whiteboarding, product breakdown etc. We also made and implemented an agile project management application. All the rituals were right. I wouldnt say it wasnt working. But it wasnt whole. Something was missing. We still did not have autonomous confident teams who could engage the customer. The products were still buggy. The releases were not foolproof. In the morning scrums, people were not confident to speak out or huddle. The gap was in ‘engineering practices’ and ‘agile infrastructure’. Without continous integration, how can someone say the feature is ‘done’ I wonder ? Without a smooth deployment pipeline, what agility the business can expect ? If a feature takes 3 months to go into production (while development effort is only 5 days), is it agile? What does the word agility really mean ?

        The factors you are mentioning here are important, but it is only an end result. The customer, management etc will engage and buy-in, provided they are confident on the people and practices who are making it.

        I am happy to see now freshers who are coming out of college are able to be really agile in matter of weeks because of the total agile environment. The energy on the floor is contagious!They can deliver very confidenty into production and satisfy any customer.

        I am a convert myself, few years ago, I thought coaching and preaching behavioral practices were enough. Coaching is a tad bit overrated these days, I wonder how many coaches have really done a software system end to end from architecture to deploy ?

        Having said that, all practices of agile should co-exist. You can check-out my other blog on ‘total agility’ that explains this co-existance.

  11. dog snuggieReplyMarch 9, 2012 at 3:23 am 


  12. GergoReplyMarch 17, 2012 at 2:42 pm 

    Nice way to put it.
    Just one thing I’m not sure about – feature toggles vs multiple branches are they really that black and white? What if you have to release a hotfix off the latest stable version, as opposed to the current main line?

  13. Abhay DoshiReplyMarch 17, 2012 at 9:54 pm 

    Very much Interesting and EYE Opening. If we go through points deeply we’ll drill down to the level we are and I believe there is always scope of improvement.

  14. Eugene DvorkinReplyMarch 18, 2012 at 2:55 pm 

    Very interesting comparison of 2 teams. Probably most of the team is somewhere between team A and Team B. The value of the article in identification the problem with so called “agile” team B and proposed solution right next to it from the team A. Also I like the definition of “Iterative”. Implementing continuous delivery is the only way to move from iterative into agile, or deploying when feature is ready like we did 20 years ago

  15. Paula Richter- DycaicoReplyApril 12, 2012 at 5:08 am 

    In an ideal world you have team A focusing on bug fixes and short to market high customer satisfaction features and Team B is concurrently developing complex new modular offerings. If both teams are communicating well, you get the best of both worlds.

  16. PrashanthReplyApril 13, 2012 at 9:49 am 

    This truly helps one to identify, if they are “Agile”. It also helps one move from being iterative to being agile. Thank you very much 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *

30  ⁄    =  6