3 Steps to Make your Culture Unique

Three months ago, we published our first blogpost which dealt with our will to define our culture and questioned what initiatives we could set up to help us fulfill our goal. Since then, we took  a further step  in our journey, and this post  is meant to show you the progress we have made so far.

In the last post, we introduced our 9 values. We could have simply stopped with these and tried to put them directly in use or just listed a number of adjectives such as collaborative, innovative or passionate… But at the same time, it does not define who we are and what makes us  unique.

– If you want to be able to find your DNA, you have to dig deeper, you have to go further in defining your culture –

Our first step was to define the values. We knew our journey to define our culture was supposed to go beyond that. The next step was to create the manifesto in itself.

What is the Arcbees’ Culture Manifesto?

The Arcbees Culture Manifesto is a written statement of all Arcbees’ employees regarding our culture and the way they see the organization as a whole.

We went through three steps to define it.

Step 1: Dig deeper, wrap it up and name it

In the previous post, I mentioned how we took the necessary step to obtain everyone’s list of values. With those values came an explanation about what it meant for them.

Make them match: Collecting those explanations and making them work together was the hardest part and the list of values came from the best of each one of us. But then, we needed to find a way to explain each value so that it could resonate in everybody’s mind.

I took each one of those explanations and put them in a single document to try and find the words and ideas which were most common.

Don’t interpret! This step is rather a long process. The objective is to not transform or interpret what a person is saying. One has to take the explanation, try and make it match with the right value and match it with the others.

For the most popular values, we received 7 or 8 explanations coming from the 12 Arcbees’ employees. It means 8 ways to explain it, 8 ways to name it, 8 different lexicons and 8 unique minds behind it.

Take your time and dig deeper: It took me time to wrap up and summarize what people wanted to say, to find the essence in each one. I asked questions to try to understand what they meant behind each sentences.

You are not Superman! I want to warn you already about something. It is not a one man job as you need inspiration from others to find the right words and find the right flow in the sentences. At Arcbees, one of our principal values is collaboration and this manifesto is a collaborative work.

At the end, we wrapped it up and came up with a list of 9 values:


Step 2: Share with the team and gather feedbacks

Once everything is ready with the manifesto and you wrote a 0.8 version, it’s time to start to get feedback from the team.

Feedback process We prepared a presentation for the team and scheduled a meeting to have everyone present at the same time. The point was to have everyone’s reaction in person.

We introduced each value and its explanation. We then gathered the comments we received on things such as titles or the words used on the explanation itself.

Appropriation begins… At this part, you will notice people starting to appropriate the different values. Some of them stay more than others. You will witness strong reactions, which is good!

After the meeting, each person read it again and gave their own comments. Sometimes directly to me, sometimes by using Slack to have a discussion all together on a particular value.

Getting things ready for the final step The final request was for everyone to rank the values by priority for them from 1 to 9. This ranking would help us determine in a collaborative way which value was the most important at Arcbees.

Step 3: Plan to make it alive

Once the final document was made and we obtained the ranking for each value, we able to start our next step. This ranking has created a plan for further work around the manifesto.

– The goal of this exercise is to make your culture unique and your company! –

One word: Focus!!! We decided to focus on one value per month to accomplish step 3. We are going to apply the same recipe as for our other projects: an agile methodology inspired from Scrum. We want to use it to implement our values. By doing sprints lasting one month, we will define more specifically what is the value and actions inherent to it.

Each month will start by a brainstorm session. This session is open to all, and everyone can bring these ideas about the value we are focusing on.

At the end of each month, we will conduct a retrospective of the past month and the work done around the value. These tasks will eventually enrich our manifesto.

We are going to continuously do this work and improve our values ​​and our manifesto.

We will keep our communities updated with our progress. In February, we will focus on the value “We believe in the individual.”

Follow us: Subscribe to our newsletter, or on social media (Facebook, Twitter, Google+) if you want to follow up on the story of our commitment to our culture.

Live GWT Q&A with David Chandler on GWT 3 and the Sencha GXT roadmap

We are pleased to announce that we are going to hold our February live Q&A with David Chandler on February the 10th..

David Chandler will be our guest for this one and he will be discussing the upcoming changes in GWT 3 and how it fits with the next version of Sencha GXT.

David was formerly the GWT Developer Advocate with Google and is now GXT Product Manager and Developer Advocate with Sencha, Inc

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Return on Kevin’s answers on live Q&A on GWT Material

As you may know, 4 months ago we decided to put in place a new initiative for the GWT community. We wanted to highlight what was happening in the GWT community and start sharing the knowledge.

We held 4 Q&As already, which you can watch here. In preparation of those Hangout on Air events, we prepared a series of questions for our guests.

We know that some of you don’t have the time to watch a 30 min. video, this is why we took notes during the event.
You will have a hint of the live event which you can watch below:

Mark Kevin Baldemor was our guest for this Q&A and he talked about GWT Material. Founder of the Gwt-Material Project,he has been involved in the community for three years now.

Phil: Who are you and what do you do?
Kevin: I am Mark Kevin R. Baldemor, I’m currently staying in the northern part of the Philippines, surrounded by oceans and tall mountains with different species of wild animals. I am now 21 years old and I graduated at Informatics College Philippines with an Advance Diploma on Multimedia Technology in the year of 2013. I have my Internship at BPM Conseil, a french company located in Lyon, France and luckily I did my first job there with the introduction of GWT Technology, HIbernate, OSGI and lots of Google API’s. I do web and mobile development using open source kits like Android SDK and Phonegap. After my work life with BPM, I continued my journey to develop my own open source GWT Ui Framework built Material Design called “GWT-Material”.

Phil: What company are you working for? Can you tell us more about it and your role there?
Kevin: Now, I am working for I3 (Canadian Company) – on the IT Department as a Gwt UI UX Developer and a Project Owner and Contributor of gwt-material open source project.

Phil: Some questions about GWT first: When and why did you start using GWT?
Kevin: I started using GWT on 2013 from version 2.5 to 2.8. I loved the architecture pattern of GWT using RPC to communicate with the Server side components. Then, I tried to make some sort of starter projects using GWT for front-end and Hibernate for the back-end which makes the development process more exciting. As a result, I did more and more projects inside my company and the result was very nice but there was a code duplication when I included the CSS, JS Resources to build a custom widget. That’s when I tried to learn how to build a UI Framework and hosted it on Github with the help of other GWT Contributors to make it more Modular and easy to integrate to other projects.

Phil: Now about GWT Material in itself, you are the founder of this project. When and why did it start?
Kevin: Yes I am the founder of this project. It was founded January of 2015 with an alpha version hosted on Google Code, but later on with the help of other GWT Contributors, we tried to host the project on Github and released a Maven version (1.0) which improved the productivity of the project plus the showcase app. The history of this project started when Google announced their design language called “Material Design” and I discovered Materializecss (a CSS Framework) founded by Mr. Alvin Wang and his team. They wanted to build a website using the design specification of Google. With the whole idea, I finally decided to create an open source Apache 2.0 license GWT Based widgets built in Material Design specifications called “gwt-material” and I added some custom components and called them “gwt-material-addins”, like Autocomplete, Time Picker, PathAnimator, Subheader and etc.

Gilberto Torrezan Filho: Talking about GWT Polymer, doesn’t GWT Material have the same purpose as Vaadin’s project? Will they be competitors to each other in the future?
Kevin: GWT Material is totally different from GWT Vaadin Polymer project, because our project is totally based on GWT widget based systems built on Material Design Specifications and with the help of Materializecss contributed by Avin Wang. GWT Vaadin created their generator api to create paper components using JSInterop, soon on GWT Material we will also implement those features using Elemento and JSInterop to support GWT 3.0.

Zakaria Amine: Is GWT material design library production ready?
Kevin: Yes it is production ready, and honestly we have news coming from the community: they have successfully built a gwt-material design application on Web and also on mobile development using Phonegap. We also provided templates for a guideline on how to develop using gwt-material.

Below are the list of applications built by the community for their personal and company projects:

  1. TripWeGo by Julien Guibert
  2. Healthphere by OrNot (Github username) – http://www.healthphere.com/
  3. MyMoney by Werner Kok

Here are also the list of the templates we provided :

Phil: Question # 5 : What can you tell us about the community?
Kevin: About the community, we have now 118 members on Gitter Channel, 116 members on Google Plus and 128 Stargazers on Github which is a good news for the project itself. Many users submitted their Pull Requests for new exciting material design widgets. Some are submitting issues which improves the stability and quality of the project. GWT Material has 9 members, some are part time contributors and others are actively contributors of the project. Thanks to Ben Dol (New Zealand) on the huge code refactoring made on 1.4 release including the modular theming of the project called “gwt-material-themes”. For the Maven releases of the project, Christian Lacerda (Brazil) is our active releaser for the said project. Sometimes we organize online session using Team Viewer to help one another on how we can leverage and discuss about the project.

Phil: Question # 6 : What can you tell us about it and its evolution?
Kevin: GWT Material is a Material Design based widgets with the help of Materializecss as core framework. We release

  • 1.0 for the (Production Release) it includes the core material widgets.
  • 1.2 Integration of Phonegap plugin with gwt-material
  • 1.3 Maven Official Release
  • 1.3.1 Bug fixes for 1.3
  • 1.3.2 gwt-material Themes
  • 1.3.3 Material Design templates
  • 1.4.0 Huge Code Refactoring
  • 1.4.1 Bug Fixes for 1.4 (Upcoming)
  • 1.5.0 gwt-material-addins components (Upcoming)

On each release we are very thankful to the contributors for their support on gwt-material project. I am very happy that until now the project status is still actively maintained.

On 1.5.0 version, we added MaterialPathAnimator to provide meaningful and delightful animations to transform a source widget into target widget. It helps the users to not loose their interaction between two components e.g a Card transforms into an overlay panel or a button transforms into a card. Also we tried our best to implement core animations like fade in/out, slide in/out or even page transitions into the Material Design widgets. We also added a built in Google Icon Fonts hosted internally and we provided a morphing animation using MaterialIconMorph.

Mohammed Al-Hammouri: What about the performance or size of the library?
Kevin: First, I’m not really good on performance optimization about web applications, but for the css or js resource, files of Materializecss can be measured using their jasmine test. Now, I am developing some big applications and the result is great, it is fast. I don’t have any issue on app’s performance including the server side and populating the data into a specific material design view component. On Phonegap, I tried to integrate my web app but it seems to be too slow because of the JQuery animation plugin which kills the performance. What we did is that we separated the modules into different repositories like gwt-material-theme and gwt-material-addins so that the user can choose whether they want to have only the core components or include the addin components.

Gilberto Torrezan Filho: Materialize CSS is the base project for GWT Material, but currently GWT Material have more components than Materialize CSS. How is the relationship between Materialize CSS and GWT project teams? What would happen to GWTM if materialize CSS is discontinued?
Kevin: This is a good question. I talked to Mr. Alvin Wang about the project and he was happy that their project was used by GWT Material. As for me, I am very thankful for their contribution to the world of web development. If Materializecss were to be discontinued, it is likely that we would have already created our Plan B: “gwt-material-addins” – a collection of custom Material Design Widgets plus Community contribution built in pure gwt-material widgets.

Phil: Question # 7 : What is the future of the GWT Material?
Kevin: This is a good question. As for now, we all know that we are waiting for the GWT 3.0. Everything is new as I heard on the GWT community, such as the usage of JSInterop, Java 8, Web Components and other tech behind it. With gwt-material 2.0, we are thinking about implementing all of these inside the project to provide a bullet proof support for the said open source project to make gwt-material a great project and supports GWT 3.0.

Also we are trying to build more Material Design Widgets and trying to refactored it using JSInterop. We are on the Research and Development process to learn how to use it and provide the architecture of GWT Material 2.0 and will be able to release on Maven Central as soon as possible.

Martin Hollerweger: How do you see the future with GWT and js-Interopt? What are the main benefits of GWT compared to other solutions like ionic?
Kevin: The future of GWT and JSInterop is interesting but it has a minor effect. First with the use of UiBInder and widget system: these features will be removed on GWT 3.0, I think. But for gwt-material, we will try our best to support it using JSInteropand Java 8 other features. For the last question, sorry but I don’t have any idea about Ionic.

Martin Hollerweger: Will Gwt-material switch fully to js-interopt?
Kevin: This will depends on the discussion with the community. If they want to switch fully to JSInterop then we will do it for them but in my opinion as a founder, it is good to have backup plans to anticipate the migration such as creating an old branch to backup the previous features that does not support JSInterop. Then, we will create a new branch for the JSInterop migration so that the user will have options if they want to switch their apps into JSInterop support or not.

Project shared
GWT Material repository – https://github.com/GwtMaterialDesign/gwt-material
GWT Material Addins – https://github.com/GwtMaterialDesign/gwt-material-addins
GWT Material Themes – https://github.com/GwtMaterialDesign/gwt-material-themes
GWT Material Showcase – https://github.com/GwtMaterialDesign/gwt-material-demo
GWT Material Phonegap – https://github.com/GwtMaterialDesign/gwt-material-phonegap
Google Plus Page – https://plus.google.com/communities/108005250093449814286
Contributing Guide – https://github.com/GwtMaterialDesign/gwt-material/wiki/Contributing

Live GWT Q&A with Mark Kevin Baldemor on GWT Material on January 19th

We are pleased to announce that we are going to hold our January live Q&A on January the 19th with the founder of Gwt-Material Project, Mark Kevin Baldemor. He is very involved in the community and he will talk about the GWT Material project.

A bit of information about our guest for this month:

“I am currently staying at the northern part of the Philippines with lots of beautiful scenic spots which leads my development life into peaceful and exciting work condition. I tried to help the gwt community and my current company to build rich web / mobile applications with the help of Google Material Design UI / UX specifications which improve the gwt developers productivity. With 3 years expertise on gwt development, I experienced the copy pasting of styles from one project to another, so I decided to create an Open source project api for Front End Framework with the help of Materializecss bringing Material Design to Web Application development with Rich UI / UX and Meaningful Animations.”

Mark Kevin Baldemor

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Live Q&A session with Brandon Donnelson on GWT Plugin for Eclipse on December 10th

We are pleased to announce that we are going to hold our december live Q&A with Brandon Donnelson on December 10th.

Brandon will be our guest for this one and he will talk about the Eclipse Plugin for GWT. This Q&A is a great opportunity to learn more about Brandon and the Plugin.

He is really involved in the GWT Community and if you don’t know him, it’s a great occasion to discover who he is. A bit of information about our guest for this month:

  • Brandon is a GXT Support Engineer for Sencha and here is his bio: “I live in Arlington Washington on a small farm with my lovely wife and 5 kids. We’ve got a llama, couple alpacas, some goats and chickens. I enjoy working with the GWT and I like helping others use it for application development. Often in my spare time I’m working on things that help others.”

Come on and join us on this event!
Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Live GWT Q&A with Francesca and Alberto on GWTcon

We are pleased to announce that we are going to hold our live Q&A with Francesca Tosi and Alberto Mancini on October 28th.

Francesca and Alberto are both the organizers of the GWTcon. This Q&A is a great opportunity to learn more about GWTcon, the event and why they are doing it.

GWTcon is a community-driven event which tries to involve the community around the GWT Toolkit as much as possible.

GWT being an open source project, we think it really needs and requires an healthy community of active developers and users that are willing to share experiences, opinions and real word practices.

  • Francesca Tosi is a Freelance, web & mobile Developer and Architect, with a passion for fine tuned details. Co-founder at JooinK (www.jooink.com). GDG-Firenze Lead and founder. Intel Software Innovator. GWTcon organizer.
  • Alberto Mancini is a passionate (web & mobile) developer and linux sysadmin. Co-founder of GDG-Firenze and GWTcon organizer. He loves to learn new programming techniques and to demonstrate how modern browsers can do high performance computations, of course using GWT.

Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

First Live GWT Q&A Session with Maxime Meriouma-Caron and Olivier Lafleur on GWT Chosen 3.0 Release

We are pleased to announce that we are going to hold our first live Q&A with Maxime Meriouma-Caron and Olivier Lafleur on October 7th.

Maxime and Olivier are both Arcbees’ employees who worked on the new release. This Q&A is a great opportunity to learn more about GWTChosen, or offer suggestions about how it can be improved for future releases.

You’ll also gain some insight into how we work at Arcbees, and get to know two of the Bees who contribute to and help support our open source projects.

  • Olivier is an Open Source and Open Web enthusiast. As our “community gardener”, he likes helping new Bees explore the Arcbees ecosystem, and really spread their wings.
  • Maxime is a passionate developer always up for new challenges who joined Arcbees in 2011. Over the past several years, he has contributed to GWTP and other open-source projects, including GWT-Chosen, Jukito, GWT-Query plugins, TeamCity plugins and GWT-SEO. He has also acquired significant expertise in the Google Cloud Platform, in his role as lead developer on many projects.

Keep tabs on all GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Owning our culture at Arcbees: First step to our manifesto

A few years ago, the process of defining your culture and owning seemed to involve copying Google : setting up a nice office with a playground if possible, slides inside the building, and open spaces with lunch room for hundreds of people. The Silicon Valley startup effect was on everyone’s mind, and a lot of companies thought that the office setup was the heart of a startup culture.

In reality, offices are just a differentiator, or a way of showing-off. Companies with cool offices are saying “We care about our employees, come work for us!”. It was a way to show it to everyone, a way to differentiate themselves from their competitor and a way to attract the best talent. In and of itself however, it doesn’t constitute the actual culture. You have to look deeper into the meaning of each action a company undertakes to find out what was the real corporate culture.

For example, in the early days of Google, collaboration and innovation were encouraged. That was the underlying reason for long tables in the lunch room, so people could sit beside unknown colleagues, to get to know each other, exchange ideas and begin to change the world together.

Google’s office facilities had two purposes:

  • To make employees feel at home and engaged in their work.
  • To attract new talent.

The real culture at Google was “Don’t be evil”, not “Playgrounds and fun work spaces for everyone”. Fun spaces were a way to engage people and, at the same time, to own their culture. They were not evil with their employees. They were giving them places for happiness even if they were at work.

The question you have to ask is :

Why are those giants investing so much money in their culture?

If you want the answer, you have to take a look at the research on employee disengagement and to see how choking it might be.

Employees disengagement costs a lot

Disengagement can cost up to 550 billion per year, actually. It becomes clear that we can not afford that. Worklife and meaning are some of the most important things if an organization wants to enhance creativity, innovation and new ideas. All level of leaders need to accompany employees throughout their careers and their projects.
Disengagement can impact an organization in various ways: higher turnover, less productivity, difficulties retaining talent, difficulties attracting new employees, lower value as social/employer brand, absenteeism, lower quality, reduced productivity and generally the most dangerous : poor customer service, which affects the company directly.

To avoid disengagement, companies have decided to invest a lot of money in their offices and on their services. It’s not just a U.S. phenomenon : Samsung Digital City is a perfect example of this trend. The downside is that you become the prisoner of your workplace. There are so many services, that you end up spending most of your time at work.

So, where is the balance in the culture? How to put it in place an environment that fits everyone desire and objectives without falling on the wrong side ?

Below you will find a list of books, articles or companies which inspired us in our process.


Today, there are many examples of companies that succeeded based on their culture. I share some examples that inspired me in our journey to build the culture at Arcbees.

Strategy For Sustainability: Adam Werbach

A few years ago, I read a book written by Adam Werbach: « Strategy for sustainability, a business manifesto ». He demonstrated that employee engagement is a key success factor for a sustainable strategy. This has benefits beyond sustainability. It supports your employment brand. If you are not supported by the masses, you won’t succeed in attracting or retaining your champions.

He and his team started a project called « PSP », the Personal Sustainability Project for Wal-Mart. Each employee was asked to do one thing for themselves, for the society, for their family or for the organization that was sustainable.

With this project, they succeeded in one aspect of their sustainability strategy. By improving the life of their employees and by creating common objectives, they created a new sense of belonging. Also, by planting seeds of sustainability in the minds of their employees, they enhanced their employees’ lives, and by extension, their employees’ families and friends.

Tribal Leadership: David Logan

« Tribal Leadership » by David Logan clearly describes the difference between companies with strong leadership and well established values, and companies with no purpose. In this book, he explains how people put in place their leadership and at the same time the culture for their tribes. This book is not focused on culture per se, but it tackles this subject indirectly.

Delivering Happiness: Tony Hsieh

Another important book on corporate culture is « Delivering Happiness » by Tony Hsieh, a book about Zappos. This company is the perfect example of the success of a strong commitment to culture, and it is an example of a tribe described in David Logan’s book.

In less than 10 years, through culture, Tony Hsieh built a billion dollar company. His book has become a reference on how to develop a unique culture inside your company.

The biggest lesson from this reading is about commitment. You can’t have a successful culture without it. You can’t succeed in defining who you want to be without it. It’s a long process and as a company, if you attain your objectives, your employees and your company will gain a lot from it.

Buffer’s Culture Blog

Finally, my last inspiration is Buffer Culture and their path to transparency. The good thing about their transparency and culture journey is that everything is recounted on their blog. So if you want to know about the upside and the downside of the day-to-day work of building your target culture, you can have a look at all their stories.

Summing Up

The biggest result of all these examples is the importance of “commitment” in this process. Without commitment you can’t take ownership of your culture. Every company should focus on that and build it straight from the beginning, it is what defines the company and the workplace.

The first steps to define our culture

We started our commitment to build our own culture by then end of the autumn (the reflection started long before that). The company was shifting its strategy and business model to emphasize products over services, and we wanted to focus on who we are and what makes us Arcbees.

We didn’t want to copy other companies’ processes, and we didn’t want it to be a 2 or 3 person job. We wanted to involve every employee.

Phase one took a month and a half. We asked each employee to reflect on their values and what they seek as a person and as an Arcbees team member.

The biggest advantage is that the process of defining culture becomes a team project. On the other hand, the downside is the fact that everyone does not explain the same thing in the same way. So it took some time and a lot of back and forth to explain what we were expecting from everyone.

We sent the following guidelines to all Arcbees employees:

“In the past few years you have been working at Arcbees, and you have completed many tasks. We would like to invite you to participate in the process of defining our culture. We want it to reflect who we are and we want to include everyone’s opinions.
We would appreciate it if each of you, on your own, would define 4 to 5 values and to explain each one in 2 or 3 sentences.
The purpose of the explanation is simple. Not everyone thinks the same way and the same word can have different meanings. That is why we ask you to define what you mean by the values you list.”

The results were outstanding! We were really impressed by the ideas and the commitment of our team to the exercise. One of our colleague even sent it in Rot13, which is the most creative and geeky way we received it. They all agreed to play the game, understanding this was their opportunity to express their feelings, and explain what they want and expect from working at Arcbees.

The hard work began when I received their emails. I had to gather the information and merge the many different explanations into one coherent set of values. When you are working with various people each with their own expertise, role and personality, you sometimes have to dig down a bit to find the real intent or real issue behind their explanation.

For example, some people had the same definition for “freedom” and “autonomy”. It was sometimes a bit hard to explain what we were expecting because some people were focusing on the company only, so it was missing a bit of their personal.

When you do this kind of exercise and it works, you notice the similarities in thinking really quickly and choosing the one you want to commit to become crystal clear.

After reconciling the explanations, I came up with a list of values that from now on will define Arcbees Culture.


This list of values is an extract from our culture which is still a work in progress.. We’ll blog about that as we work on it, so you can keep tabs on our ongoing commitment to our culture.

Subscribe to our newsletter, or on social media(Facebook, Twitter, Google+) if you want to follow up on the story of our commitment to our culture.

GWT Live Q&A sessions are about to begin!

Important developments in GWT are underway all around the world, and the GWT Live Q&A sessions of Google+ Hangouts is your chance to connect with all of them. This monthly Hangout will feature a conversation, presentation or broadcast of a live event, plus an opportunity for you to ask GWT superstars from around the world your questions – about their presentation or about any other GWT issues you want to ask them.

How GWT Live! will Work

The event in itself will be held live on Google+. Each month, 2 weeks before the event, we will create a GWT Live! Event Page on Google+. Live sessions will last between 30 min and 1 hour depending on the topic and our guest. You will be able to follow it live and ask questions through Google+ or on Twitter using the hashtag #GWTQA. We will try to answer as many  questions as possible in the time we have.

GWT Live! Video Recordings

A video recording of each GWT Live! event will be posted to the Arcbees Youtube channel, and cross-posted to the Google+ Event Page for that Hangout, and on our Arcbees blog. We will also write a blog post after the event summarizing key points from the session, as well as providing answers to any questions we did not have time to address.

Join Us for the First Session

Arcbees is releasing a new version of one of our products this month, and we are making that the topic of our our first Q&A session. Our goal in releasing products is to make your life easier as a GWT developer, and we are eager to present our latest release to you and hear what you think about it.
Stay up to date with news about the GWT Live! Hangouts by subscribing to our email list or by following one of our social media accounts (Twitter, Facebook or Google+).

Avoid headaches: Use an Agile issue-type decision tree

At Arcbees, we’ve had more discussions that I’d like to admit about issue types in sprint planning. On any given day, the same issue might be reclassified from story to improvement and back again, for reasons that seemed to have little to do with the issue itself.

If issue definition was inconsequential, this would pose no problem for us, but we have found that mis-categorizing issues actually impacts morale, velocity, estimation, and a host of other factors that have real consequences for the success of the project.

The realities and constraints of our work amplify the consequences of improperly classifying issues. We’ve come to identify five key factors that determine how smoothly the development process will unfold for us at Arcbees. All of them are impacted by improperly classified issues. These include:

  • budget;
  • scope;
  • planning;
  • time zones;
  • remote workers.


In this article I will describe a tool we have created to help speed and facilitate the correct classification of issues at Arcbees. First I will explain the negative consequences of getting issue classification wrong. That will make the value and simplicity of the solution clear. We hope our tool helps your development team avoid the problems and enjoy the benefits of easier and more accurate issue categorization.

Bad issue classification will kill you!

Everyone on your project from product owners to developers lose when issues are misclassified.

We observed four principal negative impacts of issue misclassification in our projects.


We use Jira to manage our projects. Jira’s documentation defines four types of issues, as listed below (https://confluence.atlassian.com/display/JIRA/What+is+an+Issue) :

    • Bug — A problem which impairs or prevents the functions of the product;
    • Improvement — An enhancement to an existing feature;
    • Story — A new feature.
    • Task  A task that needs to be done (love this one :P)

The team needs to communicate about the work that needs to be done in the project. Communications quickly become confused if team members start to define all issues as “improvements” to the product, which becomes tempting after the first few iterations. The key question to ask is: “Is the feature already developed or not?” If yes, the issue is an improvement, if no – if new value is going to be experienced by the end users –  it is a story. You don’t want to fall into the trap of calling too many issues “improvements”, because if you do, you’re going to miscalculate the real velocity of your team.

Frustration and feeling no progress

The value you create in a product, as a team or as a developer, is defined by the stories you deliver at the end of each sprint. Each completed feature adds value to the product. The other types of issues – bugs, improvements or tasks – do not deliver new features, so developers working on them may feel like they aren’t adding value to the product. The value delivered by working on bugs, improvements and tasks often takes time to become appreciated, and may never be apparent to the end user. Developers assigned to these issue types may feel frustration that their efforts do not count when value delivery is assessed, and this can have a negative impact on team morale.

This is important. It means that developers’ self-perceptions of their contribution to projects is directly linked to how issues are identified. Once we realized this, we began paying much more attention to getting issue definitions right, and that had a significant impact not only on each Arcbees team member, but also on the whole team.

By sharpening our process for defining issue types, we were ultimately able to clarify further the value of working on each type. This helped us counteract the perception that stories were the only important types of issues to work on. Developers were more willing and able to both define issue types properly, and value their own work on issues of every type.

Caring about estimation meetings

A lack of clarity about issue types also has a negative impact on estimation meetings. Estimation meetings are important at Arcbees, since we need to manage project scope and also coordinate the efforts of remote developers on a distributed team. Estimation meetings clarify the work that needs to be done in a sprint, and helps us assess progress on the project.

Here again, the fundamental differences between improvements and stories asserts itself. Supposedly, if you follow best practices, you only estimate the size of stories. You do discuss all tickets in the backlog, but you are not supposed to estimate the other story types.

Confusion about issue types can really kill estimation meetings. Everyone gets frustrated with the lack of clarity over how issues are classified, and after a few estimation meetings developers begin to lose focus. The meetings become empty and formalistic, with developers putting less of their heart into them. A process for clarifying issue types corrects this problem and brings focus and enthusiasm back to estimation meetings.

Velocity irregularity

Velocity should become consistent as a project takes off, with this should become apparent at the end of each sprint. It is important for product management that you be able to project velocity for upcoming sprints by looking at the history of your previous sprints.

Since you only estimate stories, the only complexity points which contribute to velocity assessment at the end of a sprint are story points. What if most of the work in that sprint was done on improvements or bugs? With the traditional way of estimating stories and calculating velocity, you wouldn’t see the real work involved.

This is why identifying the right type has a direct impact on the meaning of what has been accomplished. And since you are looking at your previous sprints to identify what you are capable of doing, it has an indirect impact on your work commitments for the next sprint, and the consistency of your velocity

Problem explained! Show us the real deal!

For any issue definitions, there will always be edge cases that don’t fit your scheme.

At first, we tried to clarify issue identification by writing better definitions of each type. This helped, but by itself it was not enough. We kept finding edge cases that did not fit neatly into our categories. We quickly decided to improve the process by creating an infographic to support better decision making. This made all the difference.

What a better way to represent issue classification than a decision tree! Visuals are easier to use and support better outcomes than verbal definitions in team meetings. We started from the general definition of an issue type and we drew this decision tree. It helped us define a clear path for choosing the right classification for each issue in a sprint.


As you can see in this tree, we started by defining a story and epic:

A feature gives value to the end user and wasn’t previously available

For those of you who are used to Agile terminology, you know a story can be reclassified as an epic. It’s not just a matter of the complexity of the issue, it’s a matter of whether or not it can be split into smaller stories.

Let’s take this story as an example:

As a user, I want to be able to manage my documents, so that I can classify them as I wish.”

This Epic can encompass many smaller stories needed in order to describe all the functionality required to deliver its value. Usually Epics describe a high level requirement of your application.

From the definition of a story, we identified what would differentiate a spike from a story. In this case, the decision point is “Do we know all the details?”.

In our projects, when we need to work on a new feature but we are not sure which library we should use or how it should be implemented, we create a “spike”.

A spike is time limited effort to research a specific feature before implementing it.

The next decision point differentiates a story from an improvement. This decision was the one that had usually stimulated the most discussion and disagreement in our meetings. Since the official definition of an improvement is that it affects an existing feature, and features deliver value to users, we decided improvements by definition should not be detectable by the user.

We defined an “improvement” as follows:

An improvement is an issue which affects an existing feature and has no effect on how the user experiences the application.

Refactoring and testing a piece of code to make it cleaner would be an improvement, not a story, even though it might be a big piece of work that might impact velocity. For this reason, improvement issues, like spikes, are time-capped within an iteration. Impact on velocity is controlled through the time cap.

Changing the label on a button would be a “story” by our definition, because it would improve the UX, and so delivers value to the end user. In the past, some team members wanted to call these kinds of small changes related to existing features “improvements”, which is understandable. However, lots of these small pieces of work taken together makes a big difference for end users. That is why we had to clarify that even small issues are “stories” if the user can detect them. These small stories factor into velocity assessment like any other story.

The last definition concerns the meaning of a “task”:

A task is not related to a feature, but needs to be done for the success of the project.

A task could include releasing a new version of the product, or writing developer documentation.

These definitions plus the decision tree removed the confusion for our planning and estimation meetings, clarified velocity calculations, and helped us scope and coordinate work. We could control time spent on improvements and spikes, and improve our projections for feature delivery against time and budget. It had a major impact on estimation meetings, focusing discussion on key decision-points, most especially: “Will this issue deliver value to the user?” That is always a valuable point to clarify.

Most importantly, this framework gave team members clarity when discussing their work. That had a big impact on improving morale and clearing up disagreements and misunderstandings. There are objective standards that explain how issues are classed, so now we can all literally work “from the same page” when classifying work.


The issue-definition decision tree and definitions work for us at Arcbees, and they fit the realities and constraints of our work. We believe every methodology should evolve to fit its environment. If you do adopt and adapt these standards to fit your context, please let us know what you did. We are always learning and adapting our own processes, so any new insights you want to share are deeply welcome. Until then, happy sprinting!