Agile

Agile Does NOT Mean “No Planning”

Agile Needs PlanningStop using Agile as an excuse for your failure to plan. There is nothing about Agile that means or implies that you do not plan. You must make the plan loose enough to be adaptable but detailed enough to be useful.

You must still plan. You may even have to plan more to consider some possible contingencies and how you will handle them. You may find things change considerably and you have to plan your adaptation to those changes.

You won’t find creativity in the chaos, you will only find chaos if you fail to plan. Agile is not an art form, it, however, can be a balance of art and science.  “Just making things up as you go along” will likely cause more issues in the future in regards to technical debt (Flaccid Scrum / Flaccid Agile and Technical Debt).

There are certainly times when you will need to make things up as you go along. Those times are usually accidental and unexpected. They should not be encouraged to occur and they should be limited as much as possible.

There can be value in doing things differently, and there can be value in planning just enough so that you have a general idea of what you are going to do. There is almost no value in going in completely unprepared.

Creativity in Chaos

 

Imagine an Instructor for a class:

Students are paying to take a class in Scrum or some other Agile variant. The instructor comes in and seems very smart and capable.

As the class progresses, the instructor hops around subject areas, going in a rambling direction. It makes them look a little flighty, like they are in a job interview getting asked random and unexpected questions from a panel of people.

The instructor forgets parts of a topic and then in the middle of other sections they revisit a previously covered topic. They use a whiteboard to draw out complex subjects. Some of it is hard to read and drawn quickly. It would have been nice if they had prepared some images in advance so the students didn’t have to wait for things to be drawn out (possibly losing interest).

The students have a horrible time and don’t believe they got their money’s worth. When it comes to testing time on the subject material, the students learn that the instructor forgot to teach them sizeable chunks of the material.

The students leave with the belief that the instructor had no clue what they were doing.

If the instructor had 10 years of experience on the material, they may be able to wing it a little better, but students can usually figure out when their instructor didn’t really think through the flow of the class or was just unprepared.

When it comes to software projects, you might be able to hide it from your customer. They often only see the output and if the output works they don’t usually probe deeper. I have seen people cheer developers who I knew to be subpar at best. I am not a great developer myself but I have had people who only saw my output and insisted I must be great at it – even when I tell them otherwise.

I have seen some messed up things that people tried to hide and managed to get away with until someone else goes through their code. I usually attribute it to a lack of skill, a lack of planning, or a lot of huge last-minute changes throughout the project. If you get all three you could see the exact same poorly written code in several locations in the same application.

That messed up code, someone is going to have to deal with it in the future. Long-term maintenance costs are going to go up. Employees are going to get irritated when they get horrific code dumped on their laps and told they have a couple of days to add a new feature but they are spending their time unraveling the noodles in the pile of spaghetti code sitting in front of them.

All the way around it is just a bad idea to not plan things out a little bit so you have some organization and structure to your methods.


Agile Planning Games


 

Reflection

I am going to repeat it again, stop using Agile as an excuse for your failure to plan. Planning still needs to be done. Agile is not a tool that gets rid of planning. It most likely will cause more planning, which can be a very good thing.

 

 

Categories: Agile, Leadership

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.