People

Adapt, improvise, overcome

Content

Agile and Lean1 principles were created more than twenty years ago to formalise ways of addressing unhealthy software production methods of the time. Their success is a mixed bag, with a lot of focus on frameworks that aim to implement either or both sets of principles. As Brooks said in his seminal work The Mythical Man-Month, there is no silver bullet.

We will guide you through adopting Shift Left, Agile and Lean principles in an incremental, evolutionary way, specifically applied to your particular circumstances. The end result is a dramatic improvement in software velocity, robustness, and quality. This is not only an engineering problem. Being Agile touches everyone from product, sales, marketing, to C-suite. By acting in harmony with each other, your products can get delivered on time, within budget, and with quality at their core.

We will teach you to assess sensible metrics to judge the current state and evaluate future changes’ success or failure as you journey towards better. Valuable code is the automation of business processes, but knowing how to wrap that in such principles as 12-factor app will make your software more friendly to own and operate.

We steer the leadership team to setting useful OKRs, starting with strategic goals which can be broken down into objectives and key results to monitor progress. First and foremost, measure the things you want to change. This gives everyone a clear vision and direction of what the company aims to achieve. The key results give a metric to judge the success (or failure!) of implementation. Of course, KPIs can be used as well to track changes in course and refocus2. From there, the engineering and product team can effectively plan work, broken into milestones, with a clear vision of what the goal is. Whether they use Scrum, Kanban, Scrumban or any other methodology, epics (a large desired business value) can be created, then broken down into individual work items to scored, and planned.

Overall, many implementations will be dependent on your environment, culture, and existing processes. However, the following two are essential to have:

  • Daily stand-ups While they might be video calls, in person, or early or late in the day (due to time zones), having a daily catch-up on everyone’s progress and raising any potential issues is essential team communication. It should be short and informative.
  • Retrospectives / lesson learned Once every iteration (whatever that is), getting a list of the things that went well, the things that went badly, and potential improvements will be the way to optimise your processes in the next iteration. Of course, metrics should be gathered before and after the change to evaluate its effectiveness.

We have the experience to guide you through a transformation towards a team structure that accelerates progress, gives staff clear areas of responsibility, and ensures all aspects of the work are someone’s core task. Be that a well-recognised Agile pattern or something more bespoke, our understanding of the abstract factors that control software velocity can create the right approach for you.

Footnotes

  1. Kanban was created in the 1950s by Taiichi Ōno at Toyota and adapted to software at the turn of the century. The Agile manifesto was released in 2001.1 

  2. Goodhart's law is something we are very familiar with: “Any observed statistical regularity will tend to collapse once pressure is placed upon it for control purposes”. 

Previous: Foundations
 | 
Next: Development