Introduction

Bold Statement: many companies that have implemented Agile are getting the benefits because they have missed the point of Agile.   Companies will implement a flavour of Agile (Scrum most commonly) but will find that while the ceremonies improve communication and help to improve speed of delivery, they do not see a significant increase in amount of software being shipped.   My theory: Organisations are not generally focusing on productivity and certainly are not “Engineering for Productivity”.

It’s Difficult to get Engineers….

During the time I spent with a previous employer I met several ‘C’ Level executives in UI and European business  building software. They all said engineering personnel at reasonable salaries were hard to find.  Since then and post Covid, finding good engineers at reasonable rates of pay is a challenge for just about anyone building software.  My current employers have engineering teams in several countries and I can report the competition for staff is “stiff” globally.    (I should add I am writing in a private capacity and the content of this article should not be regarded as those of my employers current or previous).

With staff costs heading upwards (and I wouldn’t count on a global recession to check salaries for long if at all) Engineering Management (EM) and Product Owners (PO) need to get the “biggest bank for the buck” from their engineering hours.    Depending on location and engagement model, coders, testers (including on costs) can be anywhere between £290 and £800GBP (or more) per day. At the lower end a team of 5 coders/testers costs £15,000 per two week sprint and at the higher end £40,000.  If the costs of supporting roles such as a Business Analyst (BA), DevOps Engineers and the PO are included, sprint costs will be higher.  I wonder how many PO’s know the cost of the features they build and can map this back to the business value of those features?

For EM, the challenge is tougher.  While the PO has “bottom line” accountability for the success or otherwise of the features built, EM must ensure that their teams are kept running a healthy pace.    Engineers that work long hours or under constant pressure become less productive, making them easy prey for recruiters.

To increase productivity, it is also necessary to look at the way of working (eliminating waste which is a key tenant of Lead/Agile and so often missing from Agile ways of working) and invest in the underlying code structure.

For the avoidance of doubt, do not confuse productivity with the success of features delivered.  Feature success is determined by the market take up or the delivered product achieving the stated business outcome(s).  If a PO asks for features that consumers do not use, then they have wasted the company’s money; Productivity is about the Engineers building high quality features in the shortest possible time.  In an efficient engineering shop, if the software shipped is a success, the return on investment is higher; if the features delivered are a commercial failure the cost of that failure will be lower and (hopefully) discovered sooner.

Way of Working

While Scrum is very simple (compare the Scrum Guide to SAFe® 5.0 or the AgilePM® handbook) it hasn’t kept pace with the times.  The software we build today is larger, more integrated and connected than the software we developed 23 years ago.  Scrum It does not recognise value add roles such as Business Analysts (BA), Architects or Engineering Management.  For most companies, textbook Scrum is not appropriate, therefore a hybrid model needs to be defined; often pinching ideas from SAFe® (which, in my view,  pinches ideas from everywhere), AgilePM® to build on top of the basic Scrum model.

In my career I’ve come across situations where BA’s have been the defacto PO (usually because the PO is too busy and occasionally because they do not understand of the problem domain), I have seen Engineers straying into discussions about business priority and PO making technical and planning decisions they are not qualified to make.  Productive working requires each person to understand their role/responsibility, work in true collaboration AND have the requited knowledge and experience.  (See AgilePM® list of critical success factors).

Long hours are bad; from time to time, they are needed.  However, if it’s the norm productivity will suffer.  Ideally, coders and testers need to be coding and testing for most of the working week.   In addition, time must be allowed to develop new skills and refine stories or the next sprint.  Causes of wate include stories not being “ready” so triggering discussions and stories being revised mid-sprint as well as poorly defined acceptance criteria and constant interruptions to assist other teams or resolve production issues.

Reducing Rework

One of the major causes of waste is rework, redoing stories in Sprint because quality assurance testing found issues with the work – perhaps due a poorly defined story or poor coding.  Post release, reworking stories due to bugs, often found because in large complex systems the consequences of a change in one module had a undesirable knock on effect in another.    The way of working (in particular, the aforementioned story definition and proper coding) and a sharper focus on roles help to reduce in sprint rework; comprehensive automated regression testing and pre story analysis/investigation reduces the later.

Rework triggered by adverse reaction to the software is another matter.  Putting software out as early as possible is in part to increase the return on investment, but also generate feedback about the technical viability or market reaction to the delivered software.   Confirmation or otherwise gives confidence to the team (if positive) and if negative allows for a correction (rework), stop or pivot before more money is invested in a poor solution.   In either event, the decision to carry on or change rests with the PO, however change comes with a price.

Engineering for Productivity

Keeping teams working productively is not just about a smooth flow of well-defined and refined stories.  It needs the underlying code base to be “clean” (or at least a policy of cleaning code up if currently messy).  I remember Dr. Ian Spence, who was the tutor on my SAFe® course some years back, saying the “Crappy code doesn’t scale”.  He was right; it doesn’t scale in terms of maintainability or in performance in production.

Being able to safely make changes requires lots of Unit (code) and Regression (API/UI) Tests that encapsulate the business logic (happy and negative paths), are ideally automated.   Allowing the time in the project schedule and resources to create these is critically important.  Badly tested, complex software generally leads to production issues which degrades the customer experience and leads to engineering teams taking costly interruptions to resolve issues.

Components for reassembly and common design patterns.

Firstly, keep architecture simple.  This makes it easier to explain to everyone (especially new engineers).  Componentise as much as possible for high reuse and prevent reinventing solutions.   Use common patterns for services (e.g., Micro Services) as this ensures engineers can navigate unfamiliar code easily; authentication, logging etc are all done in the same way.  This means more time is devoted to creating valuable code that solves the business problem.

Metrics

Metrics are for me, about trends, confirming that policy has been enacted and a starting point for conversations.  Are we achieving goals? If something is not working? If so start talking to people and find out what is going on.  I should add as an Engineering Manager, I strongly believe in  “Genchi Genbutsu”, i.e. go see and what is happening, talk to people at the sharp end (the ones doing the work) about the problems and solicit (and elicit) what they think should be done.

With applications of any size automated regression testing is desirable; with a large complex (and especially old codebase) automation is essential.  Building up metrics on the areas tested, number of tests running each week, length of tests etc shows that the tests are being run and actively developed.  Counting the number of defects found post release confirms that value is being added. Data can also be used to identify areas of the system that were not covered by tests and divert resources/management attention to these areas.

At the team level, standard Agile metrics regarding sprint velocity, story time etc., inform the team how as to how they are working and lead to identify ways (or experiments) as to how they can further improve.  However, EM should be looking at metrics for all teams to look for systemic issues.  For example, if all teams have a high amount of change after Sprint Planning, this suggests a systemic issue which needs addressing.

Operational data is also important; What issues are being reported in Production? How is the software performing (in terms of performance, records processed, at peak load)?   PO’s should be reviewing this data to confirm their solutions perform well in operation; EM for overall system architecture, resource planning and confirmation that other programmes (such as test automation) are working well.

Critically, teams must use data to improve their performance and change their way of working.  The essence of Agile is succeeding of failing as a team which means, irrespective of job title, everyone on the team using their full spectrum of skills to help the team succeed.

For example, how many teams review time spent in state (e.g. code review) to determine how they can move work more quickly through that state?  Is there a potential use for tooling and how will EM  to respond if a team requests improved tooling to automate reviews to increase throughput.  One important factor (and another common anti pattern) is team giving story points to production bugs when fixing these as planned sprint work.   If these are zero pointed, the team’s velocity will be impacted which creates an incentive to “right first time”.

Conclusion

I have touched on many issues in this article; with Engineers being difficult and increasingly expensive it is important for management to encourage collaborative team working and constant focus on improvement.  The best engineering teams will be keen to improve their knowledge and skills as this will make them more capable engineers as well as a more efficient unit.

Acknowledgements

Firstly to Jim Vincent of Fairfax, Virginia, USA for review editing suggestions on this article.

AgilePM® is a registered trademark of Agile Business Consortium Limited.

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile, Inc.