Agile! Why Not?

IBA MinskAlex Minkevich, PMP®Agile is beautiful. Agile is our all. Both developers and customers like Agile. However, there are projects or project phases for which Agile doesn’t work or is worse than the old good Waterfall. In my projects, developers intuitively feel when Agile can work and when it can’t, and it’s time to transfer from Waterfall to Scrum or the other way around.Why and actually when should we do it?In this article, I would like to discuss project success from a business perspective and not from a developer perspective. What’s the difference? It is very simple.In the view of a service provider team, a project is a success when the application met customer requirements, the client signed the acceptance certificate, paid the money, and the developers received salaries and bonuses.As for business, a project is a success if it helped achieve a business goal, for which it was approved. It might be earning profit, releasing a new product or service, gaining a market share, meeting law requirements, or serving a social need. A business goal should be achieved on time. It means the time is always limited and quality standards are are high. Imagine you are a customer and let’s see when Agile is not working or working but not that good:1) Scope of work. A bullshit input leads to a bullshit output. Let me give you a small example here. I am making a small web project. Imagine a dialogue between myself and the developer.–Are there any requirements?– No… (face palm)– I see. Then we use Agile!This sort of dialogue is quite typical. Agile is good when there are no clear-cut requirements.However, how can one start a project, if there is no understanding, what he or she wants to get? Each value should have a price. If there’s no price, there’s no value. The customer does not want to pay for clear requirements from the very beginning. There’s no time for that.But there is a strong wish to go ahead…. Then one should understand that the requirements will be born in hard labor of many iterations and the customer will have to pay for them anyway. There will be additional cost of rework because something will be done in the way we did not want it to be and changes and revisions will be needed.It is good, if the project is small and you have excellent communication with the developer, are on the same wavelength and quick on the uptake. What if the things are opposite? The project is big and you are based in the UK, while the developer team is in Belarus. There might be many iterations and revisions. The team will fall behind the schedule and customer requirements will be labeled first as Customer Requirements, then as Urgent Customer Requirements, Customer Troubles, Customer Pain in production… You understand what I mean.2) The key question is:When will this come to an end? Those who did repairs at home can understand me.“A project is a temporary endeavor undertaken to create a unique product, service, or result.” (A GUIDE TO THE PROJECT MANAGEMENT BODY OF KNOWLEDGE PMBOK® Guide, Fifth Edition, Page 3)‘Temporary’ is a key word in the project definition. Agile does not give strict schedules. If I don’t understand what I want to achieve, how can I know when I will complete it? Therefore, an Agile project cannot be completed. It can just be stopped. Any business person wants his or her project to be completed successfully and not just stopped after 80 percent of the top priority backlog is implemented. It is also clear that there is a direct correlation between falling behind the schedule and a price increase.3) Management of cross-functional teams. If there is one team of 5-7 people, it makes no problem to manage it. What if these are cross-functional teams? The frontend is in Minsk, the backend team is on the customer site in South Africa, the testing team is in India … The planning and coordination for the customer/project manager becomes a nightmare.One should have iron nerves and fanatic energy to make the work run smoothly. Only a few people can do that.4) The last but the most important thought in my view is the following: “Agile helps chop off illusions but such project is like trying to catch a rabbit running in circles. We are doing what we can do to meet the current business needs and we are not thinking about what business will need tomorrow.”© Dmitriy Bezugly http://www.system-approach.ru/It is clear. I talked a lot with businesspeople in the last two years. These guys want all or nothing. There’s no grey for them, just black or white. By meeting the today’s business needs, you are closing the gaps in the current operations and doing nothing for the future business. To make a solution that will be on demand in a year, one should sit down and think hard, and then document the thoughts as requirements.Conclusions. We should do what everyone is already doing. We should mix methodologies on different projects and even inside one project. Let it be Waterfall or RUP when you define project requirements, then we can go ahead and use Agile for development, back to Waterfall or RUP when we go to production. The requirements should be developed before DD.MMM.YYYY, the backend with the defined functionality prepared before DD.MMM.YYYY, three weeks from October 6 to October 24 are allocated for testing, and then exactly three weeks for go-live. It is strict and accurate project management in its classical sense.Which technology to use, be it Scrum, Kanban, Waterfall or RUP is not important. One should be guided by common sense and specific conditions of a specific project. Remember that the aim should be achieving business goals of the customer and not getting as much money or person-hours from the customer as we can. Otherwise, how would we be different from others?