Response Crafting

Agile is not a process. It’s a philosophy.

Leave a comment

It was meant to be far simpler than what it’s become.

The concept of “agile” development and its manifesto came out of a small group who met at a ski lodge in Utah. Looking at how the concept has evolved in over a decade, Dave Thomas, one of these original seventeen, now asserts: Agile is dead. “The word ‘agile’ has been subverted to the point where it is effectively meaningless, and what passes for an agile community seems to be largely an arena for consultants and vendors to hawk services and products.” People everywhere have spun the original 68-word manifesto into conferences, books, professional training, certifications, and, perhaps even most alarming: strict, dogmatic, formal processes.

This was never the point.

At the heart of Agile were four very simple original concepts:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

In other words:

People are more important than process. 
Development is more important than documentation.
People are more important than documentation. 
Development is more important than process. 

People and Development matter. Process and Documentation do not. 

1. People. And the belief in valuing people.

At its core, Agile is about having a very deep commitment to people – the team; the client. It is a commitment to trust, to show consideration for others, to remove hierarchies and promote each team member to “equal,” to honor transparency and maintain open dialogues – with each other; with outside stakeholders, with the client. It means collaboration and communication and concern for others.

2. Doing. And the dedication to moving forward. 

The idea is to free up the team to actually build things. To build things and share them, to get feedback, to implement it, to iterate, try again, and keep moving. Talk. Have a conversation; share ideas; share work; share feedback. Develop. Program. Progress.

People. Development.

That’s it. 

Nobody ever said anything about scrum boards. Stories. Story points. Scrum masters. Sprints. Sprint reviews. Sprint planning. Sprint retrospectives. Daily stand-ups. And certifications on any or all of the above.

None of that matters.

Not that there’s anything inherently wrong with those things – many of them serve as a helpful framework. The problem is when teams try to employ these things without altering their underlying value set. They try to simply lay Agile tools on top of their projects at the surface, while making no change to their conservative viewpoints on hierarchy, documentation, project plans, productivity, collaboration, work ethic and, most importantly, how to treat people. And then fail to understand why it’s not working.

While those tools may help you achieve a more agile development model, if you are approaching Agile by blindly adhering to a new process – if you simply see this as substituting a waterfall methodology with a new one – then you’ve missed the whole point.

There is a difference between the letter and the spirit. When one obeys the letter of the law but not the spirit, one is obeying the literal interpretation of the words (the “letter”) of the law, but not the intent of those who wrote the law. Conversely, when one obeys the spirit of the law but not the letter, one is doing what the authors of the law intended, though not necessarily adhering to the literal wording.

Right now, the vast majority of teams experimenting with Agile and attempting to employ it are obeying the letter of what they believe to be the methodology – which was developed after the fact – while overlooking the importance of the spirit of what it is.

Want to be good at shipping software (or, really, most anything else?) It’s really pretty simple:

Value people and progress. And always choose those over plans, documentation, rigidity, and process. 

Trust the team. Let them self-organize rather than impose hierarchies on them.

Keep the team moving. Resolve blockers, lead with clarity and a sense of direction, and give them what they need.

Build relationships. Invest in an ongoing dialogue and strong rapport; anticipate changes and address them as they happen, instead of trying to CYA with documentation around what was said one time. Project plans don’t create success. Project teams do.

Manage to morale. This is the absolute gold of the whole entire project – sabotage your team’s morale, or allow it to be sabotaged, and you put the entire delivery at substantial risk.

Accept imperfection. Encourage a degree of ambiguity. Welcome the work in progress. Embrace change.

Pushed to make a decision between two things, always choose the one that benefits people – the team; the client – and keeps them moving forward against the goal. Relinquish the idea that any other metric or measurement matters even nearly as much.

If developers are reluctant to offer estimates, let it go for now. Recognize that it’s an issue with trust (in management) or experience, or both. The focus here should be on building confidence and comfort, not pushing for a number just to fit a process. If story points are throwing the team into a tailspin, nix them for now. Always align yourself with and invest in the wellbeing of the team and their progress. Stop force-feeding them (or yourself) any other idea of “have to” or “must” or “how it’s done.”

Care. Drive.

That’s it. You get those down and you’ve got it all.

DCF 1.0


Share your thoughts

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s