Have you worked on software projects where processes and tools got in the way? There were better ways, but you couldn’t get around existing processes, practices, and habits. It was difficult to leverage any better software process or tools to help the team. Maybe good Agile team best practices didn’t exist.
What about documentation? Have you worked on software where an extreme emphasis was given to the documentation? Specifically how the software worked and other extra details? Or, how it was supposed to work? Or lack of documentation impeded the Agile teams involved?
- Boost for the Agile team best practices
- Exploring the Agile Manifesto for Agile Team Best Practices
- Don’t hide behind process!
- Understanding of goals requires direct communication
- Remember the flexibility that you have
- No substitute for good communication between the parties
- Putting Agile team best practices to use— individuals and interactions
- Working software over comprehensive documentation
- Place the work first, and documentation second
- Just like the software, don’t over complicate the documentation
- Putting into practice — working software over comprehensive documentation
- Agile team best practices for customer collaboration over contract negotiation
- Thoughts on contracts and negotiation
- Responding to change over following a plan
- Remember to be Agile my friends
- Additional content and books around agile team best practices
Boost for the Agile team best practices
If you have had issues, does your team need a boost to Agile team best practices? Reviewing and understanding the concepts of the Agile Manifesto will be of great service. There are 4 core values of the manifesto to explore. So, let’s talk about Agile software development and the Agile Manifesto. Digging into the Agile methods and ideas of the manifesto will help your project team. You will grow your Agile team best practices end over end!
Exploring the Agile Manifesto for Agile Team Best Practices
First, is Individuals and interactions over processes and tools. This is all about communication and collaboration. This stresses the need for good conversations in the Agile process. Teams need to talk instead of relying on processes and tools. This is huge for Agile team best practices. Communication is a struggle with almost any team, so any improvement here will go a long way. Communication and collaboration lead to the delivery of value. Here are some ideas to help with this.
Don’t hide behind process!
Often, team members rely upon process. Sometimes this holds up work. Sometimes this is because team members hide behind the process. Meaning, you use the existing process to not deliver tasks. As you follow a process that keeps you from having interactions. It isn’t necessarily done on purpose. But it can happen.
This can be a habit from Waterfall development. Why individuals and interactions over process and tools though? Its because process and tools are a means. They must be applied in the correct manner. If you do not have individuals and interactions, the process and tools do little. The processes and tools are not a means to an end by themselves. Don’t forget the people aspect of your Agile practices here.
Understanding of goals requires direct communication
Thus, individuals and interactions become very important. The agile team discusses goals and needs with the users. They build understanding through those interactions. The team works towards those goals. Building to deliver to users. After which, getting feedback, again via interactions.
Interactions is a very important aspect of Agile processes for the team. It is tough to deliver business value without an understanding of the needs, which comes from direct communication. Great teamwork is rooted in communication and collaboration.
Remember the flexibility that you have
Being adaptable and flexible to the situation and goal is core to Agile. It is a fundamental building block of the methodology. At its basis, is the idea that not all work is the same. Thus a standard solution to approach all work does not meet the need. You will have to vary how you do some work, and that is ok. It actually is the better way! Flexibility and agility is an important part of the mindset for Agile team best practices. Stay flexible to do the best work you can on your software project.
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. For teams new to Agile, don’t let project management habits and development methodology processes used in the past stop good communication.
The people involved in agile development cannot be replaced with processes and tools
Putting Agile team best practices to use— individuals and interactions
Individuals and interactions as a concept is more difficult. It is also more abstract than 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. Direct understanding of user needs will let the team create the highest quality software to meet those needs.
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 as an idea is all about finding that ability to communicate. As communication drives the ability to deliver value.
Working software over comprehensive documentation
The second concept is working software over comprehensive documentation. Working software is about the 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. Software requiring detailed documentation needs to be simpler. Build simple and useful documentation to meet needs. Save effort by documenting just enough. Use that effort on creating valuable software and products.
Simplicity in the work also enables the team to complete work. With smaller and simpler portions of work, the team can more easily go and execute. Then come back around for the next pieces of work.
Place the work first, and documentation second
The goal is always to deliver working software. Software that does not work, but with comprehensive documentation explaining it, just seems a bit pointless. So number one is to deliver working software. Then add helpful documentation to support it. Remember, documentation supports the software. Self organization of the team here is needed. Let them create just enough documentation for what they need. There needs to be some, but not too much that it gets in the way of work.
Just like the software, don’t over complicate the documentation
Simpler is always better. This is part of an incremental and iterative approach to delivering on goals. If you do this for software, why would you not do this for the documentation? Don’t try to deliver an all-encompassing document in a single pass. Instead, keep it relevant, and short. Add just what you need. Then add to it as you go, for additional needs.
Putting into practice — working software over comprehensive documentation
Working software over comprehensive documentation is less abstract than 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 the 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 information.
There is a tie in to 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. Use documentation to reinforce what is learned from the conversations. Don’t use it to replace conversations.
Agile team best practices for customer collaboration over contract negotiation
The third value is customer collaboration over contract negotiation. This 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 a 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 the 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 the 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 on 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 upfront, 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.
Responding to change over following a plan
The fourth value is responding to change over following a plan. Understanding all work upfront 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 upfront. There are processes that help facilitate that. Incremental delivery and good feedback processes help. This is also why Agile frameworks promote shorter sprints or iterations. The shorter time gives more opportunity to adjust to changes. This is just good iterative development. If the software development process ran for months, instead of weeks, before it completed, it takes that much longer before you deliver work and can respond to change.
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 the 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 will happen
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 upfront, work may change. The team may have all requirements 100% complete and accurate. Despite that, the business environment could 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. They don’t need to create a competing product any longer. Types of changes in the business environment are constant. Making the ability to respond to change so 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 new technology could create a better solution. Without responding to change, you may not be able to create 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. You would ignore the new version and try to create something yourselves.
Remember to be Agile my friends
At its core, the Agile methodology is about how you carry yourself and problem solve. It’s also about the way you handle your work. Adopting the Agile method will give you the tools you need. The Agile principles and concepts will help you create great best practices. In your Agile projects or any work, remember the values. Then seek to apply them, and be the rock-star that you are!
Additional content and books around agile team best practices
A larger list of tactics and practices for the Agile Product Owner can be found in The Modern Product Owner. A lot of great practices are consolidated down to tangible things you can start using right away.
Also available on Leanpub here.
Of course, lets link to the Agile Manifesto, for reference. A great tool for helping boost your Agile team best practices.