BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage Articles Renee Troughton on Agile Australia, Pragmatic Scaling and Non-violent Communication

Renee Troughton on Agile Australia, Pragmatic Scaling and Non-violent Communication

At the recent Agile Australia conference InfoQ interviewed Renee Troughton about the theme of the conference, her experiences with large scale agile adoption and using non-violent communication in coaching.

InfoQ: We are at Agile Australia talking to Renee Troughton today. Renee has got a lot of different hats that she wears, she is one of the three people who run the Agile Revolution podcast, she is the director of an organization called Unbound DNA and is part of the team behind the “Who is Agile Australia and New Zeeland” publication. And in her day job is a coach for a large financial institution. Renee did I get that all right?

Renee:  Yes, and I am also a stream adviser here at Agile Australia as well for the approaches and practices stream. I have lots of spare time obviously.

InfoQ: Let’s have a quick chat about Agile Australia. What was the theme of the conference this year and how is it gone?

Renee: The theme is “embracing disruption” which I think is quite indicative of where we are culturally in the world, changes happening at an extremely fast pace. There’s no longer an opportunity to hide, a lot of us are working in the digital channel space which is extremely fast pace. You got no choice but to embrace the magnitude of change that is happening and to try and keep up with it and try to keep ahead of the curve in an organization, we also find that people need to change their processes and adapt that quite quickly, because it’s the ones who are quite agile, in the true sense of the word, who are able to be disruptive faster.

InfoQ: So that is the theme of the conference, what are for you some of the highlights of these two days?

Renee: Rachel Botsman talk in particular was a lot of fun. Impact Mapping was really good, gathering extra techniques is always very helpful. Having a look at what Zapos has been doing within holacracy has been a lot of fun, I am very keen to look at other methods out there, that I guess would be claimed as synergistic towards Agile, such as holacracy and Vanguard this afternoon with David Joyce.

InfoQ: As one of the organizers how do you feel the conference is going?

Renee: It’s awesome! I think interestingly people talk about how the conference has changed and it’s certainly diverged away from Agile 1.0.1 which is interesting when you take into account that a huge percent of the people here are brand new to the conference, not necessarily brand new to Agile. I was a little frustrated within the Australian Agile community a couple of years ago that we were always focusing on Agile 1.0.1 in conferences or in content that we were trying to look at, and approached Rachel at that point in time and said “Look, I really think we need to get a lot more of this what I call edgy Agile practices inside of the conference”, so the last two years it’s been my goal to uplift the Agile community capability and give some awareness about all these methods that are out there. We weren’t even talking about Kanban a couple of years ago, so getting Kanban awareness out there, getting portfolio Kanban awareness out there, Lean Startup, all sorts of things which are edgy and synergistic towards Agile and really help us in many ways. Rather than focusing just on one method, it’s about picking and choosing from a toolbox and what’s right for the circumstance and the organization that you are in today.

InfoQ: Let’s talk about scaling, growing; Agile is by a number of different measures, it’s the most prevalent way of building software today. But are we scaling well? Are we taking that into our organizations and does it help to do the wrong thing better? How do we make sure we do the right thing?

Renee: I think that ensuring that you are doing the right work comes to good portfolio management at a scaling level and I think when people talk about scaling there is different elements of scaling. A lot of the work that I do on a day to day basis is a single product that is out in the market place, that is heavily used by over two million people, and I am working with ten teams at once coaching over a hundred people and they are all working on one platform, they are all working on the one product. So when you need to invest in a huge number of features for a huge number of users, you got no option but to start to employ some scaling techniques.

InfoQ: You mean you can’t just have a big Scrum?

Renee: No, you can’t have a hundred person Scrum, which is interesting because when I started we had around four teams and we scaled up about six months to ten and there are plans to get another four in as well. Interestingly, while I have been trying to help transform in an Agile sense, I have also been handling all sorts of scaling issues that I have never ever had to deal with so we keep onboarding people and so we need to have better on boarding processes and the concept of fixed teams in particular becomes very interesting when you scale a number of people. Because you can’t just simply on board ten people at once as an example and go “Here, go at this platform, that everyone else is already working on”. So looking at approaches of “Okay, we need to put these people into a team” and then how do we split teams? Which breaks the whole “Keep the team together” model, which is optimal for portfolio Kanban, so we have had to employ some really interesting strategies towards how we plan going forward when we know that we are going to do more teams; the approach that we are looking at is building the teams to around fourteen and then splitting into two teams of seven, at a particular point in time. And then choosing a different team to build up and then split it up, it’s like mitosis recipe for success.

InfoQ: I don’t see that in any of the books.

Renee: No, dealing with scaling up teams and scaling product at the same time is very rarely talked about, but interestingly Scrum of Scrums was originally around eight people and at our last count we now have twenty people at our Scrum of Scrums. Which a lot of people would be concerned about and it’s been worrying me a little while as a coach and I asked the question to the team “Is this still an effective meeting with twenty people?” We are getting through it in fifteen minutes, we are getting the questions answered and the risks raised that we need to get handled, at the end of the day it’s still a very functional Scrum, everyone that is there needs to know the information that is coming out of it, so sometimes it is about knowing when you can effectively brake the rules at scale. It’s not an ideal situation to have twenty people around one board, but it works.

InfoQ: Why does it work? What is the secret sauce in that particular case?

Renee: Discipline and a really great timer. In that particular context I’ve made sure that there is a very visible timer that is counting down and we just set it to fifteen minutes every single day and we start pretty much always on time so everyone knows that they need to be on time. We’ve got a very interesting board when we talk about managing the Scrum of Scrums. It’s divided into two segments, we got the Scrum of Scrums section on the left and the business Scrum section on the right and then we categorize new work. Work that bubbles up from the Scrum teams comes into new, it gets talked about in that Scrum of Scrums and then as we deal with those problems we put actions and owners against those we put them with a due date for that and update the particular card, and then we would also go through the ones that are due today. And then we do a round-robin where everyone talks about anything that they haven’t raised or which they should have raised. It’s sort of just like a fallback position at the end of the day. So why it’s effective is that everyone knows from a discipline prospective that that’s how we do it. And everyone knows the constraints that with twenty people around that you really have to be fast paced, you got to get it out there. The risk is that at the end of the day people don’t raise issues because they don’t feel like they’ve got the time, so it’s also about education to say “Look if we have to push the fifteen minutes because we’ve got a lot of issues bubbling up on this one particular day then we’ll do that”.

InfoQ: So, it’s knowing when and how to bend the rules. Any other advice for how to tackle some of those scaling issues? Because certainly we see this word “scaling” all over the place and what does it really mean?

Renee: Yes, so scaling ultimately to me means the ability to have multiple teams work on one purpose. And the one purpose in this particular instance would be a product. We release at least every quarter and in those releases we would have each team basically delivering something whatever they get into that release in that particular time box. So it’s about looking at dependencies across those teams about how we test, when everyone is releasing into the one product at the one time, it’s also about how do we improve continuously across all of those teams as well. So scaling to me is a whole different set of problems, it’s less about product development and it’s more around how you continuously improve at a strategic and tactical layer within teams.

InfoQ: So, your example of the Scrum of Scrums is twenty people, is one that somehow seams to be working. Any other advice?

Renee: Yes, so interestingly I was the shepherd for Sandy on the portfolio Kanban talk inside of Agile Australia. We had a number of discussions, we were really comparing notes about how we both do portfolio Kanban, and the learnings that she had were very close to the learnings that we’ve also had. One key thing was around when we build the work and the teams, it was about insuring that the work was pulled by the teams, and not pushed onto the teams. We have a very clear backlog of work that has been approved form a business case prospective and it’s prioritized rigorously by our EM product owner, or our EGM product owner potentially so we have regular portfolio meetings, once a month at a very senior layer across this board about prioritization and determining what’s going to move in or out of scope so it’s being quite flexible at that portfolio layer, but interestingly for that particular board previous from me joining it was more let’s keep pushing this on to this team, or something has happened so we are going to push another piece of work rather than look at the blocker and try to remove that. The other thing that we’ve learnt was that you can’t deliver – we call it an initiative, so it’s a big set of features – you can’t deliver an initiative and do inception for the next initiative at the same time. So, how do you “feed the beast” has been a big issue for us.

So one way in which we dealt with that was we now moved to a method of only once it goes into production and we are supporting it, only then we do inception on the next piece of work. Which raises a really interesting question, because management started to go “But my team is doing nothing”, they are having these workshops in this inception activity but when they are not in those workshops they are doing nothing, they are idle, what are they going to charge to? All these old school questions come up. And this is where we start to introduce things like “Well, we’ve got this lovely list of production support issues, that we need to potentially address, or we know that we’ve got this technical debt, or we know we’ve got this continuous improvement that we need to do”. So, we’ve got a good backup set of backlogs to potentially pull work from in the times where we’ve got a little bit of slack, to enable the teams to still be productive, but ensure that our focus is still on that feature delivery.

InfoQ: Interesting! We are at Agile Australia, you’ve got a lot of experience locally and I know that you are well connected globally. What’s different in Australia? How is the adoption of all things Agile here versus what you see elsewhere in the world?

Renee: I think Australians are interestingly a little bit more willing to experiment with their methods, so when we are talking about disruptive innovation and disruptive processes what we are doing here is that we are blending maybe a bit more quicker than other areas of the world. Probably could be due to the fact that we have less Scrum certified trainers, not quite sure, also part of it could be some of the influence that Thoughtworks  has on the community or the Agile Academy  has on the community or that Software Education  has as well.

It’s taking the holistic approach that we can use both Scrum and Kanban and look at some of the Lean Startup elements and have a look at XP and have a look at SAFe and really blend that all together to have a very useful framework for us. The challenge is there is no book out there that does that. So having a coach is quite critical to be able to know what is appropriate to pick and choose for the organization that you have. And we still have difficulties I think in Australia in the number of coaches who are potentially capable of making some of these decisions and calls, we are certainly getting a lot better, but because we have a small community we maybe haven’t gone into the problems that I hear that America commonly has which is a lot of people who have become coaches after only a very short period of time. Part of that was due to demand in Australia, demand has been quite slow, and now it’s really starting to cross the chasm, so I would expect over the next couple of years we’ll see a lot of newbie coaches come through the ranks and consequently it might result in a bad implementation of Agile in the Australian on the short term before uplifts again.

InfoQ: Another area that I know you are interested in is that of non-violent communication. Tell us a little bit more about that.

Renee: Non-violent communication is better understood over in Europe, it’s a book by Marshall Rosenberg; non-violent communication can be quite useful in confrontational or heated conversations. I use it very rarely at work generally because the emotional intelligence of people that I am working with is quite high. Interestingly I use it a lot more at home with my children. It’s a language, it’s a format to phrase your needs and your feelings and your desires in a way that is less threatening and less emotive at the end of the day. So it’s trying to take the pain out of language that most of us use every single day. That’s quite a clear framework of “when you did” and then there is an observation that should be a very independent and impartial observation so things like, “when you yell” is a bad example of an observation, because “yell” is an interpretation. “So when you turned the oven off” there is no interpretation in that. “I feel” and then you expand with the feeling. In our human language we often misuse the feeling words very commonly. It has a good framework about what are true feelings so that you can express yourself better. And it’s really difficult because when you start doing it you realize “I’ve been using language really poorly” as you understand more about what true feelings are and then you go into “Because I am needing”, and you express your need.

And again there is a set of words that represent needs, so, a good example would be “I am needing connection”; so people who feel upset when you are in team settings for example can get frustrated and they close down, it’s because they are not being engaged in that conversation. Ultimately what they need is a connection. So I am feeling disengaged is actually not a feeling interestingly, because of that lack of connection and then the request is the next step in that so “Would you be willing to” and I actually have been deliberately using a lot of “Would you be willing to” language in my day to day coaching. And it’s made a really significant difference. So rather than “You could do this, you could do that” or “You should do this or you should do that” it’s about me giving you the choice and if they say no, it’s about me being completely happy with that decision. So when you say “Would you be willing to” you have to completely accept that person’s decision without any emotion. So where non-violent communication comes useful is inside workshops where there is people with different opinions, it’s about what are each of their feelings and needs, and then what strategy might someone employ in order to resolve that particular conflict.

InfoQ: So, is this a coaching skill or is it a skill that you distil down to the members of the team for instance?

Renee: There are organizations out there that have actually rolled out non-violent communication quite effectively with significant improvements where the outcome of meetings have been forty percent more effective and productive as an example, where it’s rolled out organizationally. So yes it’s a tool for coaching but it’s also an awesome tool for teams as well.

InfoQ:  Renee, some really great stuff thank you for taking the time to talk to us

Renee: Thank you.

About the Interviewee

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. The author of both ‘Agile Forest‘ and co-author of ‘Who is Agile Australia and New Zealand‘, she also contributes heavily to her blog at Agile Forest, is a co-chair of the Approaches and Practices stream at Agile Australia, co-chairs one of the worlds leading Agile Podcasts and regularly presents at both national and international conferences on Agile. Renee specialises in enterprise transformations, Kanban, scaled and non software development implementations of Agile.

Rate this Article

Adoption
Style

BT