In the contemporary world of software development, everyone seems to be adopting an “Agile” delivery methodology; There no longer seems to be any other way. When’s the last time you saw a project or job description describing a ‘waterfall’ approach?
To develop “Agile” you need to know “Agile”. You need to be an “Agile” developer or an “Agile” tester; does that mean a more traditional waterfall developer isn’t suited or capable of being an “Agile” developer? Perhaps we misunderstood the original agile philosophy?
When agile development was first conceived and published as the Manifesto for Agile Software Development, it was done so in a minimalist manner. It was never intended to mandate and conform the way development was done; in fact, the opposite is true.
The manifesto was made up of four basic principles:
How far to push these principles was to be dependent on the situation and no two situations are ever the same. As a result, the development methodology would adjust to reflect the specific situation and alter if the situation changed, i.e. be agile! With this context, it makes no sense to ask someone if they are an “Agile” developer if no two projects have the exact same development methodology. Asking a developer or tester if they are “Agile” is meaningless. Rather, we should be asking our technical resources the same questions we’ve always asked; do they know the technology and can they deliver?
Asking a developer or tester if they are “Agile” is meaningless.
Working agile is more of a change for stakeholders and project managers than it is for developers and testers. Is the stakeholder comfortable to trust the team’s ability to deliver without the certainty of scope, timeframes and budgets being locked down, as is often the reality of an agile project? It’s important stakeholders understand what they are signing up to. Is it practical not to have these key items established prior to commencing the engagement? Surely these should be the key drivers for how agile the project is.
Let’s take the example of a major sporting organisation needing to rebuild its online presence as part of an annual global event it hosts. The event lasts for two weeks and during that period they have millions of website visitors. The event date can’t move. Visitors to the site expect certain information to be available and updated with real-time scores. Should this organisation start developing without visibility of time and budget and hope everything is right for the event? The risk of non-delivery via such a method would prove too large for many organisations. These factors drive how agile the delivery team can be.
The delivery approach depends on the relationship built over time with the stakeholders as much as anything else. It is important to understand the strength of that relationship in order to define the development methodology. It is not as simple as one “Agile” practice fits all, otherwise it would be called “Rigid”. Is that what your workplace is now coming to?
Developers and Testers will continue to do what they’ve always done which is to complete a set of tasks. How tasks are tracked was and continues to be the job of the Project Manager (or equivalent “Agile” title). Even in a waterfall methodology the lead technical resources define tasks that need to be performed. Having roles or cross functional roles working together is not solely the domain of an agile world. This is just good practice regardless of the methodology leveraged.
From a stakeholder perspective the most important thing is not the ‘how’ but the ‘what’ and this reflects the real “agile” meaning, being able to adapt and change to the situation and ensure the stakeholder gets what they have asked and paid for. So, ask this question, “How flexible is my stakeholder?”, that will go a long way to determining how agile you can be on a piece of work.