JIRA's way of partitioning the project into versions might at first glance appear as the same thing as sprints, but a deeper difference between SCRUM's and JIRA's view on software development lurks below. Where JIRA's concept of versions focus on the progress and roadmap of the application, the sprints in SCRUM acts as containers for sets of tasks, which the development team can work on. This indicates a fundamental focus in the two approaches to software projects:
- JIRA models an application focused approach to software development, with a task management aspect.
- SCRUM models a task based approach to software development, which hopefully reflects some kind of application development.
The difficulty of JIRA to model SCRUM is just one of a number of symptoms that SCRUM is a less than perfect tool for application development. Even though pretty much all of our development teams have at this point succumbed to the euphoria of SCRUMs blessings, no one has really been able to consistently finish 'good' sprint. Usually the sprints ends with a lot of lose ends, and a very unclear picture of what was achieved compared to what was planned.
This is most commonly contributed to a number of more or less unjust factors, like external intervention, unclear goals, imprecise estimates etc. In my opinion all these annoying 'factors' are more an indicator of how fragile the SCRUM sprint is , because of all the implicit requirements the sprint has to its environment. These sprint prerequisites include:
- Stable team: The central task processing engine in SCRUM is the team. If the team isen't 100% dedicated towards completing the sprint, the sprint breaks. Causes could be the allocation of people for external crisis handling or changes to the partial allocation of team members.
- Stable sprint backlog: The task set to be processed in a sprint is defined by the sprint backlog. If this changes the sprint breaks. Causes could be the introduction of emergency tasks or just general reprioritizing of tasks by higher powers.
- No external dependencies: The SCRUM name implies that the team gangs up for completing the sprint at hand and without assistance from others. If the team isn't able to complete the task defined in the sprint alone they have to draw on external resources. If the external resources do not act fast the sprint breaks. This is a very likely result of having external dependecies, which will be outside the control of the SCRUM team and probably have other priorities.
- Clear goal: One of the cornerstones of the sprint is the team being able to share a common goal and everybody works hard at reaching this goal. If the sprint goal is unclear, much of the 'uniqueness' of the sprint concept disappears, and the sprint 'degenerates' into normal iterations or increments. In my experience the set of tasks very seldom sums up to a common goal, most of the time the sprint backlog is defined by the priorities in the product backlog, ad-hoc bugfixes, available resources and other unrelated tasks.
- Small, well estimated tasks: Even if the list of tasks in the sprint backlog remains stable, the ratio between the task estimates and the actual work used for completing the tasks has to be pretty stable to be able to predict the velocity of the team. If the velocity of the team is unpredictable the sprint breaks. A lot of the tasks needing to be solved in software development are very hard to estimate individualy. Some examples are bugfixes, analysis work, integration tasks, etc.
- Visual results: One of the valuable outcomes of good sprints should be clear and visible results of the sprint. If this isn't possible the value of the sprint diminishes significantly. But a lot of the work needing to be done in a software project are enablers for the development of the application, and as such doesn't produce any direct result. These types of tasks include: Framework creation, design and architectural work, documentation and specification work, education, etc
The result is that everybody is currently walking around crying SCRUM as the answer to every project management challenge, but nobody is really seeing it work correctly in their project. Any critical approach to improving this situation has been paralyzed by the blind followers of the SCRUM movement, who have hijacked agile development the last couple of years.
Posts
7 comments:
I pretty much agree with you, that the factors you mention must be fullfilled, before scrum can excel (no pun intended). But even if you fail on several on these prerequisites then scrum will deliver half-decent or even decent result. And - IMHO - better than every other know alternative.
That aside, I must admit that I have also experienced the subtle but significant mismatch between JIRA and scrum, and therefore I must ask you: Apart from "abandon scrum and adopt JIRA!", what would you suggest? Would you give up on JIRA when "scrumming"? Or is it possible to adapt JIRA to scrum or vice versa?
The purpose of the post isn't to abandon SCRUM, but rather to avoid relying on SCRUM as the foundation the rest of the project is build on. A good project foundation, should be as robust as possible to factors usually seen in the real world, and SCRUM fails to achieve this. JIRA on the other hand is pretty much immune most of the inconveniences one can throw at a development project. JIRA is on the other hand not a project management process in itself, and needs some kind of methology defined how to process the issues maintained in JIRA.
So my answer is that projects should be build on JIRA, but you should still attempt to implement SCRUM, if you are so luck to find yourself in circumstances where this makes sense.
Hi Mikis, the fact that it's difficult to model Scrum in Jira is no indication that Scrum is broken. It is certainly an indication that Jira is less flexible than we'd like. Just like the fact that your team has trouble delivering what they promised to the product owner at the beginning of the sprint is certainly not an indication that Scrum is broken. I am a lousy piano player, but it's not my piano's fault.
In fact this something that happens often: you apply Scrum, and suddenly a lot of problems become apparent. But the problems were not caused by Scrum, they were exposed by Scrum. Blaming Scrum is just like blaming the messenger.
I think the fact that your team has found these problems means that applying Scrum was in fact a success. Now you have the choice of addressing the problems, or ignoring them. In the latter case Scrum won't do you a bit of good.
Hi xpmatteo
I agree with you that most of the problems exposed in a project when introducing SCRUM, are actually symptoms of deeper laying causes.
But in most projects these imperfections do exist, and any framework used to ensure a project success, should at the same time be apply to exposed project faults, while also being able to continue to function efficiently, regardsless of the projects shortcomes in general. JIRA excibits such robustness, SCRUM doesn't.
The issue I'm trying to address is the robustness of SCRUM compare to JIRA. If the focus was improving the efficiency and quality of the application development, JIRA doesn't help as much, as a well implemented SCRUM process. But because SCRUM is a much more fragile construct than JIRA, SCRUM should be implemented on top of a JIRA foundation, not the other way around.
The combination of the 2 is the way to go, but the current hype of SCRUM, could do with a reality check to bring the priorities right ;-)
Hi Mikis,
you seem to say that you need a well-implemented Scrum process to start with; I disagree. No team is perfect, no situation is ideal; this does not mean you can't use Scrum. Start using it, and improve along the way. A well-implemented Scrum process is not something you need to have so that you can start; it's something you arrive at with time. Scrum is nothing more than a framework for improving.
As to the comparison of Scrum and Jira, I think it's a bit like comparing apple and oranges. One is a method, the other is a tool. Many Scrum teams get along well with nothing more than a spreadsheet and a cardwall as tracking tools. Jira does not give you much indication on how to organize the development work. It's up to the user to provide the method.
Of course I'm an XP coach by trade, so my priorities may be different from yours :o)
Matteo
Yea, the whole SCRUM vs. JIRA line of thought is a bit of a contradiction, because the two concepts at the surface are pretty unrelated. But they do on the other hand have a lot of 'contact points', where the tool meets the method, and it is the friction occuring at these points that are interesting.
In general I find it to be the 'points of contact' between different aspects of application development, that are the most interesting to explore. One reason for this, is that is often gives you a different view on the problems at hand. Eg. both SCRUM & JIRA contains insights into the domain of application development. Another reason for my interest in these crosscutting points of integration is that they often are neglected. Therefore cheap opportunities for improvement can be harvested by putting a bit of focus into these areas.
Of course, tooling plays a major role in the consulting services I provide, so my priorities may (also) be somewhat unbalanced :-)
More useful information are provided by this blog..Thanks for sharing this blog
Jira Tutorial online
Post a Comment