Throwback: welcome to the world of agile
Our development team has been applying main elements of Scrum for a couple of years: stand-up meetings, user stories, burn down chart, sprint planning and review meetings have become parts of our life. The initial difficulties helped us a lot in becoming better, most important experiences of our latest agile development projects are summarized in this post.
Initial sprints: everything goes the rights way
At the beginning of our first agile development projects we decided to go on with two-week sprints. In our very first sprint we agreed with the inner product-owner to follow a grandiose plan to deliver tons of functionalities. We compiled the user stories, weighted them and split them into tasks assigned to project members.
First sprints met our goals perfectly, several functions got ready, project members started to feel the advantages of agile method.
Last sprints: storm is coming
However, it seemed that all went wrong during the final sprints. Reviews and planning of new sprints were missing, with reference to the following objections:
- "Everything included in the plan is ready."
- "The new sprint is planned, it is only about putting together the remaining user stories.”
- "There are loads of other change requests that must be handled soon."
- "There is no time for unnecessary administration."
Warnings of our development team – to remove some functions in order to compensate change requests – were refused by account managers claiming that all functions are must-haves for the client. Development team members were not satisfied with functions either, an increasing number of cases appeared when the system did not respond properly. Testers and designers became disappointed about the visual appearance, too.
Pressure became huge on the team, but thanks to the hard work and focus the project ended successfully and our dream of adopting Scrum came true. After identifying and solving problems, chaos and extra working hours just before the deadline converted into well-defined and easy-to-handle pieces.
Typical problems and the way we solved them
Hereby we try to summarize the most typical problems identified during our agile development projects. The way we solve them has been proved to be successful in numerous projects since then.
Discrepancy from the established process
It happens often that tasks end up in a wrong place in the project management system or that they are delegated according to the ’old rules’, i.e. directly, right after getting them from the client.
This leads to several misunderstandings, the scrum master should pay special attention on not missing a single task and putting everything the project management system. Further discussions about the process might also be useful.
Misunderstandings and differences
We are all human, it happens that tasks are interpreted in different ways or that former solutions become inappropriate for some reason. Clarification meetings help to resolve such situations.
Postponing design issues
Unfortunately we often have the feeling that design changes or problems can wait until every other function works properly. It is a completely wrong attitude; a function is finished only when all the expectations have been met, including design issues. Our solution is that every feature is demonstrated internally in order to avoid most of user experience related problems overwhelming us at the end of the project.
"I'm sure I can solve this in the current sprint." It happens often that certain remarks occur by the client side only during live program operation. With the exception of a critical change, managing these comments can usually wait until the next sprint. Final sprints must be planned with a safety margin so that a certain amount of minor, last-minute can be handled.
We want to figure out how the program should operate
Some old habits – like arguments between developers about how the program should work – must be overcome. A clear understanding of client requirements and keeping them in mind are essential for the good end result. Ideas and issues must be discussed upon the presentation of the end-of-the sprint version in order to avoid spending time on something that the user does not even want.