ND8 DEVELOPMENT
Best Practice Software Development
© ND8
Thursday, July 23, 2009
Adapt or Die - Project Management in an Agile World
Adapt or die is the challenge to project managers confronting Agile development for the first time. Out go detailed Pert and Gantt charts. In come leadership, management by objectives, negotiation, facilitation, coaching and support.
In some methods the name changes – e.g. Scrum’s Scrum Master – but the major responsibilities remain the same; deliver on time, to budget, to scope (at least the Must Haves) and to agreed levels of quality.
So where does the PM start. First they need to understand, own and drive the development process. Good agile development is in fact an extremely disciplined approach with up front prioritisation, tight development cycles and heavy use of techniques such as TDD and continuous integration, without which the approach falls apart.
Second they must adapt their management style. The manager must agree SMART objectives with the team. It then becomes the responsibility of the team to determine how best to meet those objectives, and the manager to ensure they have the tools to do the job, and to remove any barriers or constraints to progress.
Third they must develop a deep understanding of the problem domain and a reasonable understanding of the technical architecture. Without this knowledge it will impossible to provide leadership, help the team resolve issues or challenge and negotiate with the development team and business users.
Fourth they need to become excellent negotiators, agreeing with the business representatives the relative priorities of what needs to be delivered, and then ensuring that development stops when the minimum functionality set required to realise the business benefit.
So in the future a good software development project manager needs to be part leader, part negotiator, part analyst, part process expert, part problem solver and part technologist, most likely with a solid background in development. To be honest, for me these have always been the attributes of strong project managers so perhaps not much has changed after all.
Agile Analyst - An Oxymoron?
What’s the purpose of the analyst in an Agile team, or perhaps the question should be
reframed as “what is the purpose of analysis in agile development?” where the onus is on starting the development as soon as possible.
Perhaps the best place to start is to remind ourselves what the purpose of analysis is in general. This is to “understand enough about the problem domain to allow a solution to be developed”. Depending on the project this may need to cover a number of different aspects of the problem domain, from an understanding of business processes the solution needs to support to the detail of the business rules that need to be applied, and a variety of techniques have been developed to facilitate the analysis process such as business process modelling, user centred design, use case analysis, interaction diagramming, class modelling, etc. etc.
Clearly in Agile development, gaining an understanding of the problem domain is as important as ever. The real question is how is this accomplished. In an agile world the most important method of developing understanding is the feedback loop, the argument being that users – or people in general – don’t fully understand what they want until they see it, and therefore the best approach to defining the solution is to let it evolve through a series of short iterative cycles. In my experience this is absolutely correct. It is virtually impossible to fully specify a system correctly before the development commences and a near certainty that something highly important will be missed, and by the time this is spotted it will be too late to rectify.
Another key aspect of the Agile world that has an impact on analysis is the emphasis on direct communication between the agile development team and the business expert. Clearly the “evolution” of the solution has got to start from some firm understanding of what is required. The tasks of the users need to be understood, the major entities needs to be identified, the business rules need to be defined, etc.. In traditional developments the role of the analyst is to develop this understanding and communicate it to the developers, but in Agile is this seen as a level of in-direction too far. Again this is absolutely correct. In discussing the requirements of the users a level of tactic knowledge develops, highly important to the quality of the overall solution, but that typically never makes it into the specifications.
Perhaps the final aspect of Agile that impacts on traditional analysis activities is the level of documentation produced. Agilists promote verbal
communication over the development of specifications, hence the requirement for full time user involvement. Again it’s difficult to disagree. The agile team still need to understand the problem domain, and use case models, state transitions, domain models and the rest, are proven techniques to facilitate this. The difference is that these things will be developed informally, as and when required, through direct communication between developers and users. All analysis products are transient in nature in that they are a means to an end, rather than an end in themselves, so the trick is to do the minimum, as informally as possible.
So at this point things are not looking so rosy for the traditional analyst faced with their first Agile project, and as someone who spent a large proportion of my career working as an analyst, this is not a conclusion that’s lightly reached. Perhaps our traditional, generalist, analyst’s time is up.
However this ignores the fact that good developers do not automatically make good analysts (I once ran a training course role playing use case definition, a developer playing the analyst and myself playing the user. The developer asked whether I needed an atomic transaction, I explained I didn't need any nuclear related functionality in the order processing system, the developer persisted with his line of questioning until it became too painful to go on) so ensuring at least one person in the team has good analysis skills is very wise, and if none of the developers have them, a specialist analyst is unquestionably required.
But I'd also recommend that our analysis community has a back up plan and that is for analysts to add some specialist weapons to their armoury. The skill that springs immediately to mind is usability. Usability experts bring huge value to the development process, whether it agile or not, and at its heart usability is all about analysing the needs of the user in terms of how they go about their work. A natural fit then.
Good analysts with usability analysis and design skills, and a smattering of HTML, will be required indefinitely.
© ND8
Agile People