Organizations constantly feel the pressure to quickly adapt to rapidly changing (economic) conditions. In particular management, sales and marketing – being the “demand side” of the organization – experience this directly. They often do not feel supported by the rest of the organization and potential providers (provider side) when adjustments are required. This is also frequently the case with IT departments and providers. They usually experience change as a disturbance of the process. Nevertheless, provider and demand sides should more understanding towards each other in order to be successful together. We are convinced that a more Agile approach will help.
Recently Goyello organized a knowledge afternoon for its clients. We wanted our customers to experience the potential impact of an Agile-based method. It’s already been three years since we introduced Scrum to our great satisfaction, and a growing number of our projects is now carried out in accordance with this method. We would like to attune all our projects, including the customer process, to this system.
However, in this case unknown often makes unloved.
[slideshare id=13123958&doc=agilesoftwareontwikkelingmetscrum20120523-120529145758-phpapp01]
Too often there is a gap between provider and demand
We still quite often see the demand side, the client, trying to specify all his requirements and wishes. Sometimes they are even already thinking in terms of solutions. During a good talk it soon turns out that the REAL problem is not clear at all, as well as the solution needed to REALLY solve this problem. In practice however, the provider’s side, the (internal) provider, often thinks directly in terms of solutions as well, basing on the specifications provided. A mismatch between the real demand and supply is then lurking around the corner.
The provider’s developers then go to work in order to build what they think is right. Traditionally, the so-called waterfall methodology is applied. The project is carried out in phases, based on initial specifications. This process can take months, the customer is not involved and in the meantime the market changes. The probability that the customer gets what he needs is nil.
In the worst case an argument ensues between the customer who does not feel understood and the provider who feels he has done his best.
The disadvantage of waterfall in practice, a practical case
Recently we visited a client, where for a too long time already the workflow of a complex customer process was being described. The demand side had already lost faith in this analysis, because in the meantime the business reality had changed. Meanwhile, the IT provider had already used the process analysis to develop a system. And to make matters worse, the customer never even saw this system. The provider wanted to rebuild the system basing on the adjusted process analysis. We didn’t think this was a good idea.
We offered to continue the process in an interactive way and through iterations by simply showing the business the current version and evaluate what is good, what has to be adapted and what is really missing. Subsequently, a roadmap could be made with all the functionalities to be developed. Yet to be realized, the functionalities could be divided into monthly releases, which are then presented to the customer. Also, at the beginning of each release the customer would be closely involved in defining the functionality to be developed, to ensure that he really gets what he needs.
10 indicators that a project is likely to fail
How can you avoid a situation like the one above? Is it possible to see this coming? Yes, it is. And strangely enough it is actually quite easy to predict that a software development project is likely to fail. In his “Critical Success Factors In Software Projects” John S. Reel describes the 10 signs from which you can conclude that a project may easily fail:
- Project managers don’t understand users’ needs.
- The project’s scope is very limited (or absent).
- Project changes are managed poorly.
- The chosen technology changes during the process.
- Business needs change.
- Deadlines are unrealistic.
- Users are resistant.
- Sponsorship is lost.
- The project lacks people with appropriate skills.
- Managers ignore best practices and lessons learned.
Basically, each of the above points is easy to solve.
Working together to deliver a better result
Agile means flexibility and agility and that is what we actually need. Today, a tight schedule usually does not make any sense. A more Agile approach seems a better method. And so, it has immediately become a new “hype” or “trend”. Increasingly, the term emerges as the Holy Grail, the solution to all problems. The same applies to Agile methods like Scrum.
The reality is however somewhat more stubborn. Implementing these methods without really understanding them, without feeling the underlying philosophy, is not going to work. It then becomes a new tool whose implementation is doomed to fail.
We regularly see IT departments introduce Scrum. And after some questioning it turns out that for example there is no product owner, the representative of the customer is on the client’s side. In such case the implementation has taken place only within the IT department and believe me, that won’t be successful.
From top to bottom, through the entire organization, it should be understood and preferably be felt and experienced, what Agile work really means.
The basic idea behind Agile requires trust
Years ago, the so-called Agile Manifesto has been drawn up. This manifesto is expressed in only 4 main points that say what Agile is exactly about:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items in the right, the items on the left are more important if you want to collaborate effectively.
To reach this point mutual trust is needed between demand and supply. The client would for example like to know how much something will cost him and when it will be delivered. With an Agile method it is not possible to cover this exactly. Within Scrum for example, the deadline is sacred, the budget may be limited, but it is not possible to fully guarantee in advance what will be delivered exactly. The probability that a working product will be delivered that meets the (modified) wishes will however increase significantly.
Scrum: realizing a working product together, step by step
As previously reported, we have chosen Scrum to organize our work. Scrum focuses on the realization of complex projects (not only software development). Within Scrum the work is carried out in iterations of 2-4 weeks, the so-called sprints. At the beginning of each sprint a work package is determined, based on a list of demands and wishes which has been (previously) prioritized together with the client, the so-called user stories. The first functionality to be developed has therefore the highest value for the customer. At the end of each sprint, a working product has to be released.
The customer is closely involved in the translation of requirements to so-called user stories. A user story tells what a user should be able to do with the system under certain conditions and what the outcome will be. These user stories can be estimated by the team. Preferably, this is a budget based on story points. Through the so-called “story points poker” the complexity is determined together.
The team thus gives no indication of the time it takes to realize a user story. During the project the average work rate becomes clear, so the average number of hours per story point can be determined making the process more predictable.
The core roles in this process are:
- Product owner: represents the voice of the customer. This is someone who can decide independently when the team asks questions about the user story to be realized. He must therefore have a lot of domain knowledge and quick access to relevant stakeholders.
- Scrum master: this is the facilitator of the team process. Daily, the scrum master and the team have a so-called stand-up meeting, during which they are standing, to discuss: 1) What someone has done since yesterday, 2) What is he planning to do today and 3) What obstacles occur. It is the role of scrum master to facilitate resolution of these obstacles as soon as possible, so the team can continue working.
- Team members: within Scrum the team divides the work independently. All responsibility for realizing the agreed work for a sprint lies with the team. They mutually agree on who will do what, and they help each other.
The above is a rough summary of my presentation. As often is the case, this only covers the tip of the iceberg. There is much more to say/write about the implementation of Agile work and methods like Scrum. However, the best option is as always doing it yourself. Because Agile means embracing changes, the best way to start is just by doing it. You may confidently and continually adjust the working process, because change is simply the rule. It is paramount that the approach is supported throughout the organization, because if that is not the case, Scrum would be nothing more than just another tool that wouldn’t be able to show its strength.
What are your experiences with Scrum? Would you like to work according to Scrum, but you still have doubts? Do you have any questions? Feel free to share your thoughts below!