The biggest problem of all software developers
Do you remember the time when software products were developed using waterfall methodology? I know that many types of projects must still be developed using this old-school approach. But now when everybody is crazy about agile one problem pops up that has been hidden for a long time.
When you have completed specification for every aspect of the application the only thing that you as a developer has to do is to implement each requirement. You don’t need to know who your users are, you don’t need to meet your customer, don’t need to talk to them, you don’t even need to think about what you are doing. The only thing you care about is technical implementation of the requirements that somebody has written for you on a paper.
As expected, working only by specification has many disadvantages, for example:
- Customer has to know each aspect of the application before the first line of code is written
- Customer can’t change requirements easily
Agile methodology is a great step forward and is designed to make customers happier. It brings iterative development and early feature deployment.
Canonical Agile says that the customer should always be somewhere nearby and be ready for questions. In reality this is quite a challenge because he may be a busy man not ready to spend much time on this. On the other side, customers think that they should define what is better for their product. And this is true by default unless you have an on-site Interaction Designers’ team caring about what really should be done from both user needs and customer’s business perspective.
The main problem with agile is that managers are only team members who are using it. Think about it, in majority of cases the only people who are talking about what exactly should be done are the product owner and the project manager or a business analyst. What has changed for a regular developer is that instead of just implementing features he should attend many different types of meetings. It can take up an entire day in some cases.
As a result, there is still a “proxy” between the person who decides what the product needs and software developers who decide how the product will actually be done. I’m not saying that business analysts are bad guys because they are trying to allow us to focus on what we do best - coding.
Recently I have been on the other side (as a customer) and I’ve realized that developers don’t think about what they are doing! They implement a feature but forget one little thing that makes the feature completely unusable for users. I recognised myself doing the same thing from time to time because when I’m implementing something I’m focusing on the application architecture, performance, code reuse, readiness for following changes of requirements, and naming a variable. The main thing slips from view: who the hell will be using this and how this feature will be transformed into money.
Now at sprint planning meeting I always ask the following three questions:
- Who will use this feature?
- Why user needs this feature?
- Why customers think they know why user will use this feature?
Ina conclusion I’d like to quote my collegue:
Before you start some work, always ask yourself three questions - Why am I doing it, What the results might be and Will I be successful. Only when you think deeply and find satisfactory answers to these questions, go ahead. © Chanakya