Jul 27, 2018

Predictability and Reliability

Predictability and Reliability

As you take the increasingly well traveled Agile road, it’s worth asking yourself the question – why are you Agile? Everyone will probably have a different answer. If you don’t have an obvious answer then I can tell you ours. We want to be Predictable and Reliable. Simple as that. No more, no less.

We Want Our Teams to be Predictable

In classic waterfall, teams make an effort to estimate the work, the deadline is set and we all run headlong into a death march to hopefully make the date. There is no predictability. There are too many things that can go wrong. Missed requirements, bad estimates, scope creep, changes in priority, changes in staff are just a few of the things that can wrong in a the lifecycle of a waterfall project.

Agile teams are much more predictable, especially after a couple of sprints. Typically the number of features or story points that the team can accomplish goes up and down in the earlier sprints. But after a few sprints the number of story points starts to be the around the same for each sprint. In the earlier sprints the team fixes the most obvious problems or blockers that are making them inefficient. If they get the right support the number of points stops varying wildly and reaches a plateau. This gives you a predictable number of story points each sprint at a team level. If you’re not getting to a plateau then something else is going on. Talk to us, we can help.

We Want Our Teams to be Reliable

The Agile Testing Pyramid is a great place to start when you’re looking to make your software more reliable. The majority of our tests will be unit tests that are written at the method level. If most of your code has complimentary tests then we’re said to have good code coverage. Adding new features then becomes much easier and you don’t tend to get weird side effect bugs anymore – assuming all your tests still pass.

We do a lot of mobile apps which tend to have backend APIs. Now some of the APIs are written by our teams and some are not. To stop any finger pointing we use Postman to create a suite of API tests. If the API tests fail then the backend developers fix their code. If the API tests all pass we know it’s the mobile developer who needs to investigate the defect.

Websites and mobile apps have user interfaces that also need to be tested. So we write GUI tests in tools like Selenium or Cucumber. We write less GUI tests than unit tests or API tests but they’re still essential for making our code reliable. The Agile Pyramid – especially when it’s automatically run in a Continuous Integration server – provides you with an insurance policy of regression tests. This extra effort will increase the reliability and extend the lifetime of your code. Any new features added will not destroy any other functionality if all your tests pass during the build.