I grew up as an only child. I had no brothers or sisters to "share" anything with. It was all MINE. When I became a teenager, I completely rebelled against all authority. This probably had something to do with my only child-ness, but probably had more to do with me being a spoiled jerk.
I hated all authority...teachers, parents, pastors, police, you name it. How dare they tell me what to do! I felt that their only purpose was to make sure everyone followed arbitrary rules that MADE NO SENSE, and they were determined to make my life hell.
As the years went by, I calmed down, settled down and became a family man. But, I don't think I've ever shaken off that old "to hell with authority" attitude. I've just learned to live with it :-)
I think this is one of the reasons that I fell in love with Scrum, and agile in general. It had that familiar aroma of my old days of rebellion. Agile ideas came about really out of necessity and a spirit of rebellion. There were arbitrary rules that were imposed on organizations about how to build software that MADE NO SENSE! So, how about we rebel, and do things OUR way, i.e. the way that makes sense.
Now, let's consider the word "process". Over the last several days I've realized the profound effect this word has on people. People immediately cringe. For some reason, the word "process" paints a picture of arbitrary rules that MAKE NO SENSE that we have to follow. It implies bureaucracy and micro-management.
Now, let's set something straight. "Process" is critical to the success of any endeavor. If you let the process "evolve" without paying attention to it, it will cause chaos. One thing that people don't understand is that a process always exists, whether it's documented or not. It may feel like "free-style", but it's a process.
I've been involved in some conversations recently about role definition. This is a classic problem that plagues every company...not having a clear definition of roles. Here is the problem; without a clear understanding of a PROCESS, you will never be able to clearly define ROLES. The first thing that should happen is to clearly define what the process is in how to deliver software (or anything). I'm not talking about creating artifacts. Documentation does not equal process. It supports the process, and may be a by-product of the process, but documentation alone is not the process. But be careful. I've seen to many times a "process" created that people end up slavishly following without ever even attempting to improve it. A process must evolve along with the changing culture, technology, and business needs.
To some extent, Scrum practitioners discourage defining processes. It appears to me that maybe this whole "stick it to the man" gets a little too out of hand...even for me!
If you don't control the process, the process will control you, and it won't be a good thing.
Wednesday, January 20, 2010
Process is Not a Four Letter Word
Subscribe to:
Post Comments (Atom)
3 comments:
I agree that the word 'process' makes some people cringe. I also think they might put full trust into 'the process' or worse, they try to find where they need to do the least for the CYA when the blame game starts as it happens in many water-fall (fully planned up front' project schedule / plan.
The reason I like Scrum is that it takes the value out of the things that people would do to cover their b*tt during a project. I always say when someone hire ups says that communications are broken and we need to do more meetings or do a better documentations or fully review docs before throwing them over the wall to the next team is why do you want to do more of that process if it is broken??! Scrum in my opinion itself is communications and status updates..etc Not because people take the time do that in a Scrum environments, but because how they do it (dedicated teams all owe up to the deliverables) is your communications and status updates..etc. You can't do Scrum unless you communicate within the team and know and track progress on your daily tasks against the features you and the product owner agreed to have done in a time-boxed sprint.
Like you said. There is a process in every activity. The trick is to make sure that people keep focused on the deliverables done done and not that steps made up by other humans are followed for the sake and maybe in the hope that the process will lead us to the promised land of deliverables.
One last note. First thing that happens in project when its hits a wall is that the process is dropped and people will start figuring out who should be in an urgent meeting and what are the minimums that should be accomplished in the next few days. So, if that's real life, why not approach projects with what we already know that we don't know everything on day one and that we need to make sure we got 'real' dedication from needed team members? That's where Scrum makes sense more than a glorified 'process' that is expensive and gets sidelined when life comes calling with its challenges to the project.
I know exactly what you're saying.
If we go to the "community" model, I believe that those communities will still need leaders...at least for a while anyway. Of course, we wouldn't needs so many level of management.
If a company is willing to transition to this model, it doesn't mean everyone gets axed. It does mean, however, that the old "manager" jobs must transition to those of "community leader".
I'm someone who has relied on and found success in part by defining and executing processes. Simply put...the word "process" gives me a warm fuzzy. So this blog really challenges me.
You're very right - the simple word has taken on the implied weight of rigidity, authority, bureaucracy. The capital "P" Process. In a large, established company, it's hard to move people away from that.
According to the dictionary, little "p" process is: a series of actions or operations conducing to an end.
Essentially, *anytime* you need to get from Point A to B, you are following a process. Very simple. It says nothing about rules, documentation, oversight, waste.
Capital P "Process" and little p "process" - neither is right or wrong.
It's about having a fully stocked toolbox (which most companies lack). And possessing the critical thinking skills to decide when and where to use the hammer and when to use the wrench. Only then do you have the freedom to get from A to B most efficiently.
It's not a one-size fits all. Interesting.
Thanks for the eye-opener! :)
Post a Comment