Sustainable Pace – A True Measure To Agility

Ref: https://agilegnostic.wordpress.com/2016/01/21/sustainable-pace-a-true-measure-to-agility/

In Agile Software Development, ‘Sustainable Pace’ practice refers to the consistent and sustainable software development through a longer period. This sustainability in development should be maintained continuously until completion of product development with the consistent endeavors to improve the rate of software delivery maintaining the quality output. Originated from the Extreme Programming methodology, and having specially mentioned in Agile Manifesto; the practice has been widely accepted into Agile Software Development. It’s applicable to all kinds of development projects, for both at small and large teams at scaled agile. The phrase ‘Sustainable Pace’ was coined to denote that the team works daily for the same number of hours so that their pace of development remains consistently same or improve slowly without draining teams performance; making them fatigue or raising their frustration level such that they lose interests.

“In the long run, sustainable pace of development is the fastest way to deliver the quality software.”

The Sustainable Pace in very important, especially in long running software projects. It’s similar to maintaining the Constant Pace of Running in long distance running events like Half Marathon or Marathon. Unless a runner maintains constant pace; (s)he won’t be able to run long distance for a longer period. If runner sprints fast or has too much variation in running pace; (s)he will get tired too early and may get injured or body can resist completing the race. In software development also, if team push too hard in few iterations, they will not be able to keep up the same pace for longer period. The small variations in running pace also important, which depends in the nature of race terrains. When a runner gets into the upward or uphill terrain, (s)he slows down the pace a bit to reserve energy until plain/flat surface comes. Similarly, if the development team has come across rough patches in forms of technical debts, impediments; they would need to slow down the pace a bit, so as to take appropriate actions first before moving on with development further. Like running, keeping a constant rhythmic pace of development is important to keep the team energetic and motivated.

Where does it apply?

The sustainable pace is expected to be maintained across the software engineering disciplines; programming, quality assurance, and delivery management. One of the Agile manifesto principles read as following…

“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”

This principle states that it’s not just developers but also the sponsors and users; who should maintain the constant pace. Let’s discuss how the sponsors and users can contribute to a sustainable pace of development…

• There must be Subject Matter Experts (SMEs) from customer representing sponsor (most members of Product Management group, Product Owners) and users (end-users of the product being developed); who have vested interests in the development process. 
• They are committed to giving a certain amount of time that is sufficient to the team.  They actively participate in software development process by owning certain defined activities and responsibilities. Activities such as defining prioritizing product features, and taking business decisions whenever needed.
• Users, when interim product increments are given the demo (iteration review meetings) or handed over for review and testing; they should provide active and timely feedbacks. Any changes or improvements can be planned by the team on time earliest with their future impacts.
• Customer provided feedbacks on changes in requirements could be due to any reasons; which should be taken into consideration with appropriate planning in consultation with customer representative (the product owner).

For me, the sustainability in software engineering applies to entire software lifecycle – during the development and while in production; when the product is in actual use. The sustainable pace needs to be maintained across the software product lifecycle from product envisioning, it’s development, quality assurance, and future enhancements and changes; while the product is business facing.

What are the impacting factors?

There are many factors that directly or indirectly impacts the teams sustainable pace.

• Abnormal Working Hours/Days – It has been observed that majority of teams have extended work hours, either they continue working late evenings or until nights, they either miss to enjoy the company holidays or have prolonged weeks working on weekends. Also, in many organizations abnormal and prolonged working hours have become a normal phenomenon. These kinds of working styles for a long time are the major deterrents to sustainable development pace. Initially, it may lead to increase in productivity, but over the longer period, it degrades the  individuals and whole team’s productivity as well as the quality of work.
• Agile Anti-patterns (Culture & Mindset)– Sustainability depends a lot on the ways in which teams works and how their works are managed. The management style depends on the people in the management roles as well as on the organization’s culture and working styles. Many times managers and leaders do link the overtimes works to employees commitments and dedication to finish the tasks in hand. The worst part is many of the managers pressurize the teams to finish the work in comparatively shorter time and make a mistake to see it as increased productivity.Employees working late or on weekends are appraised for their elevated performance, (which truly does not translate to that) thereby creating a culture of imbalance and illusion in projecting achievements. This creates an unhealthy culture and unbalanced work environment. Sometimes even the senior management attempt to make a comparative distinction based on such unreasonable and unrealistic parameters. Organization should create healthy culture and mindset favorable to Agile. Read my post “Four Facets of Agile – Part 1” to get more insights on Agile culture and mindset.
• Distributed Teams – Especially in Software Development space, it has become a very common phenomenon to have distributed teams in which members work from different geographical locations and time-zones. Having the distributed team is the reality today due to various factors like cost effectiveness, availability of talents pools and other such numerous reasons; which can not be avoided. Having team members at distributed locations in different time-zones create challenges in communication, collaboration, work distribution, and synchronization etc. Without effective uses of tools and technology as well as planning of suitable team composition and placements; maintaining the consistent pace would definitely be a challenge. Refer my previous blog “Bringing Agility To Distributed Agile Teams” for more details.
• Inappropriate Planning – Insufficient and inappropriate planning of works, lack of prioritization,unresolved dependencies, unbroken users stories, unidentified tasks and insufficient estimation are the critical factors that hampers the team’s productivity and inability to maintain a sustainable pace.It is of utmost importance that team does the appropriate level of  Release Planning, Sprint Planning on time and revisit them frequently in order to adjust any deviations and anomalies caused by impediments. Having appropriate, revised and meticulous plans help a team to be organized and focused to both short-term and long-term goals; which increases teams moral, confidence and commitments.
• Unrealistic Improvement Pressure – There is constant pressure on the team, both from customer side (i.e. Product Owner) and management; to improve the velocity, by taking more and more work every iteration; even though the team’s capacity remains same. It should be left on team’s discretion and comfort to increase the velocity on a continuous basis through inspection (process, tools and practices) and adaptions (remedies and workarounds).Increased pressure without understanding and removing the root cause of problems, process and practices improvements, reducing dependencies and mitigating the risk occurrences; it becomes impossible for the team to improve velocity (and so as productivity) without working extra time than whatever was planned. In many cases, I observed that teams are pressurized to even plan for working on weekends intestinally due to the growing backlog and pressure to deliver them at earliest. In such cases team is not going to remain productive for a longer period.

How do we measure?

“The pace of development should be sustainable, measurable and predictable.”

With references to team’s daily working schedule, widely it’s been seen as whether team works consistently for the same number of hours or not. This is a common misunderstanding that if a team works consistently for the same number of hours; say for examples 40 hours per week; then they have Sustainable Pace of development. It’s just same as undervaluing the importance of sustainable pace and inappropriately measured.

Daily work schedule and the total work hours per iteration definitely have an impact of team’s productivity, quality and output of work completed. It’s worth noting that actual productive hours must not be compared with working hours.

“The actual measure of sustainable pace should be based on Consistency in Velocity and the Business Values delivered in relation to team’s capacity in every sprint .” 

If a team who havie it’s capacity constant, is able to maintain the same Velocity or Business Value delivery or even slightly improves the delivery rate; then we can say the team has a sustainable pace. 

The velocity and business value achievement should be calculated only for those piece of work that are fully completed; that is those features that are developed, integrated, tested and are production ready without any known bugs.

What to do to be sustainable?

The Sustainable Pace should be looked beyond the perspective of daily working hours. If a team has sustainable pace then through inspection and adaption they can plan to consistently improve the software delivery rate slowly maintaining the deliverables quality utmost. But while improving the delivery rate with improved pace, if the team loses focus to improving on quality then the improvement is not sustainable. The team can only have sustainable pace if they have…

• Sustainable Development – at every iteration works with consistent velocity and business values delivery, maintaining the consistent productivity
• Sustainable Quality – at end of every iteration produces deliverables (i.e. Product Increments) with no or less technical debts accumulation
• Sustainable Delivery – maintains the consistent, frequent and stable software releases to test and production environments
• Sustainable Improvement – continuously improves the processes and practices based on introspection, review feedbacks, and subsequent course correction

Following are few pointers that will help teams to be sustainable….

• Create agile mindset and culture healthy for working in Agile Software Development
• Keep team’s morale high, motivated and committed throughout development
• Trust your team, honor and value their works, give then autonomy to make local decisions
• Allow your team to set their pace and rhythm; achievements will keep them excited and motivated to do better
• Don’t let team members work overtime or force them to work weekends
• Don’t demand to take more and more works or put unrealistic pressure to increase the velocity
• Don’t let the technical debts be accumulated, address bugs at earliest
• Team members should avoid multi-tasking and wasteful works
• Promote balanced work-life and resolve personal issues
• Don’t keep asking team to increase delivery speed without optimizing the processes and practices
• Let the teams find out their perfect velocity and using that plan releases and sprints appropriately
• Team continuously inspects and adapts through course correction and improvements
• Optimize the processes and practices in whole software delivery chain; try eliminating the possible wastes consistently
• Maintain transparency, keep stakeholders and customer informed on any issues, impediments, risks, and blockers
• Wherever possible automate the repetitive manual activities, perform continuous integrationand test automation
• Involve team in estimation and planning sessions; ensure all risks and dependencies are thought off and planned accordingly 

Conclusion…

Sustainability does not mean a team should take their work slow and easy; rather team should be steady and consistent maintaining the pace of software development and delivery with slowly improving on productivity and quality of work. It has more to do with achievement of long-term goals rather than short-term peak performance.