françois beauregard

François est fondateur de Pyxis. Animé d'une passion pour le développement logiciel, François souhaite participer à des projets de développement logiciel dont les résultats sont exceptionnels tout en maximisant la qualité de vie et la satisfaction personnelle de tous les intervenants. Il agit comme accompagnateur, formateur, facilitateur et conseiller expert pour des entreprises désirant améliorer leur productivité en développement informatique et adopter une approche Agile.
voir mon profil complet »

Articles de françois :


    Le but de votre entreprise… Enchanter vos clients… En fait non!

    Mon collègue Martin a déjà publié un billet au sujet de la présentation que nous avons préférée jusqu’à maintenant à Agile 2011. Il s’agit de Making the Entire Organization Agile par Stephen Denning.

    Je vous conseille fortement de lire le billet de Martin avant de lire ce billet car il fait un survol complet de la présentation. Ne ratez pas la courte vidéo de 1 minute.

    Le bouquin Radical Management de Stephen Denning est dans ma liste de bouquins à lire depuis quelques temps. Depuis la présentation de hier, j’ai pris un peu de temps pour commencer à absorber le contenu, valider des hypothèses, intégrer les implications sur d’autres modèles d’organisation, etc. En d’autres mots, mon cerveau est en cinquième vitesse. Le bouquin de Denning se retrouve maintenant en première position dans ma liste de lectures !

    Denning propose cinq changements fondamentaux qui s’imbriquent et se renforcent. Le premier étant que le but de l’entreprise (bottom line) passe de générer de l’argent pour ses actionnaires à enchanter (delight) ses clients. C’est en fait le changement fondamental que propose Denning et celui sur lequel il a passé le plus de temps durant la présentation.

    Ce changement a des implications profondes car il demande entre autre de passer d’une logique de production (output) qui génère des profits à une logique de produire un résultat (outcome). Je crois que c’est absolument génial que des entreprises réalisent ce changement fondamental qui amène à prendre une perspective plus globale.

    Il est important de rappeler que Denning nous dit que de simplement adopter ce but d’enchanter nos clients ne fonctionnera pas et qu’il est nécessaire d’adopter les quatre autres changements suivants :

    • Nouveau rôle pour les gestionnaires : de controleur à facilitateur ;
    • Coordination du travail : d’une hiérarchie bureaucratique à des équipes liées dynamiquement ;
    • De valeur à valeurs : transparence radicale, amélioration continue ;
    • Communication interactive : de commander et contrôler à une conversation d’adulte à adulte.

    J’ai bien hâte de lire le bouquin de Denning pour comprendre plus spécifiquement ce qu’il propose et mettre tout ça en parallèle avec les modèles d’organisation apprenante (The Fifth Discipline) développé par Peter Senge et Management 3.0 développé par Jurgen Appelo.

    Lorsque je prends un point de vue systémique, comme mentionné plus haut, je suis ravi d’intégrer une mesure d’enchantement des clients en priorité sur les résultats financiers et mobiliser l’organisation vers cet objectif. J’ai d’ailleurs suggérer à Martin qu’il serait une bonne idée pour Pyxis de mettre en place une mesure similaire au Net Promoter Score (voir The Ultimate Question) dans notre cadre de suivi des résultats. Je lui également dit à la blague qu’il devrait passer de Chief Executive Officer à Chief Delighter Officer !

    Je souhaite vigoureusement ajouter que je crois qu’il est important voire essentiel pour une entreprise d’avoir un futur envisagé (une vision) établi collectivement qui met l’entreprise en mouvement dans une direction cohérente.

    De façon plus fondamentale, j’aimerais ajouter que la perspective systémique m’amène à dire que le but d’une entreprise ne doit pas être d’enchanter ses clients ; elle doit selon moi avoir cet objectif et cette préoccupation bien présente dans sa culture. Je crois qu’une organisation doit avoir une clarté de la part de l’ensemble de ses participants sur ce qui constitue sa raison d’être (sa mission). Rémi Tremblay dans son bouquin J’ai perdu ma montre au fond du lac nous invite à réfléchir et clarifier ce qu’il nomme le bien commun de l’organisation.

    Dans le cas de Pyxis, la raison d’être est notre guide depuis plusieurs années :

    Pyxis aide les organisations de développement logiciel à devenir des endroits où les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de ce qu’elle propose à ses clients et en accompagnant ceux-ci.

    Nous devons trouver comment nous assurer que nous accomplissons notre raison d’être ; que nous respectons entièrement notre définition du bien commun. Des suggestions ?

    dans Agile

    Implementing Scrum and Agile … Tools, please disappear!

    Assisting teams and organizations adopt Scrum and Agile practices for many years, I have realized, sometimes the hard way that Agile is a culture change. If you are interested in exploring more the topic of cultures and their implications, there are many resources available. I suggest you have a look at Bill Schneider’s work. I also suggest this blog post from Michael Spayd. I have found Schneider’s core culture model very useful to assess the culture in place in a group that wants to adopt Scrum and Agile. Depending on how much time you want to allow, you can do an intuitive assessment or have some people go through the questionnaire that you can find in the book The Reengineering Alternative. By having the questionnaire by multiple persons at various levels and with various roles in the organizations, you can develop a good understanding of the culture in place. With the assessment results in hand, you have a marvelous tool to drive conversations and start identifying the challenges of the transition to Scrum and Agile and where to focus efforts. DisappearAdopting Agile will certainly bring significant challenges in creating a team/collaboration culture, solid incremental software engineering practices, value driven planning, etc. Therefore, the last thing you want is tooling to get in the way. I have found that people put too much focus on the tooling for managing their scrums and not enough focus on the core issues. My advice, especially in the early stages of a product or project, is to use the tools that will provide the highest level of collaboration and interactions. Those are collaborative sessions where you use flip-charts, post-its, whiteboards, etc. Until we have tools that support a very high level of interactions and allow teams to create story maps and other models collaboratively and efficiently, I think it is wise to stick with those simple tools in those product exploration and definition sessions. For various reasons, a significant portions of the Scrum / Agile teams will want to use an electronic tool to do planning and tracking. Again, I think the best tools are the ones that do not get in the way of collaboration. As outlined in Scrum and Agile Built Into Microsoft Team Foundation Server I presented how we design Urban Turtle to blend much like a chameleon into the existing environment for organizations that are using Team Foundation Server. The Urban Turtle team is committed to enabling software teams to create kick-ass software fast and we are always striving to make the user experience seamless and simple. Give Urban Turtle a try and please let us know what you think we need to improve in Urban Turtle or what you think we completely got wrong. Please be candid. We have done a release per month (5) since the release of TFS 2010 and intend to continue sustaining this pace. Therefore, there is a high chance that if your suggestion is great, it will be included in the product soon. I value a lot exchanging points of view and experiences. Please do not hesitate to comment here, or send me an email to setup a live conversation. In a previous post, Sprints and Compelling Goals, I expressed my opinion on why I think commitment driven planning is much more powerful than capacity planning. In the next post I will present why I think compelling goals drive collaboration and creativity. Stay tuned! Cheers, ~françois
    dans Agile

    Effectively Tracking Cost in Scrum

     
    Note that the ‘Scrum Team’ refers to the Product Owner, the ScrumMaster and the Team. The Team consists of developers with all the skills to turn the Product Owner’s requirements into a potentially releasable piece of the product by the end of the Sprint.
    Last week I was discussing with Mathieu and he started to talk to me about a friend who is now Product Owner (previously project manager) on a Scrum project. This person wants to make sure he is doing a good job and wants to continuously improve. I said, this is really awesome! Mathieu, then says that his friend asked him the specific question: if I want to track the time I am investing in creating user stories and prioritizing the product backlog, which work item type and fields should I use to enter actual time spent if I am using the new Scrum process template from Microsoft. My reaction is … Interesting, why don’t you ask your friend how he is going to use this data to effectively improve as a Product Owner? If the Team is producing software that the users consider high value at an ever increasing and sustainable pace, don’t you think that those are great indications that the Scrum Team is doing good work? I believe those are much more interesting metrics to track than the actual effort he is putting in creating and prioritizing the product backlog. Mathieu: Sure, I will suggest him that but I think he also wants to track cost. Track Cost Ha! This is getting even more interesting now. Because it leads to the questions of time and cost tracking in Scrum; a question I often get in my scrum classes, especially from participants working in large corporations. When I started teaching Scrum in 2004, I used to answer in my classes that time tracking is not part of Scrum but if you want to track actuals on sprint backlog items for administrative purposes, you can go ahead. Observing Scrum Teams doing time tracking on sprint backlog items invariably leads them to questions like:
    • Where do we put the time for meetings?
    • Do we need to have absolutely all tasks in the sprint backlog?
    • When we are pairing, do we do time entries for each of us?
    • When we plan, do we create tasks for all the available hours we have? (more on this in the post Sprint and Compelling Goals)
    And the list goes on. All these questions are a struggle for the Scrum Team and answering them does not help them in creating high value software fast. Therefore, my answer now is: Tracking actual work on sprint backlog item is not part of Scrum. Period. The reaction I usually get is either “this is impossible in real life” or “you are telling us that a Scrum Team is not responsible for its cost”. I think that a Scrum Team IS responsible to be aware of their cost and the value they bring to the organization; they are software professionals and therefore they strive to maximize the ROI of their work. The Product Owner is specifically accountable for maximizing the ROI by appropriately prioritizing the product backlog. The reaction is usually “I don’t get it. You are saying not to track actuals on sprint backlog items and at the same time that the Scrum Team is responsible for its cost.”. Here is the suggestion I usually provide. Most organizations are interested in knowing how many hours their people work to be able to produce the pay checks. Therefore they have a timesheet system where people enter their time. My suggestion is to have time entries per project (much higher level of granularities than the sprint backlog items). Therefore, a team member working on a single project will produce one time entry per period. Timesheet system or not, you should be able to easily query your enterprise systems to know salary costs for a given period. May be you are lucky enough to have a cost tracking system in place that is able to give you the answer to how much expenses directly related to the product development were made during the same period. My point is that it should be possible to identify the total cost of an iteration and have the Scrum Team track this. Considering all of this, I have a request to make to Microsoft : Add the fields ‘Scrum Team Cost’ (numeric) and ‘Other Costs’ for iterations in the Scrum process template. This will be useful for enterprise Scrum. May be it is not too late to put it before version 1.0 goes final ;) Cheers, ~françois
    dans Agile

    Sprints and Compelling Goals

    There has been a debate in the Scrum and Kanban communities about having iterations  (sprints) or not. I am worried that this blog post will generate flame wars and rants. Thus, there will certainly be some energy that will be lost. My hope is that this post will generate real debates and discussions so we can learn from each other’s opinion. I have been developing software in Scrum for a long time and coaching many teams and organizations adopting Scrum. Therefore, I have been exposed to a lot of situations and feel I have integrated the fundamentals and the theoretical foundations of Scrum. My general feeling, which you will see expressed throughout this blog post is that the Agile community is falling into the trap of looking for optimizations everywhere and is losing sight of some fundamentals about complexity, creativity, teamwork and commitments. When I first heard about Kanban, I was intrigued and read about it and even applied it in some situations I felt it could be helpful. There are a couple of nice things that Kanban brings to the table but I also think that it breaks some fundamental things that make Scrum work. Within sprints, Scrum suggests a simple workflow with sprint backlog items going from ‘To Do’ to ‘In Progress’ to ‘Done’. I have certainly seen some Scrum teams have way too much work ‘In Progress’ and using Kanban techniques to limit the amount of work in progress can certainly help. I also do not think it is necessarily a bad idea that a mature team establishes a more defined workflow and uses Kanban techniques to control its flow of work but going too far (I have seen a Kanban board with 10 columns corresponding to stories’ statuses) in that direction will reduce the possibilities of emergence that creates true performance in self-managing, multidisciplinary teams. Getting to the actual debate of having sprints or not. Some Scrum proponents say that not having sprints may be problematic because the team needs to hold regular retrospectives to accelerate learning. While I do agree that holding regular retrospectives is absolutely essential, I think that a Kanban team could do regular retrospectives while not completely applying sprints. I think Ken Schwaber has a much stronger point. In his Waterfall, Lean/Kanban, and Scrum blog post, he presents sprints from the point of view of the complexity theory.
    A container is a closed space where things can get done, regardless of the overall complexity of the problem. In the case of Scrum, a container is a Sprint, an iteration. We put people with all the skills needed to solve the problem in the container. We put the highest value problems to be solved into the container. Then we protect the container from any outside disturbances while the people attempt to bring the problem to a solution. We control the container by time-boxing the length of time that we allow the problem to be worked on. We let the people select problems of a size that can be brought to fruition during the time-box. At the end of the time-box, we open the container and inspect the results. We then reset the container (adaptation) for the next time-box. By frequently re-planning and shifting our work, we are able to optimize value.
    Vincent also brings an interesting viewpoint in his recent post Scrum is not about project management . While explaining the notion of container, Ken mentions above: “We put the highest value problems to be solved into the container.” I would like to push this a little further and relate it to planning and commitment. I have always insisted in my Scrum classes that a successful sprint planning is not about delivering a sprint backlog, it is first and foremost about having a team committed toward a goal that is compelling for them as a whole including the ScrumMaster and Product Owner. I believe, this is one of the fundamentals to create creative hyper-performing, self-managing teams that can sustain. I have felt during the last few years that as a community we are putting too much focus on the concept of velocity and, therefore, many teams are un-passionately identifying their commitment based on their velocity and do not get to the true nature of what it means to be committed toward a compelling goal. Before you throw tomatoes at me, I am not saying that measuring velocity is useless. I am saying that while it is useful for a team to measure and be aware of its velocity, I think we let it drive too much the commitment decisions of the team. Some tools are in my opinion putting too much emphasis on using velocity to drive the sprint planning process. This belief of the importance of being committed toward a compelling goal was reinforced recently while reading the following book: The three laws of performance. Here are the three laws presented in the book:
    1. How people perform correlates to how situations occur to them.
    2. How a situation occurs arises in language.
    3. Future-based language transforms how situation occurs to people.
    I will not try to summarize the book here. I thought it is useful to mention this reference because I think it links the importance of creating an environment in planning sessions that enables the team to choose a goal that is compelling for them to some fundamentals of human beings. In summary, I suggest to use sprints as defined in Scrum because when done in the true spirit of Scrum, they enable a team to look at the highest value problems, imagine a compelling future, and use all of the thinking, collaboration, and creativity possible to put together solutions and plans. Then, you leave the people alone within the container of the sprint to apply their professional skills, without interruption so they can concentrate and focus on their work. This is the core of them being creative people doing creative work rather than resources being managed to optimize productivity.
    dans Agile

    Scrum and Agile Built Into Microsoft Team Foundation Server

    In Answering some common questions about Urban Turtle we answer some questions and present some of the orientations we took in designing Urban Turtle. One of the main orientation is to build Urban Turtle into TFS (as opposed to integrate with). All our design decisions are made to bring as much value-added as possible while creating a seamless experience for existing TFS users and grow with TFS as Microsoft adds new features. We believe this orientation is what allows us to have a product that installs on the server in less than two-minutes and gets a team to use it right away. We are very interested in hearing your stories and get your feedback about how we can further improve the experience. Help us make our Urban Turtle a Chameleon ;) Also, our tight integration in the Web Access user interface makes the user feel at home and perceive TFS with new capabilities (as opposed to using an extra product). This is a big plus to have a smooth user adoption. We know that adopting scrum is already an interesting challenge; you do not need tools to get in your way but be a possible accelerator. In the release that we have for you this week (June 2nd), we deliver a bunch of enhancements including a productive way to use Areas. The upcoming release will most likely focus on a feature we call Perspective that will allow you to work seamlessly in Urban Turtle on a subset of work items making it a charm to do multi-teams and grouping projects together. We will also focus on enhancing user experience in a couple of key places. Again, give Urban Turtle a try and let us know how we succeeded in turning it into a Chameleon.

    Entrepreneur

    Concours québécois en entrepreneuriat

    Je souhaite partager avec vous le discours que j’ai prononcé la semaine dernière à titre de président d’honneur lors du gala de remise des prix du Concours québécois en entrepreneuriat, région Laval.

    Bonsoir Mesdames et Messieurs,

    J’aimerais dans un premier temps demander à toutes les personnes présentes qui travaillent à titre d’employés, de bénévoles ou de membres du CA du CLD ou de Laval Technopole, à celles qui travaillent à l’organisation du concours et à celles qui travaillent pour une fondation ou un organisme qui promeut et soutient l’entrepreneuriat de se lever.

    Pour en avoir côtoyé plusieurs, je peux vous assurer que ces gens sont tous des passionnés dotés d’une générosité hors du commun et qu’ils sont un rouage important de notre société. Je demande donc de leur donner notre appréciation en les applaudissant.

    Cet après-midi, j’ai utilisé Antidote sur mon iPhone pour chercher la définition du mot ‘entrepreneur’ car c’est selon moi la meilleure suite de dictionnaires de langue française. Antidote est d’ailleurs édité par Druide informatique, qui est une firme québécoise dirigée par André d’Orsonnens, un entrepreneur d’exception qui a su construire une équipe d’exception…

    J’y ai évidemment trouvé une définition très terre à terre, c’est-à-dire : ‘Personne qui engage des capitaux et utilise une main-d’œuvre salariée en vue d’une production déterminée; chef d’entreprise’.

    Je vais devoir communiquer avec André pour voir si nous pouvons ajouter à Antidote une définition un peu plus sentimentale :

    Personne qui décide de prendre sa vie professionnelle en main en mettant de l’avant un projet créateur de valeur, qui fait cela de manière à la fois passionnée et pragmatique et qui invite d’autres personnes qui se sentent interpellés par la mission de ce projet d’entreprise à y participer avec leurs propres passions.

    Je profite de l’occasion pour vous glisser un mot sur ma vision des entreprises de demain. J’ai la ferme conviction que les entreprises qui auront du succès dans la durée pour la prochaine génération seront celles qui auront un modèle équitable de redistribution de la richesse créée.

    Notre société vit des changements substantiels et j’invite les dirigeants à innover en mettant en place des structures et moyens novateurs comme des coopératives de travailleurs actionnaires ou autre.

    Je souhaite en terminant souligner le mérite des finalistes et lauréats que nous honorons ce soir pour leur courage d’entreprendre dans ces temps de turbulences énormes. Je vous dis à tous un sincère bravo et vous souhaite le plus grand succès possible dans la réalisation de chacun de vos projets.

    Bonne soirée à tous!

    L’équilibre… un défi!

    L’équilibre travail-vie personnelle est quelque chose que j’ai toujours valorisé et qui se retrouve dans la raison d’être de Pyxis.

    Pyxis aide les organisations de développement logiciel à devenir des endroits où les résultats, la qualité de vie et le plaisir coexistent de façon durable en étant en premier lieu un exemple de ce qu’elle propose à ses clients et en accompagnant ceux-ci.

    Je dois avouer que dans certains cas, à Pyxis nous ne sommes pas fidèles à cette raison d’être et nous nous mettons une pression professionnelle qui nous amène à perdre cet équilibre. Je reste tout de même convaincu qu’elle nous sert de guide. Au cours des dernières années, j’ai personnellement été particulièrement délinquant et je n’ai pas été fidèle à mes valeurs en accordant trop d’importance aux aspects professionnels de ma vie.

    Dernièrement, j’ai lu The Seven-Day Weekend. Ce livre m’inspire; j’y ai trouvé des moyens d’enrichir la culture de Pyxis en y incluant certaines pratiques de gestion. Toutefois je suis lent à me les appliquer à moi-même. J’espère y arriver un jour. Il ne faut pas perdre espoir!

    Sur le chemin de mon équilibre personnel, j’ai décidé de faire quelques trucs concrets. En mai dernier, j’ai commencé à faire du jogging régulièrement pour me remettre en forme et parce que, pour un introverti comme moi, c’est une source de bien-être. Durant l’année, j’ai fait quelques rechutes… une nette amélioration quand même!

    Une autre décision que j’ai prise dans une recherche d’équilibre : prendre quatre semaines de vacances consécutives; une première!

    Le 26 mars, veille de mon départ en vacances, j’ai décidé de me fixer le défi de courir un minimum de 3 km chaque jour de mes vacances (c’est-à-dire 30 jours consécutifs). Pour m’encourager, j’ai fait parvenir à des collègues et amis une invitation à faire un don de 50 $ ou 100 $ à la Fondation Sport-Études.


    Grâce à RunKeeper, Facebook et Twitter, certains ont pu suivre live mes courses dans mon quartier, à Cuba, à Las Vegas (une petite sortie de mes vacances pour le lancement de Urban Turtle 2010 avec Dominic et Mario) et ailleurs en Californie. Trente jours consécutifs avec un minimum de 3 km par jour pour un total de 154 km. Défi relevé!

    Il n’est évidemment pas trop tard pour m’encourager. C’est très simple :
    1. Faites votre don en ligne et obtenez un reçu fiscal.
    2. Envoyez-moi un courriel m’indiquant votre don.

    Si vous êtes dans une démarche de remise en forme et que le jogging vous plaît, n’hésitez pas à joindre mon ‘street team’ sur RunKeeper.

    ~françois

    dans Agile

    Easy Multi-Level Planning with Urban Turtle

    Most successful Agile/Scrum teams use a multi-level planning approach. There are a couple of quotes that I like and always mention in my Scrum training: “Planning is everything. Plans are nothing.” – Winston Churchill “No plan survives contact with the enemy.” – Helmuth von Moltke the Elder I think they are good guiding principles. Lets have a look at how Urban Turtle supports teams that use multi-level planning. Here we will use an example with releases and sprints but note that you can use as many levels as you want. However, if you decide to add more levels as a team, make sure they are truly needed and they are not just inducing extra complexity. In this blog, I will use the user story and sprint terms because they are very common. Note that terms may vary depending on the process template you are using. Urban Turtle ships with mapping files for some popular Agile/Scrum process templates. It is very easy to create a simple XML mapping file to use Urban Turtle with almost any process template. For those who have their own customized process template, we will shortly write a blog entry that will explain how to easily create the mapping file. During early project planning, the team will create some user stories and use Urban Turtle’s drag and drop capabilities to prioritize their product backlog. When the team is ready for release planning, it is time to add the next release and some sprints. Here I have a sample release with three sprints. Note that it may be tempting to try and schedule up-front every story in specific sprints, but our experience shows us that it is better to defer the decisions and let the team inspect and adapt as it achieves some sprints. By deferring the commitment as much as possible, the team takes ownership of their backlog and their planning activities. In other words, have the team evaluate their capacity for the release based on past velocity and commit user stories in the release according to this. Note that because Urban Turtle computes all the statistic roll-ups, if the team is sure that a story needs to be done in a particular sprint, they can simply commit it to a sprint via drag and drop. In doing so, the release view will not be affected. When the team will get to the sprint planning for this particular sprint they will see an that the user story is already committed.
    Also take note that normally the team will wait until a sprint planning activity to identify task. However, if they have already identified a task for a story and want to make sure they do not forget it, they can simply create it in advance. Later on, when they will commit the story into a sprint, the tasks will also be automatically committed.
    During the first part of a sprint planning activity, the team identifies its commitment for the next sprint. The team goes to the current release and checks the option to display only user stories that are not yet committed in a sprint. Then they drag and drop the stories they want to plan in the sprint until they feel they have reached their capacity. Note again that Urban Turtle does all of the roll-ups for the user, allowing to have the statistics for your releases and sprints at a glance. During the second part of sprint planning, the team creates the tasks that constitute their sprint backlog. I hope that this blog gave you a good idea how Urban Turtle supports teams in their various planning activities while keeping the flexibility of not dogmatically following the suggested process. Happy planning. ~francois

    Answering some common questions about Urban Turtle

    Last week we were in Las Vegas at devconnections for the launch of Visual Studio 2010 and to present the new version of Urban Turtle. We often got the following questions :
    1. Do we need to install anything on the workstations?
    2. What happens if I customize the process template to fit the specific needs of my organization?
    3. Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed?
    4. What are your plans?
    5. What is your pricing?
    Do we need to install anything on the workstations? From the beginning, our goal is that Urban Turtle users do not feel as if hey are using another product. We want to increase their comfort and simply extend their usage of Team Foundation Server (TFS). To achieve this, we did several things. The main one is that the user interface seamlessly blends in with Web Access of TFS. Therefore, there is just a one-time installation process on the server. Furthermore when we developed the new installation process for the VS 2010 compatible version, Dominic’s (the Product Owner) condition of satisfaction was that the installation takes less than 5 minutes. The team over delivered because most of the time, the installation takes less than 2 minutes. If your installation takes longer, please let us know. What happens if I customize the process template to fit the specific needs of my organization? We know by experience that a lot of organization will want to use a standard process template and customize it by adding some fields to some work items or slightly customize some workflows or … In other words, there is no one way of doing Agile and Scrum. Therefore we designed Urban Turtle to let you take advantage of TFS’s customization capabilities; Urban Turtle is designed to be process template independent. It only needs to know a couple of things about your process template. This information needs to be put in a simple XML file. We will shortly write a blog entry that will explain how to easily create the mapping file. In the meantime, do not hesitate to ask questions on the forum Does UrbanTurtle interfere with other tools from Microsoft, other vendors or that we could have developed? No, Urban Turtle does not interfere with any tool. Again our goal in designing Urban Turtle is that it seamlessly inserts itself in the TFS ecosystem. To achieve this, we decided to rely on standard extension mechanism and not have a separate data store. Urban Turtle directly manipulates work items using the standard APIs. This allows us for example to validate the workflow transitions in the task board even if you customize your workflows. Also, since you customize your work item fields using standard mechanism and Urban Turtle does not add extra data, the powerful reporting and data warehousing capabilities of TFS will not be affected and will work as documented by Microsoft. What are your plans? The team is currently in the last sprint to release version 3.0. The product, the development environment and the team are now in a mature enough state to do solid public releases every 4 to 6 weeks. We will publish a blog every sprint to announce what we are working on. What is your pricing? I hope this answers the most common questions. If I missed some, do not hesitate to ask. Do not hesitate to turtle your TFS, you are less than 5 minutes away! ~francois

    Pyxis en vidéo sur WebTV.coop

    Pyxis est en vedette dans une courte vidéo sur WebTV.coop.

    Une coopérative de travailleurs actionnaire – Pyxis Technologies

    Je souhaite toujours en apprendre et transmettre notre expérience donc si vous souhaitez échanger sur le sujet des structures de gestion novatrices ou tout ce qui a trait à la mise en oeuvre d’une coopérative de travailleurs actionnaire, n’hésitez pas à me contacter.