Subscribe

Gaps in the Agile perception

Charlene Tshitoka Mulamba
By Charlene Tshitoka Mulamba, Consultant developer at ThoughtWorks South Africa.
Johannesburg, 10 Jun 2014

Perceptions of Agile vary from environment to environment; there is a lot of disconnect between what it is and what the clients thinks it is.

Many companies think it is a quick or fast-track ticket to delivery of software, probably because there is much of old project management thinking around waterfall development, where a fair share of project failures is evident. When Agile developers get called in to fix these, the client then sees Agile as a saviour in terms of how software development teams can successfully deliver software.

Agile is seen as a methodology - which in fact it is not. Clients see it the same way they do waterfall, and take it as a methodology that is followed step by step. Agile isn't a methodology, though, it is a set of principles and dialogues on how to work.

Business has two options when it comes to developing software - using waterfall or Agile. But these are seen as two diametrically opposed ways of developing, where actually developers can first go left, or right. So, software development can be done using waterfall, but introducing some Agile thinking. For example, while using waterfall, introduce Agile-type rituals - like a daily stand-up - to start with.

Mix 'n match

Software development does not have to be 100% Agile or waterfall - the focus should be less on how and more on 'what' is being developed that produces some level of value. Companies and stakeholders get hung up on the word 'Agile' where they shouldn't even label it - it's how software is developed in a more expedient and value-driven way.

Many businesses trip over their own feet labelling themselves Agile.

Or they see pockets of Agile in a waterfall company and it becomes 'us and them'. It shouldn't be that - the lines should be blurred based on the maturity of the business and software development teams involved. The more mature and holistic the cross-functional team, the better quality the software will be.

Companies tend to think Agile is the reserve for software developers - that business doesn't do or can't do Agile, and neither do the business analysts or designers. People forget what the word 'agile' means. They don't necessarily see it as embracing flexibility or change; they perceive it as rigid, following a rigid methodology and not allowing for chaotic change or adaptation. People also don't see it as an extension of what they do; they see it as ring-fenced.

Business (ie, everyone who doesn't code) can be Agile too - when users say they are Agile and confine themselves to developing software, they're restricting themselves. Agile principles can be used in HR, accounts, marketing... It's not applicable to all of a business' processes, but it can be used to engage the wider business, break down silos, enable departments or teams to be cross-functional, get stakeholders and decision-makers to prioritise to get value into users' or customers' hands early, and get rapid feedback for continuous improved delivery.

Many businesses trip over their own feet labelling themselves Agile.

Another common misunderstanding relates to 'stories' and 'features'. In the Agile world, there are 'user stories', and in waterfall there are 'features'. A story is still a feature that helps users complete something - the misunderstanding is that a story is customer-focused while a feature is something the business requires. This has come about because in Agile, a requirement comes from two places - the business, because it needs to build something to make money and be sustainable; and the customer, because customers need to do things too. In waterfall, features come from the business. That's why in Agile, a customer story or user story makes that distinction.

Because Agile projects are developed and delivered incrementally, design - of a visual nature - is also considered to be a low priority. This isn't the case; design is completed incrementally because the focus is on getting core features working and delivering value quickly. If the app or product is completely dressed, then trying to undress and undo the visuals becomes more difficult later on.

Ultimately, the best way to develop is the one that will give the business the greatest value (eg, best product) - Agile or waterfall, or a mix of both.

Share