Explore the Agile Manifesto

Explore The Agile Manifesto – Part 1

The Agile Manifesto guides you in agile software development. It is the base on which agile as a methodology rests. What do some of these concepts in the manifesto really mean? For you to follow the manifesto, how do you know what to do? To explore the Agile Manifesto, I discuss the first 2 statements of the manifesto. The first concept is individuals and interactions over processes and tools. The second concept is working software over comprehensive documentation. In a follow up, I will discuss the next 2 statements of the Agile Manifesto. Those statements are, customer collaboration over contract negotiation. And, responding to change over following a plan. These statements make up the Agile Manifesto. They stress the importance of some items, over other items, to be successful in agile.

Explore the Agile Manifesto – Individuals and interactions over processes and tools

Individuals and interactions is all about communication and collaboration. This stresses the need for good conversations. Teams need to talk instead of relying on process and tools. Communication and collaboration leads to delivery of value. Often, process is relied upon too heavily. Also, process can sometimes be hidden behind. Meaning, you use process to not deliver tasks. As you follow a process that keeps you from having interactions. Why individuals and interactions over tools? Its because tools are a means to accomplish something. They must be applied in the correct manner. If you do not have individuals and interactions, the tools can be worthless.

Thus, individuals and interactions becomes very important. The agile team discusses goals and needs with the users and stakeholders. Because, they build understanding through those interactions. The team delivers to users and receives feedback through interactions. Interactions is a very important aspect of the agile methodology.

The people involved in agile development cannot be replaced with processes and tools. There is no substitute for good communication between the parties. This allows all other aspects of agile to follow. Without communication, you cannot build working software. If there is no communication, you will miss customer collaboration. And, you cannot respond to change without the communication factor.

Explore the Agile Manifesto – Working software over comprehensive documentation

Working software is about focus on work that delivers value. Documentation is only as valuable as the software it supports. Work towards creating software of value. Then fill in the needed documentation. Because, in my opinion, software requiring detailed documentation needs to be simplified. Therefore, build simple and useful documentation to meet needs. Save effort by documenting just enough. Use that effort on creating valuable software and products.

Putting into practice – individuals and interactions

Individuals and interactions as a concept, is more difficult. It is also more abstract then other pieces of the manifesto. It does boil down to communication though. So, when in doubt go talk to who you need to. There is no substitute for discussing needs with your user. You also cannot replace seeing what the user sees and does. Their reactions are also critical in communication. Information gathered in person from these communications is invaluable. This information is also very difficult to fully translate into requirements documentation.

There are many things that can interfere with good communication. Some include schedules of work, or conflicting priorities. Remember the purpose of being there, to deliver software of value. To do so, you have to find ways around the hurdles and communicate with your team and users. Individuals and interactions is all about finding that ability to communicate. As that communication drives the ability to deliver value.

Putting into practice – working software over comprehensive documentation

Working software over comprehensive documentation, is less abstract then the first concept. This is all about creating functional software first. Documentation, while important, is a secondary concern. The software drives the documentation, and not the other way around. Use the working software as a framework to help determine needed documentation. Teams can create documentation as they work software. You can also circle back to documentation after they create software. In my opinion, either can work. You must remember that the software created drives the documentation. Keep the information streamlined and don’t over document.

There is tie into the first concept also, which stresses individuals and interactions. Because, documentation should not be used to replace interactions. You lose meaning and valuable information when you replace conversations with documentation. There is a loss in translation, when taking information between mediums. Don’t try to to this. Instead, have the conversations and use documentation as support. Therefore, supplement conversations with documentations. Use documentation to reinforce what is learned from the conversations. Don’t use it to replace conversations.

Further reading:

In the following I discuss tips to help with the agile process. I outline 5 items to work on to help build a better agile process. These are tips gathered from real work with my agile teams and have helped tremendously. They are concepts that are relatively easy to start working on. They are more difficult to master. I have worked with multiple agile teams. Some teams were needing work on agile fundamentals. Some teams were very skilled in the process. These are tips that are applicable to either, to help improve. You can focus on these tips to help drive improvement. Additionally, linked are thoughts on documentation in agile. My thoughts on how to approach documentation. Also, how to decide when documentation is good enough. Lastly, is a link to the Agile Manifesto itself.

Here I continue to dive into the concepts in the Agile Manifesto. Exploring Agile Further – The Agile Manifesto – Part 2

Next I discuss some concepts from traditional waterfall development, that sometimes make their way into agile process. Timelines and Due Dates in Software

Here is the document itself, the Agile Manifesto

Leave a Comment