Keep informed?
Subscribe for our newsletter now!

Making room for developers – and achieve great results

Homebase - for 24 hours

Homebase - for 24 hours

During the last years we professionalized our internal software development around camunda fox and the Activiti Engine – and we are pretty good at it by now. But if development is a serious job where you “have to code” what the customer wants – how to keep your world-class developers happy and innovation flowing? One piece in that puzzle is something I got to know from Atlassian – the company behind JIRA. They called it “FedEx Day” or more recently “Shipt-It Day”. The idea is simple: FedEx delivers within 24 hours. Build teams, come up with ideas, lock yourself for 24 hours and hack a shippable piece of software. And on top of it we added a slack time arrangement. Today I want to share my thoughts on it and present our first experiences and results.

Quick background: Professional software development means “Software Development is your job”

Professionalizing software development basically means that you try to implement the right requirements (!) in a way suiting the current situation best (!) in the most efficient way. For us the most important part was to concentrate on the right requirements. Priorities are therefor driven by product management, which is basically a proxy for the customers and end users. This sounds obvious – but it is often not the case – especially for Open Source projects. If developers do something by heart or in their free time technology comes first. But technology is not an end to itself. It has to be used right to get a good quality software suiting the current situation (aka non functional requirements). And this can sometimes be even frustrating for top architects and virtuous hackers.

At camunda we organize software development using Scrum. One thing we experienced working in a “user story driven” way: The team easily gets in the “we do what we need to do for the story” mood. This is not surprising as this is basically what we want. But we experienced the downsides of it too: Lack of innovation, lack of architectural improvements, less motivation, less identification with the product and less vision to anticipate later problems. So I wanted to act. I introduced two things at once (yeah – I know – one step at a time – but I felt that these would be a good team): Slack time and Ship-It Days.

Slack Time

Slack time refers to time where developers can decide for themselves what to do. It is often referred to “20% time” meaning 4 days normal work and 1 day self determined. See for example Thoughts on Google’s 20% time or Atlassian’s 20% Time Experiment. Actually we don’t do 20% – we do one day every Sprint – with a sprint lasting two weeks that are two days a month – approx. 10 %. Keep in mind that this is quite some investment. We calculated how much (motivational) beer we could buy the developers instead and believe me, that was quite a lot 😉 We declared some rules (inspired by 20% time nuts and bolts), the most important are:

  • The work must must be product related. There are no technology restrictions, but it must be somehow in the scope of the product. Otherwise it is hobby. To phrase it in terms of Atlassian: That’s what weekends are for.
  • The dates must be coordinated among the team and approved by the product owner.
  • You need a supporter for your idea.
  • You must present results at our internal “camunda day” in front of the whole company.

That’s it. This Friday we will see the first Slack Time reports – I am really looking forward to it.

By the way – I heard from internals at a big company having 20% time that they often call it 120 % time – we try to do better than this 😉

Ship-It Day

Our nice remote location for the Ship-It Day

Our nice remote location for the Ship-It Day

From 25th to 26th of October we rented space at an old mill somewhere in the middle of nowhere – 50 kilometers away from Berlin – bed & breakfast included. So we could really focus on coding for 24 hours – and a couple of colleagues used that time pretty well and even skipped sleeping (official note: I forced nobody! I even bought the beer to get the people tired ;-)). It was a really amazing experience! We had a very creative brainstorming / team-building phase before the even and collected loads of good ideas around the camunda fox BPM platform. Too bad we could only do a few of them 😉 I list the results below – and you can already look forward to our next “Ship-It Day” in summer 2013!

Our time line for the Ship-It Day was (compare to Atlassians time line if you like):

  • 3 weeks prior to the date: The ideas and topics were collected and commented in our wiki. Then we had an one hour meeting to discuss the ideas and formed teams working on the ideas.
  • 1 week prior to the date: The goal of every team was clear and documented in the wiki.
  • Thursday 12 a.m.: Departure from the office.
  • Thursday 3 p.m.: Start of Ship-It-Day. Snacks, Pizza, Breakfast and drinks are provided. Sleeping is allowed 😉
  • Friday 3 p.m.: Presentation of the results in front of the whole company (came to the remote location as well) and election of a winner.
  • Friday 4 p.m.: Start the After-party till Saturday 🙂

Ship-It Day results

cockpit Statistics

cockpit statistics - shipped in 24 hours :-)

For the monitoring tool “camunda fox cockpit” we currently do not provide out-of-the-box statistics. We “only” have a tutorial how to build them with a report generator of your choice – which is pretty handy in most of the real-life projects. But anyway – it is clearly nice to have some ready-to-use reports. Here they are, Falko and Kristin have build something really amazing – using only a couple of queries and a Java Script framework for the visualization. We plan to integrate that in cockpit after the 6.2 is shipped and we have a bit spare time to do a proper product feature out-of-it (surprisingly in 24 hours the quality is only CLOSE to shippable ;-)).

Cockpit Technology Upgrade

Another team (Nico, Nils, Roman, Stefan) did a prototype how cockpit can be rewritten in a HTML5 architecture (currently we have JSF). We already did that technology shift for “camunda fox cycle” and are pretty happy with it. Hence cockpit will follow. The prototype was pretty valuable – now I can always object “why is this so much story points? You prototyped it in 24 hours” ;-). But serious – we learned quite a bit and prototyped how plug-ins in cockpit can be realized – an important feature to move forward with the monitoring tool aligned with the vision we have: a framework like approach which can be leveraged in your own project easily. Look forward to something new in that area somewhere in the middle of 2013!

Graphical DIFF & MERGE in cycle

Andreas and myself (yes, I was allowed to code as well) did something I find really cool: Graphical DIFF and MERGE on BPMN 2.0 process models. We hacked that as prototype into cycle using “bpmn.js” – an Open Source hobby project from Andreas able to render BPMN 2.0 XML in the browser on-the-fly. It was actually pretty straightforward to get the easy cases – see the screen cast below – but we also identified problems we will have to solve for more complicated cases. Summary: A pretty cool approach which I want to drive further as soon as we have time to do it right. Unfortunately this will not be too soon – but I hope still in 2013. This would perfectly support our BPMN methodology (see Real-Life BPMN) and the multiple tools / best of breed approach (see our “Toolchain Approach”).

BPMN + UML Prototyping

Last but not least Daniel and Christian implemented a prototype to combine UML class diagrams with BPMN 2.0 models in order to bootstrap whole applications including Entities. Due to a lot of technical challenges we basically learned that this was too much for 24 hours. And for the moment we postponed working on that edge – as this is not really priority from a product management perspective. But great to know more in-depth of the current state of MDA and MDSD frameworks.


I think camunda is currently on a really cool journey – I enjoy it very much. On the one hand we have an already professional but still continuous improving software development process delivering shippable results – which gets us excellent feedback from customers (see references) which is motivating for everyone. And on the other hand we have some instruments to weaken the burden to be forced into prioritized sprint backlogs. I think this is a winning combination. But be assured that we will continue to watch out for improvements – as we always do: Inspect and Adapt.

By the way – if you think “Wow – this is cool – I want to work there!” – check out our job offerings: 🙂

Already read?

Scientific performance benchmark of open source BPMN engines

Why BPMN is not enough

Decision Model and Notation (DMN) – the new Business Rules Standard. An introduction by example.

New Whitepaper: The Zero-Code BPM Myth

3 Responses

Leave a reply