How I was Introduced to Agile

A few folks at some clients have asked me this and seemed to think it was an interesting story, so I thought I'd share…

…A long time ago, it what now seems like a galaxy far away,

I decided to get a Master's degree. The employer I was with at the time valued the checkbox and was willing to help pay to check it. At the time I was the equivalent of a "tech lead" doing Java work. I decided I wanted to go for something interesting and challenging and somewhat related to my job so I began down the path of a MS in Operations Research with a concentration in Artificial Intelligence.

After getting about halfway through with that I started thinking I might want a new job as I wasn't enjoying the one I had anymore. So I started looking for Ops Research jobs and what did I find? About the best thing you can do with a Master's in OR is get a PhD in OR…not the life for me. Now, I had previously noticed that one of the other concentrations for OR was Project Management so I did some poking around. What I ended up settling on was switching my Masters to Project Management with a concentration in Ops Research. I thought if I wasn't enjoying certain aspects of my job I can learn about how it should be done and then work to change them. That didn't turn out how I expected, but that is a different story :)

So all excited to learn about PM and change the world I got my first text book for my first PM class, started to read through it…and was horrified. As I read though this book I thought "no No NO! this wont work for software! These are all the same things that are going wrong on the job now". At the time I didn't think in terms of "traditional" PM, but I did know that software was not the same as construction or manufacturing, and this book kept using those for examples.

So I scoured Amazon for a book specifically on software project management. I stumbled upon Manage IT by Johanna Rothman, and after reading the reviews decided it was worth a shot…I had struck gold! Reading through her book gave me the exact opposite reaction to my course's textbook. As I read through Manage IT I kept thinking  "yes Yes YES! This is what I have been saying, or thinking, or trying to say and think but haven't articulated well". Some where in Manage IT Johanna mentions agile, almost in passing. Something to the effect of "agile" is easier to say than "incremental and iterative".

Well, I got to wondering if "agile" was actually a methodology…boy was I surprised. I soon discovered the Agile Manifesto and realized it was a lot more than a methodology…it was an entire ideology; a set of values and principles through which to perceive the world. I decided to do some research on the signatories and soon found books and blogs. Some I had heard of already as I was familiar with their technical books, but I eventually found the Scrum book, a book on XP and Alistair Cockburn's Crystal Clear. I was originally leaning toward XP, but in the end decided on Crystal because Alistair referred to it as XP-lite as it focused more on the habitability of projects. I liked that Crystal acknowledged you wouldn't always have the best people and the best situations at work, and that was certainly the case at that employer.

And the rest you could say is history. I spent the next two years of my Masters  refuting the concepts of traditional project management and the teachings of my professors using both Manage IT and Crystal Clear in literally every research paper I had to write. Along the way I kept reading more books and blogs and joined the conversation on Twitter and learned a huge amount. I also discovered a wonderful community of practitioners out there and it helped immensely to know that I wasn't alone in my ways of thinking, doing, and valuing things. I spent a couple more years after finishing my degree attempting to apply what I had learned to change my organization. Though I neither realized it nor appreciated it at the time, that huge futile attempt taught me a great deal as well.

So that is how I was introduced to agile.

Thank you Johanna and Alistair…you helped me get a 4.0 in my MS in PM, taught me a tremendous amount and introduced me to a whole new world that is now a career I love.

Team "Commitment"

It seems like I've been hearing a lot about team commitment recently, or perhaps I've just being thinking about it more and am simply more aware of conversations involving commitment, but either way, most of what I'm hearing is bothering me.

Now, before I start, I want to be clear that I don't think Scrum or iteration-based team processes are inherently bad. I will say however, that most of what I've been hearing is within the context of iterations or at a more general level of what I believe is organizational mistrust of employees.

I'd also like to say, that I don't think commitment it bad. Quite the opposite in fact. Commitment is very good, and required for a healthy team, but it often seems organizations talk or think about commitment in a wrong-headed way.

To me, good commitment has three parts, in no particular order:
- First, is the team's commitment to each other (membership).
I believe this is imperative to a team's ability to gel and the longterm sustainability of a team that will continue to work together.

- Second, is the commitment of the individuals on the team to doing a good job (professionalism).
Each team member should be committed to coming in to work each day and doing the best job he or she knows how to do.

- Finally, is the team's commitment, at a high level, to the organization (alignment).
Ultimately, every org has a purpose, and everyone in that org should be committed to helping meet it. This means that, in addition to the first two parts, teams have responsibility of understanding their org's value system and purpose. If you don't like your org's purpose or value system, help change it or leave. (I'd also point out here, it is management's responsibility to communicate and share that purpose, but that is a different blog post :)

So what is bad commitment?

Well, the easy answer is anything that's more or different than what I stated above ;)

Here are a couple examples:
- Asking a team to "commit" to getting work done in an iteration (ignorance).
There are lots of understandable and improvable reasons why work doesn't get finished. There are also lots of unexpected and unforeseeable reasons too. If a team feels that failing to meet an iteration "commitment" is unacceptable, they will not be operating in an environment in which they feel safe to learn, adapt and improve.

- The belief that not asking a team to "commit" to work will decrease a team's accountability (mistrust).
This assumes that without asking for "commitment" team members are more likely to slack off. This is treating your professional knowledge workers at best like children, at worst like untrustworthy thieves.

- Using "commitment" to motivate the team to get more done (poor leadership).
If you feel that you have to have an arbitrary deadline to motivate your team, then you have hired the wrong people. However, what is the more likely case is that the right people have been hired, but they've not been operating in an environment conducive with success. Leadership should focus more on building environments from which successful situation are likely to emerge, and less on products and projects.

So that's it. There are many other stories and examples of bad uses of "commitment". Normally though, they all seem to boil down to mistrust, ignorance, or poor leadership (or usually a cocktail of all three). Commitment should revolve around three things: membership, professionalism, and alignment. No more, no less. If you feel that your team is being asked to commit to more than the above, you should question it. If you are the one asking a team to commitment to something more, you should ask your self why.