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

 

 

 

 

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”.

Agile for UXers

This weekend I was privileged to attend Canada’s largest non-profit UX conference, UXcamp in Ottawa. Quite a few themes emerged during the conference, but two resonated deeply with me… process and team.

Several presenters either directly or indirectly talked about the importance of applying UX principles to internal processes and teams. In addition to this, on more than one occasion, “big A agile” was explicitly mentioned and quickly dismissed… it seemed to me (perception alert!!) that many presenters wanted to distance their ideas from being in any way “big A agile”.

So I wanted to take a moment to offer up a quick overview of Agile for curious UXers out there. To begin with, I want to share how deeply committed I am to the idea that we (UXers and Agilists) are focused on the same goal of delivering high quality valuable solutions to our users.

First thing that I would like to share is that the heart of Agile isn’t process. Agile came to life with its first incarnation in XP or Extreme Programming… and if you dig a little into XP, you’ll come face-to-face with its values: feedback, communication, simplicity, courage and respect.

The next thing that I would draw attention to is the Agile Manifesto itself. Several leaders in the Agile community came together in order to define Agile’s four values: “Individuals and Interactions”, “Customer Collaboration”, “Working Software” and “Responding to Change”. These values apply to the software solution as much as the team itself. In support of this, the Manifesto also describes 12 principles that help define “how to be Agile”. The majority of these principles are focused on team.

Now, this isn’t to say that there aren’t plenty of “practices and implementations” out there calling themselves “Agile”… but I would strongly question any practice that calls itself Agile that does not honour the values and principles of the Agile Manifesto or the origins of Agile in XP values. As UXers, you are in a unique position to see this on your teams… I would encourage you to help your “big A agile” teams reconnect with their core values.