BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Q&A with Renee Troughton on Leadership Patterns for Agility

Q&A with Renee Troughton on Leadership Patterns for Agility

This item in japanese

Bookmarks

Renee Troughton is one of the most experienced Enterprise Agile Transformation Coaches in the southern hemisphere with extensive experience working in small to large organisations across many sectors including finance, insurance, superannuation, government and telecommunications. She is author of the book "Agile Forest"  and co-author of ‘Who is Agile Australia and New Zealand‘, she contributes heavily to her blog at Agile Forest and co-chairs one of the world's leading Agile Podcasts. Troughton specialises in enterprise transformations, Kanban, scaled and non software development implementations of Agile.

She is talking at the upcoming Agile Indonesia conference.  She spoke to InfoQ about transforming organisations using systems thinking and important leadership patterns. 

InfoQ: Please tell us a bit more about yourself- who is Renee?

Renee Troughton: I am a passionate polymath. I want to make the world better through finding new ways of working and sharing them with others. I wouldn’t say I am just an Agile coach; I use many different methodologies and approaches, trying to focus on science and what demonstrably works in the reality. I train, advise, visually facilitate, podcast, write (including non Agile books), and importantly work with humans to support change.  

InfoQ: You're writing a book called ‘The Agile Forest’. The title sounds inspiring; can you share the main takeaways of the book with us?

Troughton: The book (still a work in progress) is written for everyday people who know nothing about Agile and tells a story about what Agile is without using any of the jargon we tend to use. It is sort of like “Who moved my cheese” or “The Phoenix Project” where it teaches through a parable.

Agile Forest is about a group of Australian marsupial animals who have a threat and the techniques and principles that they use to handle the situation.

InfoQ: Scaling is one of the topics you are known for and seems to be the hot topic in the agile world. In Indonesia, scaling is not yet a hot topic. Can you explain a bit more about scaling and some best practices or frameworks?

Troughton: I have a series on my blog called Scaling Agile Tricks which goes into a lot of depth about some of my best practices with Scaling. These include the Leadership Cell concept (the roles and ceremonies of people supporting delivery teams at scale), Mitosis team splitting, approaches to pipeline management, and the economic structuring of teams; these are just some of the concepts that are important in scaling mentioned in the blog. However, the ultimate principles that I try to address when scaling are:

  1. Reduce handoffs and dependencies

  2. Improve flow

  3. Improve building the thing right and building the right thing

  4. Integration of Agile, Lean and Design Thinking

As a result of these principles, it is less about using one particular framework for me (because none of them address principle four), and more about experimenting what works given a particular organisation’s setup and sharing a wide toolbox of practices and techniques so the right tool can be applied to the right problem. Choosing just one framework is sort of like having a hammer and thinking that everything is a nail.

InfoQ: It appears there are many hammers in the Agile space, many of them driven by commercial interests. One model that doesn’t have a commercial intent is the Spotify ‘model’. What are your views on adopting ‘the model’?

Troughton: It depends on what you classify as a mode. I would say it is more of an approach and Spotify themselves talk about it as something that is dynamic and really just for them, but if you want to try to replicate it you are welcome to.

I have coached in an environment that used guilds, tribes and chapters. It is really very challenging for it to work in practice, but it certainly wasn’t the only thing that we ended up implementing as a model.

The challenge in effective application of guilds and chapters is in having time to contribute and progress issues that benefit the guild and chapter; often there is so much delivery work on and in the pipeline that teams feel pressured not to contribute time. This results in the whole adage “we don’t have time to work smarter”.

There are a couple of patterns to help overcome this problem - such as 9/10 days where time is built into the system for not delivering or having dedicated people who have free capacity associated with each guild to help support the heavy lifting. Unfortunately most organisations choose to implement neither of these when implementing guilds and then wonder why guilds failed to realise the benefits they accepted.

Guilds and chapters is a technique to apply to the dual needs constraint in organisations. The constraint is - teams are best formed to deliver end-to-end value, but often these people have a high degree of specialisation. In addition, because multiple teams are working on the same system or channel the organisation needs a level of consistency - both in experience, look and feel and in maintainability. These are outer team constraints or needs. Potentially there are further constraints such as governance constraints to ask for consistency wider than the system or channel. The trick in this situation is not to apply guilds and chapters, as this is just one solution for the constraint, but to look at the constraints across the organisational system and define the trade offs, risks and issues for all solution options. Then choose an approach, test and learn if it works, but don’t be wedded to it - look for how you can detect early if it is not working and what you can do to either adapt it or pivot to another option. This process empowerment, adaptation, inspection and pivoting is really the core of Spotify’s success, not guilds and tribes.

InfoQ: In Indonesia, most companies are not thinking of scaling or looking at things like the Spotify approach yet. Most start with Scrum. You also have a lot of experience with Kanban. What are some of the main differences for you and how does a company choose the right framework?

Troughton: Probably the key difference between Scrum and Kanban would be in their basic approach. In Scrum, teams feel that the process replaces their existing development processes - in essence taking what they currently do, throw it in the bin and then begin Sprints. You can see this in how they react to situations where the answers aren’t in Scrum, they don’t know how to approach a common problem and they feel like they shouldn’t be doing what they used to, but struggle to find answers. Some coaches will then say when you do Scrum you aren’t meant to be throwing the baby out with the bathwater, for all that “other stuff” you still do what you used to, but in my experience the confusion is a very common early adoption pattern.

In Kanban, the adoption is to start with what you do now and add in some extra practices and principles. In this respect it is an additive rather than a replacement approach and it means that the early frustrations are not as severe.

Aside from the adoption starting standpoint, the second core difference is in timeboxing - Scrum has clear and regular timeboxes, whereas Kanban focuses more on continuous and managed flow.

Both do have concepts of “commitment”, although the more appropriate term is “planned intent”, where in Scrum the intent is defined at Sprint Planning, and in Kanban the intent is defined by the class of service cycle times (although Enterprise Services Planning has now expressed a regular cadence on commitment as well).  

Both Scrum and Kanban encourage continual inspection and adaption, both care about measuring throughput and using that information to adapt more effectively (but I would give Kanban points for having stronger mechanisms to do this).

Estimations are done for planning purposes in Scrum, whereas they are not required in Kanban (where actuals are used as a mechanism to forecast).

Scrum tends to have very simple visual management with work being broken down into tasks and the tasks moving across from “To Do” to “Doing” to “Done”. In Kanban the work isn’t broken down into tasks and instead the visual management is a representation of the flow of work by class of service. The work moves across the board’s flow and not the tasks.

As for what to use in an organisation, it is probably an “it depends” answer. If a team is continually getting change in scope inside of a week and that change has to be accepted (cost of delay is too great to hold for a week and deliver in one to two weeks) then I will always recommend Kanban. Other than that, if the work has a finite time period with core goals then it might be better to use Scrum.

Personally I always prefer to start teams to with the best of both worlds (known as Scrumban) and then try to shift them more towards pure Kanban over time as constraints outside of the team at scale are shifted more towards flow.

I really like the changes that are part of Enterprise Services Planning and feel that it is a strong attempt to address some of the long standing criticisms of Kanban.

InfoQ: You also talk about holacracy. For those who don’t know the term yet, can you explain it in a nutshell? How can holacracy help companies?

Troughton: Brian Robertson, the creator of Holacracy, would likely describe it as an operating system for self-management within organisations. Most people when they first hear of Holacracy think of it as “oh, it’s an approach to having no managers” which is somewhat true, but it is a discredit to the power of what it is.

When organisations shift to the Holacracy constitution, or set of rules, they are signalling a very strong commitment to change. The first step is sub ceding power to the constitution. Managers aren’t fired, per se, but the role of a manager no longer exists. The necessary functions of what a manager does are re-established by the people in the organisation - this could mean that the old role is split into five new roles. The same person may be doing all five of the new roles, or it may go to any number of people.

When people say Agile is an approach to inspect and adapt the development of a product, I liken Holacracy as an approach to inspect and adapt the roles and responsibilities of an organisation.

Like Agile, which has ceremonies around inspection and adaption, Holacracy has these too - called Governance Meetings. It is through the governance meetings that new roles are created, responsibilities and expectations are changed and roles are removed. The governance meetings is clinically facilitated, more so than an Agile ceremony is, so that very specific tensions are dealt with one at a time. This could mean that a single role could change multiple times in the same meeting.

Some of the really clear benefits of such an approach are:

  • Strong empowerment of your own role and accountabilities

  • Fast adaptation of accountabilities when tensions arise

  • Clear accountabilities on decision authority and policies

  • No more time spent consensus building or getting buy-in for change

As a coach, I would say a significant portion of my time is spent trying to improve empowerment, accountability, lower decision authority and build consensus for change - Holacracy would gladly negate a lot of my day to day activities.

InfoQ: Your talk at Agile Indonesia 2017 will be on agile ceremonies being 5% of the effort. What can people expect to get from this talk?

Troughton: As a community we focus on a lot of uplifting capabilities to do Sprint Planning, Daily Scrums, Retrospectives and Showcases or Demos. Whilst these are important to delivering a product they are not the complete system that teams are working within.

From a systems thinking perspective Scrum works for a while as you replace your existing heavily bureaucratic processes with a lightweight, simple approach. Over time, however, the organisation begins to re-impose policies and constraints. The challenge with a successful Agile implementation is not to get the team doing Agile or Scrum, the challenge is to reform the policies and constraints in the system faster than the system can re-impose itself.

My talk is about how you can focus on system transformation in parallel to Agile transformation.

InfoQ: Thanks for the clear insights, Renee!

To learn more about Troughton, see her profile or come join her talk at Agile Indonesia.

 

Rate this Article

Adoption
Style

BT