Agile or WAgile – Discussion

Introduction

This post represents the first half of a pair of posts which will attempt to lay out some fundamental techniques which i have found helpful in delivering projects that are on time and fit for purpose, in this first post i would like to examine the difference between Agile and what is commonly referred to as WAgile. In the second post i would like to talk about requirement gathering using stories and prototypal design.

At the heart of Agile techniques is a principal of known as people over process, let us for a moment focus on one of the intrinsic component’s of this principal – ‘Collaboration’ – when we collaborate with each other we get more done, this is a historical fact proven in many aspects of life including great engineering achievements from the channel tunnel through to huge military campaigns.

When we collaborate in the Agile setting we need to enter a mind set which can be quite alien to traditional project management, due to the blame avoidance culture we typically find in hi $$ projects we tend to find abstraction and deflection in use rather then clarity and inclusion, this is generally driven by the fear of ‘Showing ones dirty washing , as it were’.

For projects to succeed under the Agile banner we must become a team composed from a number of organisations working to achieve an end goal ‘ producing a fantastic fit for purpose deliverable’ for this to be really achieved the boundaries between roles within the project ecosystem and their associated rights and privileges must become so blurred that typically in time they become background noise and new project centric roles spring into place which are flexible and distinct from the persons employing organisation. In short the team becomes a cooperative matrix of team centric players within the project ecosystem, rather than employees of one of the contributing companies.

If you do not feel it is possible to facilitate this type of relationship with the client and the other parties involved,  other techniques might come into play such as the use of a ‘Internal Customer’ who can be the bridge between the client and the team. However this is not optimal and many projects find themselves gradually slipping into a waterfall style methodology consequently blaming Agile for a failure when in fact they were not practising agile but a hybrid methodology that is classically referred as WAgile process – see the diagram below for how this might look.

Diagram : WAgile in action

Within the Agile space there are 2 primary approaches to Agile Development

• Scrum
• eXtreme Programming

It could be argued that there are other front runners such as DSDM and then we must also consider the LEAN methodology sets as well, the distinction between different flavours of Iterative development techniques  is becoming increasingly more blurred as this group of methodologies gather a growing number of converts each contributing their distinctive flavour to the community.

However ‘What is Agile?’ is beyond the material I wish to discuss in this post , so let us instead accept that there are a number of buckets of techniques which all at their heart have the principals of the Agile Manifesto (http://agilemanifesto.org/) the guiding principles of which I quote for convenience below:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan

As you can imagine with this amount of scope for variation an agile environment can take many shapes; so instead of trying to cover each possible variation, I will provide below a diagram which illustrates some of the common factors that can be found in a Agile environment:

The biggest differentiator between the WAgile illustration  and the Agile illustration is the communication dynamics between stakeholders, the team, we also see a distinct difference in the team value statements.

Commentary

The WAgile environment uses artefacts such as project plans , long meetings , vast swathes of documentation to try to provide an accountable environment were every thing is locked down to the following factors:

• Who takes responsibility for doing it
• How long will it take
• Who holds liability if it all goes wrong
• Who’s going to pay for it
• What is the immediate profit margin on the work
• Do we project that this will take us over budget
• The above quite often translates into stress / toxic pressure expressed as can we push elements of the team harder to get this done faster

While there are important issues illustrated in these points, trying to mitigate them creates a huge risk to project completion. Classically the techniques used in a Waterfall / WAgile environment to constantly answer and document the above points leads to a lack of freedom and flexibility  and a total inability to do what is needed to just get it done at the coal face. It should be noted that we also generate a environment of fear where people and companies are scared to take risks, once there opinions or improve quality.

With the on-going need to document everything and to have a paper trails for all aspects of the project, we find we end up creating roles within the team who’s sole job is to protect the company or shift liability onto other individuals, partners or companies. Thus it can easily be seen that in the attempts to lock down the Cost, Liability, exacting time frames and Risk – we find that making even the smallest movement in the project space has huge cost and requires layers of sign off and discussion this effectively knee caps the teams ability to flex to changing conditions and to innovate when the opportunity presents itself. All of the above leads to teams creating yet more documentation in attempts to fully lock down requirements in advance including some of the following documents which quite often make for miniature novels they are so great in length.

• BRS [Business Requirement Specifications]
• Static Wireframes
• Business flow diagrams
• Huge Class diagrams that document architecture which might not be needed
• Ultra high quality creative tied down to the exact pixel
• In depth NFR’s [None Functional Requirements]
• Massive Risk logs which at times almost go as far as to include acts of god

Worst still for the team is the fact that most of the above form some sort of reference material within the overarching contractual agreement which generally means making changes to them takes a huge amount of time, effort and stress. One of the other factors to add into the mix is that quite often the wrong people have written these documents or the right people have written them under huge time pressures – the end result is tends to be more a set of hand-cuffs as opposed to empowerment.

The Agile environment drives for the concept of people over process, as such the number of inflexible paper artefacts are reduced, meetings tend to take the format of time boxed [normally 15 mins or less] whole team meetings these are quite often known as touch point meetings. In terms of risk most teams tend to practise ‘Don’t put off for tomorrow what you can deal with today‘ This can take the form of writing technical debt cards and having a regular technical debt review cycle or more preferable dealing with problems as they pop up.

The classic Agile environment will also try to practise philosophies like ‘Better to ask forgiveness , than to ask permission’ in general the the Agile player is a brave soul who just gets in there and gets it done, he can afford to work like this because of the tight communication across the team elements regardless of discipline he/she is given further confidence by knowing that team shares:

• Shared Code Ownership
• Shared Feature Ownership
• Shared Liability
• Shared responsibility for getting right
• The team practises open communication and transparency across all discipline
• Fear is not part of the team culture
• The team makes joint decisions in transparent meeting and the concept of ‘Command and Control’ has no place in the Agile teams culture
• Personal Ego is left at the door
• Team Ego and identity of team self is implicit to an agile team
• One is none , two is one [Pair Working – across planning, programming and all other applicable activities within a agile team]

One of the techniques an Agile team frequently borrows from Lean methodology is the concept of a [Red flag], this concept says that no matter a persons position inside an Agile team that person can raise a red flag , physically , by Email, by calling a meeting when they believe things are going to come off the rails and the effect of this action is everyone no matter their position stops and there is a conversation to put the situation right before the team continues.

The one main driving force behind an Agile team is not who’s fault it is , a true agile team even one split across organisations operates on a Zero blame culture because it operates on a understanding that everyone is doing there absolute best to achieve one single aim – Continually deliver high quality , demonstrable software that is 100% fit for purpose and it is this one aim that members of an Agile team no matter the company they represent or the horizontal stripe to which they belong in the ecosystem strive for, and this is one of the biggest differences between WAgile / waterfall and true Agile, true agile concerns itself totally with delivery not politics.