Agile: What Next? Or a Short Guide for Those Who Are About to Do an Agile Project, Part 2
In the previous article, we mentioned contrasting approaches to Agile and the conditions to be met to increase efficiency and cut workloads.
This second part of the series will tell you:
- How to identify values in a project?
- How to check if you deliver on the identified values?
- Why you shouldn’t limit project implementation methods?
With the Agile methodology, you create a product of the highest value.
This slogan is strongly related to the subject discussed in the previous article, namely how to work more efficiently, without unnecessary workload – and it refers directly to project scope management. To ensure that programming work is focused on the most valuable components, you should know the following rules:
Rule 1: Be aware of your project’s values
The values may be embodied by the ROI, or risk mitigation for that matter. If you are not sure that customers will use a particular feature (read on to see how to check that), then is it worth fully implementing something that could only theoretically generate the highest profits?
Work on identifying value for each project stakeholder – and make sure that items from that list are linked to the objectives of the tasks developers are working on. Prioritize those values so that the team has clarity about what they should remember when developing the product.
Rule 2: Regularly track your progress towards the identified values
There are many methods – one of the most important is to bring the developed features to users on a regular basis. Collect feedback by observing how they work with the system. Start collecting feedback right from the start – in this way, you will avoid investing time and money in the wrong solutions. You will achieve this by enabling the implementation of even small system components or isolated features. With this approach, you will get ongoing feedback from the end-user, and will save yourself energy and costs associated with maintaining unnecessary code.
Another method (although the use of both methods at the same time is recommended) is to set appropriate quality metrics. I guess that, if you are not sure how long you are going to use a particular solution, you will not want to incur costs to ensure the highest page loading speed. So the best thing to do is to establish the appropriate quality, performance or functional levels for each stage of the project. Are you designing a solution that should be intuitive? Consider using a group of testers who are not familiar with the product, and ask them to work with the new features. This will allow you to set proper priorities for developers. You might have a sophisticated function, but what if your users will not know how to make use of it? Remember that Agile is an empirical philosophy – test your ideas first, instead of assuming that you know what the final solution should best look like from the start.
Rule 3. Don’t talk about “how”, talk about “what”
I have already mentioned this aspect when talking about imagining the outcome of the work. Don’t limit the multitude of ways to design a feature to what you have seen or heard before. Project implementation is a team effort, and that’s for a reason. X heads are better than one. The benefit lies in the number of people working together. Multiply this benefit, making sure you get your team involved in designing the solution at an early stage. They will be asking key questions regarding the choice of architecture. It may well be that they have prior experience working on a similar solution in other projects, and know where focus should be placed. They might be able to say which solution will be more time-consuming and which will be more scalable.
Likewise, it would be counter-productive to provide your team with detailed documentation and then invite them to a brainstorming session, expecting them to shower you with great ideas. This is for the same reason as when you first watch a movie, and then read a book based on that movie, imagining the characters as actors, and recollecting the scenes you have seen on the screen. Solutions that have been seen cannot be unseen, and it is hard to rewire your thinking. You might want to read something by Theodore Levitt, who perfectly encapsulated what I am trying to say in this article:
People don’t want to buy a quarter-inch drill.
They want a quarter-inch hole.
Let me reiterate then: focus on the need, don’t assume a solution.
The last part in the series of Agile articles will tell you:
- How does the Scrum methodology drive the team effort?
- What project components should be in focus when working in Scrum?
