[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]
Experienced project mangers and professionals are all too familiar with the complexity of decision making processes. In some companies making decisions are long drawn out affairs which involve everyone and everything, no doubt all adding significant time to any project and as we all know, time is money. Companies which have such processes trust such traditions and rely on the hardened practices that everyone knows. Just because traditions have worked in some cases, this doesn’t mean they should be left unchallenged or looked at to improve. After all the first rule of bad business is that if something doesn’t work, keep doing it.
In traditional bureaucracy driven environments, excessive processing and thinking is a product killing, demotivating process which encourages weakness throughout. Unfortunately quotes such as the following ring true for some:
“The perfect bureaucrat…is the man who manages to make no decisions and escape all responsibility.” — Brooks Atkinson
Agile discourages bureaucratic processes
With so many people turning to Agile, one of the common misconceptions is that the simplicity of such a framework has less value than their familiar large scale project management frameworks. People familiar with complex decision making processes can misinterpret the simplicity of Agile as a lesser framework, maybe thinking that Agile is for smaller projects with lesser implications. Wrong!
Agile processes such as Scrum, I think it’s fair to say it’s pretty simple to initially grasp. What people miss is that there is much depth in it’s simplicity. For instance empowering teams who do the work. Simple as this sounds, the psychological impact alone creates a sense of belonging, ownership and pride, not to mention the responsibility of time given to the teams that complex processes miss.
Looking at the role of “Product Owner” note that this is not plural! Having a single person “the ring-able neck” responsible for the value of decisions again empowers people, creates less confusion, speeds up the decision making process and gives more value to decisions by removing the impediments associated with decision making committees.
The simple yet beautiful product backlog. A novel idea of having one list ordered by value. This subtly puts pressure on stakeholders and product owners to make clear choices often. Choices are not always easy and difficult ones are often avoided as part of human nature. How many people are so used to having each department have it’s own list of priorities, but they are all working on the one product. A simple idea to align the workflow into priority is the product backlog, which is visible to all and updated often. However as the old saying goes if everything is priority, nothing is.
Agile changes the mindset from projects to products with it’s simplistic, direct approach. People don’t build projects they build products. Having an incremental process which involves everyone to see working examples often and early directs value when and where required to achieve success. The simplicity of Agile and the constant review processes highlights that people cannot accurately predict the future which so many other frameworks assume. Knowing this allows for people to develop and as such products to become more innovative.
To those who see the simplicity of Agile as a weakness, be sure to understand that there are good reasons for less. The simplicity of Agile is one of the facets that makes it such an elegant technique to build products quickly, of high quality and most of all of value. If introducing agile, it’s not just the process that will change, but the people and the company around it. Be sure to understand Agile as more than just a simple framework.