In the following I am continuing thoughts on the Agile Manifesto. Specifically its statements 3 and 4. These are customer collaboration over contract negotiation. Also, responding to change over following a plan. The Agile Manifesto guides agile software development. The 2 concepts presented here are important building blocks of agile. Together, with the first 2 concepts in the Agile Manifesto, the team has guiding statements of what is agile. What do these statements mean to the team? How do you go about following them, or improving at them? In exploring Agile further, I will dive into these concepts and the Agile Manifesto.
Exploring agile further – customer collaboration over contract negotiation.
Customer collaboration over contract negotiation is about feedback from the user and/or customer. Feedback is a critical part of agile software development. A major intent with agile is to deliver smaller pieces of work. The goal is to be able to get feedback sooner, and more often. This allows for course correction of the work, to best meet goals and needs. That feedback loop with customers allows the team to discover more. It also allows for faster discovery than traditional requirement gathering processes.
Feedback from customer is often more correct than other means of information. Comparing to traditional requirement gathering processes, sometimes those requirements are incorrect or incomplete. Real feedback from the customer can have these issues, but is much less prone to be missing info. The feedback received is information needed by the team and is actionable by them. Unlike traditional requirements where they have to find that information first. Then they have to understand it and take action on it. With feedback, you can skip right to actionable work and delivering value.
Thoughts on contracts and negotiation
Contracts are rigid items. If the team focuses contract negotiation, they lose sight of the goals and needs of the customer. Contracts lack the room to grow and evolve. This is needed for 2 reasons. First, you will not know everything up front, thus a contract defining software work is wrong almost immediately after it is considered complete. Second, business needs will change over time, and contracts do not have the bandwidth to allow for that change.
Negotiate features to help deliver value, don’t negotiate a contract to tell you what to do or not to do. Negotiation is and should be a part of software development. There are always trade offs to measure, to help decide if you can do one thing and not another. These help decide when work is done. They help decide what work is more valuable and a higher priority. Where you get into trouble is when the contract specifies the details of the work and you have to constantly negotiate the contract. Work needs change over time, and the flexibility needed to meet those needs is not met by having work details in the contract. It would be better, as much as is possible, to not specify work details in the contract. This lets you avoid some of the constant changes that could cause.
Exploring agile further – responding to change over following a plan.
Understanding all work up front isn’t feasible, so the flexibility to respond to that and adjust for it is needed. In agile, we try to understand that we don’t know all of the requirements up front. There are processes that help facilitate that. Incremental delivery and good feedback processes. Responding to change is the mentality needed to be able to not hold to the original plan. Beings those requirements up front were maybe incorrect or incomplete, they will have to change. If you are not flexible to that change, you will not be able to pivot. Thus, you will not be able to best meet needs and goals for the user or customer. The team must remember they are there to deliver value to the user and customer. By not being flexible to change, you may deliver items of less value or no value at all.
Responding to business need changes
Another case for flexibility, and responding to change is for business needs. Flexibility to meet changing business needs is needed by the team. Despite the best information up front, work may change. The team may have all requirements 100% complete and accurate. Despite that, the business environment could change and now the work needs to change. An example could be a merger between competitors. One of the companies could have been working on competing products, but after a merger that could be irrelevant. The product line could then be shared, and they don’t need to create a competing product. They have access to it and can use it. Types of changes in the business environment are constant. Thus the need to be able to respond to the change is very important.
Responding to technology changes
Lastly, I would bring up technology changes and the need to be able to respond. Changes for new and better solutions, while in the process of doing the work could happen. Technology advances at a rapid pace and a new or better way of handling something could be created. If this happens while in the middle of work, you might want to change course. Utilizing the new technology could create a better solution. Without the ability to respond to the change, you may not be able to put forth the best solution possible. As an example, an update to a technology version may introduce new functionality that solves a problem for the team. If it is a better solution than what they had prior, they might want to use this. Without the ability and mentality to respond to changes, you may not use the best tool for the job.
An extremely important item for agile teams. Building the trust in Agile
Next there is content of the user story.
Have to have a link to the Agile Manifesto itself. Agile Manifesto