Coming across Scrum for the first time you may think you can manage projects with ease.
A Scrum coach assures that two days are quite enough to become a certified Scrum master. So, you might expect that you will learn the art of project management, applying such a powerful methodology like Scrum. Young jedis involved into rather expensive traineeship have a funny time, playing ball point game and waving cards with numbers. Two days later, the jedis are ready to manage their first projects under Scrum. No wonder. They feel inspired by the prospects of easy project and team management and they have a proof of their mastery – the certificates.
Did the Scrum coach tell them that Scrum does not guarantee success?
Years later, under the load of buried projects and lost comrades, the young jedi digs into the unknown worlds deeper and deeper. He comprehends the issues that the Scrum coach didn’t focus on, namely:
- User story is part of some complex thing. Before a project starts it is extremely useful for all team members, including the product owner, to understand this complex thing. Without grasping the whole thing, the architect can’t produce robust architecture of the future application. The lack of robust architecture leads to projects with:
- continuously growing price for implementation of each next requirement because it is not obvious how different parts of the application are interconnected
- continious bug fixing coming from numerous workarounds inside the mazy source code
- continious refactoring as an attempt to structure the mazy source code and remove critical workarounds
All mentioned consequences of architecture drawbacks increase project development time and budget.
Sequential implementation of user stories does not lead to the production of mature project architecture.
- Team’s readiness to make source code changes fast and easily during each project iteration comes along with the requirements to reconsider and refactor application architecture in order to avoid building up the technical debt. Ignoring a technical debt is like ignoring a bank debt. The later it is paid, the higher is the penalty. Continuos growth of technical debt can easily become the cause of project termination.
Variability of project requirements increases technical debt and leads to project termination.
- Source code changes can break the current business logic and cause additional bugs. Early bug detection by means of continuous integration and unit tests decreases the cost of bug fixing. In other words, each new feature requires implementation of new tests and improvement of already created tests.
Testing as part of development process allows creating a product of high quality.
- Team velocity depends not only on developers’ skills but also on the team life cycle. Moreover, same developer’s speed of development may vary in different teams. So, taking into account and paying attention to:
- team motivation as a whole and each developer’s motivation in particlular, as it is described by Maslow
- team development model described by Tacman
you can improve the development speed considerably.
Team development speed increases if you raise the team properly.
- Sometimes tasks set to developer can be not implemented or implemented incompletely. It happens because of 3 “NOs”:
- NO possibility to do because of the lack of conditions to implement the tasks as expected
- NO wish to do because of the lack of motivation in short or long term
- NO ability to do because of the lack of skills and expertise
Any unimplemented task has a negative influence on team velocity and team’s mood. So, you should track and eliminate the causes of these “NOs”.
Team velocity improves when obstacles are removed.
- Not all projects can be accomplished by means of Scrum. There are project areas where successful projects by Scrum are rather an exception to the rule than a regular event. Moreover, depending on the project requirements Scrum can be the best choice for one project stage and the worst choice for another one. Actually, apart from Scrum there are a lot of other project development methodologies and approaches which you must be aware of. Different methodologies can be combined by the Scrum master to pick out most beneficial features of all of them to accomplish the project.
It does not matter how many times the word SCRUM is repeated. In any case, YOU are responsible for the project success.
Having realized the described issues of project development, the skilled jedi understands that Scrum is just one of many methodologies popular due to its commercialisation and easy mastering. Many years ago a jedi was traped by an advertisement that listed Scrum benefits but concealed about all project development stages from initialization to closing. The discovery of these pieces has cost the jedi a lot of nerves, sleepless nights and lost projects.
Latest posts by Vitaly Hornik (see all)
- Scrum Master Games, or What Your Scrum Coach Didn’t Tell You - April 8, 2016
- FP vs TM Contract. Which One Is Better? - April 9, 2015
- Project Scope Management in IT Projects - August 12, 2014