As explained in the previous post, the first value outlined in the iNews team is that processes serve the sole purpose of being challenged and improved.
The team gathered at a meeting room. At the meeting there were John Miller, Susan Lawrence, Jane Collins, Jake Preston, Christian Fields, Joseph Ross and me.
I was invited just to listen, no talking allowed. I was in charge of time keeping so they would respect the time box for the meeting (the only thing I was allowed to say).
The first one to speak was John:
John: Hi guys! It’s a pleasure to be working with such a distinct and diverse team.
We have a very ambitious and interesting project ahead of us. We are in charge of changing the way people think about mobile news.
But before we set out to do just that, I’d like to discuss with you our team values.
All the other team members looked puzzle. Susan quickly replied:
Susan: I don’t get your meaning, John. I thought we were supposed to use scrum like the rest of the company.
If we are to use it as a process then we already know our values: the twelve principles in the agile manifesto.
What exactly do you mean by “our values”?
Every pair of eyes in the room turned to John. Tension in the air (ok, that’s just me being dramatic):
John: Very well observed. The issue here is that those are the agile manifesto principles. Not OUR principles.
We might end up with exactly the same set of principles, but then they’ll be our principles as well.
If we get to that, I’m sure we’ll live by those and in every decision you’ll abide by them.
A sense of shared understanding filled the room. “That makes just so much sense”, I thought.
Jane still looked uneasy, though. John, as a good leader sensed that and asked her what was worrying her.
Jane: Well, as a designer I’m not as used as you guys to a formal process. I’m very used to change, though.
It’s very clear to me that change is a competitive advantage.
John: I see, Jane. It is a good thing that you mentioned the process.
I really believe that processes are guides to help us interact and they serve no other purpose than to be challenged and replaced.
Christian: Coming from an open-source background, I’m very used to challenging and replacing “processes” of all kinds: contribution, releases, licensing.
Usually you get the processes from some other well-known successful project and start adapting them to your project.
Joseph: I like that discussion a lot. I come from a ScrumMaster position in the company from the early days of scrum.
A lot of failed Scrum implementations come from the fact that people get the practices without understanding the principles.
This leads to process paralysis. They won’t change anything in the process even if it gets in their way just because some book says they *HAVE* to do it this way.
John: What do you think now, Susan?
Susan: I couldn’t agree more with you guys.
I never thought that people failed to understand that processes are mutating things.
I always tried to adapt processes to fill my needs.
Jake: Even though I come from a very different background, what you said makes perfect sense.
I do share the concern with Jane, though. What if the current process does not really include us in the loop?
John: That’s exactly why we are suggesting that the process must be challenged and replaced with a better fit.
If ANYONE in the team feels some practice is not worth doing and have ANY better idea we should at least give it a try.
Best case scenario, we get best at doing what we have to do. Worst case, we learn. Looks like a win-win situation to me.
At this point I’m just amazed at how easily people with such different backgrounds connected over an ideal of delivering more.
Joseph: Well, I can confidently say that we have one of our values defined.
Processes are guides that should and will be challenged any time anyone thinks of a better way of doing some practice (or even not doing it at all).
There are no fool ideas or experiments. There are no reprimands to suggesting improvements by anyone in the team.
Does that sum it in an understandable way?
Everyone nods in agreement.
John: Ok, so we abide by this value at all times until we find it to be a poor fit to our team and change it. Ok?
Again happy nods in agreement.
Me: Awesome! Done with 5 mins to spare!
Susan: Yeah, and since I’m hungry, what do you guys say of a trip to Starbucks?
Hmmm… Caffeine addicted, are we?!
They go happily to Starbucks and then come back to discuss next value.
This value may seem counter-intuitive at first. If I keep challenging a process that means it’s not good enough. What’s the point of having a process if it’s not good enough?
The team’s answer to that is that the process is just the current best practices for delivering value and as there’s no such thing as THE best way to deliver software, they are supposed to be continuously challenged, experimented with, improved and replaced.
They do not believe that any of them know exactly the best way of doing anything, yet they uphold the ideal that together, through iterative refinement they can keep improving the way they do things.
This is the reason for this value. The process is not what’s important. Delivering business value is. The process is just the means to do that.