DEV Community

Discussion on: Should Agile Manifesto be revised?

Collapse
 
tqbit profile image
tq-bit

The statement "Working software over comprehensive documentation" for me means:

There's no need to write documentation if the software doesn't work

This does not set the developer team free of writing docs. And I find tests to be complementing parts of the documentation.

To answer your question: I don't really disagree with anything about the agile manifesto. I disagree with how it's being used by people who try to adopt an agile style without at least trying to adopt agile culture.

Collapse
 
dadyasasha profile image
Alex Pushkarev

That maybe what has to be addessed - I think in average with the current wording of the manifesto there're very good chances it will be misinterpreted. Should we change the wording to decrease the chance of it happening?

Collapse
 
tqbit profile image
tq-bit

I'm not sure if a change in wording will be the ultimate solution.

What really is necessary is to emphasize that agile PM is fundamentally different from waterfall PM. Where the former emphasizes the final product and its stakeholders, including the dev team, the latter puts the process(es) over pretty much everything else.

What I figured happens in companies is the following:

  • They get a well-paid agile coach to install 'an agile process'
  • Coach holds 3 months worth of workshops, leaves.
  • People who worked their whole life in waterfall are happy, but confused.
  • They're "empowered" to work as they like, but still receive unidirectional orders from their superior.
  • Enthusiastic manager starts holding 'sprint meetings'. Which are basically the same meetings as before.
  • The result: An agile(?) waterfall. In fact, more waterfall than agile.

I'm being overdramatic, but you'll catch the core message.

Anyway, if you'd like to change anything about the agile manifesto, I'd say is make the following its headline:

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The rest will sort itself out somehow.

Thread Thread
 
dadyasasha profile image
Alex Pushkarev

OK, but what if we don't have access to motivated individuals and there's no time to build the environment?

Thread Thread
 
tqbit profile image
tq-bit

Then you regularly play your national anthem and make your co workers goose step through their working day.

There are some companies that aren't (and shouldn't be) agile. Do you think your plumber takes part in sprint artefacts? They arrive, do their job and leave.

With development, that's a different story. Until it isn't. As a motivated individual, it's up to you to know the difference. And when it's time to leave for a company that's capable of implementing an agile culture.

Which - again - after some time will sort itself out.

  • Talented people pool at 'good' companies
  • These care enough to trust and value their employees
  • The individuals then build the environment they wish to have
  • Which in turn attracts more talented people, and so forth