Technology Radar for 2015

With 2014 drawing to a close and 2015 offering fresh opportunities it is up to every software development professional to look at the up and coming technologies which are becoming widely adopted. ThoughtWorks have released their technology radar for 2015 with a list of techniques, tools, platforms, languages and frameworks to either adopt, trial, assess or avoid in the coming year. This is well worth a read - I have to say there were quite a few which I hadn't looked at before - a prompt reminder of how quick it is to fall behind in this profession.

Here's my two tips for 2015 - the top technologies to either adopt or trial in any new projects you are working on.

AngularJS
AngularJS is an excellent JavaScript framework which when used effectively allows you to structure your code to make complex web applications easily maintainable, and promotes code re-use. While the latest version (1.3) is extensively used in both small and major projects across the world, the AngularJS team are working on a re-write for version 2 in order to address some potential performance problems. The bad news is that version 2 is not a simple upgrade and will require people to re-write their apps. However, it is unlikely that projects started in 1.3 will need to upgrade - 1.3 is perfectly sufficient. Anyone starting a new project should consider closely whether they should start with version 2.

Docker
Docker has exploded onto the scene this year with people utilizing docker in both development environments and now production environments. Docker describe the product as follows:

"Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud."

With Microsoft working on supporting docker in the next version of windows server I think it's fair to say Docker is a major player in the fast moving software container field.

I'd be delighted to hear what technologies you tip to be big in 2015 - have a great new year!

Tutorial: Create great icons with Syncfusion Metro Studio

A key part of any website, desktop or mobile application is icons. These tiny little images can really bring your project to life and improve the look and feel of your apps. Choosing the wrong icon can have a huge impact on the usability of your application. I found creating or finding icons for my projects could be a real time waster - until I found Syncfusion's free desktop application - Metro Studio.

Metro Studio comes with over 4000 pre-made icons which you can customize to meet your needs - change the colors, change the size and export them to any format you want. Here's a quick run through of how to use Metro Studio.

When you open the application you will be shown a list of available icons to choose from:

Here you can browse by category and the search feature is great - finding similar icons. Lets assume we want a shopping basket and we select that icon:

The icon is shown (and defaults to your last configuration - so you can maintain color consistency). On the right hand side there are options for shape, size, transparency, rotation and color.

You can also create a project and edit multiple icons at once, great if using icons for buttons to ensure consistent styling.

There are various export formats for example bitmap, ico and png. A great tool to prevent stalling applications.

Situational Leadership in Agile

For anyone line managing as well as performing technical leadership, the term situational leadership may have come up in an HR lecture you really don't care about! Join the club.

However, this was once explained to me in terms that really struck home to me and is something that I have learned the hard way in my teams.

Agile works because the team is empowered to succeed - to a certain degree a lot of responsibility is delegated onto the team.

Situational leadership is the theory that there is no right way to manage - but effective leaders effectively bounce between styles. The styles are:

• Telling/directing - the leader tells subordinates what to do.
• Selling/coaching - the leader sells an idea so that subordinates will do it.
• Participating/supporting - the leader will work with subordinates to get the desired outcome.
• Delegating - subordinates are essentially able to pick up the work themselves. 

At its most effective, Agile works when most of the team are at the delegation stage. The team responds well to the responsibility and will work efficiently and take ownership of their tasks. This however can cause conflicts when the leader suddenly treats subordinates at the tell or sell stage. Why does he/she no longer trust us to do this work? 

This can usually be explained as either of the following reasons:

1. The work is urgent and the leader needs to get involved closely to ensure it is done.
2. The work is new or a change in direction in the team, and the leader needs to explain to the team why we need to make the changes. 

What I have learned the hard way is that you need to explain to your team this model so they understand why you are no longer delegating this specific task. If you can explain to the team you are currently at the stage where you need to tell for some reason, explain you are in the tell stage, why, and that normal service will be resumed soon and it will switch back to delegate. I find teams respond well to this and it removes any tension or hurt feelings in the team. 

Another thing that it's vital to remember as the team are acting in the delegate stage is that ultimately you are responsible. This means that even though you trust them to do the work, you need to take responsibility for it and that to do that you need them to report back with what they are doing and why decisions are made. Explain the situational leadership model to them and they will appreciate this. Reporting back to you helps you defend their decisions if they are questioned. 

The Tannenbaum and Schmidt's leadership model is a slightly different visualization of situational leadership but it explains the delegation/responsibility issue above really well.

Note that in the top right, the line never reaches the top right. That is because no matter how much you delegate, you as the leader/scrum-master/development manager are always responsible. Again explain this to the team and it will help resolve any conflicts.

Continuous integration is the key!

Continuous integration (CI) is a key component of any successful software development team - not just an agile team. Doing it right will bring the following benefits to your team:

• Provide automated builds of software for testers to pick up. 
• A common, repeatable platform to run tests (unit, integration, automated functional and performance tests).
• A place to run code quality tools (SonarQube, FxCop, StyleCop, JSHint etc)
• A place to create production build installers. 

There are various great tools for setting up continuous integration and you should spend time evaluating what will be best for your project. My personal favorites are: 

• Jenkins
• CruiseControl

It is imperative that an agile team devotes time early in their project to get their continuous integration system up and running early (sprint 1 or 2) to ensure they have a solid platform to run on. Ideally your continuous integration will run on every commit into your source control system so that the team gets immediate feedback - have the changes compiled, have the tests run, is the code quality good. In the past in teams I have configured our continuous integration system to play a siren out loud in the office if the build has broken. The public nature of a central build location ensures extra care is taken by each team member when submitting their changes. 

For continuous integration you will need the following infrastructure at a minimum:

• A server for builds, running the tests etc. 
• A source control system (e.g. GIT, SVN, CVS)

For larger projects you may scale this up to have multiple agents running builds and tests. 

A common mistake teams make when creating their CI system is to not share knowledge of its workings with enough team members. Ideally everyone needs to know how it works - from developers to testers. These things need maintenance now and again and you want to spread the load, and have multiple people who can pick up the task. 

Once your continuous integration environment is setup and successful, you then need to look at automatic deployment - I'll write a future blog for this. Automated or continuous deployment is the next logical extension of your CI environment where you automatically build a new version of the system for test purposes perhaps or even automatically updating your production environment depending on your project.  Again with a little up front effort, the long term benefits can be huge!

The scrum meeting - some quick tips.

The scrum meeting is the key meeting in agile - it promotes communication and resolving issues and is very effective. Everyone does the scrum meeting slightly differently but the basic principle is that each team member answers the following three questions:

1. What did you do yesterday?
2. What are you working on today?
3. Are there any blocks or impediments in your way? 

This is a very simple format which works great. However, it's important that you experiment with your team to get a system which works best for you. I find that I typically make the following tweaks with my teams:

• I only run them every other day rather than every day - so Monday, Wednesday and Friday. This allows for work from home days (which I standardize as Tuesday or Thursday) to get maximum time in the office together. Daily scrums tend to feel like too much. 
• The time for the scrum is the same every time - and it's first thing in the morning! Nobody like the morning, but I find it helps the team get focused on their tasks for the day ahead. 
• As scrum-master I start the meeting outlining the teams short term objectives (what are we aiming for this sprint). I find this really focuses the team. 
• Keep it short. Depending on team size (my teams range from 6-12 people usually) this should be at most 15 mins, but can be completed in under ten minutes. 

Please experiment and ask your team their preferences. If the team contribute to the processes the team undertake then they will buy into what you are trying to achieve. Empowerment is key! 

The first key to agile success - get rid of offices!

If you are new to agile there is one simple change that you NEED to make before you even read up on anything else. Sprints, retrospectives, scrum-masters can all wait - you will instantly improve your development teams productivity by changing your office to open plan with your team co-located. 

Why is co-location so important? 

1. Communication is easier. People talking to each other to work through problems is the quickest way to resolve blocks. I see it all the time, developers talking to developers, developers talking to testers, testers talking to product management etc. I've yet to experience a major block which hasn't been resolved within a day and that is due to people simply talking to each other. 
2. Communication is faster - who you need to speak to is right there next to you.
3. Agile is about working as a team, and for a team to work well you need to feel like a team. Co-location helps improve team spirit, keeps people in the loop as they can hear what is going on, and all this helps to increase each team members empowerment. People being empowered in an agile team is the key to success. Remember all the key stakeholders when co-locating - developers, testers, technical writers, product management, project management... 
4. Peer reviews are instantaneous. Regularly developers will gather round a monitor to review code, and testers sit with developers to talk through latest changes and any issues found. This speeds up development dramatically. 

This simple change can be complex for some teams - you may be an international team, need to re-shuffle other teams to get the space or may need to re-organize your full organization - but if you want an efficient team this is the place to start!