The Way Of The Agile Samurai

Selecting a development methodology is not as simple a task as stating “Agile it is!”, no matter how hard consultants try to preach the opposite.

For years, software development was considered a “no go” zone for the likes of business managers, owners, even general public. This hesitation was mainly caused by the communication gaps while defining, tracking and communicating both requirements and results. In very rough, general terms, development is a very organized process, while business requirements tend to be quite dynamic, depending on the industry.

All of a sudden, there it was – the solution to all pains, the agile project methodology. And we all rode the hype train, and in many cases agile worked its magic. Business owners stopped caring too much about structuring their needs and developers stopped caring too much about wasting their time on project management

Lately, however, many of the caveats of agile become more and more prominent: major project delays, huge communication & execution overhead. Another key problem is the decision betweenScrum, Extreme Programming (XP), Lean and Kanban. Differences, however small, are still critical in delivering a successful project on time.

We, at Code Runners, have opted for Scrum, but also use the techniques from Lean and Kanban.

Let me tell you all about it.

Depending on the project setup, our team chooses a deployment cycle, which then becomes the “sprint”: the minimal reporting unit. Usually sprints are either one, two or four weeks long, but that largely depends on the business requirements.

Stand-ups are a good way to keep developers and PMs on the same page for larger projects, but are a horrendous waste of time for smaller ones. This is why we do stand-ups only if the customer wants to actively take part.

Kanban and Scrum boards are both very effective and a key part of our process. We reach this decision based mainly on the length of the sprint – and in case we go for Kanban, we prepare a different board for each sprint. These help us get the project status quickly and in a visually comprehensive way.

Concerning the lean approach that we take, it manifests in our ongoing strive towards discussing the MVP with the customer. Once we figure out and build the initial minimum viable that would meet the most critical business requirements, we can start adding features and improvements to the already deployed product. Thus we fulfil the most fundamental agile stepping stone: a whirlwind of small, light, quick updates.