When it comes to agile at scale, the challenge is how to coordinate multiple teams delivering output at the same time. You need to determine "what are the things that are shared, and what are the things that consume the shared stuff". At scale the performance of the team isn't as important as the performance of the corporation as a whole. Focus less on team velocity rather focus on cycle time at the program and portfolio level.
Dennis and Mike told us scaling is hard, because books tell us what it looks like but not how we get there safely. You have to align the team, management and executive perspectives to create the safety for an agile transformation. If you are in a place where you don't have trust in the team it's probably because they haven't delivered because of the system around them. Overloaded teams will find it safer to say 'yes' and fail, than to say 'no' to more work.
When it comes to starting an agile transformation start by understanding the business drivers of the organisation, define the operational framework, introduce change incrementally, measure improvement and tie it back to the business drivers. Most people in the face of good data won't make irrational decisions. Cultural shift is important but it takes time and requires safety, you have to create the operational model first. "You are not going to kumbaya yourself into an agile enterprise!"
Everything touches everything. If we are trying to change one thing it always impacts another. How does language play into the success of change? How do people talk about change in your organisation? Do they use words like: change management, drive change, create a burning platform, evangelize, cut the dead wood, clean house, roll out change, overcome resistance. When we use language it's not just the words that are active in our brains. 98% of our thinking happens at an unconscious level.
We are awash in metaphor everyday. It is pervasive, everywhere we go, in every conversation we have. When we use metaphor it kicks off a process in our heads, a frame, with roles and scenarios, therefore we need to be careful and intentional about the language we use. The way we talk about change, for the most part, masks the complexity of what we are doing. When we use metaphor and kick off that script, it makes it more difficult to engage. Every change is different . You have to start where you are and find your own road. Every time we have a gap between our values and actions, cynicism and fear fills the gap.
There is always an emotional element to change. Denying the emotion keeps it in play. You don't need to fix it you just need to acknowledge it. People eventually adjust to change and reach a new status quo. The best time to make a change is when folks have successfully integrated the last change. The worst time is when things are in a state of chaos.
When we change the structure of an organisation we impact identity, status and affiliation creating resistance. When there is resistance we push hard and the resisters push back and don't feel heard.
People resist for a number of reasons, they don't trust the person behind the change or they might think its a really stupid idea. When people don't feel like they are being heard they hold on harder. The reasons people may resist change are mostly pretty legitimate - to save the things they value.
Changing organisations changes people, impacting identity, status and affiliation. You need to provide support, empathy and time to learn. If we want to succeed in change it requires trust. Trust must be given (not earned). Trust is not binary, it is always contextual and bounded. Trust is one of the reasons that change fails. People don't resist change they resist coercion. We need to connect. If we don't connect we don't have trust.
Esther recommends the following reading material on this topic:
Metaphors We Live Byby George Lakoff & Mark Johnson
Facilitating Organization Change: Lessons from Complexity Scienceby Edwin E. Olson & Glenda H. Eoyang
Satir Change Model
Slow Ideas by Atul Gawande
Organised by +Lynn Winterboer, the Agile Business Intelligence & Data Warehousing open space was an opportunity to talk with "esteemed authors" +Scott Ambler and +Ken Collier as well as a number of practitioners about the challenges specific to using agile in the data domain. The morning session was so successful it was followed up by "Lean Cocktails" at the end of the day.
Held at Nashville's Wild Horse Saloon the conference party was unlike any conference party I had been to before. Everyone was given a cowboy hat and bandana on the way in and it was not long at all before the line dancing started! While I chose not to line dance myself, +mia horrigan and I enjoyed watching +Matthew Hodgson join in the fun.
Together with Christopher, Judith walked us through the responsibility process and how we respond to problems; moving from blame, to justify, to shame, to obligation. This is how we have been conditioned. If you are not familiar with the responsibility process, which I must admit I wasn't, here is the link to a one hour video overview.
The main premise of Judith's presentation was that questions empower. When you ask questions you are engaging someone, asking them to be creative, and honouring their intellect. When you give advice you take choice away from your teams so they don't feel responsibility. Technical people are used to being the smartest people in the room, they can be a little socially awkward and not wanting to draw attention to themselves or ask questions. Christopher says, "We need to create the culture where we are able to be vulnerable". This of course struck a cord with me given my last blog post before Agile 2013 was about "Leading Through Vulnerability".
"The cool thing about responsibility is you can't make anyone take it, all you can do is offer it and allow it" - Christopher Avery
|Scketchnotes by +Michele Ide-Smith|
|Agile Coaching Competency Framework (http://www.agilecoachinginstitute.com/agile-coaching-resources/)|
Lyssa showed a handful of videos of coaches she had worked with talking about how they had used the Agile Coaching Competency Framework which can be found here. I have posted my favourite of these by +Erin Beierwaltes below.
|Jean Tabaka's recommended reading list for Enterprise Agility|
The first topic, Flow, was introduced by Jean Tabaka. Jean said, "I don't think agile is sufficient on its own to deliver value to the customer,... I don't think executives should be talking about story points or velocity,... Good executives pay attention to "intraprenuers". "The flow of value Agile" is the best way to learn quickly. We have to take a long view of the flow of value, start earlier than the team and look beyond effective deployment to the hands of the customer. In value stream flow we watch: customer, cadence, capacity, clogs, cost and collaboration.
Collaboration across all different parties is essential. You are not going to be enterprise level agile unless you are collaborating with upstream and downstream process. Collaboration doesn't happen on its own, you have to help it. For Enterprise Agility we need to move from a language of cross functional to cross departmental. Hendrik Esser commented that "you need to look at the whole product life cycle" and Esther Derby noted, "The way accounting works and the way people are rewarded is keeping things the way it is". Esther also mentioned that the Agile Alliance is sponsoring an initiative to look at an agile accounting approach.
Hendrik covered the second topic, Collaboration and Decision Making. Collaboration is about abandoning contract thinking between different parts of one enterprise. Esther echoed this, commenting that "We need to adjust our plans so we can satisfy our customer rather than "you missed the date you won't get your bonus". We need to visualise uncertainty if we want to embrace change for example provide a range of possibly delivery dates rather than specific milestone date. Jean gave the analogy of Neo choosing between the red pill and the blue pill in The Matrix. "People willing to embrace a sense of uncertainty are taking the red pill". Enterprise agility requires us to have a new way of measuring success and failure, different metrics other than points and velocity. In Jean's view, the only useful metric is one the team asks for to help itself understand how it's doing. Esther pointed out that this holds true not only for development teams. Hendrik added at Ericsson "We measure our performance not our people".
The third topic was Eco-system, lead by Esther. If you keep replacing the individuals and get the same results it is a clear indication there is a system problem. Trying to "idiot proof" through policy or procedure almost guarantees you will get "idiotic behaviour". "I find job descriptions often get in the way of people collaborating", said Esther. We have a legacy of thinking of organisations as machines. This is not the type of ecosystem that enables flow, adaptability and responding to change. Trust begets transparency and transparency begets trust. Without this, decision making and flow breaks down. Trust is contextual not binary, and to get trust at an ecosystem level you have to give trust. What people don't know they fill in with their own fears.
The subject of building trust, brought some of +Brene Brown's material from Daring Greatly to mind for Jean: "If you have shame and blame there is no possibility of innovation We are asking individuals to be vulnerable, to enable this the organisation needs to extend its vulnerability". Esther closed out this section with the following messages: "You need to start where you are. Trust grows incrementally. Once you start seeing systems, blame goes away. It's very powerful!"
I know you are thinking, wow, she made it to Nashville and saw some live music, sorry to disappoint but the Music City Concert Tour was the name of the conference event, held in the exhibit hall, Wednesday evening. While I didn't see or hear any country music stars, I did get a free flashing guitar pin - which made brilliant "gifts" for my leadership team when I got home.
As with all the conference social events, it was another great opportunity to meet people, such as Hendrik Esser, and catch up with people I had met in Boulder earlier this year, including +Ronica Roth, +Drew Jemilo and +Jennifer Fawcett
After grabbing some dinner at one of the hotel restaurants, I headed to a gathering hosted by the guys from Leading Agile, +Dennis Stevens and +Mike Cottmeyer, where I scored a great (free) t-shirt. Thanks guys!
When Jean Tabaka ran her Scaling Collaboration workshop with my team in June, she commented on how open the team was to the experience and asked us how we went about creating an environment where traditionally introverted software engineers, from a diverse range of cultures and backgrounds, were so willing to participate in team activities. From my perspective there were lots of contributing factors eg. the Hakas, Bubble Ups, lean coffee management meetings etc. but it all began with the weekly practice of "walk the walls".
"Walk the walls" came about after I got sick of listening to my coach, carry on about what a waste of time my program status meetings were. At this time, I worked in "the business" and as program sponsor, I felt it was my duty to sit down with the program manager once a week to receive an update on the status of the program. My coach, on the other hand, was convinced that there was a deeply embedded culture of fear that was preventing the delivery teams from telling the real story. He was adamant if I spent more time with the teams I would be able to see this for myself.
I remember being mildly insulted by the insinuation that my relationships with the teams weren't strong enough for them to feel comfortable enough to tell me about their challenges, but eventually I got over myself and blocked out some time in my calendar to visit them. Even though I was not bombarded with new information in my first visit, after a gentle nudge from my coach, I made "walk the walls" a reoccurring appointment in my calendar.
Eventually, I built rapport with the teams. They started to give me problems to solve for them, and it was my role to earn their trust by actioning blockers. Later I learnt my coaches motivation in getting me to walk the walls, was to help the team see I was “human”, he said, "I want them to see the Em I see, when we are hanging out debating the issues in your office."
While "walk the walls" marked the beginning of our cultural change journey, the tipping point was about 6 months later, when we launched the EDW Agile Release Train. In our first Lite PI Planning/iteration kick-off event (aka Unity Day) my new team was introduced to The Ball Point Game. Armed with about 100 tennis balls, our coach split us all up into groups and ran the activity. Much to everyone's delight, hand-eye coordination is not one of my strengths, so I spent most of the game dropping tennis balls, laughing nervously and turning very red. I think it would be fair to say I was most embarrassed.
In the next sprint, we also started with a team activity. This time everyone with "manager" in their title to go to one corner of the room and pair up and appoint one person as the manager and the other as the worker. Everyone else was to stand between the managers and the opposite corner of the room, creating a maze we would need to navigate our way through. I paired with one of the scrum masters and we agree he would play manager. I don't think I will ever forget the painful process of being directed through the maze by my manager/scrum master - forward, backwards, stop, left, right. It was not long before all the other pairs had completed the task and there were just shy of 100 people laughing at me trying to complete the maze. Yet another horribly embarrassing morning for me.
As uncomfortable as those events were for me, with my 20-20 hindsight I can see how these moments help me build such an open and trusting team. You see vulnerability is the foundation of trust and trust is the foundation of great teams.
These days, vulnerability is something I am trying to foster right across my team. Just last week, some of my team were on facilitation training and the question of what good facilitation looks like was tabled. One of the working groups suggested a good facilitator creates safety, which led to a discussion on how to go about creating safety. In response to this question, I found myself talking to the team about the power of vulnerability. I reminded them of how the Hakas and other Unity Day antics have brought the team closer together and explained that part of my motivation in inviting our stakeholders to participate in Unity Day was to begin the process of building trust through transparency and vulnerability.
While I know our culture isn't perfect, I am immensely proud of my team and their willingness to be vulnerable in front of each other and our colleagues from across the organisation. No matter where it started – “walking the walls” or “agile learning activities” - the openness of all members of the EDW Release Train makes it a truly special place to work.
As agile leaders, we ask our teams to be transparent and consequentially vulnerable every day. We expect this of them, but what do we expect from ourselves? As I contemplate this, I am reminded of a Brené Brown quote I saw recently:
Our teams want to trust us, they are looking for vulnerability, proof we are human. It is incumbent on us as leaders to take the first step, show our vulnerability to our teams and give them the safety to reciprocate. I may not have recognised it as what I was doing at the time, but looking back I can certainly see the power of it and the need for us to challenge ourselves as leaders to inspire vulnerability by example.
Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.