Stealing Keyboards and Other Leadership Techniques
More evidence for the Secrets of Successful Cloud Foundry Adopters
Call it confirmation bias (it is), but at SpringOne Platform I couldn’t help but notice new examples of “The Secrets.” This growing list of “secrets” are patterns across companies digitally transforming using PCF. They surface as I listen to Pivotal’s customers describing their journeys, but they transcend vendor. Anyone leading a digital transformation journey can take note.
Here’s my observations from user talks at SpringOne Platform 2018, mapping back to these patterns.
1. Give teams space to change
This initially came to my attention as Pivotal customers highlighting the importance of doing the Pivotal Dojo. But it applies regardless of vendor. It’s really about making any change to a team. To start working in a new way, you have to stop working in an old way.
I often highlight this to executives and leaders. It’s often managers that fail to explicitly give their team permission to change. Unless you’re employing Bartleby the Scrivener, they need help saying “no” to their old work as you ask for the new. But the reality is that resistance to this change can come from all levels.
In Ryan Johnson’s talk, he described how the teams were reluctant to work in a new way. The Accenture Pivotal Business Group (APBG) in Columbus, Ohio was adopting agile and extreme programming practices, including pair programming. So, overnight, he took away half the monitors and keyboards to force the teams to pair. Now that team can complete tasks in hours which take other teams days to complete.
It’s an extreme example, but it speaks to the role of leadership in facilitating a new way of working.
2. Pick an application
In parenting, I *try* to practice a technique called “name it to tame it”. If you can help kids use words to describe their emotions, you move closer to a calm state. I’m starting to think it’s the same with applications — you need to be able to name the applications that you want to tame!
For example, I recently heard about a CIO that was excited about the capabilities of the platform. They mandated that their team get ten applications on PCF within a quarter, but they didn’t care which ones. Not surprisingly, the team didn’t achieve that goal. (Don’t worry, they have come around and made a lot of progress since)
In contrast, I liked the focus of George Loyer (@gloyer), Director of Technical Operations at Stubhub. He was specific about the progress made about their storefront application. And he highlighted three more applications — Search Events, Checkout, and Mobile Ticket Transfer — that are on the roadmap for modernization.
Another interesting from this list of applications on deck is the common need for experimentation. Experimentation requires an ability to iterate at high velocity. Otherwise, it’s risky and so it’s avoided.
Which brings me to a related topic. I’m getting more questions from folks about how to decide what runs in PAS versus PKS. After an enlightening talk with Josh McKenty earlier this year, I recommend folks think about their velocity needs when making this decision. Does the business want to be able to experiment around this application? If yes, then you want to choose an abstraction that supports higher velocity through higher developer productivity. If not, then a lower and slower abstraction may do just fine.
So, as we move to a multi-abstraction world, that focus — that ability to name the apps we want to tame — continues to be a key to success.
3. Make the new way to go viral among developers
Ongoing developer enablement seems to go overlooked and unfunded. Perhaps it’s the prevailing project-oriented mentality. Perhaps it’s the derth of leaders that adopt the growth-oriented mindset. Either way, many companies don’t fully realize the full return on their technology or consulting investments because they don’t include enablement.
I confess that I didn’t make the session that probably would have offered great ideas for enablement. I’m looking forward to the replay video of Tiffany Larsen of HCSC on teaching TDD to different learning styles. Not just because TDD supports the necessary assurance to release code more frequently. But because HCSC has been doing a lot of great work in their digital transformation, including developer enablement.
It’s also worth noting that Gartner recently published a recommendation to budget for tool and practice adoption when adopting DevOps. Leaders, take note.
4. Metrics and measuring
Evidence of value stream mapping abounds! In the spirit of “figure out how many tickets it takes to get something done and make the number go down”, George Loyer shared the reduction in tickets to get Stubhub’s applications into production.
Then, Greg Meyer (@greg_meyer93) at Cerner shared four value stream mapping use cases. Use cases ranged from restoring a development database to building a blue-green deployment environment. I enjoyed how his examples illustrated how granular these value maps can be. I also, of course, enjoyed seeing how recovering from a production node loss shrunk from 3 hours and 4 people to 15 minutes with no people.
Finally, there were plenty of great metrics shared. Highlights include zero hours planning security patches at Dick’s Sporting Goods via Jason Williams (@jwilliamspgh). Speaking of zero, Siew Choo Soh (@siewchoosoh) shared that DBS has had zero minutes of downtime on PCF for the last 2 years.
5. Don’t Launch with the Avengers
The flip side to not stacking the deck with heroes and super stars, is who you do put on your team. Diversity of skills and experience on these early teams is useful. It brings fresh ideas and perspectives to problem solving. So, how do you get a diversity of skills and experience onto your team?
Siew Choo Soh shared a recruiting practice that DBS has used for the last two years. She noted that this has brought in diverse candidates from outside of banking. These candidates would have been difficult for the bank to recruit through traditional methods. Check out the replay of her talk to hear about how they are iterating on their hackathon approach.
6. Invest in test automation
The corollary to investing in testing automation is that you have the tests. Who, when, and how are you going to write those tests? When you combine the need for tests to confidently make changes with a value-stream mapping exercise to identify and eliminate waste, you have a strong case for test-driven development (TDD).
Boeing’s Sophia Bright noted how TDD and other practices fit into the company’s stringent safety controls. They provide a framework for building checks into the software development process. And that helps the broader organization accept going faster.
DBS has done engagements with Pivotal Labs, learning various Agile and XP practices. But when asked about whether they were still practicing pair programming, Siew Choo said they leave that up to individual teams. TDD, however, is non-negotiable.
Another interesting observation about automation pipelines in general, was the cost of retrofitting. Not surprisingly, if you can, invest in pipelines from the beginning, you’re better off. But what Cory Jett (@coryjett)also noted in his talk, alongside William Marchlewski (@stlguitarist) at Mastercard, was the ongoing pipeline maintenance. Just like savings habits or eating your veggies, tending to your pipelines is an undeniably good habit.
7. Be bold
Sometimes bold feels crazy. For Darryl Smith and Alfred Brown, Site Reliability Engineers with the US Air Force, an order to deliver PCF in a remote location within 150 days seemed crazy at the time. But, along with Lt. Davis Gunter, they managed to contract, procure, hire, build, and ship in 148 days. At one point, they had to set up an IaaS environment in an air-gapped environment in 4 days. They were long days, but they did it.
These types of stretch goals can make people uncomfortable. Some leaders are uncomfortable with making others… uncomfortable. But, when done right, some temporary discomfort are part of the growth process.
The effort required to meet bold goals can be unsustainable, which needs to be kept in perspective. But when a team meets or beats a bold goal it can unite the team in new ways. It can also galvanize their commitment to the broader mission. And, of course, it can accelerate the teams progress by reaching a milestone quickly.
The flip side of setting bold, stretch goals for a team is practicing gratitude for the effort of the team. Alfred Brown put it best on stage when he said, “You have to celebrate the wins.”
***
Is that it? Seven secrets and we’re done? Not quite. I’ll be revealing the next couple of “secrets” at CF Summit in Basel, October 10–11. You’ll have to register here (and show up) to hear them first!
