24 Apr 2015, 11:45 Projects IBM Design Thinking

Connecting low power Things to Bluemix

We have been working with IBM Research Zurich on integrating their Long-Range Signaling and Control (LRSC) platform into Bluemix. Based on the LoRa technology, LRSC allows very low power devices to communicate wirelessly over a range of several miles.

Sensors connect to a physical gateway device, which bridges between the LoRa wireless technology and standard IP networking. The gateway then connects to a centralised LRSC server, which manages the network. The server connects to our bridge, which then passes messages to the IBM Internet of Things Foundation (IoTF) service on Bluemix.

Messages appearing in IoTF from LRSC

IoTF makes it easy to access the sensor data from custom applications running on Bluemix. It provides an MQTT interface that allows a developer to subscribe to updates from any LRSC device, as well as to publish control messages down to the end device.

The Lamplighter demo application

To help us demonstrate the bridge, we have created a mobile web application that allows a street light installer to easily test a new street light in the field.

We used IBM’s Design Thinking process to create the following Minimum Viable Product:

As a Device Installer, I can test the end-to-end bi-directional operation of a newly installed device within a minute of installing it and without leaving its location.

We worked with our designers through a series of storyboards and low fidelity prototypes, which led to the following design for the user interface:

The Lamplighter User Interface

The sidebar is dynamically updated with any new devices that connect to LRSC. The device installer can then select the new device, send a test command to the device, and finally confirm its location on the map.

The application is deployed on Bluemix using the Ionic Framework for the front end, and Express.js running in the nodejs buildpack for the back end.

We use the IMST SK-iM880A kit for our test devices and the Kerlink LoRa IoT Station for our gateway.

Using the Bridge

The bridge code is available as a sample on github.

13 Mar 2015, 11:06 Agile XP IBM Design Thinking

Using Agile Methods in the Bluemix Garage

With the cloud technologies and platforms available today, we finally have the opportunity to build applications in an agile fashion, that in the past has been hindered by the inability of traditional platforms to accommodate change.

In the Bluemix Garage we offer clients the opportunity to experience various agile methods through a number of different engagement types, which attempt to take the most relevant aspects of these practices and employ them to rapidly achieve the outcome the client is looking for. Design Thinking and Extreme Programming have very different heritages and differing focuses, but they are highly complementary provided the terminologies are understood and the appropriate hand offs are managed. In this article we overview the two key methods we use in the Garage and discuss how they focus on different stages of the development process, and why we believe they represent a string combination for organisations to adopt when building out the new innovative applications they want to bring to the cloud.

Key concepts of IBM Design Thinking

Design Thinking is all about getting into the mindset of the end user. It starts in the Explore stage with a detailed examination of the user personas being targeted, even giving them names so that the team develop a strong empathy with them going forward.

The IBM Design Thinking framework encourages the use of design thinking methods to envision the user experience. Design thinking requires diverging on many possible solutions and converging on a focused direction. You will practice design thinking using four mental spaces: Understand users, Explore concepts, Prototype designs, and Evaluate with users and stakeholders. This work may be iterative or non-linear, and can be used whenever you need to push the experience forward, diverge, or check in with users.

In the Explore phase, the team develops ‘Hills’ which are a concise written statement of what the proposed solution will deliver to the target user, stating what they will be able to do in the imagined future, and why this will be on benefit to them. In the Prototype phase, the imagined future experience is developed through a set of increasing fidelity prototypes which are shown to Stakeholders and Expert users through ‘Playbacks’, so that the whole team moves forward together against a common view of what the solution will look and feel like to the user. In the Evaluate phase, measurements are made as to how successful the prototypes are in achieving the objectives stated in the Hills. Feedback is taken on board and used in the next refinement of the system. A design thinking team is multi-disciplinary, with Designers, Product Managers, Engineers, Stakeholders and Expert Users working together as tightly as possible.

In this way the whole team has a collective agreed view of what needs to be created, and everyone has a chance to bring their ideas & concerns to the table. Design Thinking is an excellent way of ensuring pre-conceptions of what needs to be done does not prevent the creative process from coming up with even better solutions, whilst focussing in strongly on delivering the stated benefits to end users.

Key concepts of Extreme Programming

Extreme Programming (XP) is a discipline of software development based on values of simplicity, communication, feedback, courage, and respect. It works by bringing the whole team together in the presence of simple practices, with enough feedback to enable the team to see where they are and to tune the practices to their unique situation.

XP is laser focussed on delivering the minimum amount of code to satisfy the acceptance criteria in a backlog of stories that the team have agreed represent a prioritised list of work that represents a minimum viable product.

XP requires that there is strong Product Management with a clear view of what is good and what is not, and a team of engineers who are able to work together very closely through the practice of Pair programming. All coding is done test first, with the tests being written to support the acceptance criteria and then the code being written to pass the tests. No additional code is written. XP relies on good communications, a willingness for all members of the team to go on a learning journey together with the courage to embrace change at all times.

A team practicing XP will recognise they need to change direction and then do it straight away rather than blindly continuing down the wrong alley. This is achieved through fast feedback loops that are enabled by co-located teams, delivering of working software at the end of every story and continuous integration through automated builds deploying to production. Technical debt is acknowledged openly and represented in the backlog by refactoring chores and bugs. The likely future delivery of functionality is defined by the past ‘velocity’ of the team projected through the estimated size of the stories remaining in the backlog.

Common Ground

IBM Design Thinking and XP share a number of common philosophies and practices. Probably the most important one is fast feedback loops, which is baked into XP through the process of story acceptance, stand up meetings, iteration planning meetings and demos. Design Thinking employs the process of regular playbacks and evaluation of prototypes to achieve the same thing. Both methodologies stress the importance of a committed, multi-disciplinary team, preferably co-located at all times as key to really making this work. Expert users and stakeholders are particularly key in Design Thinking whereas in XP the Product Manager is seen as the one to represent the interests of those parties.

Another key shared philosophy is that of Minimum Viable Product (MVP). Both approaches focus on delivering what the business has defined to be the most valuable functions, and anything that does not contribute to that value is either removed, or, most obviously in XP, highlighted as a ‘chore’ which may have to be done but will have a measurable cost against the delivery of the overall project.

Differences of Focus

XP absolutely requires that the Product Manager has a clear view of what needs to be done to meet the business need. If this is not the case then the project ‘inception’ should not go ahead. IBM Design Thinking is an approach that can be used much earlier in the innovation process. A problem may have been identified but the solution does not have to be clear for a Design Thinking session to go ahead - in fact it is often better if the team are not already over focused on a solution in order that some more outlandish ideas can be shared and potentially lead to a more radical end result than we previously imagined to come to the fore. XP, as the name suggests, has a strong focus on delivering working software. It’s not untypical for an XP project to be delivering working code on the day after the project inception, and because the team is working from a prioritised backlog, every accepted story should be delivering value.

Test Driven Development (TDD) ensures that only the code that is needed to satisfy the story is written, and no code is written without tests. Concepts such as continuous Integration, automated builds and blue/green deployment ensure that every new piece of code delivered makes its way into production through a standardised, repeatable process and any problems introduced are immediately flagged to the engineers who wrote the code so they can fix it or back it out. In this way, new function can be rapidly tried out by selected users and any modifications needed can be quickly identified and prioritised using bug reports or new stories in the backlog.

Design Thinking is much more focussed on the user experience, and therefore various techniques for avoiding writing code that doesn’t meet the requirements are employed instead of the XP approach of quickly producing something and then changing it. Low fidelity prototypes, sometimes created on paper, are used to facilitate early user testing, and then storyboards, wireframes and mockups can be used in subsequent playbacks before the engineers start writing any UI code. Of course this doesn’t mean that the engineers are not involved until late in the process - far from it. They should be part of the Design Thinking process right from the beginning so they can give their views on feasibility of the ideas being suggested, as well as providing ideas of their own. The engineers also need to identify any ‘technical foundation’ required to support the UI designs being created, and they may well decide to start building some of this underpinning before the final UI designs have been agreed.

Working Together

IBM Design Thinking and XP will be used in different doses in different projects, but there is a clear synergy between them which will be exploited in the IBM Bluemix Garage. By merging Design Thinking with XP, it should be possible to come up with highly innovative solutions to client problems, and to then very rapidly turn them into working systems to use as Proof of Concepts or even live production applications. The start point is to have a team assembled that has the right combination of disciplines either committed to the project, or easily accessible to the project team with the importance of the work to the business firmly agreed and prioritised for the key contributors. The engineers and product management must have day job time dedicated to the project, even if it is not 100% of that time. Design expertise also needs to be readily available, especially early on in the Design Thinking sessions, and then for performing the evaluation of user feedback in order to assess likely success of the solution and suggest refinements. Empowered stakeholders in the business, who ultimately will own the solution and reap its benefits need to be closely involved in the project, or prepared to delegate the responsibility to the product manager.

Even in the latter case, they should be regularly updated on progress and have opportunities to feedback through demos or access to early system deliveries. Expert users are also key. Ideally they are part of the project team, but if not they need to be identified and methods for engaging them regularly to get feedback worked out. In terms of the process itself, once the Design Thinking sessions have successfully completed a Hills Playback, it should be possible for the team to attempt an inception in order to identify the Activities, Stories and Risks that the XP process needs in order to produce a Pointed Prioritised Backlog for the engineers to start work from. The Hills themselves will have directly identified the Actors, but if not enough is understood yet about what needs to be built in order to do an inception then the team could continue with Design Thinking to get to the Playback Zero, where a low fidelity prototype should be available and a lot more detail have been thrashed out. Beyond this point it should be possible for working code based on agreed designs to start to be built, and for the project as a whole to be able to reduce the time between subsequent playbacks or maybe even the number of playbacks needed because XP is driving the production of working code at a much faster rate. Another side effect could be that more granular playbacks can be achieved, possibly even with the concept of ‘continuous playbacks’, because the XP process is able to deliver small increments of new capability against each Hill in turn without a large overhead in producing code releases.


It has always been a stated intention of the Bluemix Garage that we would use the disciplines of IBM Design Thinking and Extreme Programming to deliver rapid value to clients exploiting cloud technology centred on Bluemix. Having gained some experience of this through our early projects, and after engaging acknowledged experts in both philosophies to discuss the similarities and differences, it is only now we are starting to appreciate how the practicalities of this will work going forward.

The good news is that the assertions that IBM Design Thinking and Extreme Programming are complementary appears to be sound, and we can now look forward to taking these approaches forward into varied projects in the future and discover more about what the ‘Bluemix Garage Way’ should look like.


Thanks to Steve Haskey from the IBM Design team in Hursley and Colin Humphreys, CEO of CloudCredo for their engagement with this discussion and valuable views based on their vast experience of IBM Design Thinking and Extreme Programming, respectively.