What Developers Need to Know About Agile

Agile is mostly driven driven by managment and consultants, seldom bottom up by developers. Some developes are suprised about agile and don’t know how to react. Lots of literature is written about agile, but very little with the developer in mind. What do you need to know about agile as a developer?

I’ll primarily talk about Scrum as the most successfull (in term of adoptions) agile method, but most applies to other agile methods.

What developers need to know about agile

  1. Much less crunch time due to better estimation, more detailed and better planning. Agile is often pull instead of push, so developers pull their work from a product owner, contrary to work pushed onto them by managment (see below). Because features are no longer pushed and there is no abitrary deadline, there is a lot less crunch time. Crunch time happens if agile teams underestimate the work or overestimate their ability. Over time estimation gets better and crunch time at the end of a sprint vanishes.
  2. More working on features. Developers in agile are not working on whatever someone wants, whatever comes to managments mind in the morning after getting up. Agile has better planning and the backlog in Scrum leads to less chaos and more predictability. But because stories and iterations are short, product management is more agile as before.
  3. Less meetings. All meetings in Scrum are pre-defined meetings and include daily standups, estimations and planning. There are much less ad-hoc meetings, meetings are time boxed and are shorter, all meetings have a clearly defined purpose with defined work results. So I consider meetings in Scrum not “meetings” but real group work. There are especially less panic status meetings because there is no crunch time.
  4. Pull not push. Developers pull features (stories) from a product owner during a planning session. They pull as many as they can do. Requirements are not pushed from customers or product management. Pull as many as you can do, strife for increasing your work.
  5. Be a critic. Agile expects you to be a critic with requirements. Your opinion is needed, there is no push in requirements. Martin Fowler writes in Conversational Stories:

    In terms of coming up with stories, what this means is that they are always something to be refined through conversation – and that developers should play an active role in helping that definition.

    Good stories follow the INVEST principle: I – Independent, N – Negotiable, V – Valuable, E – Estimable, S – Small, T – Testable. Negotiable means your opinion as a developer is needed.

  6. Agile makes you happy. There are problems in agile, and things developers need to adapt to and usually do not like at first. But in all teams I’ve worked with, satisfaction went up after the introduction of Scrum and most developers – though not all – want to stay with agile after it’s introduction.
  7. Responsibility as a team. The team wins or fails, not individual developers. The team has committed itself to stories, all developers have promised to finish those stories in the next sprint. Don’t take this lightly, it’s a major shift in responsibilites. Help each other, it’s no longer “We failed because A didn’t do B.” If the team failed, you failed.
  8. Agile is about working, high quality code. The result of agile is working, high quality code. Quality is king, pull only as many stories as you can do with high quality. Do not sacrifice quality. The pull principle (see above) gives you enough leverage to not compromise on quality. Live for software craftmanship.

Agile is a different way for thinking. Embrace agile as a developer, it will change your life and make things easier (and only some things harder) and make you love your work and your profession more.

Comments are closed.