Introducing the Tech blog, and Reminiscing on an Exciting Tech Past

First post! You have found your way to the Ixonos Tech blog, for which there has been great demand for a long time, and which is finally here. We work on really cool stuff at Ixonos you know, and that is why we eventually decided to open this window for our engineers and the internet audience to meet. As we begin, I’d like to reminisce on previous tech blogging ventures at Ixonos. The year was 2009, and a major internal project was underway. The publicity portion was a failure, but the subject matter was awe-inspiring. You can read some blog posts from that project here: secretlinuxmobile.blogspot.com. This project was done together with Fjord, a design company, and it was an awesome ride! The purpose was to build a complete Linux-based mobile phone software stack, spanning telephony integration using ofono, all the way to XML-based IPC mechanisms and a GUI framework based on Qt4. Back then we were still learning how to build graphical interfaces in an iterative agile working mode – together with graphics designers(!) – and learn we did!

Some of the key findings can be summed up by saying that good communication is 50% of a successful project of this kind. The importance of communication simply cannot be overemphasized.

The second key finding was that developer team members needed to be geared towards graphics design. Some were, some weren't. The words of my Scrumm Master trainer Jens Ostergaard come to mind: if there is a problem with the team, you may need to break the team up and build a new one - the heart of Scrum is the team!

Now years (and several GUI-related projects) later, the early learning experiences still resonate with a powerful and relevant message. Managing Agile (Scrum) teams needs to be a sober and serious undertaking, and when mixed with the challenge of having designers in the team just makes project management aspect more important. "Agile" doesn't mean easier, and it certainly doesn't mean a happy-go-lucky attitude of "let's see". Rather, the basic framework needs to be robust and rigid as ever. More on this later.

I have seen projects with "traditional" here-is-the-design-go-do-it approach, but more and more the industry takes flexible, agile working modes as a given. A software project then becomes a roller-coaster ride of constantly changing design specifications, that never are finalized, but nevertheless must be implemented! At best, this is super exciting and gives developers a chance to free their "inner graphics designer" and enjoy the creative flow. In a worst case this means a complete breakdown of understanding between designers who expect the impossible from software implementers, and developers who eventually grow bitter towards the fleeting designers who seem to be from a another planet.

And this can take serious forms. From developers who stop coming to work or who spend their days drinking coffee and watching YouTube videos, to designers who grow distant and don't even try to deliver that other version of a graphics asset, as requested by the ever annoying developer who seems to live in a cage of do's and don'ts of the technical world.

Solving real-life project management issues in design-oriented projects starts with a good project backlog. This is the most important place where designers, developers and product owner(s) can come together and speak the same language. If a product needs to have a clock, that is a goal everyone must understand. Other considerations are then the responsibility of respective teams or persons: the business perspective of what a user does with a clock, the developer perspective of which ntp system, caching mechanism and timezone setting to use, or the designer perspective of what the clock looks like. The whole team needs to be able to come together in a fireside chat sort of fashion just to get to know each other and get excited about the project goals.

A properly prioritized product backlog is not just an absolutely required prerequisite of going ahead with the development process in sprints, but also represents the most concrete projection of the project's vision. This is the place where every team member should feel excited and start dreaming about the project's final results: the product. Such team spirit-lifting is easy to overlook, but its impact is huge. The heart of Scrum is the team, and the team needs to feel they are a part of the greater project goals. This is the foundation of commitment and getting the best performance out of each individual.

Finally, to summarize, let me list a few guidelines from my experience on how to get a designer-engineer co-op project going smoothly. This is not comprehensive, but hopefully relevant to your particular needs today:

• Start by bringing everyone together around the product backlog, or if the backlog doesn't exist, involve everyone in the initial "casting the vision" phase. Everyone must feel included and important, otherwise a downhill spiral of resentments, internal hierarchies and bitterness begins.
• Create an environment of communication. I didn't say documentation, I said communication. And give freedom. Use Skype, Hipchat, Trello, Messenger / Lync, IRC, gmail chat etc. - do not stand in the way of whatever feels most comfortable for the team in the way of communication. As I said earlier, the importance of communication cannot be overstated. Big problems become small problems when you have help close at hand.
• Carefully build the product backlog, and revisit the priorities often during the first sprints of the project. In real life, priorities tend to be affected not only by the business value of features, but also by the technical effort (cost). As you involve developers and designers in this, you will learn what is easy for designers may be the hardest of all for developers. This is a highly iterative process, but eventually forms the backbone of a good project.
• Give power to the team. The developer team must have the power to decide how much is enough per sprint. And be careful to balance freedom with control, when inevitably the design team starts to request "extra" favors from the developers: this should be taken as a good sign that designers and developers are working together, but it is also a possible catastrophe brewing that results in the priorities being broken and work slowed down overall. This brings us to the final point...
• Decide early on in the project if designers and developers are one team or two teams. A highly iterative prototyping project will benefit from developers and designers sitting side-by-side with both instructing each other in what is possible the most effective way of working. But you can forget about development product and sprint backlogs when this happens. Some of the funnest projects I've been involved in have been of this kind, but if project goals are crystal clear at the beginning, you really want to maximise effectivenes and not go down this road. Only do this if design is completely unfinished for most of the project's duration. The important point to remember, is that if developers and designers are to be separate teams, then all the insulation principles of Scrum should apply to designers too, and that means no extra favors can be expected from the developers, and communication should be restricted to guiding implementation, not prototyping fun design ideas.

At the end of the day, we are (still) at the beginning of writing the folklore of the creative development process, and as such one should have a brave mind eager to try out new things. Technology has just recently started to reached the level where we are taking functionality for granted, and now also want a matching easy-to-use user interface. Design and Development is blending into a high-level creative playfulness, and project management needs to learn a bunch of new tricks.

Mikael Laine, SW Specialist - Ixonos