I’m originally from central Pennsylvania, having grown up on a farm in Lancaster County. We were about an hour and a half from Philadelphia. And you couldn’t help but connect to the local Philly teams.
The Eagles are one of those teams that always seemed to struggle, yet the local fan base is incredibly loyal to them. Disgruntled, complaining, obnoxious, whiney, but still loyal. And I am one of those diehard Eagles fans.
Now I moved away from Pennsylvania in the 1980’s. But my heart is still with those sports teams. So, you can imagine how I felt when the Eagles won the 2017 Super Bowl.
Elated, surprised, justified, humbled, fulfilled are some of the feelings that came to me.
My first piece of advice is this:
DON’T DO IT!!!
Probably the worst possible setup for “team” is spreading them around the country or the world or the universe and expecting them to behave and deliver like a close, cohesive team.
My second bit of advice for those of you that blame it on “Management” and say you don’t have any say in the matter…is:
WRONG, YOU HAVE LOTS TO SAY IN SUSTAINING DISTRIBUTED TEAMS OR CREATING ANOTHER STRATEGY!!!
I hear this situation (excuse) all of the time. An organization has inherited distributed teams yet also wants to move to more agile approaches. They understand that these teams can be less than optimal, but are reluctant to do anything about it. That is but complain about it.
I recently read an article entitled Engineering Culture and Distributed Agile Teams that was published in InfoQ. In it, the editor called out the following strong themes or takeaways:
Key Takeaways
- Team structure reflects in product architecture
- Distributed teams can perform pair programming by using some remote pairing techniques and tools.
- Microservices influence a good distributed team structure
- Increase co-ordination within a team by encouraging T-shaped engineers
- DevOps tools and practices are valuable for Distributed Agile Teams
- Increase efficiency of Continuous Integration and automation testing in distributed teams by using cloud
While the article is titled and implies a focus on culture, it really focuses more on technical tactics or tooling as the key to distributed teams.
Years ago, I worked for a company called Micrognosis. I shared a little about the company in this post. As I recall, I worked there from the late 1980’s to 1996 or for about 10 years. Over my entire 35+ year career, it was my longest tenured job. And I did a lot of growing there, both in my role and in my self-learning.
When I left Micrognosis, I moved to North Carolina for a software leadership role at Bell & Howell Mail Processing. So not only did I change jobs, but I relocated my family as well. To say the change was a bit scary for me and my family is a bit of an understatement. But we moved and never really looked back.
I realized after about three months at Bell & Howell that I’d stayed in my Micrognosis job for a bit too long. That I’d developed some “blind spots” that I didn’t even know I had.
Let me explain.
I delivered a keynote at the Agile Development + Better Software + DevOps conference put on by TechWell on Wednesday, November 8, 2017 in Orlando.
The feedback I received was wonderful and it seems the talk resonated with quite a few of the attendees.
At some point, I'll get a link to the video of the keynote and I'll share it here. Until then though, here's a link to the slide from the talk.
Nathanial Willis posted this in LinkedIn recently:
I asked Steve Denning for advice on how to successfully lead an agile transformation and here's what he said:
- Get a bullet-proof vest and hockey mask because you're going to get beaten and be shot at! (As he laughed)
- Stop communicating over email - do it face-to-face; preferably in a bar. (No seriously)
- Discover your executive leader’s problem. Find a story of how another company solved that problem and share it.
- Focus on the 20% that want to change. Forget about the folks that don't.
I came across a video the other day that had this catchy title – Radical Candor. I watched it and was intrigued by the talk AND its implication to agile teams, organizational transformations, and sustainable cultures.
Kim Scott was the presenter in the video and she was sharing lessons she’d learned in her leadership journey at Apple and Google. In a nutshell, she was advocating radical candor for leaders in communicating with their direct reports.
The stories she told made me think about my own career and leadership journey. A couple of which I’d like to share with you.
Or The Dynamics of an Agile Transformation Team
I found this great article about a leadership team (SLT) adopting agility WITH their teams.
http://blog.qrious.co.nz/how-to-navigate-with-agile-leadership
It’s relatively short, but powerful because of the perspective. That is, it focuses on the activity of the senior leadership team in an organizational agile transformation.
I often think one of the core challenges for most leaders is that they are stuck in a situation where they’re telling their teams and organizations –
Do what I say, Go Agile, and not what I do
That is, they are not walking their talk. Now don’t get me wrong. It’s usually not a malicious or lazy play. It’s simply that they have more important things to do. Things that require their specific skill set and expertise to lead and get done. So, there is little to no time left for working like or with their agile teams.
Some may think this is ok and that it doesn’t really have an impact on the agile organization. Or the potential agile organization. I actually think it has a very negative effect.
We’ve all heard of the KISS principle. It stands for: keep it simple, stupid.
Well I want to apply it to software development leadership. Particularly those leaders that are in an agile context.
I’ve been hearing a tremendous amount of pushback and whining amongst leaders in agile contexts of late. What you say. How can this be?
Here’s a sampling of the running types of dialogue (complaints, whining, pushback, etc.) that I’m referring to:
- We’ve already committed to customers a release date for a new, highly profitable product by June 1. However, the agile teams keep saying it will take till January. I thought agile would allow us to get more…faster. It’s sounds like every other time when the teams couldn’t seem to meet our demands. Where’s the creativity? Where’s the can-do attitude? Where’s the commitment to hard work? Where’s the agility?
I was chatting with some colleagues the other day and the topic of agile maturity came up. Particularly for Technology Leaders who are inquiring about agile approaches.
These could be leaders who are new to agile and want to start the transformation OR leaders who are currently engaged in a transformation and looking for assistance.
The questions were around, how to tell IF:
- Do they truly “get” or understand agility?
- Are they really “ready” for it?
- Are they serious about it?
- Are they a good candidate for a coaching engagement?
- And, are they properly aligned with the principles of the coaching/consulting firm?
Some of the questions focused towards money. In fact, quite a few of them. Questions here were around budgets, the contractual/approval process, and payment terms.
I was almost embarrassed to admit that these are not forefront in my mind when I’m engaging clients. My feeling is that they sort of take care of themselves. What I care more about is how I perceive the Inspection Report - February 2017 client’s answers to the first set of questions AND how do they align with my own principles.
