One software, many customers – Are you truly agile?

Posted by Tobias Spöcker on August 2, 2018

Does your company consider itself to do agile development?

Is the Software you produce delivered to a huge customer base?

Have you ever wondered if you and your organization really follow the practices of the agile manifesto?

If yes then this is a good read for you. At TOPdesk we reached the size of a company that can no longer be labeled small. With over 600 employees across 14 countries we list ourselves as a mid size company. Although we are not a large-scale enterprise yet I figured we are already facing the downsides such an organization comes with.

Before I go into more detail about that, I would like to briefly state the agile manifesto’s core values before I set them into contrast with the practices in our company.

Read more

Why the Lean Unconference is gaining popularity

Posted by Hollis Hazel on August 5, 2016

One of the great things about working at TOPdesk is the freedom you get to organize your own events, like the recent Pecha Kucha evening that the Agile Community held, or our annual innovation Hackathon. In this post I want to share what it’s like to participate in a Lean Unconference (a conference with no schedule), a concept I first encountered in the Leancamp Startup circle.


What is a Lean Un-conference?

The Lean Unconference started with a kick off.  Together with around thirty young professionals and entrepreneurs, the organisers gathered in the lobby. They first recapped the format and goals of the (half) day and gave everyone time to fully arrive and focus on the present.

The organisers underlined elimination of waste is at the heart of Lean. A Lean Unconference thrives on the premise that we have all come to learn or to share.  If you are not doing one or the other, you risk wasting not only your time, but the time of others who are trying to learn or share. We agreed to use the law of two feet. If a session is not as relevant as hoped, use your time wisely and join another session instead.

Instead of a passive conference experience, the Unconference organisers did a good job in activating the participants. For a short time, they said (and they were right!), we had access to a wealth of knowledge, experience and expertise. It would take weeks, or even years to share all that we had learned. We only had half a day, so let’s make the most of it! An introduction like this generated a noticeable drive among those present to make it time well spent.



An Un-scheduled conference?

When I say an Unconference has no schedule, this is not strictly true. An empty schedule posted in the central area displayed six slots of a half hour, each with a number of available rooms (say, four or five).

Before each block of three slots, participants could pitch their session to the group. We then assigned post-its to a room big enough to seat those interested. While everyone was welcome to prepare, keeping the schedule empty ensured that all proposed topics were current, relevant and interesting. It was perhaps more reminiscent of open spaces or breakout sessions than a traditional conference.



What can the sessions be about?

This is another advantage of Unconferences. Sessions can be about anything! You might follow a particular theme (Agile Testing, Customer Feedback) or simply leave your options open. To make the outcome as useful as possible, pitches should be relevant (address a current issue) and personal (based on experience).

  • You might ask a question: How does user experience fit into Agile Development?
  • You could share tips or experience: How I made Risk Poker really work for my project team.
  • Maybe you want to teach a new skill: Mind-mapping for user scenarios.
  • Or get advice: How do I get my team to talk more about unit testing?

For each session, the host could choose from a number of interesting session formats.



Read more

From Wall to Test Plan: bringing programmers and testers together

Posted by Sander Koning on July 26, 2016

In my early programming days at TOPdesk, communication with the Testing department was deceptively easy: throw the feature over the wall, and some time later receive a notification that it was okay (or not). Luckily we learned that the easy way is not always the best way, and we introduced scrum and agile techniques.

This shortened the lines of communication and the contact between programmers and testers became a lot more intensive. We started discussing the story details and the biggest risks together. With everything written down, while the programmers were writing the code, the testers could already start writing test specifications. Next to writing unit and component tests, the programmer could already do some manual testing themselves based on these specifications, before leaving it to the tester to take a second critical look.

Not long after, we introduced automated GUI tests, on top of our unit and component tests. This did not only increase our test coverage, but also our confidence in that all features were tested well. As the automation frameworks took over the repetitive work of clicking through the GUI, the testers were able to do a smarter job, thinking about what should be tested exactly.

Read more