FAQs

Answer:  Agile transformations often fail because they focus solely on adopting surface-level "ceremonial" work practices and partial engineering strategies. They tend to overlook or fail to address the fundamental underlying issues that hinder genuine and continuous agility.

These issues encompass:

1. Couplings in architecture, design, code, and data, which also influence team structures.

2. Challenges in consistently maintaining engineering discipline.

3. Scarcity of appropriately skilled engineers (in software teams often only one-third of engineers are at senior and principal levels).  Advanced engineering techniques require lots of training and significant experience to practise and hone them.

4. Insufficient early feedback, particularly from actual end-users of the product or services.

5. Difficulties in accurately estimating delivery deadlines.

6. Issues related to long-term planning.

These factors collectively contribute to a rising "cost of change" for your product and its software. This escalation can materialise as:

a) Quality issues in your live systems.

b) Inability to meet deadlines.

c) Necessity for team expansion.

We have carried out numerous successful transformations and deeply understand the challenges organisations face.  Our approach has a number of unique elements that can significantly increase the likelihood of success. 

Answer: Over time, we've collaborated with numerous consultancies and companies, gaining deep insights into their practices. While most bring value, they often face the pressure of showcasing immediate and tangible improvements.  As a result, they may shy away from engaging in the tougher conversations and tackling the more complex challenges that lie beneath the surface, because they are time-consuming.

With a wealth of experience to draw from being at the forefront of the digital movement and software engineering advances, we are uniquely equipped with a distinct perspective and a deep understanding of the evolving landscape.

Our approach emphasises a balanced portfolio of improvements, encompassing People, Process, Technology, and the intricate web of organisational dynamics.  However, we place particular emphasis, on leveraging our expertise in recognising, managing, and ultimately reducing unnecessary complexity and dependencies.  This is as much within the deepest, darkest depths of your technology estate as it is within your processes.  Architecture, data models and tooling are important, more important than teams are often allowed to reflect in terms of the thinking space and time afforded to them.

Answer: Agile as it is typically practiced today seldom works.  That's a strong statement, so let's be a bit clearer.  It may provide some benefits, and it certainly supports a faster pace of digital product development than a waterfall approach.  And if it encourages good discipline then it is better than a more ad-hoc way of working.  But... much of the cultural change aspects, that the early agile movement once drove, have been lost.  Also, there is rarely enough focus on the technical practices required to allow for changes of direction and volatile requirements.

When agile was new and effective at driving huge, positive change, it relied on expertise and very experienced people for it to work.  When the business benefits were seen by others, it drove companies to invest in training and developing their people... to raise the competency of their workforces so that more empowerment and autonomy could be safely and effectively assumed.  This investment simply isn't at the levels now that it was.  Furthermore, the agile training and consultancy space is awash with materials and people that fail to make a positive impact on how a company operates.

Answer: Absolutely!   Using our assessment coupled with your goals we can help your teams become even better.

Due to our extensive experience in product development, engineering and management, we provide mentoring, coaching and hands-on help.

There are  lots of areas where we can bring innovative approaches to software development including:

1. How to use Domain Driven Design (DDD) in simpler ways... much simpler ways.

2. How to improve the quality of the code your engineers write, by reducing (yes reducing) the actual number of tests they write.

3. How to enable Junior & Mids to "punch above their weight".

4. How to exploit programming paradigms such as Object Orientation (OO) & Functional Programming (FP) to enable code to be written faster, but more importantly, better long-term maintainability. And all this, without increasing costs.

If you're in a good place and want to push on to the next level, it's definitely worth arranging a chat with us.

Answer: We have observed an awful lot of waste in software development.  Most teams only scratch the surface of waste reduction.  An often used acronym for the 8 wastes of lean is DOWNTIME which stands for: Defects, Overproduction, Waiting, Not utilising talent, Transportation, Inventory excess, Motion waste, Excess processing.

These all have an equivalent on product & software development.  Areas which lead to a lot of waste are in the details of how requirements are captured and analysed, how designs are iterated on, testing & QA activities, to name just a few.  Some of this can be improved with process improvements, with better practicing of agile framework ceremonies.  But much of it can only be improved by dramatically reducing the complex world of the software codebase; understanding and relearning what the code does to be able to change it; not being able to make the assumptions you should be able to about how a software framework operates 'under the hood'; why your coding standards and guidelines prevent you from doing what you think is a sensible and simple approach.

If you see our case studies, you'll see that, significant saving can be achieved by our approaches whilst achieving better outcomes. 

Answer: We like to start with an Assessment (we have four levels of assessments, something to suite everyone) which range in depth and breadth. 

We deeply want to understand you challenges and goals. 

Then we can agree a way forward which can be either full time or fractional / part-time.  We can sometimes support with as little as 4 hours a week.

We can even provide turn key bespoke software build service. 

Answer: Given the decades of experience - we are tech stack and language agnostic

Answer: 

Answer: A rewrite is typically costly and risky as you have to maintain the existing system whilst the rewrite is happening and it is very hard to catch up feature wise to a mature legacy system.

There are alternative strategies on how to approach a legacy sytem depending on the problems ranging from improving the legacy system to incrementally moving away from the legacy system.

We can discuss with you the various options and costs vs benefits vs risks of the various approaches. 

Answer: This is one of these "it depends" questions.
Based on the challenges and requirements of the system we can discuss the costs vs benefits vs risks of doing so.

We helped organisations migrate to cloud.

Also we know of organisations that have migrated to the cloud and then after after a view years migrated back on their own on prem hardware.

There are numerous factors to think about not least the skills sets of the teams, operating costs, flexibility, etc, etc. 

Answer:  Absolutely!  There are numerous strategies to help manage cloud costs. 

Answer: