A presentation by full-stack agile on some of the myths regarding the Agile framework. There are important questions such as benefits, documentation, scalability, architecture, planning and discipline.

1. Ashley-Christian Hardy
Common Myths Surrounding Agile

2. Hi, I’m Ashley-Christian Hardy
In Progress…
full- stackagile.com
achardy@fullstackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm

3. Agile will solve all your problems
Agile 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.

4. Agile says don’t document
This 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.

5. Agile says I don’t need to plan
Agile 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.

6. Agile has no discipline
Agile 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.

7. Agile has a lot of change
Yes 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.

8. 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.

9. 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.

10. Thank you!
Full-stackagile.com
achardy@full-stackagile.com
@achardypm
facebook.com/ fullstackagile
medium.com/@achardypm
pinterest.com/achardypm
instagram.com/achardypm
linkedin.com/in/achardypm
slideshare.net/ ashlychrstn
tumblr.com/ blog/achardypm
https://plus.google.com/ achardypm