New Leaders Series – Part 1: Shift in Stance

After years of hard work as a software developer and high performing team member, you’ve found yourself facing a whole new set of challenges. You are a leader (architect, team lead, scrum master, mentor, manager) on your team.

Looking back, everything that you’ve done along the way has supported you to get to this point. You’ve never backed down from challenge and have embraced the uncertainty of solving problems in code. You love the focus that comes with being able to tackle these problems with confidence. You’ve enjoyed the satisfaction that comes each and every time you’ve transformed an idea into a solution.

However, all the skills you worked hard to hone in yourself reflect your stance as “expert practitioner” and while expert practitioner skills are foundational to your role, these are not the skills that you will need to grow in order to succeed as a leader.

And no one told you this. When you got the promotion, no doubt your manager told you of the confidence he had in your abilities; however, your leadership up to this point has been fundamentally built on your ability to hone your craft expertly.

Your new role requires a shift in stance. You are now responsible for supporting others to do what you did so well. There is a hidden assumption there; indeed, a fundamental change in how you perceive your value on the team.

Your work is less “about you” and more “about them”.

This shift from “me” to “we” isn’t a small change in thinking and being. It’s one that I’ve seen many new leaders struggle with as they are drawn instinctually back to the joy derived in expressing their craft…. the satisfaction and joy they experienced in being “the guy who solves the problems” rather than “the guy who enables others to solve problems”.

In this series, I plan to explore some of the new skills that young leaders might consider as part of their new practice – assisting them to make this shift from “me” to “we”. It is my sincere hope that my own lessons (sometimes learned the hard way) can be of service to others beginning on this journey.

Introducing… InsideOutAgile

It’s been 4 years since I created my very first blog entry on this site. At that time, I was a software developer, Lean & Agile practitioner and aspiring coach at Corel Corporation. Quite frankly, I had no idea of the many adventures that awaited me in the years ahead.

4 years ago… I had no idea that I would soon work closely with a team of bright developer consultants in order help client teams deliver software. I also had no plans to become an executive – to suddenly find my own path and growth into management and leadership. And yet – through long hours spent inside and outside work – all these things came to be…

So much change. None of it planned for or anticipated.

Along the way, there emerged a core pattern in my practice to help teams deliver impactful high quality iterative solutions using the values, principles, and practices from UX, Lean, and Agile. It is based on this core pattern that I am taking this next step into entrepreneurship…

The only way to truly embrace change is from the inside out.

For individuals, this means the ability to become aware of our own blindspots – working inside out means that we are able to observe and adapt to these blindspots with skill and intention.

For teams and organizations, this means developing the system that will support delivery of work effectively and collectively – working inside out means that the team is able to surface and govern for themselves the key principles and practices they will need in order to succeed.

It is with a humble and grateful heart that I bring InsideOutAgile to the world. I look forward to building stories of individual, team and organizational success and growth with you.

Please follow the links below and the menu above to learn more.

Home – To learn more about InsideOutAgile’s approach

Client Stories – To read stories of client success

About – To learn more about InsideOutAgile itself

 

 

 

 

Agile Coach Camp – Making Space

Last weekend, I was privileged to participate in Agile Coach Camp East. This is an event that I try very hard to attend every year… and every year, a theme emerges for me through the weekend.

This year’s theme for me was “making space” and it’s a theme that I want to keep exploring. However, in the interest of sharing, here are my first thoughts based on what happened at camp…

“Making space” means:

1. Creating an environment where things can happen.

Open Space and Unconference are wonderful examples of the power of making space. I’ve attended Coach Camp 3 times already… each time I am a little surprised at the depth and breadth of sessions that come out of such an event. It reminds me: this is the spirit of self organization; of trusting a group (in this case 70 individuals) to pull together and create something amazing collaboratively.

2. Leaving room to breathe between all the things that happen.

Some of the best group conversations I had during coach camp this year were during a jam session that went late into the night. I believe the quality of the conversations was directly connected to the ability of the group to disengage from these talks and do something else – something fun, something creative – in the space between the conversations. It reminds me that we are all better and happier people when we take time to connect with each other on a level that doesn’t directly relate to a specific or measurable outcome.

My intention then is to go forth and “make space” for myself and others. I look forward to seeing what else emerges from this theme in the days to come…

Thank you to the organizers and volunteers who make the space possible for Agile Coach Camp every year… and to all the participants who make space in their lives to connect. Looking forward to next year already!

Why We Play…

It’s not uncommon for Agile coaches to engage their teams in games in order to experiment with new ideas. If you have ever participated in such activities, it’s likely that you have encountered individuals who dislike the idea of anything work related being transformed into a “game”.

So… why do we play?

We play to prototype and experiment with new ways of thinking and behaving. We play to open our minds to possibilities. Indeed, engaging in an activity “as play” actually helps us to explore many new ideas quickly and effectively as a team.

In short, playing brings us to a “personal edge” in a friendly and joyful way.

That being said, for some of us, the edge is simply to engage in play at all… and that’s an edge that I’m learning to see and understand better. In these situations, I would invite the individual to simply try the game and then to reflect on why we play… rather than focus on whatever other agenda I’m hoping to bring to the table by engaging in a game.

After all, when we play, we explore many ideas at the same time… and one of those ideas can certainly be “why do we play?”

Powerful Questions

There are many things that I’ve learned since becoming a mom… but there is nothing more powerful for me to date than learning to see the world through very young eyes.

The beauty behind a child’s approach to the world is that it is so fundamentally based in observation rather than judgement. When my daughter asks questions, she seeks to better understand what she observes. In so doing, she rarely asks “why?” but is more focused on “what?” in her line of inquiry.

From this, I’ve realized that “what?” is actually a very powerful way to question the world. Consider these examples for a moment…

Rather than asking: “Why is that?” …ask instead: “What does that mean?”

Rather than asking: “Why is she (or he) like that?” …ask instead: “What happened to her (or him)?”

Changing your stance from “Why?” to “What?” opens up your line of inquiry. You automatically move away from a place of judgement to a place of understanding. Looking at the world through the eyes of a child isn’t for every occasion… but if you are aspiring to understand and accept, it’s not a bad place to start.

The Secret of Success

Recently, the stellar community of Ottawa Agilists gathered to share stories about Agile regrets and success. The first session was hosted as a “fail faire” and the second session was hosted as its’ counterpart… a “success faire”. As an outcome, we attempted to gather the “lessons learned” and “secrets of success” for each event respectively.

Having hosted both these sessions, it was interesting to me how much harder it was to root out the source of success over the lessons learned. In part, this came from the participants themselves… story tellers were more apt to share directly what was the cause of a failure. Success stories were related in more detail about “what happened” rather than “what exactly made this work”.

This got me thinking… why don’t we pin point the source of success with the same attention and effort we do causes of failures?

Could be that we don’t analyze success with the same interest because… well, it worked… what is there to analyze further? Sure, I get it.

However, just like not all steps undertaken when we make a mistake are necessarily causes of our failure, not all steps that were undertaken when we succeed necessarily meaningfully lead to our success.

And just like we identify root causes of mistakes so that we don’t repeat them, we should seek out the root causes of success… so that we can repeat them.

We can’t do Agile.

Over the years, I’ve heard many variations of “we can’t do Agile”:

Agile doesn’t allow for proper thoughtful design.
Our project \ organization is too big to do Agile.
Agile is really just a dev thing.
Agile just isn’t reality.

I realize that behind every single “we can’t do Agile” statement, there’s a story. My intent here isn’t to delve into the stories of Agile woe… rather, I would like to open a small crack for the “we can’t do Agile” crowd.

Consider…

1. Have you ever stopped yourself from sending an email, and instead decided to walk over and have a conversation with a team mate?

2. Have you ever argued to make the right fix on your project, even if it went against the requirements \ spec document?

3. Have you ever sought out feedback from your customer or end user in order validate your understanding of a project?

4. Have you ever adjusted your project plan in light of new feedback (user based or technological)?

If you answered yes to any of these questions, then you successfully “did Agile”! Consider the values of Agile below and review the questions above again respectively…

1. Individuals and interactions over processes and tools

2. Working software over comprehensive documentation

3. Customer collaboration over contract negotiation

4. Responding to change over following a plan

Viewed in the light of Agile values, many teams are already adopting Agile methods… albeit implicitly. Embracing these values in a more explicit fashion opens a door of possibilities… among these possibilities would be to let go of the idea that “we can’t do Agile”.