2

By being responsible to make the product do what it needs to do, Agile can be hard on the developer. He/she is the one responsible for things not being correct, even if it was delivered what was asked / promised.

Why should a developer want to work Agile? (Not that any other methodology is better)

  • 1
    "agile" is a huge group of practices. None of them say "He/she is the one responsible for things not being correct, even if it was delivered what was asked". Can you maybe add more details to your question? – nvoigt Aug 30 at 10:47
  • @Todd A. Jacobs already addressed my concerns. When working agile, developers have shared responsibility. When they have all the responsibility (which is the case), there's one or many problems in the way agile is being conducted. Todd A. Jacobs went one step further by explaining also how to deal with such problems. – Tiago supports GoFundMonica Aug 30 at 15:18
  • Also, @Daniel gave a nice compliment by answering some reasons why a developer should still go for it (even though it can be hard). – Tiago supports GoFundMonica Aug 30 at 15:22
6

Why should a developer want to work Agile?

Because a properly-implemented agile framework improves the pacing of a project and the sustainability of the developers' work efforts. It also increases collaboration between developers and stakeholders. If it doesn't do all of these things, then the team (or the organization) is probably Doing Agile Wrong™.

He/she is the one responsible for things not being correct, even if it was delivered what was asked / promised.

This is never true in successful agile implementations. The whole team collaborates with stakeholders to build the product. The tight feedback loops and inspect-and-adapt cycles built into effective agile frameworks can control for cost, quality, and fitness-for-purpose when implemented properly.

If stakeholders or executives are "holding developers accountable" (e.g. blaming them) for building the wrong things, then they are not sufficiently engaged in collaboration with the project team. This is a often a leadership failure, and often involves process silos and organizational issues (primarily issues involving politics or cross-team communications) that can't be fixed by waving "agility" at them. The only real solutions to these types of problems are:

  1. Executive support for effective agile processes including ongoing cross-functional collaboration, process transparency, and open communications.
  2. Leadership-driven, continuous process improvement.

Teams that apply agile practices to a project are often happier and more effective than teams that don't. The benefits come from being agile, though, not just from adopting "Agile" nomenclature or applying non-agile practices, values, or principles to the workflow.

3

IT IS! People forget this or gloss over it all the time. Pushing authority down the hierarchy has a lot of benefits for the organization and the individual but it is definitely harder - and for some people, it isn't worth it. For those that find it worth it, some of the most common reasons are:

1) Pride - Along with ownership comes a pride in the work that is hard to support without ownership.

2) Purpose - For many people (but not all by a long shot), purpose is a powerful intrinsic motivator.

3) Sustainability - Most agile teams discover that they can deliver value more effectively at a sustainable pace. This leads to a more enjoyable work environment for many.

4) Comaraderie - Many Agile approaches, especially XP and Scrum, focus on connections and support between team members. Even for people who like to work independently, feeling like part of a group and feeling supported are large factors for many.

5) Lots of small wins - The iterative and incremental approach to development leads to a lot of small wins and protects against death marches on projects.

2

Todd covers quite well (+1!) the reason from an agile team perspective. I'd like to add a parallel perspective to it - why a developer would want to work on an agile team.

First of all, agile is not for every developer. Not that's a problem per se, as there's still a lot of projects out there that are follows Command and Control approaches (some even using ceremonies from some agile frameworks) and are relatively successful.

However, there's a specific set of professionals - the Knowledge Workers - that are intrinsically motivated by empowerment. The SAFe Framework promotes the autonomy with purpose to give motivation to the team.

This specific set of professionals are highly motivated by mastery, autonomy and purpose. These motivational factors applies to everyone, the difference (I believe) is that only knowledge workers find these factors within their daily work, whereas other people (the ones that aren't a good fit for an agile project) find them somewhere else out of the office.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.