Agile2017 Recap – Day 2

The morning got off to a great start by having breakfast with my professional idol, Johanna Rothman. We enjoyed the conference breakfast and caught up with what’s the latest in our lives. One of the highlights of the conference so far for sure! I really appreciated her spending some time with me.

Creating Leadership and Engagement at Every Level

This morning’s keynote was Creating Leadership and Engagement at Every Level by David Marquet, and wow, it was a good one. Definitely, check out the video, and I’ll hit the highlights here. The slides can also be found here.

David’s keynote was a story of him taking command over the USS Santa Fe, one of the poorest performing submarine teams in the Navy at the time, and he focused on:

• Converting an attitude of “just following a command” to a “thinking” one.
• The importance of language and mindsets.
• The distinction between Blue Work (thinking and making decisions) and Red Work (process driven, with the goal of reducing variabilities in the system).
• The balance of doing work and encouraging thinking

He titled his talk “I see Red people” – think of workers in the industrial revolution (his example was of clock makers). Their goal is to make the same clock over and over again each day. The goal is production, not thinking.

For so long, the expectation was for the boss to be infallible and know all the answers; this behavior continued the “Red” mindset because bosses needed to constantly tell people what to do. There was a performance mindset (Red) vs. a growth mindset (Blue).

David then tells the story about how being a Captain in the Navy, one needs to learn a boat inside and out. So for his next assignment, he spent weeks learning his new boat. However, at the last moment, he was re-assigned to the Santa Fe, one of the newest boats in the Navy and a class of boat that he was not familiar with nor did he have time to learn.

His presentation was fun because he included taking us on a “tour of the boat” to get us familiar with living and working on a submarine.

He included stories about how he would ask one of his team members “what does this button do?” His team members knew that he wasn’t up-to-speed on the boat, so they took his question as curiosity vs. a test of their knowledge. When one of his team members didn’t know what a button was, the team member honestly answered “I don’t know,” and David responded by being supportive vs. command and control-style, and the respect that his team he for him went up.

It can be scary and liberating to give up control:

Then he told a story about when the team was going through an exercise, he asked a team member to do something. The team member followed the order, but when the resulting outcome didn’t happen (in this case it was how to configure the engines), someone explained that the setting wasn’t available in that class of ship. When David asked the team member why he proceeded even though the order wasn’t technically possible with the ship, the team member replied, “You told me to.”

He gathered his men and began to go down the path of people being more proactive, that they need to speak up and tell him. Someone said, “I think the problem is you,” which caused David to realized that he needed to change his behavior and let the team lean in, and he gave up giving orders. He was clear that the team has to lean forward in order for this to work.

He didn’t use the word empowered, he just said, “lean in, and if I don’t stop you, continue to proceed.” The mentality that “it’s going to happen unless you stop me.”

He spoke about gradually building this into the organization, e.g. if it starts out all Red work, then move to “tell me what you intend to do and when,” then we need to build checks into the system to allow for decision making and for team members to determine that “it’s the right thing to do” and take deliberate action.

This approach allows for Blue work to be injected further down into the organization. Creating a “thinking” vs. “just doing” mindset. Are we “doing” or are we “deciding”?

He saw huge improvements in morale, and everyone re-upped for the following session. Things he learned was that early on, he gave his team too much power and control and that it needs to be bounded with competence and clarity. Fear is also the largest distractor – especially when it comes to “thinking” work. With cognitive work, stress makes it harder to solve the problem.

As a leader, we give up the ability to affect things, and we can’t make up preparing the team. All the drills that were done in the Navy were to prepare team members to handle various situations appropriately and execute without being told what to do.

Then he went into the various languages of Red vs. Blue work:

• Red: “Get ‘er done,” “All Hands Mtg (hands are the least important part of software development),” “Does that make sense?”, “You know?”, which creates a bunch of bobbleheads, “Build Consensus,” “Let’s discuss and have a vote,” “Are you sure?”
• Blue: “How can we get better?”, “What am I missing?”, “Who sees it differently?”, “Let’s vote first and then hear from the outliers,” “How sure are you?”

We need to front load the learning and provide team members with a way to come out of the Red, e.g. like the stop cord at Toyota. He then played a clip of the Oscar blunder where Warren Beatty and Faye Dunnaway announced the incorrect winner for Best Picture. Warren realized that something was wrong, but had no way to get out of the situation. He then reverted to a “Red” place and gave the card to Faye, which was technically his only job and expectation – he was “in the clear,” but the outcome was a disaster.

David ended with the sage advice that “if you don’t have a little trepidation as a leader, you’re not growing your team,” and also the warning that early in life, we’re conditioned to learn, and later on, we’re conditioned to learn. We need to continue to push ourselves to continue learning.

After some coffee at the break and saying hi to friends, it was time for the next session.

The Leadership Circle: An Agile Framework for Leadership Development

Peter Green and Mike O’Conner lead a workshop that introduced participants to the Leadership Circle. After a strong opening that describes why it’s important and how it connects to agile development, we got into the meat of what it meant.

The Leadership Circle focuses on traits that demonstrate either a 1) Reactive approach or a 2) Creative approach to leadership. Focusing on the problem usually leads to Reactive leadership and focusing on outcomes creates Creative approaches. It’s all about how we respond to stimulus, and it’s important to know that the Reactive approach doesn’t mean it’s all “bad.” Reactive styles, however, may be causing us to get in our own way.

The circle encompasses Relationship -> Task on the X-Axis and Reactive -> Creative. The quadrants are 1) Relationship Creative, 2) Task Creative, 3) Task Reactive and 4) Relationship Reactive.

Then they covered the three predominant styles of Reactive Leadership:

1. Complying – where we’re not paying attention; we’re focused on harmony, playing small, pleasing. Your needs are more important than mine – “go along to get along.” The intention is the heart.
2. Protecting – creating distance for protection, being critical, arrogance, not caring. Intellect is the intention – “I can see what’s wrong, but I’m doing it to make myself feel safe, not for the benefit of the group.”
3. Controlling – Autocratic, ambition, driven and perfect. The intention is muscle. Ambition can override overall goal – need to get things “just so.” Force of will.

Again, these aren’t bad, but they can override our actions and cause us to be less innovated and creative.

By doing assessments like these, they can help us see blindspots, for example, there are groups where everyone is Complying or all Protecting, and it’s also important to remember that some of these behaviors and traits are contextual – someone can be Controlling at work and Complying at home.

My big take away is that “reacting is exhausting.” There were a number of moments that people shared in the group that once they released their Reactive tendencies, they felt less stress and more energy. This resonated with me personally a lot and gave me a lot to think about (Wait, am I reacting to this information…???? What do I do now???)

In the Creative space, we’re playing to win vs. the Reactive space where we’re playing not to lose. This also speaks to integrity, which they defined as “are we working in alignment with those things that we care about?”

Or, another way to look at Creative vs. Reactive is Creative is “in service of us and the outcome we’re trying to create,” where Reactive is “in service of me.” It’s inside out vs. outside in.

They also mention that leaders will be “given credit for good intentions.” However, Reactive tendencies come with high physical and mental costs.

Leaders who had the greatest leadership effectiveness, showed high scores in the 1) Fosters Team Play, 2) Purposeful and Visionary, 3) Collaborator and 4) Mentoring and Developing.

The relationship to Creative Competencies and Reactive Tendencies was also interesting:

It was a great session with a lot of thought-provoking content, and I’m definitely thinking about my Reactive tendencies.

Next up was a lunch break, so I took some time to recharge out by the pool and garden. It was nice to have a break to be outside and catch up on a few things back at the office.

After lunch it was time for the third session of the day:

The Agile PMO: Six Things You Need to Nail with Joshua Arnold

I was really excited about this session because I remember reviewing it as a track reviewer, and Joshua Arnold didn’t disappoint.

He got the crowd going with an exercise to shout out what a PMO means to them, and there were responses like “controlling” and “cost, schedule, performance.” He reinforced that there is no one type of PMO and that the PMO is a good mirror to the organization as a whole.

Before he went into the antipatterns, he described the cobra effect for those who weren’t familiar. In India, there were places that were over-run with cobras, and in an attempt to cut down on the cobra population, the government put a bounty on cobras that were killed and brought in. Over time, people realized they could turn this into a business and started to raise cobras solely for the purpose of killing them and collecting the bounty. The government figured this out and shut down the problem – what happened then? The people who were raising the cobras unleashed them into the wild because they no longer had value and the wild cobra issue became 1000x worse.

It’s an example of how good intentions can create untended consequences.

In a software development organization, this can look happen in cases were there are schedule delays and the focus is on getting more accruate estimates; maybe KPIs on tracking the actual vs. planned difference are instituted, maybe people’s bonus is tied to minimizing that difference. Sounds good in theory, right? Well, the untended consequence is that there’s more upfront analysis, padded estimates, more contingency and fear of the consequences. Combine that with Parkinson’s Law, which states that work expands to fill the time available, and you have delayed value getting to the market.

He then shared six anti-patterns and proposed alternatives:

1. Reliance on Up Front Planning
   1. This reinforces sticking to the plan, which is another anti-pattern because plans need to adapt.
   2. As Mike Tyson once said, “Everyone has a plan until they get punched in the face.”
   3. Instead of using Hours, Days and People, use Outcomes and Outputs to measure progress. It’s like using the fuel gauge to see how far we’ve driven.
   4. Change the language from planning to forecasting based on current run-rate; use confidence levels.
2.  Playing Tetris with Individual Resources
   1. Team members are not parts of a car, they can’t just be swapped out.
   2. Teams need time to go through the learning curve and don’t mistake the amount of team that it takes for a team to learn 1) Tech and Tools, 2) Team Dynamics and 3) the Problem Space.
   3. The focus needs to be on growing teams, and teams should be the lowest form of measurement a PMO deals with.
   4. Stop “Teamacide” at the end of the project; or when consultants just walk out the door with all the knowledge in their heads.
   5. Focus on growing great teams; take the problem to the team, not the individuals to the problems.
3. Pushing Work to the System
   1. Needs to be a pull vs. push
   2. PMO can’t predict at the portfolio level
   3. Instead, look at Cycle Times, Capacity to prevent a “denial of service attack” on the team when too much work is pushed to the team that they don’t have the capacity to handle.
4. Treating Requirements Like Orders
   1. Customers (the “Business”) don’t always know best. Instead of requirements, think in Experiments that need to be proven or unproven.
   2. PMO can help by focusing on speeding up the Build -> Measure -> Learn cycle/feedback loop.
   3. Also, ask the question, when was the last time we removed a feature?
5. Treating everything like a project
   1. A project is defined with a beginning and an end, need to be on time and on a budget.
   2. The PMO can help shift this mindset that not everything is a project because teams will struggle with this.
   3. Instead of projects, think of them as initiatives.
   4. This is also where some creative things can happen with flexible funding models and continuous integration.
6. Using Fake Deadlines to Drive Urgency
   1. Instead, use Cost of Delay (CoD). The Cost of Delay is the impact of time on outcomes, which can sometimes differ by orders of magnitude.
   2. What would it be worth to us if we had it a month earlier? (There’s your answer to what happens if there’s a month delay)
   3. CoD helps communicate the urgency based on trade-offs and helps the team prioritize. It helps change the conversation – for example, we’re losing $1k/week or $1MM/week.
   4. Also, need to remember that arrival time for some items with a high cost of delay is random. Planning needs to be flexible in order to accommodate these random arrivals.

Below are some of the slides for the above points:

All in all, great session, and I always love sitting in a room with fellow PMO folks to hear what they are doing, what they aren’t doing and how information like this resonates with them.

After another quick break (and another coffee), it was time to head to the final session of the day.

Dealing with Distributed Teams with Samantha Laing and Karen Greaves

This was one that my team asked me to attend to bring back strategies for them. Sam and Karen from Growing Agile did a great job keeping the energy high in the room. They opened with the Conference Call in real life sketch video before jumping into how to make working with remote teams easier.

First, they broke the various types of remote team members into three groups:

1. Same Timezone
2. Partial Timezone
3. No Overlap in Timezone

They also defined “co-located” as being able to see each other’s faces in person, not just in the same large room or in the same office building. 

They gave the following recommendations for the various types:

1. For the Same Time Zone, use synchronous communication (Slack, Zoom, Skype, etc) to get that instant feedback.
2. For Partial/Much Overlap, stop struggling with trying to coordinate a stand. The time together is better used to create shared understanding, e.g. vision, strategy, sprint planning. Use asynchronous for everything else – don’t waste precious time together for things can be covered in other channels. Another option is to create sub-teams that work in the same time zone.
3. For No Overlap, they recommended to really try to avoid doing it. If it’s necessary, tactics include video recordings stand for one group of people in one time zone, and then that’s the first thing the team in the other time zone reviews when they arrive in the office. Or, have a rotating assignment for a team member to work in the “other” time zone for a period of time.

It’s important that the burden of attending off-hour meetings, calls, etc is shared across the team. Don’t always have it at a time that inconveniences one party because it reinforces the “us vs. them” mentality.

Tips for distributed meetings:

1. Use Good Tech (software and hardware)
2. Working Agreements (ensure people will be able to pay 100% attention, well facilitated and something called “bottom lining” where only the bottom line is shared, not the whole story).
3. Rules for Talking Over (does the Facilitator break the tie, or do the parties agree?)
4. Disaster Plan (if one channel fails, what is the back-up? If a member drops off, do we continue or stop?)
5. Publish connection information is an easy to find place for team members.
6. Get comfortable with silence – humans don’t like the sound of silence, and it’s 10 times worse on the phone. Without a pause, people will talk over each other. Some tactics include 1) Wait 10 seconds before responding, 2) Get the group comfortable with pausing.
7. Good voice is better than bad video – try to have everyone on voice or everyone on video. Also, on voice, it’s been found that people are more likely to be vulnerable because they don’t see the reactions of other people.
8. Pay attention to countries with slower bandwidth, they might not be able to support video. Zoom does a great thing where it will buffer the conversation to “catch someone up” if they experience a periodic slow connection.
9. Try to have everyone have the same experience – everyone dial in (even if they’re sitting next to each other), ensure that you figure out what everyone’s experience will be based on type of device (e.g. maybe someone won’t be able to see the chat box while on a screen share) and be fair.
10. Prepare – facilitation is even more important for remote meetings. Investigate things and ideas that can help people engage more. Bad meetings were fixed in person by bringing more discipline. Plan in breaks, just ask that your remote attendees keep things running. Be creative in how you can facilitate.

Then there was an exercise where we worked with our table mates to come up with other ideas to make remote meeting facilitation easier, and below are highlights from the entire room during readouts:

1. Sketchboard.io – virtual whiteboard
2. Working Agreements
3. Holidays
4. Do some type of cultural sharing, e.g. a lunch/dinner/breakfast where a person shares the details of a meal that’s important to their culture.
5. For Scrum Masters, have 1:1 sessions with all team members; bring inspecting and adapting to all meetings and touchpoints, including personal retrospectives.
6. Other Tools included: Scrumbler.ca, Thingz, GroupMap (MindMap) and Retrium
7. The Grove Facilitation Model is also a good tool.
8. One group shared that they created dolls for remote team members so that they were physically present in the room.
9. Happiness Apps before Stands to get the pulse of the team.
10. Second Life (one person created an island for the team)
11. Schedule “chats” – meetings where there is no telephone, only a text chat session. This helps with groups who have a variety of languages spoken and written English may be better than spoken.
12. Communicate in the same language; don’t create silos by some team members speaking in another language.

Wow, that was intense! Looking forward to doing it again tomorrow!