An Agile Approach to Strata Building Defects
Bringing a tech start-up approach to strata building defects management …
The old ways of doing things no longer work in many parts of our social, economic and personal activities. And, strata building defect claims are handled the same way today as they did were 25 years ago. So, I’m looking to innovations in the tech world for new and better strategies for handling strata building defects.
[10.5 minutes estimated reading time, 2,059 words]
Introduction
There’s a new way tech startups manage their activities, work, and projects that eschews the traditional hierarchical project management approach.
It’s called Agile: a more incremental, flexible, progressive, and faster way of getting results.
Since it’s been used by some of the largest and most successful organisations in the world, it’s the way virtually all software is written now, and, the leading Agile tools are developed by an Australian business [Atlassian], I think it’s a better way to manage strata building defects.
So, let’s explore that approach and how it could apply to strata title building defects in this article.
What is Agile?
Agile today stands as one of the most popular approaches to project management because of its flexibility and evolutionary nature.
Agile, in a nutshell, is an iterative and incremental approach to project management that helps teams keep up with the demands of the modern workplace. It consists of different methodologies and all of them are based on the concepts of flexibility, transparency, quality, and continuous improvement.
Data from 2018 indicates that projects using Agile methodologies are 28% more successful and almost 71% of organizations use Agile with varying frequencies.
The intention of Agile is to align development with business needs, and the success of Agile is apparent. Agile projects are customer-focused and encourage customer guidance and participation. As a result, Agile has grown to be an overarching view of software development throughout the software industry and an industry all by itself.
For the geeks, you can read more about Agile in the following articles:
Embracing Agile, by the Harvard Business Review
The 9 Key Benefits of Using the Agile Methodology, by Kissflow.
An Agile history lesson
The Agile Manifesto and the Twelve Principles of Agile Software were the consequences of software industry frustration in the 1990s.
There were enormous time lags between business requirements specification (the applications and features customers were requesting) and the delivery of technology that answered those needs and this often led to the canceling of many projects. Business requirements and customer requisites changed during this lag time, and the final product did not then meet the then-current needs. The software development models of the day, led by the Waterfall model, were not were too slow and did not take advantage of just how quickly software could now be altered.
In 2000, a group of seventeen ‘thought leaders,’ including Jon Kern, Kent Beck, Ward Cunningham, Arie van Bennekum, and Alistair Cockburn, met in Oregon and Utah and wrote the Agile Manifesto and the Twelve Principles.
The Manifesto reads:
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
And, thereby a brave new world of software development and more were launched by those prosaic words.
I have no doubt that the development of the Agile approach to software development in the early 1990s was an essential ingredient to the massive changes we’ve experienced over the last few decades.
An explanation of Agile processes
Agile project management is an iterative approach to product delivery that builds incrementally from the start of the project, instead of trying to deliver the entire product at once near the end.
Agile works by breaking projects down into little bits of user functionality, prioritizing them, and then continuously delivering them in 2-4 week cycles called iterations or sprints.
Teams operate in short cycles aimed at continuous improvement to develop only what the stakeholders want or need. Work goals are defined by the team before each cycle starts. The team communicates directly with stakeholders if they have any questions concerning the function. The stakeholders’ priorities are analysed by the product/outcome owner and fed into the team to keep them working on the highest priority items. The team estimates how much time work will take in an iteration, as well as how to do the work.
Performance is measured by stakeholders at the end of the iteration. The lessons learned in each iteration are captured in retrospectives and used in future iterations. In this way, the outcomes are constantly improved and the process for developing them also improved.
* Visualisation of an Agile sprint model
The Agile Manifesto
The Agile Manifesto is comprised of four foundational values and 12 supporting principles which lead the Agile approach to software development. Each Agile methodology applies the four values in different ways, but all of them rely on them to guide the development and delivery of high-quality, working software.
1. Individuals and Interactions Over Processes and Tools
The first value in the Agile Manifesto is “Individuals and interactions over processes and tools.”
Valuing people more highly than processes or tools is easy to understand because it is the people who respond to business needs and drive the development process. If the process or the tools drive development, the team is less responsive to change and less likely to meet customer needs. Communication is an example of the difference between valuing individuals versus processes. In the case of individuals, communication is fluid and happens when a need arises. In the case of process, communication is scheduled and requires specific content.
2. Working Software Over Comprehensive Documentation
Historically, enormous amounts of time were spent on documenting the product for development and ultimate delivery. Technical specifications, technical requirements, technical prospectus, interface design documents, test plans, documentation plans, and approvals required for each. The list was extensive and was a cause for the long delays in development.
Agile does not eliminate documentation but streamlines it in a form that gives the developer what is needed to do the work without getting bogged down in minutiae. Agile documents requirements as user stories, which are sufficient for a software developer to begin the task of building a new function. The Agile Manifesto values documentation, but it values working software more.
3. Customer Collaboration Over Contract Negotiation
Negotiation is the period when the customer and the product manager work out the details of delivery, with points along the way where the details may be renegotiated. Collaboration is a different creature entirely. With development models such as Waterfall, customers negotiate the requirements for the product, often in great detail, prior to any work starts. This meant the customer was involved in the process of development before development began and after it was completed, but not during the actual development process.
The Agile Manifesto describes a customer who is engaged and collaborates throughout the development process. This makes it far easier for development to meet their needs of the customer. Agile methods may include the customer at intervals for periodic demos, but a project could just as easily have an end-user as a daily part of the team and attending all meetings, ensuring the product meets the business needs of the customer.
4. Responding to Change Over Following a Plan
Traditional software development regarded change as an expense, so it was to be avoided. The intention was to develop detailed, elaborate plans, with a defined set of features and with everything, generally, having as high a priority as everything else, and with a large number of many dependencies on delivering in a certain order so that the team can work on the next piece of the puzzle.
With Agile, the shortness of an iteration means priorities can be shifted from iteration to iteration and new features can be added into the next iteration. Agile’s view is that changes always improve a project; changes provide additional value.
Perhaps nothing illustrates Agile’s positive approach to change better than the concept of Method Tailoring, defined in An Agile Information Systems Development Method as:
‘A process or capability in which human agents determine a system development approach for a specific project situation through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments.’
Agile methodologies allow Agile teams to modify the process and make it fit the team rather than the other way around.
The Twelve Agile Manifesto Principles
The following Twelve Principles are the methodologies that are applied to the values and the work.
They describe a culture in which change is welcome, and the stakeholders are the focus of the work, and where the outcomes are in alignment with stakeholder needs.
1. Stakeholder satisfaction through early and continuous software delivery – Stakeholders are happier when they receive working software or outputs at regular intervals, rather than waiting extended periods of time between releases or deliveries.
2. Accommodate changing requirements throughout the development process – The ability to avoid delays when a requirement or feature request changes.
3. Frequent delivery of working software or outputs – Scrum accommodates this principle since the team operates in software/outcome sprints or iterations that ensure regular delivery of working material.
4. Collaboration between stakeholders and team members throughout the project – Better decisions are made when the stakeholders and team are aligned.
5. Support, trust, and motivate the people involved – Motivated teams are more likely to deliver their best work than unhappy teams.
6. Enable face-to-face interactions – Communication is more successful when development teams are co-located and can communicate freely.
7. Working software or outputs is the primary measure of progress – Delivering functional software or other outputs to the stakeholders is the ultimate factor that measures progress.
8. Agile processes to support a consistent progress pace –Teams establish a repeatable and maintainable speed at which they can deliver outcomes, and they repeat it with each release.
9. Attention to technical detail and design enhances agility – The right skills, good design, and technical precision ensure the team can maintain the pace, constantly improve the outcomes, and sustain change.
10. Simplicity – Develop just enough to get the task done right now.
11. Self-organising teams encourage great architectures, requirements, and designs – Skilled and motivated team members who have decision-making power take ownership, communicate regularly with other team members and share ideas that deliver quality outcomes.
12. Regular reflections on how to become more effective – Self-improvement, process improvement, advancing skills, and techniques help team members work more efficiently.
Applying Agile to strata building defect management
So, applying Agile principles to strata building defect management involves redefining these principles using domain expertise in strata building defects.
I’m now doing that in my consultancy work and summarise some of the differences below.
If there’s enough interest I’ll also write a more detailed article about my approach in an article for paid subscribers to the GoStrata Stak. If you want to become a paid subscriber you can do so here.
Given how poorly strata building defects have been handled so far and the weak outcomes being achieved, trying another approach definitely can’t hurt.
June 04, 2021
Francesco …
FRANCESCO’S AGILE APPROACH TO STRATA BUILDING DEFECTS
1. Create an unstructured and informal team that’s multi-disciplined and works together continuously; rather than using a command/control approach where the project manager engages others for limited sub-tasks.
2. Treat information as fluid, so get and share information progressively as it is available, is needed, and emerges; rather than treating information as a discrete initial project and as fixed.
3. Make high level and/or macro assessments about value and direction of strata building defects management often [and be prepared for them to change and redefine and redirect the project]; rather than focusing on moving the process forward and only assessing it at the end [when it’s too late].
4. Work on things in parcelled but repeating ways to deliver mini outcomes from the beginning [and use the mini outcomes to inform and support later outcomes]; rather than defining big milestones to be achieved over longer periods.
5. Act in parallel, not linear, ways so that whilst one activity is slowed by external factors other’s progress [and revisiting the activity if necessary or things change]; rather than structuring things sequentially and conditionally on the completion of other actions.
6. Engage the builder, developer and other construction participants early, openly and often [even if they won’t participate] to reinforce their role and accountability; rather than only communicating in relation to demands, threats, or litigation.
7. Engage the strata building stakeholders continuously in a two-way process with frequently updated information, access to progress updates, and, a feedback loop; rather than basic, flat, and one-way milestone reporting.
8. Go digital by using software tools to for strata building defect management; rather than create paper, PDFs and spreadsheets that get buried in confidential archived folders.