Ashley-Christian Hardy

Common Myths Surrounding Agile

Hi, I’m Ashley-Christian Hardy

In Progress…

full- stackagile.comachardy@fullstackagile.com@achardypmfacebook.com/ fullstackagile

medium.com/@achardypmpinterest.com/achardypminstagram.com/achardypm

linkedin.com/in/achardypm

Agile will solve all your problemsAgile is not a silver bullet, and it probably won’t solve all your problems. Alights will say that the success rate on an Agile project is a lot higher, and they may be right; but an Agile projects can still fail – and with them being incremental will fail a lot faster. Agile promotes the following values:

• Focus on business needs• Collaboration• Innovation• Open and clear communication• Self-empowerment

If your team does not support or adopt this philosophy or attitude then the agile approach will not work for your company.

Agile says don’t documentThis is absolutely not correct, and does not make much business sense. Agile states:

“Working software over comprehensive documentation”

Agile does not state you do not have to document, or is ant-document, it states do not create lengthy documentation for the sake of it.  Documentation should be treated like any other deliverable. It should be prioritized and estimated like any other user story. The point is, documentation can lean away from communication. Why create a long document or email when talking to someone will suffice and will likely be a lot faster.

Agile says I don’t need to planAgile doesn’t state you don’t have to plan; its actually quite the opposite. It may different to more traditional methods of project management in the sense that traditional approaches expect all the planning to be up front. This is actually quite unrealistic. The amount we know about a new development or project is actually at the beginning.  Agile planning is much the same as its delivery, continuous and iteratively. In Agile you have:

• Daily 15 minute stand up.• Bi-weekly sprint planning and sprint

retrospective meetings.• Release planning where scheduled.

Agile has no disciplineAgile actually requires a lot of discipline. Many teams will take the easy parts from Agile such as the daily stand ups and iterative planning, but its not much good if you don’t also take on board the more difficult aspects of Agile such as actually delivering a product at the end of every sprint and testing. The agile discipline actually requires you to:

• Test throughout.• Give regular feedback.• Regularly ship software at the end of every sprint.• Change and update the plan where needed – don’t

be afraid of change; embrace it.• You have to deliver bad news early.

Agile has a lot of changeYes ok, there is some rework in Agile, but this is not a bad thing. Imagine with more traditional methodology where you do your big plan up front. You get 60% through the development and realize there is a fatal flaw in your plan. You have to go back to the beginning or scrap most of the work that you have done. With Agile, your plan is continuous; and development in iterations, so if you need to make change you can.

There are two main areas of rework in Agile:• Requirements – you need to refine and rework requirements

with the customer.• Software – the development team will learn and come up

with new ways to develop.

That being said, this needs to be balanced. You can’t allow the customer to keep changing their mind, and the development need to create a finished product. Burn down charts track progress and allow teams to asses where they stand.

Agile doesn't support architecture

With Agile, it says that you shouldn’t build it when you don’t need it. In the past, we used to develop over complicated, expensive and hard to maintain systems. With Agile you can keep it simple only use what you need and learn from what you know and have done in the past.

Agile doesn't scale

Scaling is hard, no matter what project methodology you use. If there is a lot of teams that need co-ordination, complex systems with multiple parts, and get everything going in the same direction.

Agile, actually tries to get you to scale things down, to break up large projects into small pieces and deliver in iterations.

Thank you!

Full-stackagile.comachardy@full-stackagile.com@achardypmfacebook.com/ fullstackagile

medium.com/@achardypmpinterest.com/achardypminstagram.com/achardypm

linkedin.com/in/achardypmslideshare.net/ ashlychrstn

tumblr.com/ blog/achardypmhttps://plus.google.com/ achardypm