Can we really achieve more by working less?
In a global climate where being present in the office is equated with being productive how do we make a case for the Sustainable work-life balance promoted by Agile?
This is a particularly pertinent question for organisations in the early days of transformation. The reality they have become used to, capacity will miraculously expand to fit the work into an increasingly unrealistic deadline, is turned on its head.
Empowering teams to provide realistic estimates to get a good job done at a sustainable pace (mostly within their contracted hours) and then giving them teeth to resist pressure to do more can be very scary for stakeholders. This article examines why less really can mean more and presents the case for Sustainability improving Productivity.
This article is approx. 2500 words and will take about 15 minutes of your time to read and digest. Best taken with tea/ coffee and a biscuit. If you are time or attention span limited jump to the conclusion - What does this mean for an organisation?
The Old World Order
Traditionally projects have been delivered by silo teams working in bursts of activity to deadlines that others have estimated and set for them.
In the old world, a 3-month software build could be characterised as one month of steady effort in normal working hours, one month of more urgent effort over longer hours, topped off with a month of frenzied 20x7 working as the team desperately try to meet cost and schedule targets.
The respite came when the exhausted development team could throw their build over the wall to QA. Of course, it didn’t last as QA systematically began to uncover the issues that escaped a Dev team that had sacrificed quality to maintain an impossible schedule.
After projects, it was not uncommon to see a huge attrition rate as both Dev and QA colleagues decided that the grass had to be greener elsewhere. And due to employee’s inconvenient expectations around being paid for additional hours ROI was inevitably eroded as the cost of building the product proved to be much higher than estimated. It was no way to live.
Bums on Seats = Productivity
Despite the inherent problems of this working style managers came to value the bums that occupied seats long before the sun was up and were still in situ long after everyone else had gone to bed; the ever-present heroes. They got things done, were obviously more productive, since logically more can be achieved in a 16-hour day than 8, and were feted as the exemplars of the perfect human resource.
Agile changed all that by promoting a continuous iterative process that could incrementally deliver tested, working software. There would be no downtime, therefore the process needed to be sustainable which, in turn, meant that overtime would be the exceptional exception, not the norm. Bums were only expected to be on seats during normal working hours; unconvinced managers got nervous.
To add to the woes of the Command and Control school of management Agile also suggested that estimating how long doing work would take should be the province of those who would be doing the work; a licence for padded estimates and institutionalised slacking.
Many management professionals saw these two Agile principles as a death knell for productivity and set about adapting the Agile methods to look an awful lot like nothing had changed in an effort to retain their command and control capability.
The Productivity Question
One of the measures for Scrum teams is acceleration, the rate at which a team’s velocity improves over time. This and story points per ideal developer day (SP/IDD) are measures of team productivity.
Productivity is seen, by some, as an anti-pattern for Agility and known, by all, to be easily gamed. Story Points are an abstract measure and, therefore, can be inflated to suit the need to demonstrate acceleration. This misses the point however since the purpose of measurement is to improve. It also supposes that our primary purpose at work is to avoid work; both insulting and untrue for the overwhelming majority of workers.
In practice, most of us like to be busy, want to make visible progress towards a known goal and, get a great deal of satisfaction from moving items into the ‘Done’ column. In a study by the Harvard Business School, participants were asked to keep a diary and record good and bad days at work making a note of what made them stand out; 76% of good days were notable for ‘making visible progress toward the goal’.
One conclusion from this could be that anything we can do to measure the rate of progress and improve it must be a good thing. The faster we can accelerate and move items from ‘to do’ to ‘done’ the happier we’ll be.
Thinking more broadly about Productivity and Efficiency it could be considered as getting the maximum outcome for the minimum output; the principle of maximising the amount of work not done. Agile principles also tell us that the highest priority is to satisfy the customer through the early and continuous delivery of valuable software. That we should deliver working software frequently and, that it is the primary measure of progress. It certainly doesn’t seem to be saying that Productivity should be sacrificed for Sustainability.
Working More Sustainable Hours Boosts Productivity
During the first 18 months of the trial, the nurses working shorter hours logged less sick leave, reported better-perceived health and boosted their productivity by organising 85% more activities for their patients.
The history of limiting the work day can be traced back to the 1800’s when mill owner Robert Owen cut his workers hours, first to ten and, then to eight by 1817, coining the slogan “eight hours labour, eight hours recreation, eight hours rest”. The 5-day/ 40-hour week didn’t become widespread however until Henry Ford adopted it in 1926 to gain productivity and loyalty benefits; the 9-5 was born.
More recently there have been experiments with reducing the working day to 6-hours. In a Swedish trial, nurses at a care home tried out a 6-hour working day resulting in better productivity, greater efficiency and a perceived benefit to their personal health.
Toyota service centres in Gothenburg have operated on a six-hour working day for more than ten years now, and report a low turnover of staff, coupled with an easier recruitment process when new workers are needed. Martin Banck, Managing Director, also reports that profits have risen 25% since the scheme was introduced.
While not everyone is ready to go that far a cursory glance at the News headlines will tell you that German workers are a staggering 27% more productive than their British counterparts despite working an average 38 days a year less. Clearly, at the national scale, it is possible to do more with less.
What this tells us is that being present does not equate to being productive. Workers who have had time for recreation and rest can be more productive in 40 hours than their heroic 100-hour colleagues and will probably make fewer mistakes. If you think that is unlikely ask yourself how comfortable you would be putting your life in the hands of a junior Doctor at the end of their 72-hour (recently reduced from 91) working week?
Maintaining Constant Pace Indefinitely
Agile Principle #8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Agile, done well, promises organisations a pathway to building better products faster. It promises individuals a more engaging, collaborative and rewarding role and, it promotes a more sustainable work-life balance than that experienced in the feast and famine of traditional staged methods.
Teams are entrusted with knowing how to do the work and providing realistic estimates of how long that work will take to do well. Scrum goes so far as to recognise a role, Scrum Master, with responsibility for team health; protecting the team from overload. In Kanban work in progress is limited to maintain a steady of flow of completed jobs and avoid the inefficiency of having too much on the go.
However, with trust comes accountability so we expect high quality from an Agile team; the aim should always be zero defect code. Additionally, we expect teams to be prepared to explain why something that appears to be simple will take so long to deliver; it is not wrong to ask a trusted team to verify an estimate.
Nor, for that matter, is it wrong to ask a team to work additional hours in those exceptional circumstances when we need to go the extra mile to meet a deadline or fix a production incident. So long as this is the exception and not the rule it is perfectly fine and can be compensated with overtime payments or time off in lieu.
Avoiding burnout for teams and individuals helps with stability and provides a solid foundation for ‘better’ but what about ‘faster’? Agile doesn’t immediately seem to have much to say about speed but if you look a little deeper and think a little harder it is there in the language of Agile metrics. Velocity, Flow, Acceleration, Burn-up and Burn-down all imply speed.
Agile methods are designed to deliver value rapidly either in short iterations or through a constant flow of value delivered in a very short cycle time. The promotion of ‘Fail Fast’ and short feedback loops between the customer and team contribute to reducing time to market; Agile promotes and expects speed.
Sustainability and Speed are not Mutually Exclusive
"Pace judgement is everything in the hour record. If you can ride 16.1 or 16.2-second laps constantly for 221 laps, and not go 15.9s or 16.4s, it's keeping it on the line every lap, lap after lap." Bradley Wiggins - Cyclist
Work smarter, not harder is a well-worn adage, it’s not how many hours you put in but how you spend them. Agile teams should be equipped with all the tools to work smart and encouraged to continually inspect and adapt to work smarter still. It’s this smarter working that will go a long way to delivering better products faster.
That doesn’t mean that Agile teams don’t need to work hard; they absolutely do and are far more likely to if they maintain a sustainable pace and good work/ life balance. No one ever won a marathon by intermittently walking and sprinting and no one would say that the winners hadn’t worked hard to maintain a 4.5-minute mile pace for 26 miles.
So? Can we really achieve more by working less?
Studies and experiments have demonstrated that simply reducing time spent at work makes people more productive and engaged without changing anything else. Take those same people and introduce them to better ways of working and you have a winning formula for a happy and productive workforce.
Happy workers are, on average, 12% more productive; up to 20% for some. That makes a happy 8-hour day the equivalent to 9.6 hours of a less enthused colleagues time. Taken in conjunction with the frequency of errors that tired minds make and there is a compelling case for making overtime the exception and not the rule.
Working software is the primary measure of progress and with the transparent nature of Agile methods teams and individuals who are not working effectively become apparent very quickly. If you are worried use the principle of trust and verification to check estimates. And finally, don’t confuse presence with productivity, they really are not the same thing.
Agile enables motivated individuals and teams to do more at a sustainable, and accelerating pace. Expect to see more value delivered for fewer hours and use a broad spectrum of metrics to measure to improve. Expect to attract better talent and retain it for longer because of your enlightened approach and continue to strive for the stable and dynamic practices that mark out the highest performing organisations.
What does this mean for Organisations?
Looking specifically at an early stage Agile transformation here are some things we should expect and some we should not.
Expect the perception that teams are less productive after transitioning to Agile. In the short term that will be true as they learn the new method, start to get to grips with technical debt, expose hidden work such as BAU and Support and provide estimates to do a quality job. In the medium to long term the perception will fade as the value of better business outcomes (happier customers) from happier teams is seen.
Don’t expect that overtime and weekend working will disappear overnight or ever.It should, however, be by exception and subject to the approval of the Product Owner; it is their ROI that gets eroded by overtime payments or the cost of capacity lost to Time Off In Lieu, so it should be their call.
Expect that you will be asked to verify your estimation on occasion. Stakeholders are mostly laypeople not imbued with your wealth of technical knowledge and therefore may not understand why something that appears simple isn’t.
Don’t expect teams using the Scrum method to be happy when asked to accept something brand new into their current Sprint. The Sprint is a time to focus on an agreed goal and is most efficient and productive when allowed to run its course uninterrupted so ask yourself exactly how urgent what you’re asking for is and if it won’t wait (a maximum of 10 working days).
Expect to be politely directed to the Product Owner if you approach one of the team with a new request. Product Owners own the backlog of work and prioritise it by value. The team are accountable to the PO to deliver what they committed for the Sprint and won’t have either the time or the knowledge to make a value judgement.
Don’t expect an easy life. Agile isn’t easy and neither is being the best. The inherent transparency in the method will very quickly expose passengers. Working hard at a sustainable pace is the only way to win the marathon.
Expect to see pair programming as heroes disseminate knowledge to their teammates. Heroes, or single points of failure as they are more accurately known, are actively discouraged in Agile teams. Generalising Specialists who share knowledge and upskill colleagues are, conversely, very welcome.
Don’t expect to be limited by your job title. Developers can run tests, though shouldn’t mark their own homework, and QA can update the user guide if needs must. Contribute what you can, where you can, to achieve the shared vision and goal.
Expect to be measured and use the results to continuously improve. The initial focus will be on getting teams into ‘doing Agile’. It is going to shift to ‘being Agile’ and that requires teams to measure themselves across a wide spectrum in order to select targets for improvement.
Expect to enjoy the ride. If you can embrace the mindset, values, principles and opportunities that an Agile initiative presents there is no reason why coming to work shouldn’t be a fun and rewarding experience.
Comments