6 Practical Agile Techniques You Can Start Using Today
Introduction
In large organizations one often finds a mixture of development models. Some projects are done in Agile, some in a more traditional way such as waterfall or RUP. Everyone has heard of agile development, but shifting to more Agile methods can often be a long and hard journey. This paper aims to explain a number of practical Agile techniques that can easily be applied to any development, and practical tips, which you can start using in your day to day work right away, even as of today.
This paper is based on my experience with hundreds of customers in large companies. All of the techniques mentioned hereunder have been tried, tested and tweaked over many years and I have repeatedly recommended any number of the below techniques for a huge list of companies, depending on their unique circumstances and needs at that particular moment in time.
Techniques such as user stories, usability testing, and improved communication will demonstrably aid teams in creating a better product in less time.
- Post a comment
- Email Article
- Print Article
These techniques have been identified as they provide a ‘low hanging fruit’ sort of benefit in that they do not require huge expenditures or investments, but produce noticeable and most importantly, trackable, improvements in processes, speed and quality.
1 - Deliver More Frequently
It is easier to write requirements, develop and test smaller chunks of software than to develop for half a year and then release. In many organizations, releases still happen 2-3 times a year due to slow release processes, waterfall-based project management models and most crucially, misunderstandings of what the best model of operation is.
I understand that it is not always possible to go from two releases per year to two releases per month, even if it is better in some aspects, however, more frequent deliveries are a de facto standard for making better software in this day and age. The question is how to get more frequent deliveries than what you presently have. Four releases per year is better than two, eight releases per year is better than four and so on.
This is closely related to the Lean concept called “Deliver Fast” and it forces teams to think of how to plan their work more efficiently while cutting down on waste, both in terms of wasted time as well as wasted code and implementations.
If the deadline is six months away, teams tend to work too slowly during development. If the deadline is one month away teams know that they have to speed up a little bit to make the deadline. By keeping releases every month you will always work a little bit more efficiently.
Additionally, it is impossible to find out all the requirements for something that is going to be developed over the next six months. Attempting to do so leads to voluminous requirements documentation where the reader drowns in all the details. Not to mention the problems that arise when you have to maintain all these requirements during the lifetime of the system.
Similarly, it is impossible to thoroughly test something that has been under development for six months.
2 - Bring Testers and Developers into Requirements Discussions
Requirements discussions are most productive when carried out in the form of workshops. Workshops, which involve both testers and developers (as well as the client, of course) will make it much easier to identify testable requirements, get them all sensibly grouped and then prioritizing said requirements.
Additionally, a workshop takes advantage of the team's complementary skills and ideas are illuminated from different perspectives. The requirements are simply better when compared to other forms of meetings where such a person writes down what the others say. Participants at a workshop are more active than at other meetings.
Workshops can be supplemented with several other requirements gathering techniques including regular telephone interviews with clients or occasional electronic questionnaires, sent to users to get an overview of what can be improved.
On the subject of requirements, it is of great importance that the requirements are not too detailed early on in the process. There is no compelling reason to place too great a focus on requirements that come into play a year from the time of writing. Writing detailed requirements for the coming year is a very non-agile habit and forces individuals to spend time on the wrong things. By all means take note of perceived future requirements but do not spend too much time fleshing them, mainly because things might change greatly by the time the requirements come into play.
3 - Testable Requirements Documentation
Start writing requirements in the form of user stories. This way, when writing requirements, you will tend to focus on needs rather than on the solution and technology. The danger of proposing solutions too early is that the real need might be forgotten. The solution that is built might correspond to the suggested solution, but it may not solve the original demands.
To easily formulate the overall business requirements, you can use the so-called WWW template that describes three important parts:
- Who?
- What?
- Why?
The WWW template describes who the stakeholder is, what the stakeholder wants (the goal) and why the stakeholder wants this (the motive behind the requirement).
If we apply the WWW method on a simple requirement it may look as follows:
| Who |
What |
Why |
| The user |
Wants to transfer files to two different servers via an application |
To store project data |
To inch ever closer to the user stories template, the requirement can be reworded as follows:
| Who |
What |
Why |
| The customer / user |
Wants to digitize the archiving process |
In order to better utilize staff skills, increase efficiency and improve information sharing |
Only now does the WWW template start to resemble what is called ‘user stories’.
User stories are a requirements pattern technique commonly used in Agile projects and are usually expressed as follows:
As a [type of user] I want [some goal] so that [some reason].
For example, in this case - As a client, I want to digitize the archiving process so that we achieve better use of staff skills, increase efficiency and improve information sharing.
In many cases the requirements do need to be fleshed out and detailed but that is a later step, not one to be taken so early on. Sometimes, however, you will get criticism saying that user stories are too short, repetitive, and that they all look the same. While the latter might be true, you do have to consider that the point of requirements documentation is not prose or poetry, rather clear and concise communication of user needs and wants. What really matters is that the documentation is clear, not that it’s varied or nonrepetitive.
4 - Communicate More, Document Less
Communication is a common problem in any project that involves a number of people and good communication is a prerequisite for being able to work Agile. The more years one garners in this industry, the more one will stress the importance of good, effective communication.
If your teams work in the same building, ensure that a lot of the daily communication takes place over coffee or at the desk. It’s much easier to understand what a colleague is saying face to face than it is from a hurriedly put together email.
Agile methodologies encourage daily coordination meetings, or check-ins, within the project. Of course, this is something that every project can benefit from.
It’s often appropriate to hold daily check-ins in the form of short “stand-up” meetings, so that they don't take too much time; usually the meeting takes less than 10 minutes in a group of 5-7 participants.
During check-in meetings, go through what has been accomplished since yesterday, what will be done today, and whether there are any problems that need to be discussed. It's also a good idea to visualize the progress, with a burn down chart for example.
Daily meetings aside, every iteration should begin with a planning meeting, where the time needed for every development, documentation and test activity is estimated. Iterations should conclude with an evaluation, which in Scrum is called a “retrospective”.
The purpose of these meetings is to find areas for improvement in the process. Planning and evaluation matters tend to require longer meetings, maybe half a day compared to brief meetings such as daily Scrum.
It's far too common for people to skip over these evaluations in traditional development, all too often with nightmarish results. The result is that the same mistakes are repeated over and over again, and that good examples that you want repeated in the next iteration are forgotten and not integrated.
A good rule of thumb is that the majority of the meetings are short and concise.
Even very practical considerations like the arrangement of furniture can improve communication.
Agile methodology emphasizes keeping the development group and the customer close together; ideally everyone should sit in the same room. Sitting close to each other is helpful in traditional development too. If it's not possible to always sit close by each other, you should at least try to do it frequently. Proximity improves communication. If team members sit too far from each other, feelings of “us versus them” can easily arise between different groups such as customers, users and developers.
Flexible roles also help in fostering good communication. For example you could set up teams in which there is no clear separation or demarcation between the requirements specialists, testers and developers. The whole team is involved in requirements management and testing, including the developers. This places greater demands on individuals, as it is not enough to be good at one thing only. However what you do get in return is that the work becomes more enjoyable, the quality is better and people work better together.
5 – Use Prototypes
Use sketches and mock-ups to clarify requirements for the user interface. Sketches are a useful inclusion in the requirements documentation and can also be used to do usability tests. These are used to evaluate the usefulness of newly developed features.
An illustration always speaks more than a thousand words. Not everybody understands a complicated requirements document, but everyone can discuss a prototype.
A common problem that can come up when new functionality is delivered is that of discovering that the customer actually wanted something altogether different. To make sure this problem is avoided, complement requirements with prototypes and combine the prototypes with usability tests whereby users execute an actual task in the system and explain out loud to the test lead if anything is difficult to understand or in any other way unclear.
Often improvement areas will be identified in the usability test and provided you operate in short iterations, the problem can be addressed by the next day and the test repeated with a different user.
Usability tests can be done with wireframes, pictures drawn in illustration programs like Microsoft Visio or Balsamiq Mockups or with prototypes in the partially-complete system. Developers appreciate the fact that they get quick feedback, instead of needing to correct the problems much later.
Prototypes work as a kind of “interpretation” where the developers confirm the requirement from their point of view and are a great way to improve the requirements dialogue, and confirm that the right system is being built according to the requirements.
6 - Think about Testing Early
Thinking about testing early can be a game changer.
In traditional development, it's quite common that test cases are written too late in the process resulting in shortcomings in the requirements being discovered so far along in the chain that it's too late or too expensive to address the problems.
However, if test cases are written in parallel with requirements, the result is that the acceptance test cases are completed when the requirements are finished. The test cases then function as the next level down in detail, on the level beneath requirements.
One problem that many people run into in agile development is that they don't have time to regression test the existing code base sufficiently. Iterations are short, usually 4 weeks from start to delivery. Better regression tests can be achieved by executing iterations consisting of design, implementation, and low-level tests.
After a few iterations you complement with one iteration that only consists of test activities. This iteration can have varying goals, such as focusing on system testing, integration with other systems, regression, or performance. After that, you continue Agile work with short iterations.
When working in Agile, there’s a risk that too little test documentation is written. If the iterations are approximately one month long, a particularly comprehensive test plan may very well not be crucial. Test planning will, of course, always need to be done, but it does not have to lead to a test plan being written. One approach is to write shorter test plans, while another is to develop a testing strategy for every system or maybe a strategy that covers all testing for one particular system.
The testing strategy describes things that don't change from iteration to iteration. Typical examples include the testing environment, test data, and a description of the goal of different tests. Having a documented testing strategy is a great security net to fall back on when there are doubts or uncertainties during test execution.
Next Steps for You
Of course, most companies or teams can’t afford to embark on all of the above tips as of tomorrow. However, there are plenty of places where one can start off from and move onwards thereafter.
For example you can start using user stories and usability. Your team might not be able to start working with Agile iterations in a few weeks time, but it is often possible to go from four deployments to six or eight deployments per year. It is possible to start the day with a short stand up meeting, whether you are working with tests or requirements management. Think about which meetings can be shorter in order to increase efficiency and reduce boredom. And if you do not have a common tool for testing and requirements management today, consider adopting one in a single project, and analyse how it goes from there on.
About the Author
Ulf Eriksson is one of the founders of ReQtest, an online bug tracking software hand-built and developed in Sweden. ReQtest is the culmination of Ulf’s decades of work in development and testing. Ulf is a huge fan of Agile and counts himself as an early adopter of the philosophy, which he has abided to for a number of years in his professional life as well as in private.
Ulf’s goal is to make life easier for everyone involved in testing and requirements management, and he works towards this goal in his role of Product Owner at ReQtest, where he strives to make ReQtest easy and logical for anyone to use, regardless of their technical knowledge or lack thereof.
The author of a number of white papers and articles, mostly on the world of software testing, Ulf is also slaving over a book, which will be a compendium of his experiences in the industry. Ulf lives in Stockholm, Sweden.