After years helping companies to adapt their practices and change their mindset toward agile values, a comment we hear very often is “Ok, we know that we don’t follow the recommendations… But our context is quite singular and Agile/Scrum is meant to adapt to everything, right? Thus, we adapt it to our context.”. Unfortunately, it is not as simple as that!
Let’s first draw the relation between the Agile culture and adaptation. The Agile culture consists in a set of values. Accepting and facilitating change is one of these values. It comes from the observation that unlike other domains early software management took inspiration from, it is difficult to plan software development ahead and very unlikely that requirements, expectation, budget, delays, etc. will not vary a lot as the project goes on.
Among the many things that may change during a project, an agile mindset mainly helps anticipate and adapt to changes of delays, budget and functional scope (along with the underlying code). However, this is no magic and one cannot summon agile “we are agile, why don’t you adapt?!” each time an adaptation would be desirable.
Take a traditional organization, if it considers that agile must adapt to the existing values of the organization, then that is just putting an “agile” label on them, which is meaningless. If an organization wants to be agile, then it must adopt the agile culture and its values. This change, which is often called Agile transition, adoption or transformation, is difficult and has a significant impact on an organization as a whole.
One of the main goals of Scrum is helping in this process. This methodology is a framework that brings a common terminology and set of rules that make adoption of agile values easier by naming and legitimating practices that favor them.
Just as any framework, it is recommended that novice teams follow the rules. On the other hand, a mature team can bend them because it knows precisely why it is relevant to do so. Sometimes, that means moving from Scrum to a lighter and smoother workflow inspired by Kanban. However, an Agile team may need months or even years to reach this level of maturity.
Our experience told us that on the field it’s a whole different story. Disclaimer: this is not a criticism to any organization, but rather our observation of a phenomenon that has intricate roots and implications.
The majority of teams switching to agile do so in a context that is hostile to Agile values. In such case, practices involving a change of mentality are simply put apart in the name of adaptation in favor of “visible” practices (e.g. daily stand-up meeting, post-its, burndown, user stories instead of requirements…). Adopting these practices is a change, but it mainly impacts developers who then grow an aversion to “Agile” as they pay the price of change without any benefit. In the end, if such projects fails or gets delayed, Agile and Scrum are pointed out as the cause and it is concluded that “it doesn’t work”.
Make no mistake, I am not pessimistic and it is definitely possible to avoid this scheme! The first step consists in acknowledging the risks (that’s why we write this blog post!). Then, we really encourage you to reach out for external help through coaching and training (if your team is located in France, check our training services: https://www.icescrum.com/training/, we will be glad to help!). Finally, It is also essential to observe the practices provided by agile methodologies (it doesn’t have to be strictly by the book, but if you have to choose, focus on rules that trigger mentality change rather than the easy ones).
We are often told that iceScrum doesn’t do much to help manage bugs / defects, backed by the evidence that it doesn’t provide a separate bug system with its own workflow and that defects are seldom mentioned in the user interface.
Actually, this doesn’t denote an absence of feature, it is a deliberate feature! Well, software developers have a tendency to dismiss negative user feedback by saying “it’s a feature!” so you may be becoming a bit suspicious here… Don’t worry I understand and I don’t ask you to take my word for that, I will rather try to explain our motivations!
First, let’s forget about iceScrum and start with traditional project management because I think that most preconceptions about defect management come from there. Since requirements are intended to be all known in advance, the product specification is written once and for all. Throughout the project, this document is the comprehensive source of truth telling what the product is expected to be. Deviations from these requirements observed in the product clearly don’t belong to the same document, that’s why they are filed into bug trackers.
Fast forward to agile methodologies, where there is no such thing as an exhaustive product specification document. Of course you may have formal specification or documentation (I hope so!), but the vision of what the product should be evolves continuously and, rather than a document, it’s the responsibility of the Product Owner to embody this vision.
The product is what it is and any desired deviation from its current state must be submitted to the backlog where it is discussed, prioritized by the Product Owner and planned accordingly so the team eventually implements it in the product. Whether this deviation is a missing feature, a defect to fix, a useless feature to remove, a performance problem or a software quality issue doesn’t matter, and this fact is a major asset.
If you have separate backlogs, how does the Product Owner materialize their vision, how do developers know what to implement next, and how do users or stakeholder know what to expect in upcoming versions of the product? For the backlog to be effective, it must be unique and ordered.
Now the title of this blog should make sense: we usually don’t recommend using bug trackers as you know them (i.e. separate tools with distinct workflow) to manage defects. However, you may already have a bug tracker you are used to and getting rid of it at once may not be desirable. Back to iceScrum, that’s why our tool provides integrations with bug trackers, making the transition smooth.
The supported bug trackers are Mantis, Bugzilla, Trac, Redmine and Jira. If you too want to sponsor the support of another bug tracker, please contact us.
The integration is straightforward: people fill bugs in your bug tracker, when they are ready they are imported automatically in your iceScrum backlog where they continue their lives. Changes in iceScrum are synced back to the bug tracker. This way, people who report issues are not forced to learn and use iceScrum when you team start using it, but of course in the long run learning about what really happen to their issues would be beneficial! Read more in the bug tracker documentation.
As I said, we don’t recommend any unnecessary special treatments for defects, but iceScrum provides actually two simple ones that we think add value:
Creating an effective defect story is as simple as filling these fields in combination with regular story fields, e.g. a proper description, attached screenshots to demonstrate the issue and a dependency to the done story that it relates to.
In iceScrum R7, you will also be able to define story templates to pre-fill stories when you create them so this will give you the ability to define your own default task list, e.g. “Reproduce the bug”, “Write a unit test”, “Solve the bug”…
Finally, some metrics such as the project Burndown Chart allow to keep track of the evolution of defect rates, which of course you want to keep low. Apart from that, a defect story continues its life in iceScrum just as any user story.
In an ideal world, to preserve your team and reduce “sprint noise”, an Agile team would be dedicated to one project at a time. But reality is often quite different and isn’t always as easy as expected.
You have to deal with holidays, sick leaves, maternity leaves and other things every day! That’s why it’s often necessary, Agile project or not, to explicitly manage your team members availabilities.
With the Availabilities extension! When enabled on your project, each team member can set their availability (we don’t like terms like allocate, resource…) for each day of a sprint. For convenience, the ScrumMaster can manage that for everybody.
Day, hours or minutes (really?) can be used as measurement unit. It doesn’t matter as long as you choose one and use it consistently in your project.
Other options are available such as pre-filled values or disabled weekends. Oh wait, do you work on weekends? “Sustainable Pace” will be for a futur blog post!
Spreadsheet lovers will be happy: cells behave like in Excel.
In parallel, if your team updates task remaining time with the same unit during the sprint then you get a powerful indicator for your sprint. Usually the remaining time is updated before the daily meeting so it can be displayed and discussed.
It’s tempting to have a remaining time equal to availabilities but it is not safe! Indeed, you must take into account risks and additional time needed to manage emergencies. From availabilities and remaining time, iceScrum computes the sprint latitude. This useful indicator is easily set and visible in your sprint. Sprint latitude will be adjusted according to the context, the expertise of the team or the project difficulty.
There is no magic in the latitude calculation but this post isn’t intended to replace our documentation, so for further reading you should read this.
At higher level, the Project bundle feature is another way to use the data. You can easily follow team availabilities on several parallel projects or for Scrum of Scrum. Of course, in order to make better use of the data, you will synchronize sprints between these projects.
The following information is displayed for each sprint:
*With iceScrum of course!