DZone
Thanks for visiting DZone today,
Edit Profile
  • Manage Email Subscriptions
  • How to Post to DZone
  • Article Submission Guidelines
Sign Out View Profile
  • Post an Article
  • Manage My Drafts
Over 2 million developers have joined DZone.
Log In / Join
Refcards Trend Reports Events Over 2 million developers have joined DZone. Join Today! Thanks for visiting DZone today,
Edit Profile Manage Email Subscriptions Moderation Admin Console How to Post to DZone Article Submission Guidelines
View Profile
Sign Out
Refcards
Trend Reports
Events
Zones
Culture and Methodologies Agile Career Development Methodologies Team Management
Data Engineering AI/ML Big Data Data Databases IoT
Software Design and Architecture Cloud Architecture Containers Integration Microservices Performance Security
Coding Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
Culture and Methodologies
Agile Career Development Methodologies Team Management
Data Engineering
AI/ML Big Data Data Databases IoT
Software Design and Architecture
Cloud Architecture Containers Integration Microservices Performance Security
Coding
Frameworks Java JavaScript Languages Tools
Testing, Deployment, and Maintenance
Deployment DevOps and CI/CD Maintenance Monitoring and Observability Testing, Tools, and Frameworks
  1. DZone
  2. Culture and Methodologies
  3. Agile
  4. The Single Most Important Thing in Agile

The Single Most Important Thing in Agile

Unfortunately, the one principle practitioners need to grasp isn't explicitly stated in the Agile Manifesto.

Dele Sikuade user avatar by
Dele Sikuade
·
Sep. 04, 19 · Opinion
Like (18)
Save
Tweet
Share
31.01K Views

Join the DZone community and get the full member experience.

Join For Free

One thing

Agile can ultimately be boiled down to just one thing. What's that? If I told you, you probably wouldn't read much further now, would you?

Another stand-up; another pointing session. Each team member recites the mantra ‘where I am with my work and how long do I think there is to go.’

As the ceremony unfolds, the scrum master notes down the project blockers and extracts a promise from the product owner to help clear them.

After the team has gone, I reflect on why management is paying me to help them with their Agile development. It's quickly obvious: The team knows how to use the tools, they know the process; it’s the principles they haven’t grasped.

Unfortunately, the one principle they need to grasp isn't explicitly stated in the Agile Manifesto.

Agile, for all that it can be broken down into best practice activities and output, is about just one thing: You can only give people what they ask for, not what they want.

I once rewrote the 12 principles of the Agile Manifesto to reflect the strongly held view of mine that there is really only one principle and the rest are just rules. I only released two of them because I got a backlash from people who thought I cared about scrums and backlogs and sprints and blah and all the things they care about.

I have no aspirations to be anyone’s scrum master, and I don’t care about any of these things; packaging work up and managing delivery and expectations is not unique to Agile, and it’ll be here for as long as it is obviously better to use a kettle to make a cup of tea than boil the ocean.

What I do care about is that people understand why we work in Sprints, why we insist on the participation of the business, why Agile is such an effective methodology when properly understood.

The reason is this:

If you can only give people what they ask for not what they want, then you’d better show them what they’re going to get as soon as possible and involve them in bridging the gap.

Don’t let some bright spark claim that this gap is a problem of an ineffective requirements gathering process. Duh! Of course you should try as hard as you can to get the requirements nailed down accurately (is this a conflict with the Agile Manifesto’s be happy with late changes? Discuss).

Accurate requirements can’t solve the problem that people don’t know what they want until after they see what they’re going to get. If there is any doubt about the truth of this, here’s an exercise that I use to demonstrate it:

Get a group together, any group it really doesn’t matter, sit them down so that they face you, and get yourself a flipchart. Ask the group to list all of the features of a car that they think they would need. Write every feature down – steering wheel, seats, wheels, gears, etc.

At the end, when there are no more requirements forthcoming, draw them a car with one of the actual features of a car missing – there will always be dozens!

The last time I did this the team forgot that they might want their car to have doors (and brakes, and an aerial for the radio and…). You can play the ‘you forgot to tell me something that you only realized when I drew a car without it…’ game endlessly.

In other words, until they see the car and discover what is missing, they don’t think to ask for it.

Agile is a methodology that was formed to bridge the gap between abstract requirement and real-world want. It implicitly acknowledges the existence of the gap by requiring the business to participate and therefore to be complicit in the process of development and delivery.

It is the best methodology I have ever seen for overcoming this problem, and this problem is the single biggest cause of pain in software development. This problem is the reason for the existence of the universally hated Change Request, which is about who is going to PAY for the gap.

The solution – that you need to show people what they’re going to get so they can help you build it for them – seems so cheap I’m ashamed to sell it.

Then again, the team that has been working in an Agile manner for several years left the room to work on their sprint without ever telling me (or each other) what it is we’ll be able to see either during, or at the end of it.

It might be Agile to them; to me it’s just coding in the dark.

Originally published October 2014

Further Reading

Why Don't Software Customers Just Say What They Want?

How to Handle Software Requirements Change After Implementation Has Begun

agile scrum

Opinions expressed by DZone contributors are their own.

Popular on DZone

  • GPT-3 Playground: The AI That Can Write for You
  • DevSecOps Benefits and Challenges
  • Silver Bullet or False Panacea? 3 Questions for Data Contracts
  • Top Five Tools for AI-based Test Automation

Comments

Partner Resources

X

ABOUT US

  • About DZone
  • Send feedback
  • Careers
  • Sitemap

ADVERTISE

  • Advertise with DZone

CONTRIBUTE ON DZONE

  • Article Submission Guidelines
  • Become a Contributor
  • Visit the Writers' Zone

LEGAL

  • Terms of Service
  • Privacy Policy

CONTACT US

  • 600 Park Offices Drive
  • Suite 300
  • Durham, NC 27709
  • support@dzone.com
  • +1 (919) 678-0300

Let's be friends: