Peter Horsten
Agile and Lean aren't new practices, Toyota used them already in the 70's. Recently, these methods are getting increasingly popular. While talking to clients and IT providers I notice people are fighting how to implement Agile in the right way. Below a list of hurdles that you might be facing in becoming fully Agile. Feel free to add problems you are or have been facing. During the conference New Trends in Project Management, 27-28 April, Gdynia, Poland, http://ntpm.pl, I will discuss some of the hurdles and the possible solutions during the conference closing keynote. A summary will follow on our blog as well with in addition a new list with potential implementation solutions.
Many people underestimate the mindset change needed to change existing, very often rather bureaucratic or even chaotic, processes into an Agile flow. After reading some books and/or articles they start implementing components of the different Agile methods, without really understanding "Why". They chose the methods and tools they believe are easy to implement. But that doesn't mean you are becoming Agile. You will really have to change your mindset.
IT-departments very often decide to implement Agile methods and tools to improve their own performance. But without top-management support this might have some result but not the possible big impact it could have..
Similar to the implementation of Agile by the IT-department without management support is the case where the client is not eager to adjust its way of working. But, in case your client won't join, you don't have a Product Owner and you can really not fix this just by arranging your own "Product Owner Proxy". In case you client seems enthusiastic he will have to realise how much communication will be needed with the team and the involvement this will demand from the client side.
Clients want to know what they are going to pay for. All cost estimates and budgets will be merely indicative as consequence of the Agile based working method. In case you want to work in an Agile way you will not be able to fix the budget, define the delivery date and commit to the requested set of features.
As mentioned earlier implementing Agile working methods is not easy. There is a big risk that a team or even a whole organisation will return to old behaviour after some first issues.
For different reasons in many companies the business side, or even the end client, is just not happy about the deliveries. Agile is then too easily used as a last effort to solve the situation.
Thanks to the instant feedback loops teams frequently see the client as a test resource. Internal quality control does not get the attention it should get. The team is mostly focussed on delivering new features during a sprint.
On a daily basis the progress compared to the sprint goal (when using SCRUM) is being discussed. Problems will be noticed almost immediately. This transparency can cause fear among the team members resulting in destructive behaviour towards the essential change process.
The incremental and iterative work approach combined with frequent brainstorms in between the business (the demand side) and the team that has to deliver the solution, demands a certain level of business knowledge among the delivery team. Together the functionality that needs to be delivered will be described. But that is only possible when the team understand the business.
It takes guts to say: "For now we are done, let's get out of the building and see what our (potential) clients think about it". In general business managers and sales reps tend to continue defining additional features that are really needed before we can show it too the client, leading to all kind of (may be unnecessary) patch work.
Companies are used to the fact that the team members are working on multiple projects and meanwhile they are responsible for maintenance as well. In fact this means that the development of new functionality is always interrupted, leading to unhappy clients because the team never delivers. Implementing an Agile approach will not solve this "cultural" aspect of a lack of dedication.
Selling the impossible happens frequently in many organisations because the delivery side is not or hardly involved in the initial client meetings. The result: unrealistic deadlines.
When you are used to work on long term projects, the stress is always at the end of the project because 80% of the work is being done in 20% of the time. Working in iterations means you will have to deliver what has been promised by the end of the Sprint. There is a tendency to try to postpone delivery dates or just to drop certain features to stick to the Sprint end date.
To be able to deliver, you will have to really understand the needs. Too often communication about needs takes place at a too high conceptual level. Things might seem clear up to the moment the team starts realising them and has to conclude the tasks were way more complex than expected.
One of the great results of Agile working is frequent delivery. Very often this is one of the core reasons for an organisation to start working Agile. But the risk is that this leads to a lack of thinking about the bigger future picture resulting in a poor solution architecture, too little testing and too little documentation.
A lack of trust in between the demand and supply sight might be one of the most important ones. Without mutual respect and trust Agile will never work,
Whether you are delivering an internal solution or a commercial one, depending on the client you might have to face additional bureaucratic procedures for user acceptance and signoff processes.
