My general contention is that business’ goals haven’t changed in ages, even with the introduction of the Internet, and I don’t see them changing either. The mechanisms by which businesses address these challenges might change, but they’re still doing the same things. So when people say “developers must change from doing x to doing y“, or say “businesses must start using [insert new social media thing]“, I’d argue that although they might be doing something different, their reasons and goals remain the same.
I’m not looking at the world as a pure developer. While I was a developer, I tried to look at the business goals, and the ‘why‘ of a request, not just the technical ‘what‘ specifics. I’m now a business analyst, so in some ways this career transition makes sense.
My comments on the Agile Manifesto are as a former developer who was part of a web development company, which built web solutions for businesses as clients. These viewpoints may be different to someone whose client is the same business they work for (as an in-house developer for instance).
My immediate observation on this manifesto is that these principals are VERY developer-centric. Project managers and developers with a more worldly outlook will struggle with some of these, and if a PM thinks that these are all you need, then I’d be concerned.
Lastly, if I disagree with these principals, or I see things more in a more nuanced fashion, then yes, you can accuse me of being jaded and cynical. Projects can still succeed even while not following pure agile processes. The strength of the people involved is the most important quality of a project, and the processes you follow should be secondary to what you deliver.
Anyhoo, onto the principals:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
I’d challenge this. This would be true if you view yourself as purely a software developer. Even as a developer, I saw myself as solving a business problem, which covers much more than just delivering software (not every business problem can be solved through software).
I would rephrase this as ‘Our highest priority is to satisfy the customer’s business needs‘.
Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
I’d challenge this. Developers (including Project Managers) are often not in a position to evaluate a client’s competitive advantage, unless they’re part of the business. More often than not, they’re there to build what they’ve been asked to build, as determined by the client.
Changing of requirements as discovered through the iterative process are fine, but how they get addressed is a project management issue. The RFP usually spells out what the requirements are, so to change this can be a difficult process, and not one for the developers to face alone.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
It depends. If your deployment and bug tracking processes can handle feedback from multiple deployments, then go for it. I prefer to have a big fat full stop at the end of a development iteration, which then goes into a testing and feedback phase.
Doing development work during this time is risky as you may end up with defect tickets which have been solved as part of the ongoing development – keeping track of the ‘relevant’ bugs can be hard in these circumstances.
However it’s done though, the delivered software for each iteration must accurately reflect the requirements (as known at the time), so the timescale needs to realistically reflect what’s possible. Otherwise you’ll get people lodging defect tickets about missing features or bugs that you already know are missing or not working.
Business people and developers must work together daily throughout the project.
I disagree. Strongly disagree. I’ve worked on projects which were explicitly sold as being run on the ‘agile’ methodology, but the client had absolutely no intention of having daily or even weekly conversations. The ‘let me know when it’s finished’ mentality is still strong, and if everyone is happy with that and the implications this brings, then go for it. Bombarding people with daily meetings with information that they don’t understand or don’t care about will result in them disengaging from the process.
PROTIP: make sure your meetings are of high value.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
I agree. However, this is a very delicate balance. Oversight is needed to stop people going rogue, but overbearing time tracking will crush morale. Developers need to demonstrate that the client can trust them, and work to maintain that trust. The processes that are required should reflect the level of trust between the group. If the client is wanting daily progress updates, then ask yourself, what did you do (or did not do) to require this?
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
I agree. Sometimes though, an email or telephone conversation will suffice. Dragging everyone into a meeting where only one person does the talking is a costly waste of time.
Working software is the primary measure of progress.
I’d challenge this. I’d replace ‘progress’ with ‘success’, and if ‘working software’ is the primary measure of success, then yes, I agree. But I’d bet good money that there are more and bigger issues for the business which should be considered. I’d also ask ‘what does working mean, and for whom?‘. Clients sometimes have a lower threshold for determining ‘working’ than developers, who may instinctively prefer 100% code coverage and unit-tested code.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
I agree. I have no problem with this idea. If your development, reporting and deployment iterations are to everybody’s satisfaction then this shouldn’t be a problem.
Continuous attention to technical excellence and good design enhances agility.
I’d challenge this. Having worked on projects which were abstracted out to rediculous levels, I think the effort required to understand and maintain ‘technically excellent’ projects like these detract from the agility of the project. I’d personally emphasize ‘fit for use’ code, which strikes a balance between the current needs of the project and the expected ongoing life of the project. If this means a simpler, less fancy architecture, then so be it.
Simplicity–the art of maximizing the amount of work not done–is essential.
I agree. If this refers to project management issues, then sure, this sounds like a grand idea. If this refers to code re-use, then this a development best-practice issue, not a project methodology.
The best architectures, requirements, and designs emerge from self-organizing teams.
I’d challenge this. This is such a people-dependant issue, that I’m not sure if it would work without at least a bit of management oversight. The goals of the business or project have to be communicated extremely clearly, and the teams need to have complete buy-in to the ideas. If this can’t be guaranteed, then it won’t work.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
I’d challenge this. In my experience, people pay lip service to this. Everyone agrees that there are problems or issues, and then carries on doing the same old thing. This is especially true when there are multiple stakeholders or dependencies for whom this project isn’t the biggest priority. Sometimes things suck, and that’s just the way things are.
So there you go. I think agile is a collection of common sense approaches, but depending on the project you have, some aspects of it may not be appropriate. And if you consider your people to be the key asset of an effective team, then it doesn’t even matter what methodology you use.
It’s the people, not the process.