NOTE: This post was drafted from a talk given by our Captain (Dave Haeffner) on ‘Risk Management in an Agile World’ at the DC Automated Software Testing (DCAST) Meetup on Feb. 19, 2013. The idea came from Michael Connolly (DCAST’s Organizer), this is merely Arrgyle’s interpretation of it.
What is Risk
“Risk is the potential that a chosen action or activity (including the choice of inaction) will lead to a loss (an undesirable outcome).” – Wikipedia
In the case of Agile Software Development, the risk of what?
- System Performance Issues
- Introducing Regressions and Egg On Face
- Releasing something no one wants/will use/is offended by
- Premature Releases
- Scheduling & Estimating Inaccuracies
Each covered briefly in turn…
System Performance Issues
The first thing that may come to mind for this is issues with load and scale. But we’ve seen performance issues occur due to bad code – infinite loop, anyone?
Introducing Regressions and Egg On Face
What once worked, now doesn’t. Or, you really botch things and get some free publicity on The Daily WTF blog.
Releasing Something No One Wants
Remember Digg.com circa 2010 when they released a new UI? Yeah, everyone hated it.
“The launch of Digg’s redesign will likely go down in the history of social media as a textbook example for how to alienate your users.” - ReadWrite
We’re not condoning waiting until your product is perfect. But you don’t want to release something half baked. Danny Boice of Speek has some thoughts on this with his aptly named talk You Only Launch Once (YOLO)
Scheduling & Estimating Inaccuraces
You’re asked to estimate something based on limited data loosely backed by reality, you set off on a path, and then the business requirements change. That’s probably why there is so much written on the topic.
Agile Accounting – An approach to Risk Management in an Agile World
View your Agile Engineering efforts like you would a financial investment, a portfolio if you will.
Think about the minimal investment you can make to maximize your return, with reasonable risk.
Your risk tolerance may vary, as will your amount to invest.
But let me ask you this – are you living “pay check to pay check” (release to release) hoping it all works out? Or are you able to spend your money how you want? Releasing when you want, with little issue, putting product in front of customers that they want?
Much like how the Lean Startup speaks to a new way of Accounting (e.g. Innovation Accounting), we too need to determine a more effective way to measure things. One devoid of Vanity Metrics.
Consider us your new financial planner. Here’s a look at a portfolio you may want to invest in for your future.
Your Investment Portfolio Awaits
NOTE: Everything in this list is measurable in some way. If you find that hard to grasp, we encourage you to check out the book How To Measure Anything.
It is broken out into 2 parts – Technology and Process.
After reviewing, you should:
1. Assess your current reality
2. Envision a happier future
3. Plan out steps to take starting tomorrow that will start you on the path to get there
NOTE: It is assumed that once you have identified the things worth doing, you should automate them. In that order.
Mike Cohn’s The Testing Pyramid is all the rage, and is a good mental model for test coverage. Note the top of the pyramid is small and reserved for UI. This is where you should start. But don’t think of it merely as UI tests (they could be service layer tests too). Think of it in terms of Acceptance Testing. Here are some questions that will help apply this to your context:
- How does your business make money?
- How do your users actually use your app?
- What are the prominent, relevant traits of your users (e.g. browser type, location, etc.)?
- What things have bitten you before?
Once you identify what those things are, write automated tests for them. There are numerous tools to use for this. We recommend going with an open source toolchain to accomplish this. Full disclosure: We have some opinions on how best to do this.
To be clear – we think testing at all levels is valuable. But from a business and risk perspective, we think getting Acceptance Testing right is the most important thing you can do.
Version Control System (VCS)
Odds are you already have one, but if you don’t – Git, Mercurial, Subversion. There are plenty to choose from. Pick one, implement it, and move on. You’ll thank yourself later.
Continuous Integration (CI)
I would hope you already have one. But if you’re super small, then may not need one. But it’s table stakes in order to provide a tight feedback loop and position you for long term success. Jenkins, Bamboo, TravisCI, Semaphore, and the list goes on.
How’s your code smellin’? There are a plethora of tools available to help assess and improve the quality of your code. Some quick things to look once at that can be enlightening – code duplication, unit test coverage, code complexity.
Here’s a short list:
- Ruby: CodeClimate
- Python: PyLint
- What Wikipedia thinks
But do keep in mind that, as Sandie Metz says in her book Practical Object Oriented Design in Ruby, poor code quality can be measured. But good quality scores do not necessarily mean that you will have code that is easy to maintain.
If you do nothing else – mimic your production environment across all others (e.g. test, staging, etc.). Replication? Generation? Other? Find a Test Data Management (TDM) strategy that works for you and go do it. Eliminating environment discrepancies is not a trivial task, but it is fundamental to finding issues early and releasing quality software well.
In his writings (e.g. Bridging The Communication Gap and Specification By Example), Gojko Adzic talks about teasing out a shared mental model of what you need to build in “Specification Workshops” and solidifying it in a tangible, written form, through the use of a “Ubiquitous Language”. This is then used as “Living Documentation” that describes the behavior of your system that all members of a team can relate to (e.g. Business Owner, QA, Developer, etc.).
Tool chains have emerged to help better facilitate this, not just enabling teams to capture complex requirements in a terse/concise version of English (a.k.a. “Feature files” or “Gherkin”), but also enabling teams to bring them life with automated tests.
That’s all well and good, but one thing to always keep in mind, is to start with “Why?”. This will influence everything you build and test. Simon Sinek has a great, and inspiring TED Talk on this. It’s worth a watch.
Assuming you are holding Specification Workshops and have started with “Why?”, you’ll be in a much better position to write excellent user stories.
Some things to consider – make sure they are right sized. Keep asking yourself, can this story be any smaller? We have seen shops have “epics” with “stories” that were still the size of epics.
A small story, written with context, with a measurable impact (e.g. business metrics), and a ubiquitious language, is likely well understood, easy to estimate, approachable, testable, and worth doing.
Don’t just come up with answers to these questions:
1. What went well?
2. What didn’t go well?
3. What do we want to try?
Foster a culture of improvement and action. If you answer the questions – great! But if you don’t do anything with the answers, then it’s really not worth doing.
Always be cross pollinating. Silos of information all too often exists in teams and organizations. If one person knows all of the tricky bits about your application, and it’s not documented, and he leaves the organization, then you are in for trouble.
Writing documentation, brown bags, pairing, rotational roles. These are a few things that can help alleviate your bus number issues.
These are practices worth doing that can greatly improve code quality, Developer skill/information sharing, and general maintainability of your application:
- Code Reviews
- Pair Programming
- Test Driven Development
Your business may necessitate more focus in some of these areas, or ones we didn’t mention (e.g. Performance/Load Testing, Security, etc). But, regardless, thinking about and investing in these things as an inclusive whole will help you more easily identify risk and have process that leads to overall quality and customer satisfaction.