Teams Over Processes – Don’t Be Insane

[Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible for managing,coaching and improving cross functional teams using Agile. Follow him on Twitter @craigstrong and blogs at www.c6s.co.uk]

Do we really need to do that?

One of the embedded issues which often exists in most cultures is the accumulation of processes. Processes make people comfortable and empowered. People are generally creatures of habit and enjoy routine. If people feel good about such things its tempting and common to see more processes emerging to strengthen or improving the existing processes. Now don’t get me wrong, certain processes and frameworks are essential and have high value to business. However sometimes where they exist, they are the main focus and not what the process was setup in the first place to achieve.

When you get a group of people together and put them on the same project they are not a team they are simply a group of individuals. By applying processes, frameworks or tools to this group it’s likely they will simply be a group of individuals using processes, frameworks and tools. Not only will this not help build a team, but could slow down the group of individuals.You don’t build teams by simply applying a framework or process. Certain processes are inherited from previous projects so they must be applied again. In some cases they didn’t even work well previously, but were in place and therefore must be re-used. There is no such thing as silver bullets which when applied guarantee success.

As the famous quote says :

Insanity: doing the same thing over and over again and expecting different results. – Albert Einstein

agile team product managementA colleague of mine recently made a profound simple statement, which was “question the value of everything, if you don’t know why or can’t remember why you are doing something, just stop doing it.”

As simple as this sounds, it’s very true. How many of us are routinely writing and/or requesting documentation, forms or following certain processes because we are used to it not because it’s really needed. If you question some of these and ask yourself why you are doing something or why do you need this information and how is it going to be used, you may find that you don’t really need to continue with it. When you stop doing such an activity from then on, you will have free time to do something of value. Not only in such cases can you improve value, but you might just stop doing something which is devaluing the situation.

In Kanban this is often seen when you are visualising workflow. By visualising the workflow you can identify routes of inefficiency and routes to improvement. The same can be discovered when undertaking Lean analysis. This regularly proves to provide fantastic results over time. However sometimes outside the direct workflow of production it’s worth questioning other not so tangible artefacts. In doing so you may eliminate waste and identify micro-management which can and needs to be challenged. A process is not beneficial unless it has a clear value which should be easily identifiable. Value isn’t something which is nice to have, but something which clearly delivers or benefits a person, group, company or product.

So next time you are about to spend 30 or more minutes writing a report or asking someone else to provide you with a graph, ask yourself “Do we really need to do that?”

FacebookTwitterLinkedInShare

4 Responses to “Teams Over Processes – Don’t Be Insane”

  1. Gail Swanson
    December 28, 2011 at 10:03 am #

    What is your response when an organization insists that they need to have a systematized process that can be applied to every project? I run into this with UX work all the time. Clients want a formulaic process that is predictable and repeatable. They don’t easily accept the explanation that while there is a standard set of tools and methods to choose from, every project needs to be evaluated for it’s own needs.

    How do you make this argument authoritatively?

  2. Craig Strong
    December 28, 2011 at 11:21 am #

    Hi Gail,

    Great question! Change is not always welcome particularly if success has been achieved through given processes. If certain processes have been in place and have been observed to be have been working, very few people will want to change them. You can also have protectors of processes who are against change altogether, particularly if those have been involved in getting the processes in place (unfortunately this is very common) . However value is a key component to change. There should always be tangible value in the process/change which will need to be presented to warrant the change as not all change will by default positive and people don’t like to take risks. If you can present the value in the change, often this will become the focus away from the process. In my experience this often has to take the path of small steps to prove the concept and then you get buy in. Also there is a social aspect of getting people to want to make the change and be part of it. Taking the incremental path also helps break down the barriers as people can see this as being less of a risk etc. Therefore the change is manageable has reduced risk and as with the Agile iterative approach can keep on the path of value whilst identifying risks early. With traditional projects a change might not be seen for a very long time often when it’s too late. Involving the business/clients often and early gives them confidence that the change is not damaging and it’s in control through regular communication leading to better value in the product development stream.

    Relating to your comments on “Clients want a formulaic process that is predictable and repeatable”. Each project will have levels of cross over where experiences and practices can be called upon, but the differences should be in place to accommodate the unique dynamic of the project. Creative work is not by it’s nature predictable or repeatable. If clients insist on repeating the same processes they will mostly produce the same or very close output to those previous processes. To take a creative profession by example, People wouldn’t commission an artist and provide a canvas with a framework of paint by numbers, otherwise they would cease to be an artist and produce the same painting over an over. However they might want to commission an artist and provide a canvas and materials. So although the construction and provisions should be same, the granular processes should be open for the creative processes to flourish and produce the product for the market. Getting this message across should convince them that they are not getting value for money in such cases as well.

    I hope that goes some way to answering your question, if not let me know and I’ll try to add some more.

    Thanks

    Craig

Trackbacks/Pingbacks

  1. Teams Over Processes – Don’t Be Insane | Agile Software Development | Scoop.it - December 28, 2011

    […] jQuery("#errors*").hide(); window.location= data.themeInternalUrl; } }); } agilescout.com (via @mattfowler) – Today, 6:32 […]

  2. Teams Over Processes – Don’t Be Insane | Agile | Syngu - December 29, 2011

    […] [Guest Post: Craig Strong, MBCS CSM has been involved with software production for over 12 years and is currently contracting as a ScrumMaster for Sky. Having been a developer Craig has experienced first hand the effects and problems when being managed by various project management techniques and frameworks. On a daily basis Craig is responsible […]You just finished reading Teams Over Processes – Don't Be Insane! Consider leaving a comment! We run our blog on Standard Theme. Be a writer for us. Post a job with us on Agile Jobs. Teams Over Processes – Don’t Be Insane    Agile Read the original post on Agile Scout… […]

Leave a Reply