Skip to main content
App management icon

This post is from the Apperian blog and has not been updated since the original publish date.

Last Updated Apr 15, 2015 — App Management expert

When Agile Is Done Badly

App Management

Agile development has become very popular in the high tech world, to the point where most companies think they need to be a part of the movement even if they are not sure why or how.  Like anything that requires a measure of discipline, agile development requires knowledge and training. If you listen to how people describe their agile implementation, you can tell who gets it and who doesn’t.

“We do Scrum.  We have daily standups."

The most common way to do agile badly is to add daily standups to a waterfall process. What often happens is that someone decides to go agile, and tries to implement some of the principles without understanding the purpose.  It seems like all software companies are running “daily standups” even if they aren’t following an agile process. The result is often just more meetings than before, because the new daily meetings get added to the weekly status meetings, department meetings, etc. It becomes an opportunity for managers to collect status reports more often, instead of a chance for engineers to collaborate.

“Standup was quick today.  We were done in only a half hour!"

When standups are used as management status meetings, it is easy for them to get out of hand and run for a long time, often even up to an hour per day. This kind of time commitment is detrimental and demoralizing to the team, but the happy manager often doesn’t notice. Try to remember that a standup is supposed to be a quick team huddle, not a status meeting. Keep them short!

“We work in sprints.  We develop in one sprint, and then test in the next one."

Another way agile gets off the rails is by turning big waterfalls into mini waterfalls. One of the key agile principles is that you work until you are “done”, and each piece of work should be completed in a single sprint.  That means really done - coded, tested, code reviewed, documented, etc.  How can you consider a story done if you haven’t tested it? Forcing teams to complete work inside a sprint is difficult, but once the team gets the hang of it, you will see that they are more productive.

“Well, it would have been done, but the QA guys didn’t finish their part."

In a true agile team, success is measured at the team level. Either work is finished, or it is not, but it is never the fault of one person or one discipline. If you have static roles and boundaries, you are not working at peak potential, and that is not agile.

“We work in sprints.  My manager tells us what will be in each sprint."

Agile methods were developed in response to the old idea that you can define a project's requirements, team capacity, and schedule ahead of time and reasonably expect to finish on time. If you have worked on a waterfall project, you know that it doesn’t work. You need to let the team members define their capacity if you want them committed to finishing the work.

At Apperian, we are committed to following Scrum as carefully and completely as possible.  It makes us work faster, smarter, better.  How is your team doing?

More from the Blog

View more
Apr 30, 2020

Mobile Application Management: A Forward View

App Management
  IT Is Adapting in the Midst of the COVID-19 Pandemic The Coron ...
Read More
May 19, 2019

Sneak Peek: How Are IT Leaders Driving Mobile App Adoption?

App Management
Apperian conducted the The Mobile Enterprise Application Survey to fin ...
Read More
Jan 30, 2019

Part 1: App Security Should Be an Integral Part of Your DevSecOps Process — Not an Afterthought

Application Security
What are the key considerations and components of DevSecOps? The in ...
Read More
Nov 19, 2018

Breaking Down the New California IoT Law

Application Security
Recently California passed legislation regarding the security of all I ...
Read More
Contact Us