Here comes iceScrum 7.0.0-beta.7.
This version brings the “Team availability” feature back, making a new step towards a final release. It works as before, including the recent addition of the useful Sprint Burndown Chart that compares the remaining time to the remaining availability.
Apart from that, this new beta also fixes a few bugs and improves the overall performance of the application.
We are now implementening the last “must-have” features so are now very close to the functional scope we want for a first public release!
Thanks for all the great feedback we receive. We are very glad to know that this version will be enjoyed both by our longstanding users and the newcomers.
Here is a new iceScrum 7: 7.0.0-beta.6.
A promised, after Git/SVN integration we worked on another big iceScrum Pro feature: integration with bug trackers, namely Bugzilla, Jira, Mantis, Redmine and Trac.
These integrations work quite like before (here is the old documentation for reference: https://www.icescrum.com/documentation/bug-trackers/).
A nifty addition is that you can now apply a story template (including features, tags, tasks and acceptance tests…) to stories imported from your bug tracker. For the record, story template allow prefilling stories with data taken from an existing story which serves as a model.
Open your project settings http://beta.icescrum.com/ and configure your integration!
This version comes with other improvements:
We took some time since the last release, partly because we also released a maintenance version of iceScrum R6 (R6#14.11) and we moved our main office to an awesome new location, you may hear more about it soon!
A new iceScrum 7 beta is here: 7.0.0-beta.5.
As planned, this version comes with Source Code Management and Continuous Integration (Git, SVN, Jenkins…).
That means that you can know link your commits to iceScrum Tasks and Stories and get the latest build status on your project Dashboard!
We did not choose this feature by accident, in the “Eating your own dog food” mindset we can now link our commits to our public project.
Try this version on http://beta.icescrum.com/.
We plan to continue releasing big features to get closer to the general availability, stay tuned!
The fourth version of iceScrum 7 beta is now online: 7.0.0-beta.4.
Open http://beta.icescrum.com/ to try this version!
As promised, we try to push the pace of releases. After making the beta more robust, it’s time to bring big features to get closer to the general availability. Our next sprint is dedicated to porting and improving the SCM integration (Git, SVN, Jenkins…) feature! Stay tuned!
Here comes a third version of iceScrum 7 beta: 7.0.0-beta.3. Unlike previous versions, this one doesn’t bring much visible changes. However, we worked a lot under the hood to provide more consistency and stability. Here are the main improvements and bug fixes:
Open http://beta.icescrum.com/ to try this version!
We took some time to release this version because of holidays. We should now publish news and improvements at a faster pace, stay tuned!
A week ago, we were glad to publish the first Beta of the version that embodies the future of iceScrum!
If you did not hear about it yet, you can read the blog post named “A bright future for iceScrum”.
First, we would like to thank our early users for their encouraging and insightful feedback! We are glad to see that you like this new version and we will do our best to make it even better thanks to your comments.
A sample project is automatically created for you and you can play with as you want. This version is free and unlimited and it will not affect your existing subscriptions in any way. Thus, you can also freely create new projects. Just keep in mind that we may not be able to keep your data as this is still an early stage of the Beta.
We will try to keep a good pace by releasing new versions often and keeping you updated through blog posts such as this one.
This new version is the occasion to adopt a clear and broadly use version number pattern, inspired by Semantic Versionning. It should help keep up with version updates.
Speaking of updates, we have just deployed the first update of the Beta version: 7.0.0-beta.2. Here are the main improvements and bug fixes:
Go to http://beta.icescrum.com/ to try this version!
The beginning of the Beta stage was dedicated to ensure that everything works smoothly.
The first results are really encouraging and so we are preparing the Roadmap to inform you about the steps that will lead to the general availability!
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.
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.
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 !).
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…
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:
To materialize this idea, we chose to:
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.
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!