Friday, 15 May 2015

The Evolution of Development

I've seen a lot of change in my time working in IT. It's been a constant state of of evolution and improvement for as long as I can remember. Changes to coding practices, estimation techniques, methodologies, and many other things along the way.

The people that work in IT have also changed. They are no longer the stereotypical brains who have no people skills, but are in fact a group of highly intellectual people. They can solve almost any problem you can put in front of them, and they can also get up and speak in front of a room full of people.

These changes bring with them a culture of continual improvement, and it this culture which can ultimately drive a business to be successful. Embracing a culture of learning and improving is exactly what any eCommerce business should be doing, so to have a workforce that applies these same rules to themselves can only be a good thing.

Unfortunately, this culture needs to be business wide. You need everyone to be bought in. If this doesn't happen, then you will be limited what you can achieve as a business, and ultimately hindering your own success.

As a result of the changes in culture and working practice, IT has moved on from simply being a service to the rest of the business, now forming a core part of what any business wants to achieve. The current pinnacle of this evolution is the rise of the Product Team.

A true Product Team should have full ownership of the product(s) for which they are responsible. They should work collaboratively across the business, engaging with all of the people who have an interest or an idea for a products evolution. The team would ideally be built of people with a full range of cross cutting skills, enabling them to perform with autonomy. As I mentioned before, this requires change at the business level. If this approach is only partially adopted, the result is most likely going to be frustrating for all involved.

So - how do we tackle this problem? The obvious answer is to adopt a culture as a business. But what if this just isn't happening?

Historically, businesses saw IT as a service. People would come to them and tell them what they wanted and when they wanted it by. This has been proven to not work, and is a large catalyst to all of the changes I have talked about so far. So, with the advent of the product team and working towards realistic targets using data - maybe the shoe should now be on the other foot?

Obviously it would be much better if a company could all have the same culture and values throughout its departments. Even better if people stop siloing themselves off in to "departments" and just get involved as a single team. However, if this isn't the case - and experience tells me that in most cases it isn't - then we need to have another option.

How would the other areas of a business like to be treated as a service? The product teams are closest to the products. They have the understanding, the experience, and the data to back up all of the decisions that they make. If other departments don't want to be progressive and improve and work as a part a team, maybe it is time that they be a service to the product teams instead?


Friday, 17 January 2014

Working With Geographically Distributed Teams

For the past number of months I have been running a project to develop a new range of apps. As a part of this I have had to face a number of challenges, the biggest of which is how to manage a number teams that located in different parts of the world. With us all working towards the same goal and on the same code base, communication is key. The intent of this post is to share some of the (sometimes obvious) ways in which to get around the problem and run a project where people can be scattered around the world.
To begin with, I feel that there are 4 main areas on which to focus. These are People, Process, Tools, and Cadence.

The most important thing to remember when working in this way is that everyone involved is still a person. Nothing beats that interaction when it comes to helping your project to progress at the desired rate.

When choosing your tools & processes, you should remember this. Anything that helps your team feel more real and together will be of benefit here.

People tend to forget parts of the process when working in this way. Make sure you follow the normal patterns;
  • Daily Standup
  • Tech Huddles
  • Sprint Reviews/Demos
  • Retrospectives
  • Scrum Boards
  • Burn up/down charts
  • Reporting

There are some great tools around to help us work collaboratively across geographically distributed locations.
  • Google Hangouts/Docs
  • Skype
  • Basecamp
  • Campfire

There are also tools which will help you to follow your particular processes across different locations.
  • JIRA
  • Leankit

With all of the above, it is of paramount importance that you keep up the cadence. It is much more of a challenge to get this to work smoothly with people in different locations. Ideally you would have someone responsible for this in each location to help facilitate and engender this behaviour. Once it sets in, all of the above will contribute hugely to your project being successful.

Other Stuff
There are other things that can be done to help ensure that your projects like this are successful;
  • Meet face to face regularly. All the tools in the world cannot replace this
  • Pick up the phone. It's much better to speak to the person at the other end rather than playing email tennis
  • Take advantage of technology. Don't be restricted to the above if you find something that can help.

For more details feel free to look at the document here

Monday, 8 July 2013

Empowerment - Helping Your Teams to Succeed

I had a bit of a disagreement recently when it came to what a particular product team should be "called". Whilst this might seem a bit small in the grand scheme of things, I think that the importance of a team having its own identity should not be underestimated.

It boils down to a simple level of trust and true empowerment of a team. Allowing the team to decide what their identity will be is the first step. In some cases - actually allowing teams to choose themselves is an even more powerful and effective way of instigating such a change, as explained here.

It takes a lot more than the above to create an awesome working environment, but we all have to start somewhere, and the above is a great way to get started. Below are just a few examples of some other ways to improve your working environment and get the most out of your product teams.

  • Set the goal, let the team come up with how they will achieve it.
  • Trust your teams to self manage and organise, they want to succeed just as much as you do.
  • Provide time for your teams to learn. Google have a 20 percent rule where employees can work on their own special projects. That's 1 day per week - think of the positive impact on morale.
  • Avoid micro-management at all costs. An empowered employee/team does not need to be told what to do every 5 minutes.
  • Allow the team to fail, failure is the quickest way anyone can learn, as long as you take the time to learn from your mistakes.
  • Have clear priorities. We all know that things change quickly, but if you never see a project through to completion - how can you expect your teams to be enthused about doing it?
  • Leave the old "I must have everything" mentality in the past where it belongs. If 20% of the work delivers 80% of the value, why do the rest?
  • Don't adopt an approach that dictates that just because you can buy something off the shelf you should. This type of approach, whilst on the surface will give the teams more time to focus on things where they can be innovative, it in fact stifles the innovation as it adds constraints to what the teams can actually do.

The benefits of this kind of working environment are quite simply astounding. By showing this level of trust and empowerment, the teams will be more bought in to what they are doing, be proud and enthusiastic about their work. Innovation will flourish, and your company as a whole will benefit. A happy and positive environment for your development teams will not only be good for the people working directly in or with those teams, but actually for the business as a whole. This becomes more and more obvious as technology plays an every increasing role within business. In a world where being innovative can be the difference between your company remaining competitive or failing, this is the best opportunity you have to ensure you succeed. It is not an easy task as all of the above requires a shift in mindset from the entire business, but if you want survive, you don't really have a choice.

So, in conclusion, and to complete the circle - whilst having a disagreement over the naming of a product team on the face of it appears to be a very small thing - the level of impact it could potentially have on the product team and business as a whole was profound. Never underestimate the power of the finer details.

Wednesday, 29 May 2013

Organisational Structure: Product Teams

There are two ways of running your organisation. The more common of the two is to do some form of project-based planning. In this model, the management of the company defines the roadmap – they come up with a prioritised set of projects and allocates time and people to them. For example, they may decide that a team will spend two months on some new search functionality. The team will likely not change, but the project and domain typically changes frequently. If you were to look at this roadmap, you would see different projects typically with rows per team and projects “assigned” to them.

Due to the nature of software engineering, it is rare that a week goes by without this roadmap changing significantly. New business opportunities come along, priorities change, and the plans have to change accordingly. Alternatively a project will take longer than anticipated so all subsequently planned work has to get pushed back.

These roadmaps are usually filled with an abundance of assumptions, and are typically created without any solid information or knowledge of what needs to be done or how much it will cost. This often results in the plan never being truly realised. This can be a massive source of frustration for businesses and development teams alike. These assumptions are often made from people outside of the teams and are done in a very dictatorial way, which can quite easily and effectively quash both innovation and collaboration.

The alternative to the above is to move across to a product team based organisation. This is the way forward, and an option that companies are increasingly turning to in order to try and improve how they develop their products.

In this model, the focus is instead around which areas of the business the company wants to invest in. This removes the focus on projects and instead allows each product team to be able to focus on what is best for it. It is important that the product teams are given space and freedom in order to innovate and collaborate effectively. This means that the business should present a problem to the relevant team, and allow them to come up with the solution.

The teams should be cross functional, composed of members who are capable of carrying out any and all of the tasks that may arise. Over time they will develop a deep understanding of the domain of their product, meaning that the longer they are kept together on the same product, the more efficient they will be become. Tie this in with the concept of continual improvement and you have a recipe for success.

Making It Work

There are a number of key points that I would advise you to follow if you truly want to make the move to product focussed development teams a success.
  • Do not prescribe a solution to a product team, give them the problem you are trying to solve and work with them to come up with the best solution
  • Resist the urge to be dictatorial and tell people what to do. This quashes innovation and collaboration
  • Allow the product managers to be fully accountable and responsible for what happens in their product. Give them steer in order to ensure they are working towards the overall company objectives, but allow them to decide how they will get there
  • Give everyone an equal voice – collaboration is key to success
  • Limit the amount of people involved in making decisions. The more people involved, the more painful and difficult the process of agreeing a way forward
  • Agree on a scorecard for giving backlog items, which will effectively highlight which work will give the biggest ROI
  • Do not follow ‘Agile’ like a religion. Every company is different, and whilst the core message will be the same for everyone, the best way to implement this will vary

Monday, 29 April 2013

The Mobile Age

With the whole world moving into the mobile age and more and more devices connected to the internet, it seems a very logical step that companies want to increase their "mobile presence". To me, this brings about a whole raft of questions and challenges around development. With this being a fairly new area, and with such a range of devices available - the biggest questions is where do you start?

The two big players in the market today are Apple and Android. If all else fails, you need to have something to offer these two or you may as well not try. Then you have to ask yourself if you should invest in the BlackBerry and/or Windows Phone markets - hopefully a decision that will be answered through the use of stats. Smartphones are still the device to target first, with it being blatantly obvious that far more people have these than tablets.

Then comes the question of approach. Do you develop native apps? Do you use a platform, such as Titanium, Xamarin, KonyOne... The list is endless.

I am of the opinion that developing native apps is the way forward (at the moment at least), getting full access to all of a devices capabilities in order to deliver the best user experience possible. I expect given time this may change, and as the single platform development space evolves, there may well be a shift across.

I make no claims to knowing all there is to know when it comes to these things, but it is an area in which I have a great deal of interest. I would love to hear your ideas and opinions on how to tackle the challenges of mobile, your suggestions on technology approach, and if possible learn from your experiences. Feel free to message me directly or drop a comment below.


Friday, 22 March 2013

Perception - How Do We Change It

Last year I posted an article around the power of perception and how this can have such an influence on the way people will interact and treat you in the work place. I have since spoken to a lot of people who read the article and seen the many different ways in which it can affect them.

Perception can work in many ways, and it is unfortunately true that first impressions tend to stick. From the person that wears a suit to try and appear more important in his new job, to the guy who joined as a junior 4 years ago and always had fun. It's something that in most company's will stick with you. Once someone has this perception of you, it is quite a challenge to get it changed.

I wanted to start a discussion around ways in which we can try to change the way in which people judge people. I don't believe that people should be judged on anything other than what they do. Not what they wear, who they know, or might have done 3 years ago. As people work they learn, and they progress as people. I believe it is this inherent problem with perception that leads to a lot of people leaving the companies that they work for. The perceptions they gain during their early days stick with them, and for many the easiest way to change the situation is to go somewhere new so that new people can get a new impression and therefore perception of you.

This is a challenge that all companies face, as it is down to the culture of the business and how they reward their staff, recognising their achievements and acknowledging their progress that has the biggest influence over this.

So what are the other options to try and change someones perception of you? What have you done in the past? Did it work? What didn't work? I would love to hear some feedback on this one.

Thursday, 21 February 2013

Agile, it's a funny old word.

It seems to be a common theme in the development world today about being "agile". With recruiters reporting that this "skill" is fast approaching the point where it will take over from "HTML" on developers CV's, the word "agile" is now losing its value. The meaning behind it is being lost to the realms of the buzzword, and as a result it is becoming harder to find the people who truly understand what we mean when we say it.

So what do we really mean by "agile"? This is a question that tends to be asked in interviews, and is greeted by a whole array answers. What we want to hear about is a passion to deliver value faster, incrementally, and collaboratively with the business. We want to hear about minimal marketable features, breaking down work into small chunks and regular releases. We want work to flow through the team via a pull methodology rather than it being pushed into the pipe.

The bottom line of it all is that 'agile' is just a word. It is all about the way you work and how you go about doing things on a day to day basis. To me, a lot of what 'agile' preaches is just common sense. It doesn't need to be badged up as some kind of buzzword, or worshiped as some kind of religion.

Its not just IT, but the whole business that needs to adopt these working practices in order for them to work. It requires a change in mind set, to put trust in the development teams and how they work. Despite common views, developers are just as committed to delivering value as anyone else in the business. They need the support and environment in order to do this the best way possible.

I have often seen departments suffer from "us and them" syndrome. This cannot be the case if you truly want to be a value driven business. These walls need to be knocked down and everyone needs to wake up and smell the coffee and realise that everyone is in this together. Once you reach this point, and everyone starts to work together - that is when you can really start to deliver. End to end delivery teams, responsible for taking an idea from inception to delivery. Quick and responsive feedback loops between the people doing the code and the people driving the ideas. Collaboration and taking everyone's views and inputs to a solution in to consideration in order to get the best possible result. This is the world I want to live in.

The bottom line, ladies and gentlemen, is that we should not get hung up on words or the latest craze - but we should strive to continually improve and take the best common sense approach when developing software.