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’ ?
Author
A seasoned tech leader with 20+ years of experience, Nisha drives global business development and client relations at People10.