The discipline that is software engineering is supported by many methodologies and technical applications, and while methodologies and technical approaches are valuable they often present challenges to the user and the wider stakeholder community.
One of the most compelling arguments for using agile methods is its core doctrine. At the heart of its doctrine is empowerment (and of course highly competent developers).
Agile subscribes to the values of communication, courage, feedback, humility and simplicity. Such values are conceptualised in the methodology and are measured in the way users engage and build adaptive technical communities.
Although agilists value individuals and interactions over process and tools the authors have long advocated the benefits of gaining economies of scale by using the same toolset.
All too frequently however the approach to development seems to include inventing a completely new technical approach for every project which leads to ever-increasing overheads in development and support, pockets of disintegrated technical expertise and difficulty in mobility of resources.
Obstacles
In adopting agile methods the development manager is faced with many obstacles and risks. One obstacle is customer bureaucracy. Customers who have a limited understanding of development practices tend to overcompensate and swamp the development process with users and managers who add little or no value to a project.
In our experience this happens frequently in low-maturity level organisations. In choosing to use agile methods for project delivery it is important to influence the customer and the project stakeholders that 'less is more'.
Buy-in is essential and agile needs strong supporters but the developers must receive clear signals that what they are doing is worthwhile. There is nothing more frustrating to a development team than seeing their work go to waste.
Some of our peers would argue that, even with the plethora of sophisticated and adaptive methodologies at our disposal, how difficult it is to develop software today relative to a decade ago.
One of the characteristics associated with agile methods is emergent architecture (that is, both technology and requirements emerge through the development cycle).
Whilst this may present an opportunity for the customer, it presents a potential threat to the development team and their project stakeholders. We have all experienced situations in which the development team have performed below expectations due to this ideological belief.
Experienced software architects know that the development of architecture under agile is very difficult to achieve first time round and requires an iterative and incremental approach.
This incremental approach goes some way to mitigating the risk of an inadequate or inappropriate architecture. During this process it is common to use diagrams or models to convey the message.
Although architecture diagrams and models are obviously used to convey the 'what' of the architecture, they can do little to explain the 'why'.
It is absolutely crucial to explain the 'why' of things and to document the rationale for the trade-offs that have been agreed - so when the business requirements change, the impact on the architecture and design and the thought processes behind it can be traced.
During the initial iterations it is vital that the technical team and the customer come to an agreement as to the landscape of the system that they are constructing.
Although these technical design meetings may be painful they are nevertheless critical and if total agreement cannot be reached then some majority agreement is recommended so the project can start moving forward.
Competencies
A significant and critical success factor when employing agile methods is the people who will work on the development team. According to Professor McManus a significant consideration here is the unavoidable truth that many of the world's software developers are below average.
Critical competencies for developers using agile methods include interpersonal skills, technical competency in software engineering, and verbal communication skills and leadership.
A recent assessment by Constantine1 identifies leadership as a potential threat to agile projects. All agile methods put a premium on having the best people. It is unrealistic to assume that every person employed within the team will be best of breed.
We are convinced however that at least 70 per cent of the team must possess high levels of competency in technical (that is having built similar systems in the past) and interpersonal skills.
A characteristic of software engineering projects is variety and complexity. As a rule of thumb the greater the complexity the greater is the stakeholder involvement. One of the major disputes within the agile community and among software managers is how to reconcile the different needs of stakeholders.
In our experience client organisations and providers of software engineering capabilities have limited resources and as such stakeholders compete for these resources. Stakeholder values and their requirements often differ widely and there is usually a highly skewed distribution of resources among stakeholder groups.
Typically on agile projects, and depending where you are in the life cycle, stakeholders have different priorities, different objectives and different styles of influencing. This cocktail of priorities, objectives and influence, and the unequal distribution of resources generally exacerbate conflict even in closely knit teams.
Complexity
Conflict kills projects - it is a sad fact that many software developers (and project managers) do not manage customer and stakeholder expectations well.
Many users have a strong tendency to work with and please the development community and this can put them at odds with their paymasters who are generally trying to push for early completion or a reduction on price.
In managing customer and stakeholder expectations it is prudent to consider that each has the ability to both threaten and cooperate; the objective is to reduce the threatening element and increase the cooperative behaviour.
It is important to realise their potential to act and their willingness to act are not directly related. Therefore, when looking at ways to reduce conflict, it is important to examine not only those individuals who are positively disposed towards the project but those who are negatively disposed towards the project as well.
Our experience suggests that there are limitations and some strategies may only be appropriate for those stakeholders with a specific disposition towards the project, whether positive or negative.
Given the unrealistic expectations of many customers and end-users, getting people to buy in to an agile project is not an easy undertaking and as previously outlined requires a high level of leadership competency.
Those that lead agile projects must possess enormous process and planning capabilities and the courage to say no to the customer and to their superiors. We see a lot of misapprehension from customers, users, IT directors and account managers on what agile technology projects can realistically deliver. Setting unrealistic expectations is not a win / win scenario.
Expertise
All agile projects rely on business expertise and explicit documented knowledge. A good piece of advice is to involve the business experts as much as possible during the development process and keep simplicity in mind at all times.
Frequent assessments will help the development team and your stakeholders understand the complexity and the risks involved.
One of the criticisms of agile methods is that they do not work for complex systems with high performance requirements. Amongst technical architects there is some disagreement about suitability of agile for these types of projects.
Some argue that agile methods work if performance requirements are made explicit early and if proper levels of testing can be planned for. The limitation here is the methodology. At some point the team's ability to function is dependent on the domain expertise and the flow of information between developers and users.
When agile methods employ documentation, the methodology emphasises doing the minimum essential amount. Documentation cannot be traded off and should be factored into the cost of development as a high-level priority.
Strength or weakness
In contrast to other software development methods where it can be difficult to see what value functionality will have until it's gone through user acceptance testing, agile developments allow the users to assess the usability and performance early in the development cycle.
Words of caution here are to remember to keep it as simple as possible. In most agile projects, no matter what the development tool, you will only have time to test the minimum. In advance determine what the minimum amount of testing will prove to the users.
People have a negative view of the word 'minimum', but if it wasn't 'good enough', it wouldn't be the minimum.
To conclude - a weakness with developers is their propensity to oversell agile. Those who work with agile methods are sometimes faced with moments of truth - is the hardest lesson accepting that the method has boundaries and limitations, and not knowing a methodology's limitations? You decide.
