iceScrum v7 is coming! Click here to see changes and download it!

Agile is not magic

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!

Agile doesn’t mean adaptation to everything

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.

dilbert agile triangle

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.

Scrum to the rescue

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.

Theory versus reality

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”.

There is hope!

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).

Cheers!

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!

Defects in agile methodologies

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.

iceScrum and bug trackers

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.

Bug trackers compatible with iceScrum
Bug trackers compatible with iceScrum

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.

Defect management in iceScrum

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:

  • “Defect story” type, which makes clear that the story is a defect to be fixed. An exclamation mark icon is displayed on the post-it (the icon will become a “bug” in iceScrum R7).
  • Affected version, where you can point to the product version affected by the bug (a version associated to a sprint beforehand or a new version that iceScrum doesn’t know about yet)

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.

A defect story in iceScrum R7
A defect story in iceScrum R7

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.

Is there any additional special treatment to manage defects that you think would make sense? Tell us in the comment section!

Si vous êtes un agiliste confirmé vous pouvez sans doute passer votre chemin ou lire l’excellent article (en anglais) de mon collègue Nicolas sur le futur d’iceScrum. En revanche, si vous êtes débutant(e) en agilité comme moi, enfin comme moi avant, alors je souhaite partager avec vous ma vision sur ce domaine que j’ai découvert il y a maintenant 3 ans.

N’étant pas issu du monde informatique, j’ai néanmoins pu observer ce grand mouvement vers les méthodes agiles, à travers internet, les réseaux sociaux et bien sûr mes contacts avec les clients et utilisateurs d’iceScrum. Ce qui était il y a peu encore une niche est désormais au centre de l’attention de tous les acteurs de l’informatique, et pas seulement (certains auront peut-être même vu des publicités à la télévision proclamant une certaine “agilité”, nous ne commenterons pas !).

Que ce soit les startups et PME ou les grands groupes en quête d’innovation, l’agilité est maintenant incontournable dans le paysage des entreprises françaises et internationales et c’est tant mieux ! Elle est d’ailleurs plus que jamais d’actualité à l’ère du management éthique et responsable, des entreprises libérées et du bonheur au travail.

En parallèle, les formations “certifiantes” déferlent sur l’Hexagone, bien que j’aie du mal à comprendre comment on peut devenir un super ScrumMaster en 3 jours ou en remplissant des formulaires sur internet alors que c’est un rôle pour lequel l’expérience personnelle et la dimension humaine ont une importance majeure.

Dessin-blogpost-3

Toujours est-il que la communauté agile grandit elle aussi et de plus en plus de villes ont leurs groupes d’agilistes novices ou confirmés qui se réunissent autour d’un petit déjeuner, d’un verre de vin ou d’une table ronde. Des conférences y sont dédiées, telles que l’Agile Tour. Avec Kagilum, j’ai d’ailleurs participé deux fois à l’édition Toulousaine dont nous avons été partenaire pour apporter notre petite pierre à l’édifice de la communauté Agile française. C’est une expérience de partage, d’apprentissage et d’échanges que je vous recommande !

L’agilité gagne aussi bien sûr les outils de gestion de projet dont on ne compte plus les plugins, les adaptations ou les simples renommages “agiles”. La première valeur du manifeste agile est là pour rappeler que les individus et les interactions doivent primer sur les outils, c’est pourquoi nous avons bâti iceScrum sur les valeurs de l’agilité et non pas seulement sur sa terminologie et ses pratiques. Nous pensons d’ailleurs qu’un bon outil peut rendre des services fondamentaux (je ne les évoquerai pas ici) mais qu’il n’est pas suffisant.

En effet, il est primordial de bénéficier d’un accompagnement humain tout au long de la transition agile pour que ce changement majeur soit un succès. Un bon moyen de mettre le pied à l’étrier est de suivre une formation qui fournit une base solide et les éléments fondamentaux pour aborder sereinement les défis de cette transition. Nous proposons depuis plusieurs années des formations qui remplissent ce rôle en enseignant les racines et les principes de l’agilité ainsi que les pratiques de Scrum en les mettant en application (avec iceScrum ou pas, c’est au choix !).

Depuis maintenant 5 ans nous proposons des formations sur la méthode Scrum. Nos formateurs ont sillonné l’Hexagone et répandu les valeurs agiles sur leur chemin. Notre offre de formation a maintenant une page dédiée sur notre site : suivez le menu “Training” en haut de cette page ou cliquez ici pour en savoir plus, et peut-être à bientôt autour d’un planning poker !

Je terminerai en conseillant évidemment à tout agiliste en herbe de lire des ouvrages sur Scrum dont certains sont très instructifs, j’ai moi-même commencé par là. La lecture est une chose mais suggérer des stories et y ajouter des tests d’acceptation, estimer en points, prioriser puis planifier les stories et savoir analyser les différents indicateurs de projets, tout cela nécessite une expérience “vivante”.

Aussi, si vous avez besoin d’un coup de main pour vous lancer, n’hésitez pas à faire appel à notre équipe de formateurs !

You are currently looking at the future of iceScrum! Well… at least a part of it. Indeed, the visual identity of our website will soon be shared by our tool, and it is just one of the many improvements we are preparing for you…

Former logo      New logo

With years of experience and enlightening feedback from our users and customers, our vision of iceScrum kept evolving until a point where the current version, iceScrum R6, had shown its limits. Indeed, it hindered our ability to offer you the great tool we think you deserve: the best of iceScrum but easier to use, multi-support, more consistent, more customizable and more intelligent.

That’s why, more than two years ago, the seed of a brand new version has been planted under the name “iceScrum R7”.

Our idea consists in two simple parts:

  1. Address today’s needs for the best agile project management tool by improving upon iceScrum R6 in every aspect thanks to the experience and feedback we have gathered.
  2. Give iceScrum the ability to adapt to future feedback and to the continuous improvements made in the field of agile methodologies.

To materialize this idea, we chose to:

  1. On the surface: keep the best of iceScrum and deliver it under a more consistent and enjoyable user experience, in addition to sensible new features.
  2. Under the hood: re-build iceScrum on top of modern and robust technology that will give us a solid foundation to ensure years of maintainability and improvability.

Contextual editing of a story in unified & customizable backlog view
Contextual editing of a story in unified & customizable backlog view

As eager we were to fulfill this promise, we did not let down our faithful users and customers and kept improving iceScrum R6. In parallel, we started iterating on the R7, both on the user interface in collaboration with UI/UX experts and early testers that provided an insightful feedback, and on the technical foundations.

Mobile & Tablet support
Mobile & Tablet support

In a lean startup fashion (if you don’t know lean startup yet, we highly recommend that you have a look at it!), we have pivoted a few times until we found an effective and simple way to provide the rich interactions required by agile project management. Sprint after sprint, we delivered user stories and today we are happy to say that iceScrum R7 is very close to beta!

If you want to be part of early R7 testers or if you just have anything to say about theses news, let us know in a comment!