• AboutExplore our genome
  • ServicesThe tech platter
  • ProcessInside the pit-stop
  • WorkEpics delivered
  • ThoughtsLeft brain musings
  • CareersBe in the beehive
  • ContactSay Hi! Talk to us

Are you really agile ? A free assessment here…

agile-assessment-People10

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
Refactoring
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?

Infrastructure

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
Estimation
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
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 !
Retrospectives
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’ ?

 

25 comments

  1. Andrew Cordova says:

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

  2. Vicente says:

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

  3. 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. 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

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

      • 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 Sapra says:

    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.

  6. Stephen Norbury says:

    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. Alana says:

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

  8. 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!

    Siva

  9. Ruth Vitek says:

    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 Neis says:

    Hi,
    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 Muzzafar says:

      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. :)

      • 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 you