28 February 2014

The Agile Store Has Been Launched!

After spending nearly two years working at Shopify, I took the plunge and actually created my own online store!

Remote Coaching
There are two aspects to the store. The first represents a simple way to view and purchase the coaching and training services I provide. For example, you can purchase blocks of time for both Remote and Onsite Coaching simply using a credit card. There's no need for hassle of creating a purchase order or RFP!

The second is The Agile Store - a collection of 'swag' for people who have an interest in Agile methods. The items in The Agile Store are a fun way to show off that you're into Agile, and include T-Shirts, Mugs and Mousepads.

For example, for the Agile Coaches out there we have this mug to show off your effective but low-tech approach to work:

And who wouldn't want to rock a T-shirt like this one, showing your undying support for the Agile Manifesto?!

I Want to Believe - Agile Manifesto T-Shirt (black)
But wait... that's not all! Just to make sure you hammer the message home, you can get these TDD Cycle Mugs that will keep it front and centre.
TDD Cycle Mug

And there's plenty more in The Agile Store!

Sleazy Hype Guy
OK, so enough of sounding like this guy. :) But do please swing by the store and have a look. If you don't see anything you like, let me know and I'll try to get it up there for you.

The underlying message of the store is that we can have fun while delivering software systems. We also need to be mindful of the original reasons why the Agile Manifesto was created, and to ensure that we get back to its values and principles.

And just as one last teaser, the first 50 people who buy from the store can use the discount code FE26QKD146BP at checkout to receive 10% off their order.

27 February 2014

The Prodigal Son

I want Agile back.
Click for more!
(This post was inspired by Tim Ottinger.)

At Agile Coach Camp 2012 here in Ottawa, I led a session called "I'm done with Agile". The discussion during that session focused on how the marketing of various 'brands' had fractured the Agile world to the detriment of people and organizations who were trying to become more effective at their software delivery efforts.

I jokingly made a biblical reference, saying that if the Agile Manifesto represented the Ten Commandments, then we were in need of The Sermon on the Mount. Following the religious metaphor, Susan Davis had a much better way of expressing the sentiment:
I don't want to burn down the temple, I just want to throw the merchants out!
Religion and the politics of the Agile community aside, what the people in that session didn't know was that I really did feel that I was done with "Agile". I had grown so terribly disenchanted with trying to help organizations that were either beyond help or simply weren't ready for the kind of changes needed. Yes, there were some bright spots - most of which I didn't realize until later - but I was literally and figuratively tired of working so hard and seeing so little progress.

At that point, I had left the coaching/consulting world and had taken a full-time position at Shopify. Here was a young, vibrant, successful organization that was the antithesis of many places where I had coached. They were being an agile company vs. trying to do Agile. My role at Shopify was effectively an internal coach, but I wanted so little to do with anything 'Agile' that I came up with 'Sherpa' for my title.

So, I mostly dropped out of the Agile community. I stopped attending Agile Ottawa events, and left the organizing group. I blogged very rarely. I was still active on Twitter, but much less so about agile topics.

During my time at Shopify I watched a group of about 100 people in the development capacity ship software consistently, with many production deployments a day. Testing was taken seriously, product management worked closely with the developers, and everyone strove to keep improving. It wasn't perfect, but it was a damned sight better than most places I had coached.

What I realized during that time was that teams weren't using an Agile process like Scrum or XP (out of 20+ dev teams, no two used the same process), but they were being quite effective at shipping software. That word effective is the key - if you follow Scrum or XP to the letter, but aren't shipping what the consumers of your software need when they need it, you aren't being effective!

When Shopify and I mutually parted ways as an internal coach, I decided that I was ready to return to the Agile world. To beat the religious metaphor once again, I would be the prodigal son returning.

This time, though, I have a different perspective. While I do believe that XP is a great process and my default way of building software, I'm much more aware of what's effective in the context of a team, the organization in which that team exists, and even the technical environment the team has.

I don't want to teach Agile, I want to teach effective.

You won't see me with the letters CST, KCP or SPC after my name. I'm not interested in tying myself to a brand or spending ridiculous amounts of money for certifications. I'm interested solely in helping people, teams and organizations become more effective at delivering software. So interested, in fact, I'm writing a book about it!

Being effective is what truly represents the values and principles of the Agile Manifesto, and is a return to the roots of the Agile movement. As Tim Ottinger says, "I want Agile back." So do I... I want to believe.

21 February 2014

Technical Competence

I recently read an excellent book by David Marquet entitled Turn The Ship Around. David is a former U.S. Navy nuclear submarine captain who was given command of a ship that was the worst-performing in the submarine fleet. He leveraged his experience as a junior officer in previous assignments to attempt to bring his sub up to the expected norms of the Navy.

While the story is based in a military setting, anyone in the agile community would recognize that David was a classic servant leader, delegating responsibility and decision-making to the people closest to where the decisions needed to be made. Indeed, I found out about David because he was the keynote speaker at the Gatineau-Ottawa Agile Tour 2013!

I highly recommend reading the book, because it's essentially a textbook about how to turn around the mindset and actions of a group of people. I found that there were very direct applications of his concepts to what we encounter in agile adoptions for organizations larger than a single team! I won't go into all the details with a comprehensive review of the book, but I would like to touch on one point that really struck a chord with me.

David wrote an entire section of the book on Competence. When he started pushing control and decision making to lower and lower levels of the crew, they started to encounter safety and operational issues. He realized that the mistake he had made was to assume that the people had the technical competence to make those decisions when in fact they didn't have it. He states,
Control without competence is chaos.
This wasn't a knock against the people or their training, because under traditional leadership models they had relied on the competence of their commander to know what decisions were appropriate. So, David sat down with his officers and chiefs (chief petty officers - the naval equivalent of sergeants), and they hashed out the values and principles for the ship. Core to those principles was constant, continuous learning. Not just learning, but learning by doing.

This had the effect of pushing the ability (competence) to make decisions further and further down the chain of command on the ship. In the space of a year, the submarine went from having the worst ratings in its squadron to the best, receiving awards for its performance.

Anyone who has been involved in a transition to a self-organized, self-managed model would recognize many of the actions David took. He speaks of replacing a leader-follower organization with one that's leader-leader. The notion of empowering people, and the resulting increase in engagement and motivation are quite familiar.

The one thing, though, that I believe that David saw that many involved in agile transitions don't is the effect of not having the technical competence to make decisions. For example, if developers have been empowered to go ahead and change workflows within a product, do those developers have the proper skills to understand the consequences of those changes? Even if those developers aren't touching external-facing functionality, do they have the knowledge and skill to understand how their changes will affect the overall architecture of the system? When business people are making decisions about features and schedules, do they really understand the capacity of the group or groups who will implement those features? Are they including them in the discussions? When operations people are making infrastructure changes, do they understand the ramifications on the business if there is an outage? Do people anywhere in the organization feel that they can question decisions by their leader without repercussions because they have enough knowledge to be able to understand the effects of the decision?

To truly be effective, people building systems need to ensure that constant learning is taking place and being shared in order to push the required knowledge and skills to as many people as possible so that they can make these decisions. This will create the kind of environment where people are motivated to do great work and feel they can experiment in order to try different approaches to technologies. This is the fertile soil from which innovation grows, but it can only work if everyone is constantly learning.

As a final note, it took David a full year for the submarine he commanded to transform. There were potholes along the way, and David mentions more than once that he questioned himself and the process and thought about simply reverting to the old way. He had his commander's support, and persevered. This isn't something that can happen overnight, and it does that time and patience.

In the end, though, the engagement and innovation creates a great environment in which the whole of the people will become greater than the sum of the parts.

18 February 2014

Forgiveness vs. Permission

It's easier to ask forgiveness than it is to get permission. -- Grace Hopper 
This phrase is oft-cited in the world of agility. Don't wait for permission to do something - just go do it! If someone complains after the fact, simply beg forgiveness. After all, the business will be better off owing to your initiative. Innovation doesn't come from committees, nor from the faint of heart who fear the consequences of action.

So, just freaking do it and sort out the problems while the dust settles.

We celebrate this brash entrepreneurial streak in western society as something to which we all should aspire. People like Steve Jobs and Richard Branson are held up as poster children for this attitude that rules are made to be broken! But for every Jobs and Branson, how many people are actually punished for their actions, their impudence, their insubordination?

I have been, and I probably will be again.

A number of times in my career I've taken that initiative because I felt that it was the right thing to do. I quietly gave some key users early access to a system in order to obtain feedback. I broke the corporate rules and set up a dial-in remote access box so that I could perform support & maintenance without having to waste time traveling from building to building. I've gone ahead and published no-so-great-news when it wasn't likely to be received well. I did those things because they were the right things to do in those situations.

In some cases, I was simply asked not to do it again (and quietly thanked). In another case, it contributed to me losing that job. And that's the key...
If you are going to simply do it and ask for forgiveness later, you had better be prepared for the repercussions.
If you rock the boat, you may indeed get the job done. You may indeed get information to those who need it when it would otherwise be hidden. You may also be called out as "not a team player". You may be ostracized by those who have a vested interest in the status quo. You may simply be punished because those in power don't know what you know! Regardless, there will be consequences to your actions.

Barry Schwartz gave this great TED talk a few years back called Our Loss of Wisdom:

In the end, which do you believe you should do? What's right, or what the rules say or what the cultural norms of your organization dictate? I was willing to accept the consequences of what I did because I knew that I was doing what was right. I'm also quite certain that I don't fit very well in organizational cultures where you're expected to say only good news and "toe the party line".

So, if you feel the need to ask for forgiveness rather than permission, good on you! Just be sure you realize that such actions have consequences.