Are you truly Agile ?
A lof of people and companies claim to be “agile”. This has become a tag to imply one’s devotion to quickly satisfying the customer need. But, is that really so ?
I have seen so many “agile”s that have no idea about what Agile Manifesto says. Knowing so, would have effectively stop them claiming to be agile. So, are you truly agile ? Or are you just cheating yourself (and others) by claiming to follow shiny magical buzz words ? Is “Agile” used as a guide towards a sustainable predictable managable production process or scape goat for all your problems ?
Let’s go through all 12 principles and honestly check where you are:
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Is your product installable/upgradable any given time, just by invoking a single click, or running a script ?
How long does it take for a new developer to setup environment and check in her first commit ?
Does your customer have access to their requested features immediately after you developed them ?
Which is more important for your business people ? Solving the customer’s problem or reaching sales quota ?
- Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Does it take weeks to make changes to customer requests ?
Do you reject or charge extra money for changes to requirements once your customers signs them ?
Is it agonizing to see that a requirement has changed ?
Are you often criticized by your customers for being “slow” even though you are working “agile” ?
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Do you hardly make a release per year ?
Is making a release as easy as pushing a button ?
Do you have highly stressful periods during the year when “special” dates come closer ?
Do you get truck load of bugs after you release ?
Business people and developers must work together daily throughout the project.
Do your business people just say “i want some nice food” and leave all else to you to discover yourself ?
Do you have clear agreements with business people on the requirements, acceptance criterias ?
Can your business people use interfaces of your product ?
Can your business people just look and understand the features you are developing and the way you verify them ?
Do you write your stories yourself, alone ?
Do you often have dispute between business people on stories developed ?
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
Do you have colleages who refrain from learning anything new ?
Is rejection a common reaction in your team ?
Do your colleages often mock “Agile” and blame agile for everyting that is not going right ?
Do you have hard time getting convenient development environment ? (tools, environment, hardware etc.)
Do you often have hard time to deal with the “procedures” and “standards” in order to improve your work ?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Do you only communicate over tickets ?
Do you sit together to solve a problem ?
Do you often have missing people in standups ?
Working software is the primary measure of progress.
Do you have your trunk and maintenance branches broken ?
Is it common to get bugs for the requirements/acceptance criteria that are supposed to be implemented ?
Do you have extensive unit/integration/ui test coverage ?
Do you fear of refactoring ?
Do you have a separate development and test teams ?
Is your test team often crucified for not being able to find bugs ?
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Do you have certain periods through the year that you are overwhelmed with bugs ?
Do you have certain periods trough the year that you do not have much to do and have to wait others ?
Continuous attention to technical excellence and good design enhances agility.
Do you work by the principle “do not touch if it is working” ?
Do you often make things just to make them work ?
Do you experiment ?
Do you refactor ? Do you challenge old decisions ?
Simplicity — the art of maximizing the amount of work not done — is essential.
Is KISS an english word, or a rock band for your colleagues ?
Do you have complex administrative hierarchy that forces you get past multiple levels even for small things ?
Does “gold plating” ring any bell in your team ?
Do you often discuss about features that are supposed to be nice to have, without any customer actually desiring ?
The best architectures, requirements, and designs emerge from self-organizing teams.
Do you have to follow company wide rules ? Like standard environments, standard work flows, standard vendors, libraries, tools etc ?
Do people outside your team affect how you perform your job ?
Does your company prevent you from doing something that will improve your process, just because of your position and responsibilities ?
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Do you often get together, discuss about what has been done good or bad ? Do you just whine about all the nasty stuff and keep living like that ? Or, do you note and take actions to fix them ?
Note that, none of the principles mention Scrum, Kanban, TDD, BDD, Lean etc .. Techniques may and will change in time. You have to stick with the core principles, keep questioning how you do your job and cherrypick agile methodologies that will help you reach your target.
So, are you really agile ?