Agile has become a major buzz word being thrown around in the meeting and board rooms. It is often assumed that because the development effort has been mandated to follow an Agile methodology the project will take less time. The problem comes when the project is not allowed to follow an Agile methodology. Management gets disturbed when progress is not apparent and starts requesting large amounts of documentation. The development effort grinds to a halt while this documentation is produced. What happens next is a rather nasty mix of Waterfall with Agile expectations. We will call this Wagile.
For anyone familiar with Agile and the scenario described above, you have probably already identified the problem. One of the 12 principles of Agile software speaks to trust.
“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”
When documentation or proof of progress via paperwork is required, alarm bells should be going off regarding the trust the requester has in the team tasked with producing the work. While I agree that some form of up front thinking is needed before embarking on a development effort, requesting documentation that the up front thinking is being done seems to be a waste of valuable time. We need to ask ourselves why this documentation is being requested.
Why is the documentation being requested?
Going back to the principle of trust we have to first understand the concept of trust. The term is thrown around rather loosely nowadays and holds very little value. A quick “define trust” search on Google gives us the following definition:
“firm belief in the reliability, truth, ability, or strength of someone or something”
This firm belief is not something that comes easily, especially when millions are being poured into the project. Especially in large corporate environments where the stakeholders funding the project are not involved in the day to day operations of the team. Small start-up companies have a distinct advantage in this space because a flat organizational structure means it is easier to include the stakeholders funding the effort. With this reasoning, it is pretty easy to see why the documentation is being requested. The stakeholders funding the project do not see the work being done and the progress being made. This lack of visibility leads to a feeling of distrust that work is not being done yet people are getting paid.
How do we negate this distrust?
The easiest way to fix the problem described above is to increase the visibility on the work being done. There are many different ideas on how to do this but the primary point is that it has to be easily accessible to the relevant stakeholders. Once the stakeholders have complete transparency on the work being undertaken, they tend to understand the problems the team is facing and are far more inclined to introduce means to help mitigate any impediments preventing the development team from succeeding. This is why it is imperative to follow another principle of the Agile manifesto:
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
People with a hand in the project need to be easily reachable. They should engage each other regularly. If a question is raised, an attempt to should be made to resolve it immediately via a conversation with the party that might have the answer. If a decision is made it should be communicated to everyone that needs to know about it. This is were things become tricky.
Often, as technology professionals, the first thing we want to do to solve a problem is introduce a system. Task tracking, time tracking and the list goes on. Everything has to be logged into a system, carefully recorded for auditing purposes to prevent any recourse if something goes wrong. The underlying thought is one of “if this doesn’t work out, at least I have myself covered”. The problem with introducing these systems off the bat is it violates the Agile manifesto, namely:
“Individuals and interactions over processes and tools”
If any teams is just starting out down the Agile road after being heavily involved in Waterfall development, introducing tools and processes increases the risk of everything being molded into a Wagile process. While the tools say “Agile” the underlying process is very much Waterfall. One thing people find very hard to let go of is the investment they have made in learning things. The one way to get people to let go is to introduce a mechanism that is completely contrary to what they are used to.
Having coached a few teams in Scrum, the initial resistance is generally dropped when people start interacting with the methodology. For some reason, the act of moving a physical sticky note from one column to another leaves the individual with a sense of accomplishment. The side effect of moving the sticky note also leaves a status update that anyone can view without having to request status documents. This visibility increases trust and teams are not weighed down by the burden of evidence proving they are working.
Once the team is more mature and have established a means of organizing themselves, tools can be introduced to replace manual means in use. The reason manual means are better initially is because while you are establishing how your team will work, the process might go through multiple iterations. Software tools have a habit of being very difficult to easily reconfigure once the process has been set up.
Another means of increasing transparency is the demonstration of working software. This speaks to a few processes in the Agile manifesto:
“Working software is the primary measure of progress.”
“Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.”
The demonstration of this software on a regular basis shows the relevant stakeholders that software is being built. So as opposed to pumping money into something for month and seeing nothing, people get to interact with software and see additional features being added continually.
How does senior management fit in?
In large corporate environments (the context of this article) senior management is often difficult to get hold of on a regular basis. Often the feeling portrayed to development teams is that they have far more important things to do and keep up to speed with the progress of development.
While it cannot be expected that they will attend daily stand ups, view boards depicting progress or log into software tracking progress, they should attend the demonstrations of the working software or at the very least, have access to the working software. The demonstration would be first prize due to fact that contextual questions can be answered face to face. This will also help establish a stronger feeling of trust in the development team.
In closing, Agile does not work unless the entire organization buys into the effort. It is imperative to have everyone involved from the beginning. It does not work if teams go off and collect requirements then flush those requirements down to development teams and wash their hands. Inevitably development teams will push the requirements back to the requirements team who will have to reschedule time to answer the questions and potentially go through another requirements gathering exercise. By the time the requirements are solidified, the business has changed its requirements and the delivered software no longer meets the immediate requirements the business has.
“Business people and developers must work together daily throughout the project.”
All hands on deck!