To celebrate the 10th anniversary of the AgileAus Conference, we sent some alumni speakers on a trip down memory lane. Learn from past speakers as they reflect on whether their presentations have stood the test of time.
Simon presented “Leading by Serving” at AgileAus 2011. Simon is currently a Champion, Agility Transformation and Management Consultant at 460degrees.
When I spoke on servant leadership in 2011, my research into Robert Greenleaf’s work was motivated by a desire to make sense of my observations on leadership. My work helped me understand my inherent inclination to serve others first. For me, key servant leadership principles such as small steps, acceptance and withdrawal, fostering community, art over science and ultimately ‘serving first’ seemed honourable leadership foundations for building successful Agile organisations.
Since then, ‘Agile transformation’ has become mainstream. It’s everywhere, it’s a business imperative for organisations big and small, and it’s brought about an urgent need for leadership change.
At Agile conferences and meetups, we’ve talked at length about focusing on people over process and tools and the need for culture and mindset shift above all else. We’ve been wooed by autonomy, mastery and purpose, seduced by the prospect of true teal organisations and disrupted by the different cultural needs of the millennial generation. Hell, even servant leadership is mainstream: Greenleaf would be so proud!
Despite this, I still work with many organisations who are struggling with the cultural and mindset shift to agility. In my view, a prevailing coercive leadership and management style is the single biggest barrier to change.
Sure, there is an understanding that there is a need to lead differently, but too often this isn’t backed up in practice. Leaders don’t ask themselves the question “and how will I need to change?”. When the going gets tough, there is a reversion to type; to a command and control approach where any trust or empowerment that has been built is immediately eroded.
“Trust takes a very long time to build, but no time at all to break down”
I firmly believe the servant leadership principles that I spoke about then are as important today for organisations seeking to become truly Agile, if not more so. As a precursor to writing this article, I reviewed the content of my presentation from 2011 and I decided I wouldn’t change it one bit!
Renee presented “A Rogue’s Take on the 4 ‘C’s: Culture, Change, Costs, Currency” at Agile Australia in 2011. Renee is currently an Enterprise Agile Coach at The Boston Consulting Group.
In 2011, my presentation was a dive into the five types of Agile transformations we had seen within Australia and New Zealand:
- Undercover – where people do Agile but don’t tell anyone
- Unstealthed – team-based Agile implementation
- Unfocused – ‘Fragile’ implementations that are Agile in name, but not by behaviour
- Unleashed – Agile, but in IT only
- Unstoppable – all parts of the organisation working in an Agile way
Seven years on, these patterns are still seen in their various forms. However, there is an additional type of model which focuses more on program or portfolio implementations; commonly known as ‘Agile at scale’. ‘Unleashed’ and ‘Unstoppable’ forms of transformation now have more clarity with greater information available on how to change governance, finance and HR.
My talk covered the key roles these five types of change play in a larger scale transformation. The biggest callout today remains that we have too many transformations that are lacking strong sponsorship (referred to as a ‘tank’ in my talk). While a lot may seemed to have changed in seven years, we still have the same implementation issues.
Lachlan Heasman and Jody Podbury
Lachlan and Jody spoke on “Agile for Business as Usual” (BAU) at AgileAus 2009, sharing Suncorp’s BAU journey. Lachlan is now working on his PhD and will soon commence work at Elabor8. Jody is an Agile Coach at OFX.
Jody: When Lachlan and I were working at Suncorp, Agile was still an emerging concept and organisations were divided into BAU and product teams. We felt strongly that teams should own their product end-to-end and own the on-going life of the production. This continues to serve as the underlying principle of our work today.
In bringing together product teams and BAU teams, we experimented with different flavours of Agile to identify what worked for the organisation. Just plugging in one particular flavour of Agile isn’t the way to work; we aren’t dealing with toasters or dishwashers!
As an industry, we tend to look for a ‘pre-fab’ version of Agile for an organisation. If we plug in to Scrum, LESS, SAFe, Kanban or any other preferred Agile flavour, it’s assumed all our issues will be solved. We’re failing as an industry to see each of these flavours as a framework within which we can use the Agile principles to deliver better customer value.
Lachlan: Ten years later, I still believe if you have BAU, you have a bigger problem than Agile in BAU. This is because BAU fragments ownership of products. If someone makes a crappy product they don’t have to support it, and if they make a great product BAU disconnects them from the ongoing impact of their work.
BAU is often structured around assets rather than value. Problems arise when scheduling work focused on creating value, because you need to coordinate the BAU teams to work together to make even the smallest change. You can improve the work within a BAU team or environment, but you’ll always reach a point where the BAU organisational structure needs to be changed for greater improvement. This radical change is often beyond the limits of continuous improvement authority or beyond the appetite of the organisation.
Jody: Businesses are still making the same mistakes they were ten years ago. Older, more established organisations may have grown out of BAU at some point over the past decade, but they’re now growing back into these practices. When busy or under pressure, they automatically throw everything into BAU teams.
Small or new companies also revert to BAU when their product teams get stretched. They build or bring in new product teams, which results in products getting overlooked and the company throwing developers on the issue in the hopes of solving it.
Ultimately, we continue to believe that continuous improvement is critical to the success of Agile in any incarnation.
At AgileAus 2010, Jez presented “DevOps and Agile Release Management: Rapid, reliable software releases through automation and collaboration.” He returned to Australia with a 2017 keynote: “Continuous Delivery sounds great but it won’t work here.” Jez is the founder and CTO of DevOps Research and Assessment and lectures at UC Berkeley.
If you were at AgileAus in 2010, you might have watched a jetlagged pom give a talk on DevOps and Agile release management. I presented ideas from a book I wrote with Dave Farley, published earlier that year: Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation. Re-reading my slides, the principles and practices described haven’t changed. On the contrary, to my surprise, what was then considered “emerging” has become mainstream: shown to be effective in even the largest and most highly regulated domains (or, at least, in the parts of them willing to put in the work). However, it remains as hard as ever to implement these ideas.
At 2017’s AgileAus I gave a keynote reflecting on the last seven years of watching and helping the industry adopt Continuous Delivery (see it on InfoQ, or read a paper based on the talk I wrote for Communications of the ACM.) I describe how these ideas have been implemented on mainframe systems in financial services, in the US Federal Government, and in embedded systems. Broadly speaking, if you’re working on a product or service you expect to evolve significantly over the course of its life cycle – or even if you need to be able to patch and redeploy a service quickly and safely in response to a vulnerability – it’s worth pursuing DevOps and Continuous Delivery.
However, doing so is hard. It requires significant, sustained investment over many years to perform essential improvement work and then to keep improving. This demands focus, clear prioritisation and communication at all levels of the organisation – from executives to engineers. Thoroughgoing architectural changes will need to be made. Process improvement work must be carried out, such as moving to a peer-review based change management process supported by comprehensive automated and manual tests. When things inevitably go wrong as a result of experimenting with new ways of working, those responsible must be rewarded for helping the organisation learn and be encouraged to keep trying. Meanwhile, new features and capabilities must also be delivered – indeed, the whole point of the investment is to continuously improve our delivery capability.
For organisations willing to invest the necessary effort, the results are game-changing. In our latest book, Accelerate: The Science of Lean Software and DevOps, Dr Nicole Forsgren, Gene Kim and I present the results of a four year research program which shows that high performing teams – even in large, highly regulated organisations – can achieve more frequent deployments and much faster lead times while increasing the stability and quality of the products and services they are building. As a result, high performers were twice as likely to exceed commercial goals such as profitability and market share. They also achieved goals important to all kinds of organisations like customer satisfaction and operating efficiency, and realised their mission goals.
Rebecca visited Australia to present on “Agile and Enterprise Architecture are not mutually exclusive” in 2011 at Agile Australia.Rebecca Parsons is the Chief Technology Officer at ThoughtWorks and chairs the board of Agile Alliance.
When I spoke about Agile and Enterprise Architecture, I considered reconciling the principles and practices of Agile software development with those of Enterprise Architecture. Many see these two sets of principles and practices as mutually exclusive. Architecture is supposed to be stable – the foundation on which an organisation’s software assets are built. Embracing change in architecture just didn’t seem to make sense.
The reconciliation effort requires accepting that both practices have legitimacy in modern software development. We must be able to develop systems quickly; Agile software development, particularly utilising the strong engineering practices, is quite effective at doing this while maintaining superior levels of quality. However, as the size of an organisation’s software estate grows, the traditional concerns of enterprise architects must be taken into account. We recommended using Agile practices for software delivery, but undertaking decision-making while considering the combined concerns of enterprise architects and the business drivers pushing software development.
Since my talk, our understanding of software architecture has changed. We cannot continue to think of architecture as those things that are hard to change, since we no longer have an idea of how changes in policy, regulation, technology choices, business models or customer expectations will impact our systems. We’ve expanded our thinking about architecture to encompass more evolutionary ideas, where our target architecture is no longer a set of block diagrams and technology choices. Our target architecture is now a suite of architecture fitness functions that capture the behaviours we want our systems and our architecture to exhibit. Teams work within the bounds of these fitness functions to continually evolve both the application code and the architecture of the system. Concepts from Agile have moved firmly into the realm of architecture.
Martin spoke on “Introspection and Leadership” at 2010’s Agile Australia. Martin is currently the Chief Digital Officer at Innodev.
In 2010, my presentation focused on how we could incorporate Agile at a coaching level. My work has now shifted toward the question of what it means to be a leader, challenging the dominant leadership styles in the Agile community. Our community is full of people who believe they are experts, but it is impossible to be an ‘expert’ in this industry! We can’t continue to rely solely on one self-proclaimed expert’s opinion: we need to embrace a diversity of knowledge.
Leaders’ bad habits haven’t changed since 2010. In fact, they’ve probably become even worse! As they adjust to Agile, many organisations’ leaders don’t realise that they are creating their own problems. When things go wrong, they blame the new systems rather than their own inability to adjust to change. Leaders must be aware of how their failure to embrace change may be causing their company’s issues.
Introspection can amend the leadership issues we face in the Agile community. An introspective learning cycle involves looking backwards in a world where we are too busy looking forward. At the heart of introspection is the process of reflection. There are many different styles of reflection: for example, we can engage in liminal thinking, undertake timelines reviews or conduct personal retrospectives.
In my seminars, I ask attendees to open their calendars to see how much time they’ve allocated to reflection. Less than 5% practice some form of reflection. Learning your way out of a complex problem is a principle at the heart of Agile, but this can’t be realised without organisation-wide reflection. However, leaders can’t expect others to adopt this introspective mindset if they aren’t the first to model it.
Leaders must recognise that valuable intelligence is gained from listening closely to customers, staff and peers. There is too much bragging in this industry and we don’t hear the knowledge others have to offer. The conference presentations of many Agile ‘experts’ essentially boil down to: “I know something you don’t!” or “I do Agile better!”. Reflecting on my presentation style, I realised my need for a positive reception hindered my ability to listen and learn from my audience.
As we move forward, leaders must emphasise the value of cooperation. The bell curve currently used to measure and reward corporate success isn’t conducive to progress. These comparisons between staff stop us from winning. Organisations must make a conscious effort to reward collaboration.
Craig spoke on “The Speed to Cool: Valuing Testing and Quality in Agile Teams” at Agile Australia in 2011. Craig is an Agile Coach and Director at Unbound DNA and works as a Trainer and Consultant at Software Education.
In 2011, my talk highlighted the need for a greater understanding of the changing role of testing in Agile environments and the need to build quality into our solutions from the beginning.
Fast forwarding to 2018, the community is improving in this space but still has a long way to go. The rise in popularity of DevOps has helped immensely in this area, although it astounds me how many teams and organisations I work with still do not have some of the basic building blocks in place (like continuous integration or sometimes, worryingly, version control). Many organisations still have a large focus on manually testing via the UI which becomes increasingly riskier and slower as the importance of digital continues to rise.
In my talk, I spoke about what is now referred to as the “three amigos” concept. In the ‘conversation’ around a user story, three key principles outline how to actually implement the work:
- When developers and user representatives collaborate we get a better understanding of the specification or the requirements.
- When testers and user representatives collaborate we get a better understanding of the acceptance criteria and how we will meet our agreed definition of ‘done’.
- When testers and developers collaborate we get a better understanding of quality, but also get the value of pairing on automated testing.
Approaches such as Behaviour Driven Development have risen in popularity and support the above model well but, as I highlighted in the talk, this requires behavioural changes across the team. Mainly:
- User representatives need to have a greater testing involvement, working closer in real time with testers.
- Testers need to build technical knowledge and work closer in real time with developers, understanding developer tests and interfaces to avoid rework and improve quality.
- Developers need work closer with the user representatives on the requirements collaboration, as well as with the testers to ensure that testing artefacts are left behind.
We need to appreciate testing as a team skill set and not as a job or an anchor. While this now occurs more frequently in the Agile community, many organisations still have a long way to go. Testing remains an important skill, but mindsets and skill sets need to change to fully embrace an Agile way of working.
Speakers at AgileAus18 include some of those who spoke at the very first AgileAus – Adam Boas, Julian Boot, Marina Chiovetti, Nigel Dalton, Jeff Smith and John Sullivan – agileaustralia.com.au