Top Agile Tips
It’s not a secret that I’m a fan of agile methods in general with a bias towards lean/kanban. Recently a friend who wanted to start on the agile path asked me about my experiences about common pitfalls and proven ‘good’ paths - and while I said to him that agile is not a set of stone-engraved commandmends rather a way of thinking, there actually are some golden rules to follow…
Agile is a mindset, not a checklist of commandments
I often see people looking for clear, simple step-by-step guides. We seek the easy path, but actually agile means a change in our classical way of thinking about people, projects, team dynamics and responsibilities. An excerpt from the Agile Manifesto:
Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.
Practicing agile needs discipline
Sometimes agile teams are said to be ‘ad hoc’ or even seen undisciplined. This is mainly beacause they accept change, but this in fact requires much discipline. You can only control change if you are determined, have the right mindset and right toolset. Discipline means on one side testing, automation, test automation and continuous integration and on the other side doing the daily agile practices (clear vision, transparency, daily standups, etc.)
Always have the ‘big picture’ and the business value in mind
Getting lost in the details usually doesn’t lead to success. The whole team needs to know in every single moment what they are trying to achieve. You need people who are capable of systems thinking. The code and the architecture are only the tools to achieve the (business) goal. Always focus on the business value of what you’re doing.
Know the difference between ‘done’ and ‘done done’
A quote from James Shore’s book: The art of agile development:
A story is only complete when on-site customers can use it as they intended. In addition to coding and testing, completed stories are designed, refactored, and integrated. The build script builds, installs, and migrates data for the story. Bugs have been identified and fixed (or formally accepted), and customers have reviewed the story and agree it’s complete.
I think this says it all. In many teams, ‘done’ means it’s been coded, maybe someone looked at it and ‘we should be able to ship it’. You have to do your best to transform this into ‘done done’ as described above. Then you’ll be able to sleep with a smile.
Don’t stop planning and evaluating
Planning should be an essential part of your daily workflow. Look at the past and present, learn, evaluate, adapt and plan. Saying “we’re doing it right” is only acceptable after you’ve looked at things with discipline. Focus on maximizing the (business) value when you’re planning. Keep your roadmaps with milestones, but be ready to adapt them at any time.
Measure, measure and measure some more
Gut feeling is good and sometimes surprisingly accurate, but it’s not to be trusted blindly. Set up facilities to measure your status and progress in as much factors as possible. Measuring the business value is the bare minimum. Without measurement how do you know if you’re making good progress? Try to set up KPIs for each business indicator and also for your team! Be sure to share these informations with the whole team!
Forget about ‘religion’
There are no silver bullets. Be ready to try as much methodologies and tools as possible then choose the best fitting or create your own. Methods and tools are just - well - tools. Rememeber that a tool is never a business value but something that can help to grow it. Try kanban, try scrum, try scrumban, check out the Atalassian tools or anything else and choose the one that helps you the most without getting in your way.