3 Reasons Why I Wouldn't Do Agile Software Development
DZone's Guide to
3 Reasons Why I Wouldn't Do Agile Software Development
Join the DZone community and get the full member experience.
Join For FreeWhatever new awaits you, begin it here. In an entirely reimagined Jira.
Agile software development has been a revelation for me. It has brought me and my teams much success, and a very rewarding working environment.
Sometimes I hear people say that agile development isn't appropriate in all circumstances.
In fact, I used to say that myself; however now I'm not so sure.
There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:
1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.
2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.
3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.
In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!
When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.
I think I would do agile on a fixed price, but I would be very careful to:
On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.
I'd love to know your thoughts on this: When wouldn't you do agile software development?
Sometimes I hear people say that agile development isn't appropriate in all circumstances.
In fact, I used to say that myself; however now I'm not so sure.
There are some circumstances where an organisation's culture is possibly too different to successfully adopt agile. At the moment I can think of only 3 reasons why I wouldn't do agile software development:
1. If I was working for an organisation that believed it needed complete clarity about a solution before it could start a project. I believe this is a false positive, and it would be very hard to adopt agile in an environment where key stakeholders insist on this.
2. If I was working for an organisation where the relevant product owners couldn't - or wouldn't - commit to being actively involved throughout the project. I really do believe that active user involvement is the first principle of agile, and imperative for a project to succeed.
3. If I was working with a team that I didn't believe could cope with ambiguity, or didn't have sufficient communication skills to collaborate effectively with business colleagues or customers.
In these circumstances (particularly if combined), adopting agile could be very difficult indeed, because in my experience these 3 agile principles are critical success factors!
When writing this list, I did also wonder whether to add fixed price projects to my list? Working from a feature list, having no more detail about the features up-front, and allowing change throughout the project, could potentially be a complete disaster with some clients on a fixed price contract.
I think I would do agile on a fixed price, but I would be very careful to:
- Understand the client's attitude towards scope up-front, and be very clear about the fact it's fixed price, not fixed price and fixed scope. In other words, they can add or change features throughout development, giving them the benefits of flexibility, but will need to remove other features to do so.
- Build in sufficient contingency and allow for a reasonable number of changes to happen without too much debate. You are taking the risk on a fixed price project. The client needs to pay a premium to offload that risk to you.
On the other hand, I'd probably try to persuade the customer that T&M (Time & Materials) is not a problem with agile software development, because of the level of collaboration, visibility and transparency, and the frequent delivery of working software.
I'd love to know your thoughts on this: When wouldn't you do agile software development?
New roadmaps, more flexible boards, and dozens of new integrations. And that's just the beginning.
Like This Article? Read More From DZone
Topics:
Published at DZone with permission of Kelly Waters , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
{{ parent.title || parent.header.title}}
{{ parent.tldr }}
{{ parent.linkDescription }}
{{ parent.urlSource.name }}