GWT.create 2015: Return of experience

As I look back, almost three weeks after GWT.create, I can’t keep myself from smiling. It was, for several reasons, the best time I’ve had with the GWT community since I joined. Traveling between Mountain View in the Computer History Museum and Munich, meeting hundreds of GWT enthusiasts and exchanging ideas with them about how to make GWT even better made me realize how incredible this community is and how lucky we are to be part of it. Learning from their technical knowledge and their deep personal and business involvement with this toolkit, I felt lucky I got the chance to connect with some of the best engineers in the world. If you’re reading these lines and you spoke with me, I’m glad to have met you 😀


GWT.create this year was Arcbees’ chance to shine! We jumped in as major partner. Julien had two sessions: Best development practice for GWT web application and CSS3 and GWT in perfect harmony, plus one workshop on how to contribute to GWT, while I delivered a keynote plus one session: How to improve your productivity using GWTP. We had major news to deliver at the keynote, having taken some of our free time to develop a new brand and a new website for GWT. This will have huge impact in the future of GWT as we try to make the brand more modern and sexy to support the design goals for upcoming developments in GWT. We spent a lot of time to give you the best experience we can and we welcome any constructive comments that might make it evenbetter in the future. One major improvement that was made to the website, even before the rebranding, was the introduction of ability to contribute documentation right from the website using markdown and GWT. We’ve preserved this functionality and hope the community will help us maintain the documentation.


When David Chandler got on stage to deliver the second keynote, I got a little bit nostalgic. He was the one that invited Philippe Beaudoin (cofounder of Arcbees) to speak about GWTP four years ago, in front of an overcrowded room at Google IO focused on how to build online business applications. He also made a statement about how everyone in the community cares deeply about abstraction and architecture, which are the two concepts that have inspired me and the rest of Arcbees for years to contribute open source libraries and frameworks to the community, to help them build better web applications. I was also amazed by the huge amount of raw talent that this community has to offer, and saw great web applications from businesses like Ruxit, Boomi and Magnolia. I could go on for a while, but needless to say that we’re starting to have great, beautiful and mature web applications built on GWT, and not just Google offspring like AdWords, Sheets and Inbox.GWT2015_9

During the first panel discussion, Ray Cromwell reminded the audience that GWT fuels the web applications that run the world. Stock exchanges, financial institutions, healthcare, airports, you name it. Whenever something needs to run on top of critical infrastructure, needs to be scalable and/or multi-platform, GWT is commonly seen. Javascript may have a lot of fresh cool toys to play with that GWT may not have (yet!), but would you invest everything you have on fresh cool toys? There’s a lot to learn from the Javascript community, but as decision makers, we need to choose robust solutions, not fashionable ones.

I got carried when I was writing this blog post and didn’t even started to write about my top 5 session/announcement, stay tuned early next week to know more about what was our top 5 sessions/announcement of the GWT.create 2015!

A Guaranteed Future for gQuery!

Arcbees is proud to officially support g(wt)-Query (gQuery), a jQuery-clone API written in Java for GWT. We hope this will helps gQuery grow even further, promoting clear direction and a strong future for this awesome product – one that we ourselves are using in all our projects.

We are firmly committed to keeping gQuery an Open Source product, available under the Apache 2.0. licence. The gQuery project continues to be led by the top three contributors to the codebase: Ray CromwellManuel Carrasco Moñino and Julien Dramaix.gQuerY-1

What does our official support of gQuery mean to you? First, gQuery will be part of ArcBees’ other Open Source product offerings, and gQuery support will be included in the support package offered by Arcbees for GWTP. Also, Arcbees is planning a complete re-write of the documentation. This new documentation will follow Arcbees new conventions and will be hosted on

There is more. This is just the tip of the iceberg! The Arcbees development ecosystem is evolving fast, and you can hear all about it at GWT.create this year!


Le futur de gQuery est assuré!

Arcbees peut se targuer d’être la 1ère entreprise à supporter officiellement g(wt)Query, une librairie similaire à jQuery, mais pour GWT. Fort de cet appui, nous espérons que le produit va continuer de croître en plus d’en assurer sa pérennité, surtout que nous en sommes nous-mêmes de fiers utilisateurs!

Essentiellement, gQuery va demeurer le même produit Open Source offert sous licence Apache 2.0. que vous avez toujours connu et son développement va continuer d’être mené par ses top contributeurs, soit messieurs Manuel Carrasco Moñino, Ray Cromwell et Julien Dramaix.

Vous l’avez peut-être déjà constaté, mais les sources ont été transférées sous Arcbees (github) et d’importants changements se pointent à l’horizon puisque la ré-écriture complète de la documentation est en cours et que gQuery s’ajoute à la gamme de produits Open Source déjà offerte par Arcbees, faisant en sorte qu’il sera désormais couvert par le forfait de support pour GWTP.

Plusieurs autres modifications sont à venir et vous pourrez en apprendre bien davantage sur le sujet et sur Arcbees lors du prochain GWT.create et lors du dévoilement de notre nouvelle image qui approche à grands pas!


GWTP 1.3 release

Two weeks ago we released GWTP 1.3. This release was a little bit stealthy and you have me to blame for that, I didn’t prepare an announcement! I hope you can forgive my oversight 😀

Here’s the complete list of changes:


  • Improved Javadoc site
  • #14 : ActionException & ServiceException now implement IsSerializable
  • #282 : LazyActionHandlerValidatorRegistryImpl is now threadsafe
  • #467 : Allow REST and RPC dispatchers to be used at the same time
  • #517 : Updated to GWT 2.6.1 and updated DTDs (Thanks rdwallis)


  • Improved form-factor detection (Thanks rdwallis)
  • #184 : DefaultModule now has the Builder pattern
  • #284 : Add toString() to PlaceRequest
  • #346 : Map more than one name token to presenter
  • #489 : Added .without() to PlaceRequest.Builder to remove parameter from PlaceRequest
  • #492 : PlaceRequest.Builder(PlaceRequest request) now creates a deep copy
  • #499 : Decode embedded paramaters of RouteTokenFormatter (Thanks rdwallis)


  • #484 : Deprecated HttpSessionSecurityCookieFilter (Thanks bradcupit )

REST Dispatcher

  • Updated gwt-jackson to 0.6.1
  • #468 : Generate REST services based on the presence of @Path. Deprecate RestService interface
  • #498 : De/Serializing null/empty should result to null

Thanks to all contributors! We’re already working hard on GWTP 1.4 and should be out earlier than our usual release cycle. Stay tuned!

Great contributions to our open source projects

Here’s something you may not know about Arcbees; every single line of code that we can open source to our developer community, is open sourced. It is one of our core values. We believe that sharing our work and ideas openly with others can and will inspire great developers to contribute back to our own growing ecosystem of tools.

In the past few week, the number of great programmers collaborating with us in the open source community has been rising, and we want to say thanks to two in particular.

One is Richard Wallis who has contributed most of the work done to construct our Universal Analytics project, and who has also contributed to our GWTP project. He is now a trusted contributor and has been granted write privileges over GWTP and Universal Analytics.

Congratulation Richard!

Equally appreciated is Jonathan Kuleff who went from making a great suggestion for improving our Bitbucket Teamcity plugin to doing the implementation himself in one jump.

Thanks Jonathan!

Both of you contributed really great quality code, and we really appreciate that. We learn from your work, and we hope you learn from ours. That’s what we love about open. The sharing we do around specific projects has ripple effects. We share programming tactics and practices with everyone we collaborate with, and this ultimately helps all developers improve their craftsmanship to create better, stronger, quality code.

Our mission includes the promotion of this kind of code-quality education worldwide, which explains why we subject you new contributions to such rigorous code review. We don’t want to slow you down, but we do want to make sure that future contributors can easily read the codebase we are all putting together. We want the codebase to be useful and fun to program, and also to teach people how to produce quality code. We are thrilled to work with so many open source developers who want to help us do that.

There’s a lot of contributors to our open source projects, we try to thank them in every single release announcement we do around any of our open source projects. We welcome anyone to contribute in any way they can.

Software engineering is a young craft. It is only about 50 years old, unlike mechanical engineering and civil engineering, which have been with us for millennia. Our field is still in its infancy, but it’s growing fast, and this is in large part due to open source. Let’s keep flying forward by sharing code and collaborating on projects. Knowledge is a public good, all of us can have it without ever depleting it.

We look forward to future learnings with you all. See you on our project sites!

GAE-Studio reaches V 1.0 and now supports all App Engine programming languages!

It’s a big day for GAE Studio. Version 1.0 has finally arrived! The software is ready for use by a much larger segment of the GAE development community. It is now possible to use it with every language that App Engine supports!

To get started, you only have to read our documentation. Now, let’s dive in and see what’s new in version 1.0 of GAE Studio.

Screen Shot 2014-07-22 at 11.17.16 AM

For all you GAE developers who create applications in languages other than Java, GAE-Studio now supports Python, Go and PHP. This is a big step forwards for our product. Supporting all available runtimes has always been one of our objectives, and we know it is a capability many people were waiting for. To make multi-language support possible, you can now use GAE-Studio as a module. Using GAE-Studio locally will be a challenge, but we’re working hard to make it easy to use GAE-Studio. Using it locally with Java is already possible if you build an EAR. We’re working hard to make this process as seamless as possible in every runtime.

The login/oauth system was a hassle for first-time users. Since we want to put this software in as many hands as possible, authentication and license validation has been removed. You still need to login with your developer account to use GAE-Studio as a module. This change comes at a cost, in order to keep developing GAE Studio, we need to sustain an income, so we have moved some features to the paid tier. Once we’re ready to re-introduce them, you’ll be able to purchase a license to activate those features. We’ll talk about them in detail in a future newsletter, but just as a snapshot here’s a list: profiling datastore requests, applying batch operations on large datasets and evaluating GAE usage cost.

We also installed GAE-Studio on a really simple sandbox application, which will allow you to try it and quickly see if that’s what you need. There’s a Submit form if you want to help us fix any problems you find, or to send suggestions to improve the product. You’ll need to request access to the sandbox by sending an email to:

Also, GAE-Studio will now let you execute GQL requests to filter data. It is a powerful tool for extracting only the data you need for a given development task.

Screen Shot 2014-07-22 at 11.29.13 AM

We’ve added visual cues based on beta tester feedback, and we think this really improves the UX. We ourselves use GAE-Studio every day for our projects, so we really understand and appreciate the value of these UX improvements.

After adding JSON import/export in our last release, we now feature the ability to export to CSV, which can be useful if you want to use analytical tools like Excel to examine your data.

Screen Shot 2014-07-22 at 11.29.55 AM

Last but not least, you can now select multiple entities and delete them, or mass-edit the values in fields that selected entities share.

Screen Shot 2014-07-22 at 11.31.01 AM

Please continue offering us feedback via our issue tracker, or drop us an email ! This was a big release, but more and better things are yet to come. We are really looking forward to our upcoming releases and want to incorporate your feedback in the process. Thanks for all your help so far. You are all awesome and please join our community on Google+ to follow progress as well as exchange ideas with other developers.

To conclude this newsletter, we should not forget that building software is a collaborative enterprise and we have many contributors to thank. You should pay attention to those names, because these people are awesome and have mad skills! We are deeply grateful for their work. Thanks so much!

Contributors (since the first commit in 2011)

Alexandre Breton
Brandon Donnelson
Christian Goudreau
Christopher Viel
Gael-Jurin Nkouyee
Jason Lemay
Javier Fernandez-Ivern
Jean-Christophe Larivière
Joël Trottier-Hébert
Julien Dramaix
Manon Gruaz
Maxime Mériouma-Caron
Mrabti Idriss
Olivier Lafleur
Simon-Pierre Gingras
Vincent Roseberry

The bees need your thoughts on GAE-Studio!

As our product evolves, we rely on frequent feedback from users to stay aligned on what you really want and need as developers.

We want to make a tool that will help you be more productive and drive down development costs.

We would really appreciate it if you would take a few minutes to help us by filling out the following survey.

Thanks so much! It really means a lot to us. We pay enormous attention to every idea you share.

Jukito 1.4 and GWTP 1.2.1

In parrallel with the development of our next major commercial product, our ninja developers continue to work on our open source projects. We love working in the trenches of web application development. It’s what gives us the perspective we need to build the best web framework and tools we

Your feedback is our most valuable guidance. It helps us polish our software and even inspires us to develop entirely new and unforeseen features !

Jukito 1.4

We’re proud to announce a new version of Jukito with three new kinds functionalities: support for private modules, ability to override the UseModules declaration, and inheritance of the UseModules annotation.

Here are the details of the changes on GitHub :

Added support for PrivateModules in the JukitoRunner

Enabling the use of UseModules on methods to override class level

Allow inheritance of @UseModules

GWTP 1.2.1

We’re also proud to release a new version of GWTP, which is compatible with the newest GWT 2.6. Also, you can now have access to the project information quickly by going to Please give us feedback to help us improve the information published on this website with each future release.

We fixed a few failing tests and updated some librairies to get things right with GWT 2.6. Starting with 1.2.1, the build process will also display a warning if a newer version of GWTP is available.

We improved the Route Token Formatter by allowing the hashbang (#!/), so web crawlers can recognize your tokens. We also moved some classes to a shared package so you can reuse  the route token formatter from your server code. Please see the migration notes as the latter is a breaking change.

The Rest Dispatch project also got a load of new features. Most of them are configuration methods to help illuminate your development journey. The exhaustive list is available in the release notes, but we’ll review some of the key changes:

  • The CSRF protection header can be disabled on specific calls by using a new annotation.

  • It’s now possible to configure parameters that will be added automatically to your calls without specifying them in your service interface. Those parameters can be filtered out by HTTP method and parameter type.

  • We added some support for formatting dates.

You can see the release notes here or the details of the key commits on GitHub:

Changed version for Guava and Gin

Fixing CarStore’s selenium tests

Update gwt-jackson to 0.4.0

Fixing CarStore and selenium tests

Improved the ability to configure the serialization mechanism

Rest-Dispatch: Support for Sub-Resources

Retrieve the latest version and compare it when compilation

Custom request timeout configuration

Allow specific unsecured REST calls when SecurityCookie is bound

Move PlaceRequest and TokenFormatters to mvp-shared

Improvements to Route Token Formatter

Added customization methods for global Query and Header parameters

Fixed Fix Multimap Serialization

Fixed some checkstyle warnings

Allows interfaces compositions when creating RestService

Configurable date formats for resource parameters

In particular, thanks to aldenquimby, christiangoudreau, Chris-V, diamondq, jDramaix, meriouma, nmorel, olafleur, PhilBeaudoin, spg and tonuquq for this awesome release!

GAE-Studio Newsletter #6

The agile Bees are working really hard to develop the best tool ever for working with Google App Engine. We want to make using the GAE stack easy and fun. We’re happy to announce the release of GAE-Studio 0.8.1, the latest version of our rapidly evolving GAE development environment !

What to expect in this newest version?

We have completed the redesign of the application that we initiated a few weeks ago. We also added a logout button and tweaked some of the feedback/error messages to improve your user experience, which is always important to us.


At a technical level, we have added a much-requested feature : the ability to import and export data from Google App Engine. At the moment, there’s an import limit of 2 Gb, due to the limitations of GAE Blobstore, but within that limit the import/export feature works. Additionally, we fixed an issue with the prior version of GAE Studio which did not allow people to activate email addresses containing a “+” character.

A quick warning note : we’re planning to refactor our authentification API in the next iteration of GAE-Studio, so when we will release 0.9, you will need to update to the newest version.

As usual, thanks for reporting any issues that you find when working with GAE Studio. That feedback is our most powerful resource for making the software better. We’d love to hear more! If you have a few minutes today, please let us know what you like most about GAE-Studio, what you like least, and what features you’d like us to add. We appreciate your advice. Drop us an email or use the issue tracker to let us know what you think.

Thanks a lot and we look forward to your feedback !


Agile Contracts: Creating and Managing Successful Projects With Scrum

Agile at ArcBees

Agile is embedded in the ArcBees way of life. It drives our culture and productivity. However, many new clients have no prior experience with Agile. It is usually easy to explain how Agile leads to better software, but sometimes they struggle with the business implications. How can they sign a contract to build a product when they don’t know exactly what they will get?

The book Agile Contracts Creating and Managing Successful Projects With Scrum by Opelt et al., highlights four contractual mechanisms that give business owners the predictability they need. It offers a model of project governance that meshes perfectly with the realities of Scrum project management. For Agile teams, Agile Contracts are crucial Agile software development tools, as important as Scrum boards or Kanban boards. This article summarizes this Agile development tool, emphasizing the way we apply these concepts in our work

What Is Agile?

If Agile is new for you, here’s the big idea behind it: the key Agile insight is that old-style “waterfall” project management practices, which were plan-driven (rather than feedback-driven), generated bad products. Those products were buggy and bloated with features people didn’t use. Those projects were also always late and over-budget.


Why? Delayed feedback. In the old days, to create software, you would:

  • Gather requirements in advance
  • Then specify software features
  • Then design the software
  • Then develop the software (for months and months)
  • Then have a QA department (not end-users) test it
  • And finally deploy the software, maybe a year after you gathered requirements.

In other words, you only got real feedback from real users in real work situations at the end of the process. All the key decisions were made in advance, based on guesswork. It was disciplined guesswork, but still guesswork.

The Agile remedy is to build a small product with just a few features and give it to real users. You build that as quickly and cheaply as possible, and watch people use it. Then you improve the product based on what you learn. It’s empirical. After many cycles of real-time feedback, the end product is well-tested, useful, has only those features people need, and few surviving bugs.

The Illusion of Predictability

Here’s the hard truth. Old-style estimates have always been pure fantasies. Budgets based on them were always blown away. We need to stop wanting the false reassurance that fortune telling (planning) provides. Instead, we should pragmatically confront the mix of certainty and uncertainty that is inescapable in software development, and set up mechanisms that let us make the right decisions at the right times to manage cost and limit risk.

Agile Contract Mechanisms

The key cost/risk limiting mechanisms that Opelt et al. define in their book are:

  1. Estimates
  2. Riskshare Ratios
  3. Checkpoints
  4. Exit Points


1. Estimates

Cost vs. Time Estimate

Opelt et al. call cost estimates “Indicative Fixed-Price Ranges”. On the one hand, this is useful because many Agile teams work hard to do time and effort estimation during projects, and this is not exactly the same thing as cost estimation. For example:

  • The cost of developers’ time varies depending on their skill set and seniority, which impacts cost.
  • Complex projects require more coordination and project management overhead cost.
  • Projects that have to meet higher performance benchmarks require more testing, debugging and refactoring at every step.

So there is more to cost estimation than raw time/effort estimation. However, as long as we keep this difference in mind, we can talk about the first concern of Agile Contracting as the “cost estimate”, instead of using the less-familiar term “Indicative Fixed-Price Range”.

Levels of Cost Estimation

You can do cost estimates for the Whole Project, for Exit Point Phases, and for Checkpoint Phases.

Whole Project Estimates define the outer limits of cost, based on our best current information. They are not contractual promises. Because of the nature of software development, the business owners and development team will need to discuss the project as work progresses, which may impact the final cost.

However, at the outset, the Whole Project Cost Estimate defines the maximum that a client will be charged, unless they decide otherwise. The developer team promises to honor all the mechanisms of the Agile Contract that govern the process of managing cost as the project evolves.

The Whole Project Cost Estimate is based on what Agile practitioners call “Epic” use-cases that describe the software’s main functions. These are the most general Agile specifications, and developers never make exact promises about exactly how long it will take to build things at the Epic level. It would be irresponsible to pretend exact estimation is possible at this level.

However, Agile teams break large projects down into smaller chunks, and can do a fairly detailed time/effort estimate for what they will do in the next chunk as they prepare to do it. We work in “Sprints” of 2 or 3 weeks. We also know who will be doing the various tasks in a Sprint, and what the performance benchmarks are for the features in that Sprint. This means that the cost estimate for a Sprint is much more accurate than the Whole Project Cost Estimate, and we can guarantee how much functionality will be delivered in that brief time period for that specific price.

These low level, one-batch-at-a-time estimates are sure things. As the project progresses, we can see how many of the Epics are realistically getting built within the fixed cost for the project, and adjust our expectations for project scope.

Agile practitioners always prefer to adjust scope, building simple, solid products missing some bells and whistles, in order to deliver on time and on budget. Experience shows the simpler projects usually meet the client’s business need. Hard time/budget limits force good decisions about what features matter most.

Agile Contract Mechanisms

We make Agile Contracts because we accept the reality that large-batch estimates are unreliable illusions. This is an unfortunate fact of life. Small-batch estimates are more accurate. Agile Contracts therefore set a hard outer limit to project cost, and define a schedule of two kinds of business meetings for where clients and developers discuss their business deal. These meetings are Exit Point Meetings and Checkpoint Meetings. Both are described below.

The key point to emphasize here is that the Whole Project Estimate freezes the outer limit for project cost, and there is a clear process for monitoring progress against cost. In other words, the Agile business deal has a “brake pedal and steering wheel”, as well as a “gas pedal and ignition key”. It has clearly defined mechanisms for making adjustments in the face of reality. It is not a money train where clients risk falling asleep, and waking up later to find out they missed their stop and are now many miles farther than they planned to go.

2. Riskshare Ratios

Agile has a little secret. The planning fallacy never goes away. Estimates for a Sprint are more accurate than estimates for a Whole Project, but it is still common to underestimate how much time and effort it will take to build software, even if you are only planning a 2 or 3 week Sprint. So how can we guarantee to be on time and on budget?

Sprint Risk: Borne by Developers

Basically, Agile teams assume 100% of the cost overrun risk within a single Sprint. If our team accepts too much work during a Sprint, and we had to work long hours to get everything done on time, we eat those costs. We deliver the Sprint on time and on budget as promised, no matter what. Of course, based on what we learned, we make a more realistic estimate for scope of work in the next Sprint.

Scope Adjustment: Risk Shared 50/50

Since we accept the Whole Project Cost Estimate as a fixed outer limit on project cost and duration, this means that if it turns out that the initial proposed scope of the project was too ambitious (it often is), we need to discuss how to make the scope more realistic with clients. Clients also often decide they want new features they had not thought of at first, or they want existing features to behave differently.

We try to make all these changes “free” changes by suggesting tradeoffs, or simpler ways of achieving product goals. If the client is willing to consider these adjustments, we try to accommodate that without charging more, even though sometimes that means some extra effort on our side. We share risk 50/50 in this process of mutual adjustment, so long as the adjustments are reasonably manageable.

Note that project scope may need to be adjusted even when the client has not asked for anything extra. If developers building the software discover it will be much harder to build than we thought, this is an objective fact. The planning fallacy was the illusion, but the real complexity of the task, confronted by people trying to implement it, is real.

After discovering this complexity – and realizing that we all made the planning fallacy when we drafted the Whole Project Cost Estimate – we have two choices: define a more realistic scope (shared risk), or expand the project scope.

Scope Expansion: Borne by Client

If clients insist on having their full wish-list of Epics built, even though new evidence has made it clear that their project is bigger in reality than anybody anticipated, this counts as an expansion of project scope. We know it does not feel like expanded scope: you said you wanted those Epics built, and we estimated we could do it, but there is a real risk whenever you plan to do something ambitious. There is a real risk that it will be harder, take longer and cost more than you planned.

Please understand this going in to a software development project, and face this reality with open eyes. We will try to work with you to adjust scope and give you a product that solves the main problem you want to solve. But if you are not willing to adjust scope in light of new evidence that the project will be harder than anticipated to complete, that is a risk that you must bear.

The same constraints apply when you look at how early iterations of your software function for users. If, at those times, you add features to the wish-list, or ask that features be substantially changed, you must realize that this can have an impact on project scope.

It’s the same if you decide to significantly reposition or redefine your product, fundamentally changing it at the “Epics” level. This creates a situation where you are essentially asking for a new project, from our perspective, and the whole business deal needs to be revised.

These are critical decisions of great strategic importance, and we think it is very important to schedule regular opportunities to monitor progress and consider these issues. Those scheduled opportunities are called Checkpoint Meetings.

3. Checkpoints

I mentioned that we work in Sprints, and we interact with clients at the beginning and end of every Sprint, but these Sprint Planning Meetings, and all the other common Agile Project Management Events, are not Agile Contract Checkpoint Meetings.

Agile Contract Checkpoint Meetings can be scheduled in different ways. They might take place after a fixed number of Sprints, or after completion of a certain number of Epics, or Agile work units (called “story points“). They can also be scheduled as needed whenever news from the development team requires a business response.

Contract Checkpoints are business meetings, not project management meetings. They are meetings where we examine and update the hypothesis on which our business agreement is based. For example:

  1. We might suggest we can deliver a better, more minimal product at lower cost. If you agree, we shrink the project scope.
  2. You might decide you need to reduce or slow down your spend, and so some features can be dropped. We can adjust our estimate to match.
  3. We may mutually decide to re-scope the releases of the product, doing it in phases and postponing work on some features until a later release.
  4. Users may not be using the product in ways you expected, and you may need to pivot – to change the product’s goals and direction. This changes our estimate.
  5. You might be concerned that our “burndown rate” (task completion rate) shows the project may run long or exceed budget. We can discuss if this is so, along with mitigation strategies.
  6. We might be concerned that your feature requests will exceed your budget, seek verification that you can afford the scope increases you want, or draft up an addendum to our initial agreement to formally expand scope. Terms for the addendum might include partial advance payment for the additional scope of work.

Checkpoint meetings provide us with an orderly way to govern scope changes and manage costs, and they do it in a way that deals with the inherent unpredictability of software development, instead of pretending we can make it go away.

4. Exit Points

Exit Points are clear conditions or junctures where the parties may terminate the project in a controlled manner. Some Exit Points are traditional and obvious, like non-payment of an invoice, or cost overruns. Others become available as a benefit of Agile.

In Agile, we try to deliver functional iterations of client products as often as possible. The goal is always to leave product owners with usable software, even if a project has to be halted early. This gives clients more freedom. There are viable Exit Points in Agile projects, where clients can walk away with a complete, production-ready software product they can use. We can schedule one or more Exit Points during the course of a project, with the stipulation that the product be ready to ship prior to each Exit Point Meeting.

Scheduled Exit Point Meetings are less frequent than Checkpoint Meetings. Exit Point Meetings can also be set up as needed, if scope/cost issues are raised during Checkpoint Meetings that cannot be resolved. During such Checkpoint Meetings, one or both sides think they may need to exit the project. This should not be decided right away. Instead, an Exit Meeting should be scheduled.

In preparation for the meeting, the development team can determine how much work is needed to make the current iteration of software ready to ship, and clients can review their own cost and scope expectations for both an Exit and a Don’t Exit scenario. If Exit proves to be the best option for the project, the process of finalizing the current iteration and amending contracts can be planned out and executed using an orderly and cooperative process.

There is also, naturally, an Exit Point meeting at the end of the project! It’s not just a celebration, but also an orderly way to make sure the product is shipped and working as promised, that all payments for work are finalized, and all development contract obligations are complete, and if ongoing maintenance and support work is needed, that these matters have been finalized as well.


Software development always involves some uncertainty regarding what the scope of the project is, and how much it will cost. The best way to manage this is to construct estimates based on Agile best practices for sizing stories (units of Agile work), and to wrap the cost/scope estimates with an orderly process for revising them. That way any and all scope changes will be well governed across the project lifecycle.

Even if the estimate is good, it will not reflect the final cost of the project to the penny, and so cannot be committed to as final during the creation of the contract. However, following the Agile Contract process can be promised with full certainty, and the mechanisms of this process make the risks of software development manageable.

This blog post has offered a very brief overview of an important book, as it applies to our work processes at ArcBees. To see how these ideas apply to your own Agile practices, we encourage you to get a copy and enjoy!

Agile Contracts: Creating and Managing Successful Projects with Scrum.
Andreas Opelt, Boris Gloger, Wolfgang Pfarl, Ralf Mittermayr.
Wiley 2013

GAE-Studio Newsletter #5

(Version française à la suite)

Good morning fellow developers !

In business news, we greeted yesterday a new bee : Joël Trottier-Hébert, who will enhance our team by focusing on integration tests in our projects, including GAE-Studio.

In product news, we’re proud to announce our first version of GAE-Studio for 2014, GAE-Studio 0.7 !

We have started releasing GAE-Studio to Maven Central, a long awaited feature, which will be a lot more convenient than downloading a jar for every new version. 😉

You can already find our newest version on Maven.

On the functionality side, we switched from RestyGWT to RestDispatch. We also added a lot more user feedback to the UX, which we think is really important when developing something that we want people to use a lot and often.

As promised, our new UI is really kicking ass. Please tell us if you like it ! It’s a work in progress, but we think it’s moving in the right direction to make GAE-Studio an application that will be easy and fun to use.

Also, we’ve sent a new wave of invites to the  GAE-Studio beta group. We now have quite a few of you and we really appreciate the feedback that we’re receiving. Please continue to send it !

If you have suggestions or issues, let’s talk in the issue tracker ! We really look forward to any opportunity to provide help or be of service.

Here are a few screenshots of the new user experience. Give it a try today ! You won’t regret it.

visualizer profiler


Bon matin à vous, chers développeurs!

Tout d’abord, une nouvelle d’entreprise puisque hier une nouvelle abeille s’est jointe à nous, soit Joël Trottier-Hébert. Joël ajoutera une plus-value à notre équipe en se concentrant sur les tests d’intégration de nos différents projets, dont GAE-Studio.

Ensuite, côté produits, nous sommes très fiers d’annoncer notre première version de GAE-Studio de 2014, GAE-Studio 0.7!

De plus, nos nouvelles versions sont maintenant disponibles sur Maven Central, une fonctionnalité attendue depuis longtemps. Beaucoup plus pratique que de télécharger un fichier .jar à chaque nouvelle version. 😉

Vous pouvez déjà y retrouver notre version 0.7.

Côté fonctionnalités, nous sommes passés de RestyGWT à RestDispatch. Nous avons aussi ajouté beaucoup de feedback à l’expérience utilisateur, une modification essentielle pour quiconque veut que son produit soit davantage utilisé.

Tel que promis, notre nouvelle interface usager est vraiment superbe. Merci de nous dire si vous l’aimez ! Ce n’est qu’un début, mais nous pensons que nous sommes dans la bonne direction pour faire de GAE-Studio une application agréable et facile d’utilisation.

Aussi, nous avons envoyé une nouvelle vague d’invitations à GAE-Studio. Nous avons constitué une bonne liste de béta-testeurs et nous apprécions réellement les commentaires que nous recevons. Continuez à partager avec nous!

Si vous avez des suggestions ou des problèmes, n’hésitez pas à le mentionner dans notre gestionnaire d’incidents. Laissez-nous vous aider!

Voici quelques captures d’écran de la nouvelle expérience utilisateur. Essayez GAE-Studio aujourd’hui. Vous ne le regretterez pas.

visualizer profiler