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.

ScrumMaster and ZenMaster: The joke of certification

Many people object to ScrumMaster certifications:

  1. It's a money making machine
  2. Scrum Masters do not learn anything during classes
  3. The certification is nothing worth - because nothing is certified

I have been a Certified ScrumMaster (CSM) and a Scrum practioner for some years. People who object to the certification do see it from the wrong angle. You need to understand Zen to understand the goodness in CSMs.


Nénuphare
Creative Commons License photo credit: darkpatator

Certification is a Zen joke, because the role of a ScrumMaster cannot be certified. It's not about knowing some technical questions. What should a trainer certify in such a class? That you can lead an agile Scrum team as a ScrumMaster? No one can certify the fact that you're a leader, catalyst and enabler. You either are or you aren't. Zen masters (ha, another master without a master!) would laugh at the fun in the ScrumMaster certification. They laugh about the idea of certifying enlightenment.

Scrum without ScrumMasters

As another parallel, both in Scrum and in Zen, masters are only enablers. They are not needed after the act of enabling Zen/Scrum. My Scrum trainer told me, the goal of a ScrumMaster is to make himself obsolete. There is a Zen koan which goes like this:

If you meet the Buddha, kill him.
— Linji

If you see a ScrumMaster, kill him. Zen tells you:

If you are thinking about Buddha, this is thinking and delusion, not awakening. One must destroy preconceptions of the Buddha. Zen master Shunryu Suzuki wrote in Zen Mind, Beginner's Mind during an introduction to Zazen, "Kill the Buddha if the Buddha exists somewhere else. Kill the Buddha, because you should resume your own Buddha nature."

If you think the ScrumMaster is Scrum, you're delusioning yourself. In Scrum the product owner and the scrum team can, and should from my view, act by themselves, without the need of a ScrumMaster. The ScrumMaster helps them achieve their Scrum. Helps them overcoming initial obstacles in their productivity.

Kick your ScrumMaster
If the ScrumMaster is not good enough for them, certification and coaching inside the company hasn't helped, the Scrum team has always the right to kick their SM if he isn't good enough for them. And they should do so. If in Zen a master isn't good, pupils will just leave him. This might lead to problems within the organization, especially if the ScrumMaster is their boss, but that should be the problem of the organization, not a team problem.

Practitioner certification

There are many more certifications from the Scrum alliance. If you dig deeper, the real fun part is that CSM doesn't mean anything, practitioner means much more:

The practitioner level of certification (CSP) is only offered to those CSMs who have hands-on experience using Scrum. Applicants must complete an extensive questionnaire with probing questions that focus on applicants’ real-world experience using Scrum on software development projects. Their application is reviewed for answers demonstrating competence and comprehension of principles that can only result from hands-on work. The applicant may be questioned to determine eligibility. To maintain CSP status, you must submit a new application every two years.

Is the certification any use?

Yes. The Certified Scrum Master training has several merits:

  1. Calling the Scrum training "Certified" guaranties the quality of the trainer
  2. It motivates the Scrum master to think in Scrum
  3. If managers take part, it helps the organisation adopt a "we can do it" view about Scrum
  4. Certification (CSM) seems to be one of the main reasons for Scrum success in the enterprise. The certification makes Scrum compatible for managment.

The view about acceptance is shared by Peter Stevens:

It is also about branding, and has been quite successful. The acceptance of the CSM program is high (especially from corporate customers, and this is where the money is). I believe the CSM program is an important reason why Scrum is better accepted than say, XP, in corporate management circles.

Scrum is successful. I've seen it help development departments gain productivity. If you do not scrum yet, go for it.