startups and code

Agile is Dead

← Back to home

Agile is Dead - But Development Lives ON!

Let me start by saying, Yes, I signed the Agile Manifesto back in 2012. And for those who don't know, here is what it states:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

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

That is, while there is value in the items on the right, we value the items on the left more.

My Translation

We are uncovering better ways of developing software We are not creating new ways, they already exist, we are simply identifying them as they come to light

By doing it and helping others do it. "It" refers to developing software, it does not mean writing a book about how to write software, or planning on how to write software, it means ACTUALLY developing software (or helping a team develop software)

Through this work, we have come to value: It means we actually worked, we didn't theorize, we didn't pontificate, we didn't consider a hypothetical idea/process, we did the work... A LOT

Individuals and Interactions OVER process and tools This means, talk to people about what you are doing, don't look for the new Agile tool (trello/jira/rally/versionOne/etc..) just communicate. Don't over-process the process... just do the work

Working software OVER comprehensive documentation Don't worry about your 1200 design comps and feature set and mockups, create working software and then add to it. Sure you will have some basics, authentication, and even a few initial features, but you don't need a comprehensive list, just enough is enough! Make it work first!

Customer collaboration OVER contract negotiation Get your customer/user/client on board early by saying, let's work together on this and identify some key features we want, and let's get you something in a couple of weeks for you to review, that's it. I know that involves trust, and not so many lawyers, but isn't trust a great way to start a relationship?

Responding to change OVER following a plan Plan all you want, things are going to change. So why bother, just do what you need and pivot as you get feedback

This is, while there is value in the items on right, we value the items on the left more. That is not saying WE value the items on the right, we concede that there is some value, but the items on the left are more valuable for a better way to develop software

The Agile Scheme

That being said, "Agile is Dead" returns about half a million results from Google. What I am saying is not news, it is simply another article explaining why it is dead. Agile has become the biggest buzzword in project management and people are making millions on this process scheme. There are people who are Agile Coaches, Agile Managers, Scrum Masters, Scrum Coaches, Lean Experts, XP Instructors, and so much more. They teach people about the ceremonies that are preached throughout the Agile community. You must have a backlog of work that regularly groomed, and sized. You need to have enough work for the team in a sprint so you can forecast your velocity and determine the complexity of epics and then stories so you can plan for the next sprint in your sprint planning session, and make sure you have your retrospective so you can improve your process at each sprint which is measured by velocity increase over sprints. It is really insane if you think of how much process is implemented in Agile when the FIRST thing they value is Individuals and Interactions OVER process and tools.

Scaled Agile Framework

Then there is Scaled Agile Framework which is an enterprise level of Agile for all parties (CEO down to the Delivery Team) and creates business owners, stakeholders, program management, epic owners, and the list goes on. Translation: We are going to inundate you with process so you will see how many people are assigned to your product, and we will create a plethora of documentation (Note the second value: Working Software OVER comprehensive documentation) so you will feel like we are spending your money in a smart way and you will trust us with more work even though we have not created a single piece of working software for the first 3 months of this project by explaining to you our process and how it works because other clients were persuaded to give us money to do the same thing, even if it really is a waste, we can prove that other corporations are just as ignorant as you and you want to be part of that elite level of ignorance, because we are better sales people than developers, but we'll eventually get you a working prototype, but aren't all these documents and slide decks pretty and overwhelm you on our elegance? That is why Agile is Dead. Because of greed, and good marketing.

A happier solution

Imagine a world like this: You have a team of developers (DEV), a team of creatives (UX/UI), a few QA, a team manager (internal) and a SINGLE client facing project manager that identifies priorities WITH the client. The "kickoff meeting" goes like this: PM: We need a new web site for a client. DEV: Is it just a static site, or a web application? PM: It's a web application, kind of dashboard thing that displays their existing data in a pretty way. UX: Ok, we can mockup a few ideas on that, what kind of sample data do we have to start? PM: Don't know, I'll see what they have. DEV: Ok, web application, probably with authentication of some sort since it is internal data, let's get started. QA: Ok, we can start testing auth and some data that is mocked up. PM: Great! I'll get you some sample data from them. I love this team!

Meeting over... people are working...

OMG, who freaked out from that? How many people just thought, but what about... the type of authentication, what about their brand and style, what about the color scheme for them, what about the environments, what about... All of that will come out as we work. And what we do, is simply ASK and that decision should be made within 30 seconds. It may be wrong, it may not be fully informed, but that is what iteration is all about.

The Devil's Advocate is the most detrimental person to a team. They always figure out why things can't work, why things can't be done, and everything we are forgetting. They create fear, worry, and insecurity. The destroy innovation. Stop thinking about how you can't do something, and start trying to do it. I heard a few great quotes recently that I want to share:

If it is too difficult then you haven't done it enough  - Unknown

And

It always seems impossible until it is done - Nelson Mandela

 

The goal of managing great software is being able to handle change.

The goal of developing great software is simply writing code and then making it better.

Don't over-engineer, Don't over-manage, simply do the next indicated thing, and move forward.

I know this post will make people feel the need to justify their job, but I don't care. I think there is too much management, too much process, and faster delivery can happen with a lot less people involved and it will still be amazing and a much happier team too.

Now go fix your team, and build amazing things!