Mobilizing Your Enterprise – Part III: Making It Happen

Written by Jesse Beaumont

In part 1 and part 2 of this series we looked at some high level strategies for enterprise mobility and some of the key differentiators from traditional enterprise software development. In this final part, I’d like to get down to some practical suggestions on ways to approach mobile application development as an organization which address some of the things we discussed in previous posts.

A Word of Caution

Every organization is different and it would be ludicrous to suggest that what I’ve offered here is a comprehensive set of tools to succeed with mobile application development. It’s not comprehensive and it’s not fool proof. The unfortunate reality is that there is no one-size-fits-all, silver bullet. That’s also the reason this is part 3 rather than part 1 of this series. I’m a firm believer in common sense, and as long as you understand the basic drivers for why you’re doing what you’re doing, and what the important aspects to pay attention to are, you’re already in a much stronger position. Nevertheless, this post contains some elements that we have identified in consultancy projects at ShinobiControls, through working with our customers, and which we have used for our own internal development, which have proven to be very successful. I hope that they will be useful to you as well. I cover a lot of ground here so if anything is unclear or incomplete I do apologize in advance, please don’t hesitate to leave a comment and I can get back to you on your questions.

A Different World

Mobile development is different from traditional enterprise software development in that it must be much more user oriented and expectation levels are very different. The thing I didn’t mention previously, which I think is extremely important, is that the pace is much, much greater in mobile development. This is a result of the fact that the entire mobile world is moving much more rapidly and so user expectations and the state of the art is catapulting forward at a great rate of knots. If you rely on the pace of traditional enterprise development, you’re always going to be lagging behind and will not live up to expectations.

Around the User

We’re going to have to involve the user, based on our previous discussions. We also know we’re going to have to move faster. The question is: How? Here are a few of the factors that we’ve found to be most beneficial to increasing speed and making the process more user oriented.

Agile Thinking

In our experience, the term “agile software development” is fairly common, but also commonly misunderstood and misapplied. Agile development is a mindset and approach centered around the notion that requirements change. It is not a procedural set of steps or rules to be adhered to.

Agile Thinking

Agile software development has been around in spirit for a long time now and generally software development teams are aware of the concept and apply at least some aspects of agile in most projects. All too often, though, it seems that teams get bogged down in the process of agile and lose sight of the wider mindset.  However, it’s the mindset that is the real game changer.

Agile development is a mindset required to be adopted by both the engineering team and the organization around them for it to really work well. Any process, whether it’s Kanban or Scrum or XP, is simply there to support the mindset, not vice versa.

I don’t want to give a big lecture on agile development, there is so much written about it already, but the Agile Manifesto is as good a place to start as any because it describes this approach and mindset. I would strongly encourage everyone involved in a mobile software development project, from user to stakeholder to developer, project manager, product manager and beyond to read that page and try and get familiar with the fundamental principles of agile development and internalize those. It can seem scary to work in that way for people who are used to operating in a more structured, process driven environment, but there is plenty of evidence on a wide variety of projects that agile development, when done right, is both faster and more reliable than its more traditional counterparts (for example).

In the context of our world of mobile enterprise development, being accommodating and receptive to change is a key focus. It allows your users to directly influence the course of the project as you’re building. You’re inviting them to get involved and you can allow their views to influence the direction as early as the next iteration, meaning they can have the results in their hands within weeks. That improves user buy-in, because they are actively involved in shaping the results and it helps make sure that the end result meets their actual expectations and requirements, not the expectations and requirements they articulated on day 1 of the project before they had anything to visualize how it would work. That’s a huge win for you and them. Not to mention that agile development has a very good track record of delivering results faster which is very much in keeping with the need for speed on mobile projects.

One point worth re-emphasising is that the agile mindset applies to more than just the development team. You need the stakeholders on all sides to be adjusting their expectations to an agile world for it to bear the greatest possible fruits for your organization. The more you can do to get everyone thinking along agile lines, the better your experience of it will be and as evidenced above, the empirical evidence suggests it works when done right. It’s also worth noting that increasingly, agile principles are being applied to more than just software development. Marketing and sales, product management and product support activities can be thought of in agile terms too!

UX Design and User-Oriented Development

One of the techniques we use here at ShinobiControls is what we refer to as User-Oriented Development. That is a term that we use to describe the melding of User Experience (UX) design and software development disciplines.

User-Oriented Development

UX Design is a relatively new field, in its current incarnation. It’s born out of fields such as information design, human computer interaction, usability and interaction design amongst others. UX Design is the process of optimising a user’s experience of a product or service. The results can be very significant indeed. This is true both in terms of the user’s perception of your product and also in terms of how well the product meets your business’ needs by making it easy for the user to achieve what you want them to be able to achieve.

The issue is that with UX design being a new field it is still unclear how to best integrate this new domain into the software development lifecycle. Not to mention that expert UX designers are still comparatively few and far between. Many of the organizations we work with don’t have access to a lot of the skills and theoretical knowledge required to get the most out of UX design. This is especially so in the mobile space where the “rules” governing user experience are still being written.

The UX Champion

The key principle in making User-Oriented Development work is to be “UX led” in your project. That means, let the user experience drive what you do and how you do it. This is not to say that the user experience must take precedence in all cases. You need to factor in both what the user needs out of a product as well as what the product and the business needs out of a user but let the user needs lead the way because they tend to get forgotten otherwise.

To allow for this we advocate nominating a UX champion. Where you have a UX designer or designers in your team, they are the obvious candidate for this role, as they can bring their theoretical knowledge and design skills to bear as well. However, if you don’t have the luxury of a skilled UX designer, simply asking someone to don a UX “hat” is already a huge step in the right direction. The job of the UX champion is to protect and defend the user experience (and therefore the user) in the project. Toward this end it can be useful for them to not have intimate technical knowledge of the project, so project managers, stakeholders, designers or testers are great candidates for the role. Even if you don’t have UX skills, a healthy dose of common sense and a purely user-oriented perspective will do your project a great deal of good.

The Steps

In a UX led, User-Oriented Development project, the first task is to ascertain the needs of the users and the business. At ShinobiControls, we generally do this by conducting a UX workshop. These are facilitated brainstorming sessions attended by stakeholders in the project to identify some key information about who the users are, what they want, what motivates them and what need we’re trying to fulfil with the project. The outcomes from these workshops will vary based on who your UX champion is, but you should come away with a clear idea of the answers to those questions. If run by an experienced UX designer, you might come away with some user personas, an information architecture for your project and possibly even some wireframes or visual mock-ups of how it might look as well.

Once you have that information, we have found it very useful to ask developers to go and do independent research into a product and its UX implications. They go away and look up examples of similar products, think about the user requirements and how the users might view the product. The key here is that they go away and think about the product without thinking about code or any sort of implementation detail. Engineers often have a tendency to dive straight into thinking about how to implement something rather than what to implement. That isn’t wrong, but it only works well if someone else is thinking very careful about what it is they should build. This research phase, which can last anywhere from a couple hours to a few days, just gets them out of that mindset and into thinking about what product should do. We’ve found our developers tend to really enjoy the process and get quite invested in the user side of the project, which is a good thing for everyone. The idea is that the UX champion is then responsible for taking on board all of this research and incorporating it into the UX thinking, meaning they don’t need to do all the research themselves and have the benefit of additional points of view.

Once you’re into designing and writing code it’s important to deliver prototypes and early versions of the product very quickly. This is really an agile concept and is fairly common. In this case, the UX champion at least, however, should be intimately involved in the development throughout. Often we find it useful to have the UX champion and the developers operating in a “pair programming” type environment or at least sitting together on a daily basis to review progress and make changes. It’s essential to build something and get it into a user or the UX champion’s hands (or ideally both) as soon as you can and start getting their feedback. Then iterate as quickly as you can and keep getting feedback. You don’t have to wait for sprint demos – they’re more for the project stakeholders. Behaviour and aesthetics are very difficult to express in written form, it’s much easier to have a rich dialogue based on evolving samples. This, more than anything else, has shown itself to be a big winner for us at ShinobiControls.

Most importantly our User-Oriented Development approach maintains the user at the center of focus and makes sure they are represented fully in the project’s delivery throughout its lifecycle. If you’d like to find out more about User-Oriented Development, or would like help running your first UX led workshop, please do get in touch.

Avoid Silos

Traditionally, corporate structures are often organized into functional silos. There will be a development department, the design team, the database team, the server team, the admin team, the project management office, and so on. This is to the detriment of user involvement.


Building these silos makes a lot of sense from a management point of view, but from a software development point of view, and particularly from a user involvement and User-Oriented Development point of view, it’s not ideal. What happens is that you are constantly handing the work, and the user, off between different silos as the project moves from one skills requirement to another, or even worse, you’ve got lots of people independently talking to the user without talking to each other. Silos hinder collaboration and they hinder user involvement. Finding a way to break down these silos can really improve the productivity and success of your projects.

Many organizations are now building project teams, which are fully cross-functional teams of people who bring all the requisite skills with them, from user experience design to development, management, marketing and sales and after-care. That group of people are often physically co-located and actively collaborating throughout the lifetime of the project which cuts down on administrative and communication overheads and happily makes it much easier for users to remain involved, since everyone is right there in the same place and on the same page.

If you have a silo based organizational structure, I would advise formulating a temporary project team to see how it works for you.

The Rise of the Polymath

One thing I’ve noticed, especially in larger organizations, is the reluctance to allow individuals to apply all of their talents. There are great efficiency gains to be had by allowing your team members to bring all of their skills to bear on a problem, be it developers who also have design skills or UX designers with some project management know-how. These polymaths are rare gems and if you have them, it’s a great waste to not make it as easy as possible for them to use that to your advantage. Not only does it add to your team’s flexibility but it cuts down greatly on the communication overheads you encounter. What better way to reduce the amount of explanation required than to have it all happen inside a single person’s head?

Of course, there are limits to the value of this. There is something to be said for depth of expertise over breadth and there is danger in letting someone forge ahead on their own without needing to involve others. It needs to be managed, but it’s worth spending time figuring out how to enable this to happen in your teams. Removing silos as discussed above will go a long way, as will fostering a generally collaborative environment within your team and organization. Nevertheless, it’s worth being aware of this as an issue and a potential source of an easy win.

Finding Skills and Talent

The hardest part in any business, is finding good people. It’s also, alas, the most direct route to success. If you have good people working for and with you, you’re maximising the potential for success. The problem is that finding and keeping them is hard.

Especially in an emerging field like mobile development, with all its new skills requirements such as UX design and resource constrained software development and agile, user involved development processes, the need to get users excited about a project and all the other stuff I’ve been writing about, the talent pools are much more shallow than in established domains. Add to that, that the growth in these areas is extreme and it makes for a very competitive, not to mention expensive, market to be looking for talent.

The bottom line, though, is that it is a necessity if you want to build great mobile products. You simply have to have excellent skills. Of course, skills development and talent management is worthy of a book all on its own (and many of these already exist out there) so I’m not going to pretend that I can give you a sound bite to solve all your problems here.

The best I can offer is this:

  1. Make people a priority. If you respect and value them they will respond in kind and that’s important because the success of your business depends on them.
  2. More often than not, the best people are the ones who love what they do, so give them an environment in which they can continue to love it. The corporate environment has a stigma of being full of red-tape and inertia. Some of that is necessary to run an enterprise of scale, but protect the passion and creativity of your team.
  3. Engage with the talent communities both as a way of scoping out people’s competence and as a way of promoting your business. Open source projects, online communities, hackathons, developer events and meetups are all great places to find smart, talented people.

Finally, if you can’t find the talent to hire, find a partner to work with. There are plenty of top notch consultancies who offer the skills, talents and expertise to be able to help your business. It’s a great way to get access to all the skills you need in one place. Even better, many of these places will be more than happy to help transfer some of that knowledge into your organization as part of the project, so it’s a great way to get on top of the learning curve quickly.

A Final Note

That brings us to the end of this series. As I said right at the start, I’m neither suggesting that I am dropping unique knowledge bombs on you, nor am I pretending to have all the answers. This series was just a high level, mostly common sense, overview of what our experience has been in riding this technology wave we call mobile. To us, it’s all about the user and shaping yourself and your team and thinking around servicing the user. I’m very conscious that we’ve only briefly touched on some areas and I’m sure there are things I’ve omitted entirely. If there are subjects that you’d like to learn more about, you have follow up questions or if you disagree with something I’ve said, by all means drop me a line or leave a comment, I’d love to hear from you.

And if there is something you think we can help with, either through our products, our development or design services or in an advisory capacity, just get in touch and we’ll be happy to jump on a call to discuss further.