We are a team; we are winners – thought manager of the project like many others on the IT market. Therefore, since we are a group that has a common goal, we focus on success, and do everything to meet clients’ needs – why do we fail? It is time to take things into our hands, let’s organize our work, let’s implement agile projects.
Let’s be agile!
That was the idea of our main character. The question is, how to be agile? How to introduce agile methodologies to our project? How to convince a client to carry out the project using a different approach? The problems don’t lay in the above questions, since, who asks, will usually find a solution. The problems start when the project manager did not ask himself these questions before implementing agile methodologies. The difficulty begins when the methodology is introduced, and you don’t stick to the designated standards or bend the rules for the project. We know the rules are there to be broken, but breaking the rules established from the start, when the team is not fully familiar with the methodology, shouldn’t have happened. Established rules and schemes are there to tell the team “how it is”. Only when all the rules are fully understood, one should think about making improvements.
In this post, I’d like to give you some advice, which I hope will enable young Scrum teams to improve their understanding of assumptions of the process. Every team is different, each case must be approached individually, but with these few rules, it will certainly be easier for you to introduce Scrum into your project.
- Communication – good communication is the foundation of a well-functioning team. Scrum gives us great tools to improve communication – planning meetings, grooming, retrospectives and best of all – daily stand-ups. Most of the problems in teams begin with miscommunication. Scrum Master has to take care of it during the meetings, so that the team knows what is being discussed. During stand-ups, Scrum Master has to talk about things that are actually important. Each of you should admit how many times during the stand-up, after listening to 15 minutes’ speech of one of the team members, you realized that you have not listened at all? How many times during the standup have you thought “I’ll say what I have to say and I can go back to work, what do I care what does the rest do.” Lack of communication leads to lack of agility of the team.
- Understand the process – Scrum Master guarantees a good understanding of Scrum and compliance with its rules. According to Ken Schweber and Jeff Sutherland, creators of Scrum, Scrum Master is responsible for ensuring that Scrum methodology was understood and applied. Scrum Master should patiently teach the team about self-organization and multi
-functionality and should remove all the obstacles, which could restrict the work of the team. The team should start working in Scrum by familiarizing themselves with the process and thinking about why the following Scrum items are needed. Iterative improvement of one’s organizational skills is one of many advantages of working in agile methodologies. Streamline your process and eliminate the obstacles.
- Understand your role – without understanding and acceptance of your role in the team, it will be difficult to work properly in Scrum. If the Product Owner takes over the responsibility for estimating tasks, instead of Development Team, or Scrum Master tells the team how to do the task – just know that something is happening. In Scrum, everyone must adapt to their new role, and interfering with the competencies of other people is a simple way to defeat. In Scrum there are three basic types of roles: Product Owner, Scrum Master and Development Team. All roles are briefly described in the info-graphics, which you can find at the bottom of the page.
- Trust – trust in a team is important. If the team says that the task cannot be fitted to the Sprint, it probably is so.
Well-motivated teams do not try to limit the tasks in the iteration, simply because they do not want to work. No, the team has the biggest knowledge about the cost of each task and is at the best position to know which task could cause problems. Greed is one of the Seven Deadly Sins of Scrum (http://www.jonarcher.com/2010/10/seven-deadly-sins-of-scrum.html). Therefore we should trust the team’s speed calculated on the basis of previous sprints, and we shouldn’t allow additional tasks. This usually results in incorrect code, poor quality solution, or transferring tasks to the next sprint.
- Teamwork – Scrum is a team, a team that fully complements each other. If one team mode stops working, it reflects on the whole team. Let’s make sure that team members become acquainted, the atmosphere is right, and appropriate attitudes are praised. Words of praise for a job well done, on the summary of Sprint, are a great reward for the team. It’s all about collaboration.
Scrum is not a cure for all the problems of a team. Scrum will not tell you how to achieve success. Scrum is a set of rules that help you organize your work in the project. Thanks to this approach, our design process can turn into something really cool, or be a total flop. It all depends on our attitude, the willingness to cooperate and continuous improvement. Everything is in your hands :).
Certainly, one could mention many more factors that influence the success of the implementation of agile methodologies in the design, feel free to comment.
The following info-graphic shows some basic information about what is Scrum. If you are looking for a suitable tool to keep your project in this particular methodology, go to www.scrumbay.com and learn more about the capabilities of our product.
You can download it from Scrumbay’s website: http://scrumbay.com/uploads/ScrumPosterEN.pdf.