7 Myths of Agile

07:50 There is no documentation.

“We value working software over comprehensive documentation” ~Agile Manifesto

There is less emphasis on extraneous documentation. The project continually evolves during the development process. The focus is on creating working products instead of detailed documentation up front. An appropriate level of documentation will be an output of each iteration.

Think of documentation as another deliverable. Documentation should be focused, value-driven, business-beneficial. Enabling the business to use the product effectively. On the technical side the team needs to be able to support and maintain the project.

14:35 Agile doesn’t require planning.

Planning is an important step. You need to know what you are building. If not done properly it greatly reduces effectiveness of project.

“It doesn’t require planning in the same sense that a camping trip doesn’t require planning.”

Agile spreads planning out over the course of the project. This means less extensive planning upfront. Instead you have periodic planning sessions. Projects start much quicker and it’s easier to make adjustments along the way.

Iterative design is based on cyclical processes. It involves going through cycles of prototyping, testing, analyzing, and refining. This increases the speed of design and changes. It also brings to light misunderstandings about specs and requirements sooner.

20:35 Agile means there is no architecture.

“Continuous attention to technical excellence and good design enhances agility” ~Agile Manifesto

Agile pushed back on over engineered projects. This can be a pain point for people used to the highly engineered and structured way of planning a project. You don’t have to think about every single possibility before building something.

Start by building the basics and iterate over that. Iterative design means you can change the way it is build during the process. Doesn’t mean you don’t select a language/framework and stick with those larger decisions. It does mean that you don’t specify exactly how developers build.

32:15 Agile means no oversight.

Team members have autonomy. Able to make decisions about how to meet user needs. Users provide information about what they want to happen. Team determines implementation details for how to make that happen.

The idea is to put those building the product as close as possible with those using it. The idea here is to reduce the impedance caused by separating the user from the creator. Developers are better able to understand business requirements when they can ask about them directly.

“You honestly get more insight into what the employees are doing.”

Agile promotes lightweight, fast moving, project governance. You may have reporting and other requirements for oversight. Regular and ad hoc meetings should be set so that information can be passed up the chain and decision made quickly.

40:40 Agile is a silver-bullet.

“You shouldn’t be looking for a silver bullet unless you have a werewolf problem, you don’t.”

Agile is not the answer to all IT problems. There’s no single answer to all IT problems. Integrating different methodologies to put the pieces together.

You can fail with Agile. The failures are smaller and more frequent. The iterative process allows for easier recovery from failure as well.

Agile allows for changes in the process. It brings transparency and visibility to a project. You can drop things that are not working and add new things to get better results during the project life cycle. This empowers developers to take initiative and get things done. The team becomes accountable to each other for their work.

43:25 Pure agile is the only answer.

There are Agile zealots out there. You may have one on your team. This is not a bad thing as they will keep you from straying too far.

“An agile zealot is a purveyor of agile as a silver bullet.”

Agile may not meet all the needs of an organization. Adding something new such as Agile does increase the risk of the project. Implementation of Agile should be pragmatic. Look beyond the ivory tower into the real world implementation of project management. You can moderate the level of change and slowly increase it.

Only stray if you have valid business reasons. You may have rules, regulations, or the organizational structures and cultural expectations that prevent full Agile. You can still implement some small changes in the direction of an Agile approach:

• Conduct and communicate lessons learned frequently and not just at the end of the project.
• Have short (15 minute) daily stand-up meetings.
• Set clear and realistic expectations for what work can be accomplished in a given period to not over-allocate resources.

49:15 Scrum is the same as agile.

Scrum is a popular methodology. It is iterative and adaptive like Agile. Scrum is a framework for developing and managing work. Agile is an approach that follows a common set of values and principles that many methodologies fall under. Scrum is your specific programming language whereas Agile is the type of project (web, desktop, mobile).

“A lot of people confuse what is SCRUM and what is Agile.”

Scrum came before Agile. While there is some debate as to who and when, Scrum has been around since the late 80’s – early 90’s. The Agile Manifesto was written and signed in 2001. This goes back to Agile being an approach to project management and Scrum being a specific implementation.

There are many other implementations of Agile methodologies. They all have their own unique way of applying the principles of Agile.