Agile welcomes changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Short feedback loops in Agile allow the team to get fast feedback and incorporate changes required by the customer and reduce the possibility of the team developing the wrong product for too long.
The Product Backlog is dynamic and evolves over the lifetime of the product and requires constant grooming and refinement. The Product Backlog is continuously updated by the Product Owner to reflect changes in the needs of the customer, new ideas or insights, moves by the competition, technical hurdles that appear, and so forth.
During an iteration, the Agile Team should invest some time to work with the Product Owner to refine the Product Backlog (a.k.a. Product Backlog Grooming). This includes requirements analysis, splitting large items into smaller ones, estimation of new items, and re-estimation of existing items. Priorities can change and requirements can move up and down in the Product Backlog. When new items are discovered, they are inserted into the Product Backlog causing the lower ones to move down the list (and possibly fall outside of the scope of the release) or old requirements removed as appropriate.
Although Agile welcomes changes, when using time-boxed delivery like Scrum, there are no changes allowed during the iteration, and the end date of the iteration does not change. In return for not making changes during the current iteration, the Product Owner can make any changes they want to the Product Backlog before the start of the *next* iteration. The Product Owner can add, remove, reorder, or change items before the start of the next iteration. This enables the Agile team to make and keep commitments, it gives the team focus and stability during the iteration, and it trains the Product Owner to clearly think through what is in the Product Backlog. Due to the short time-boxes, the team should be able to get some reasonable certainty into the planning and requirements and avoid churning during an iteration.
Overtime if you find that the Product Owner keeps needing to change requirements mid-iteration, then perhaps the iteration length is not short enough. Plan iteration durations around how long you can commit to keeping change out of the iteration.
How many times have you heard, “that’s what I said, but not what I meant or wanted”? Too many times I would suspect. Many symptoms of project issues are related to organizational, collaboration, and communication issues, not technology. One of the challenges of any I.T. initiative is getting people to communicate and collaborate together, especially between business and I.T.
Wikipedia defines it as:
Communication is the activity of conveying meaningful information. […] Communication requires that the communicating parties share an area of communicative commonality. The communication process is complete once the receiver has understood the sender.
The last sentence above is quite important and often overlooked. We rely too often on using static channels of communication, such as sending an email or word document to communicate a message. However, the receiver of the message may not have understood what your intention is and we often ask ourselves “why people don’t understand it? I sent them the email with the requirements!”.
The sixth Agile Manifesto principle reminds us:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Getting people together face-to-face provides richness in our communication through, tone of voice, eye contact, visual gestures and the ability to convey tacit knowledge.
Collaboration is working together to achieve a goal. Agile And again, we can look to the Agile Manifesto for some guidance:
Customer collaboration over contract negotiation
Business people and developers must work together daily throughout the project
The best architectures, requirements, and designs emerge from self-organizing teams
During a team discussion, I liked what a fellow colleague said on what collaboration meant:
Collaboration means acknowledging that you don’t have all the answers and that the collective wisdom is better used to solve problems. Collaboration is being vulnerable and being transparent so the conversation brings out things that were otherwise not consciously known.
My communication and collaboration experience
Over the last several weeks I have been coaching and facilitating several inception/discovery workshops that included both business and I.T. One particular workshop was attended by 35 people from all levels of the organization with some participants traveling from interstate. The goal of the 3 day workshop was to discuss and plan how we would tackle a large program of work by identifying the program vision, goals, drivers, measures and the various streams of work that would make up the program.
In the 3 days we accomplished what previously would have taken weeks (possibly months) to complete. The face-to-face workshops provided a rapid, efficient and effective way to for people to communicate and collaborate. An important outcome was obtaining a shared vision amongst all participants. After the 3 days everyone walked away with a shared understanding and vision that they can take into the various projects that would make up the program of work.
What I also observed was the large amount of informal communication and collaboration that occurred outside the workshop hours such as during breaks and lunch that otherwise would not have occurred. Getting everyone together allowed whole team discussions which I believed lead to greater buy-in by all team members.
There was a high level of collaboration between everyone in clarifying business requirements, the problem space and each others understanding. The power of bringing people together to communicate and collaborate to achieve a goal was powerful. Trust was being built between business and I.T.. The business was able to understand the complexities and risk involved in I.T. development. And the level of negotiation between the parties allowed mutual decisions to be made and the quality of the decision making was made possible by having the right people together.
Agile stresses the importance on communication and collaboration. Alistair Cockburn recently remarked how important it is to increase collaboration between people and across the enterprise. Effective communicators realize that the goal is to share information, and that the information sharing is typically a two-way street. Through conversation we can iterate over meaning and seek clarification. The ability to answer questions in real time is important because questions provide insight into how well the information is being understood by the listener. Face to face collaboration also reduces the cycle time of information sharing through continuous flow of tacit knowledge.
Agile is about bringing people together to achieve more than they could individually. It is only if we have consensus through group collaboration that we can provide optimal solutions to address business problems. So next time you want to bridge the business and I.T. gap consider increasing the amount of real-time communication and collaboration between the two parties:
- Get all the players in the one place and talk.
- Engage the right players to make decisions.
- Leverage the knowledge of the team – listen as much as you talk, ask questions when you don’t understand, question if you do not agree. There is no silly question!
- Clarify and iterate over meaning to get a common understanding:
- “So what you’re saying is…”
- “Let’s use an example…”
- “Doesn’t that imply…”
- Find the value that each member adds to the group.
- Think ‘one team’. We stand or fall together. Collaboration expands our potential to succeed.
- Negotiate to reach an understanding, resolve a point of difference, or to produce an agreement upon courses of action.
- Document and capture important information so it is best not forgotten (don’t document just for prosperity sake) – it is the dialogue that is important.
Software development is a creative process and any creative endeavor requiring teams collaborating together to share knowledge, learning, ideas, solve problems and build consensus. Communicating and collaborating will always help you steer your way to a far more successful outcome.
Most people associate daily stand ups or daily Scrums when they think of Agile. And they are often the first practice that is adopted. I have observed some teams adopt the daily stand ups and a little of other practices (often with smells/anti-patterns) and say they are Agile.
The adoption of agile methods and practices is clearly producing enviable results by improving quality, time to market, productivity, increasing transparency and ROI. Agile is simple, but it is not easy. Few things that are truly worth doing are easy to do, and the adoption of Agile is no exception. As a result there is a propensity for Cargo Cult Agile teams looking for a silver bullet.
Cargo Cult refers to a phenomenon during World War II in the South Pacific where the natives observed what the Allied Forces were doing. The natives were not aware of the modern civilization, however, they did observed that certain actions of the military resulted in supplies of food, clothing, equipment and various other cargo being air dropped. When the war ended, the flow of goods and cargo ended too. Not understanding the underlying mechanisms for the delivery of cargo and in an attempt to attract further deliveries, the natives engaged in ritualistic practices such as building crude imitation landing strips, aircraft and radio equipment, and mimicking the behavior that they had observed of the military personnel operating them. However, no matter how well they mimicked the military actions, the cargo did not return.
In Agile we sometimes behave like Cargo Cult by imitating the superficial Agile methods and practices without having any understanding of the underlying essence. We adopt the daily stand up meeting because it is easy to do and many Agile teams use it. However, if the team is synchronized, communicating and collaborating well, the daily stand up may not be required.
What works for you, your team, organization, etc. can bring another person, team, etc. to a screeching halt. No practice will work for everyone or every team in every context. Before adopting any practice or technique, you should ask yourself does it make sense and does it align with the Agile values and principles? Does it help me deliver software more quickly to my customers? Does it help with achieving technical excellence? Will it help my team to be more effective?
You not only need to know the ‘what’ of Agile but also the ‘why’. Just because jumping jacks works for someone else, it may not work for you.