For Jagdeep Singh,head of software development at the Financial Times,agile programming is less about formal development techniques and more a way of modern business life.
In the fast-moving world of the media,development teams have to respond quickly,according to Singh."You have a tiny window.You need to be there,very quick,and very agile–and I am talking from a business perspective,as well as a technology perspective,"he said.
The FT has grown up through acquisitions over time.This has left it with a"hodge-podge"of technologies,processes and methodologies,he told a meeting of Computer Weekly's 500 Club.
So while some development teams struggle with the agile philosophy,others behave in a very agile way,even without formal agile methodologies.
"They can get something done very quickly.Information is shared across the team,and it's very agile,without any kind of scrum or Kanban,so it's agile in the purest sense,"he said.
Agile development as a philosophy
For Singh,agile should be a philosophy,rather than a prescriptive software methodology.Doing scrum by the book actually makes you less agile,he said.
The FT's software development team uses a variety of approaches,depending on the nature of the project.For example,developers are using Japanese Kanban techniques to manage a project to improve search and discovery.
In its simplest form,Kanban uses cards or Post-It notes on a board to represent each job.The process makes the work,and the interdependencies between jobs,visible.
Ultimately,it's a quick way of identifying bottlenecks,allowing both the business team and the development team to see where the project is at a glance,said Singh.
Combining development techniques
The FT has taken a different approach with a digital publishing project,run by a team of 30 developers based in Romania and Milan.
In this case,the newspaper is using a blend of different software methodologies,taking parts from Kanban,agile,and extreme programming.
The combination gives the developers flexibility,while still allowing managers to track the progress of the project.
"It is basically risk assurance for the business,so we are working to some sort of process that they can track and monitor,"said Singh.
Selling techniques such as Kanban to the rest of the FT business can be a challenge.Some product owners are more comfortable with scrum than Kanban,and they need winning over,according to Singh.
He pointed out that businesses can implement technology quickly,but implementing different cultures and thinking can take more time.
Agile programming at The LateRooms Group
As a young company,The LateRooms Group has been able to adopt agile programming techniques without having to worry too much about maintaining legacy systems.
Nevertheless,the company's programming team has to work quickly just to stand still,according to Dave Heath(pictured left),head of software development at the travel group.
"It's amazing how quickly it goes stale.So you are always trying to play catch-up,"he said.
The company has grown rapidly since Heath joined eight years ago,expanding from a turnover of£12m to£500m,and growing its IT team from four to 70 people.
Approaches to code development
During that time,Heath and his team have tried several different approaches to code development.
Although the traditional waterfall approach reduces risk for the IT department,in practice it was too slow,he said.
The team tried"scrumfall",a hybrid of waterfall and scrum,scrum itself,and another variant which Heath calls"scrum but".
Heath currently uses Kanban,a system that makes each project visible through a series of cards or Post-It notes on a board.
"It gives visibility,it is a living breathing thing.It is how everybody knows exactly the right priority of everything,"he said."You can say,'Great,that is the right order',or,'Forget that,we are doing this one today'."
The guiding principle of Kanban is to break code down into manageable chunks of work,so that developers can file new code each day.
"We don't want big pieces of work.Everything we do has to be releasable.So you can break down big projects of six months and start delivering straight away,"he said.
No software documentation
In addition to simplifying the software development process,LateRooms has simplified the paperwork,by dispensing with software documentation completely.
Code that is correctly written should be self-documenting,according to Heath.
And if a piece of code is too big to understand,the answer is to break it down into smaller chunks that can be understood."We don't want to go down the old 1990s route of having a big coding standards document,with case-sensitive this,case-sensitive that,"he said.
Joint business/analyst teams
Today,developers work hand-in-hand with the business,sitting next to people from marketing,sales and company directors.
Heath typically creates six teams,pairing one businessperson with one developer,to work on projects.
It's a hard sell to the rest of the business,he admitted,as at first sight,it looks like the team is working at half-speed.
"But what comes out is right first time.The coding is better,consistent,and it is better quality,"he said.
The strategy means that quality assurance is part of the development process,and the business is constantly involved in user acceptance testing(UAT).
"It means we get it right first time.And because the business is involved in the delivery chain,the business is included in the accountability.We all win or lose together,"he said.
One of Heath's challenges was to reconcile the agile techniques used by LateRoom's developers with the formal ITIL-based processes used by LateRoom's IT service desk.
At first,the service desk struggled with the idea of daily code updates due to concerns over the stability of the system.
However,it became clear that scheduling smaller,more frequent code releases could actually reduce the risk.
"Now we can negotiate and work closely with the service desk to schedule releases daily and sometimes by the hour,"said Heath.
Continuous delivery
Over time,the company has changed the architecture of its international websites to allow them to be updated without having to take them down.
And there has been a steady shift of what Heath calls the"release maturity model"–from sleeping bag,pizza and Red Bull,to coffee and a slice of cake.
"Five years ago I was releasing code late nights and early mornings-so it was'sleeping bag and Red Bull'.That was the way you had to release,"he said."Now we are more into coffee and a piece of cake.We don't have to come in early.We can do it when we like–just press a button,and press another to roll back if you have to."
Fortunately,roll-backs are rare,with only a few cases this year.
Adopting agile techniques has allowed LateRooms to move to monthly,even daily and sometimes hourly,software releases."It has given us predictability and reliability,"said Heath.
Gradual roll-out
Heath introduced agile techniques gradually,so that the rest of the business could get used to working with software developers in an agile way.
"We started three years ago with scrum,with a single team piloting the whole process,"he said.
His advice to developers and managers is to find a marketing or operations director to work with to introduce agile techniques.Preferably someone who grasps the principles of lean working and wants to roll out projects fast.
"You have to put your balls on the line a bit,but if you can pilot that,and get success,you have someone that will shout for you in the boardroom:'Look at the value we have delivered,it's delivered on time,it's delivered collaboratively',"he said.
Taking the geek out of the software developer
Software developers are not renowned for having the best people skills.In too many companies,developers sit in darkened rooms,with headphones on,Gus Power(pictured left),chief technology officer at Energized Work,told a meeting of Computer Weekly's 500 Club.
"We are in danger of creating teams of Morlocks–people who live underground with very dark eyes–and that is not good for anyone,"he said.
But increasingly,businesses are encouraging developers to come out of the basement and start talking with non-IT staff.
Given the right opportunities,developers have a lot to contribute to innovation in the business,a meeting of Computer Weekly's 500 Club heard.
Jagdeep Singh,head of software development at the Financial Times,said things have changed a lot since he first started out in IT.
"The place I worked was called'the dungeon'.Everyone was 30 years my senior,"he said."It was more writing code than understanding what the code was meant to do."
Singh now tries to encourage his developers to build their social skills and their self-confidence by leaving the basement where possible.
"Go to conferences,talk about what you do.Don't be shy.Collaborate.Go and see other people outside.Don't sit in your silos,"he said.
Most developers feel nervous initially,but once they meet like-minded people,it's a big boost to their confidence,added Singh.
"Some developers have very good ideas,but they don't have the confidence,"he said."Much of my role is trying to help people come out of their shell."
In some cases,developers have great technical skills,but their confidence has been damaged through negative experiences with previous employers.
"It's a bit like working overseas.You spend a year there and you don't realise you have picked up the accent,"he said.
Dave Heath,head of software engineering at The LateRooms Group,is only half joking when he suggests that IT and people skills don't mix.
"We have found that developers and anyone who is technical can't communicate.Stick them in a room at a networking event and you find they are trying to hack the router in the corner,"he said.
Give them a technical challenge,however,and it's a different story.Systems developers who normally don't talk to anybody will quite happily talk to other people when they are working on a technical challenge.
Heath has developers attending technology-focused event,Hack Manchester,to get the developers talking."100 developers got together from the North West to talk and network and work on collaborative technical challenges."
The result was that developers started to collaborate and to learn from each other."It gives them confidence,"said Heath.
Eliminating distractions
Striking the right balance between collaboration and getting the programming job done is a perennial problem for software developers.
Social media,smartphones and e-mails can very easily turn into a distraction,rather than a useful form of communication,Gus Power,CTO of Energized Work,told attendees of the 500 Club meeting.
"We think that is collaboration,but it's actually taking away their time to do the work we need,"he said.
Videoconferencing and Skype can be particularly problematic,Jandeep Singh,head of software development at the Financial Times,told the group.
"Every time you use Skype,and have a chat,it takes half an hour to get back into your work.If you are dipping in and out of meetings,you are actually missing out on development time,"he said.
Developers at the FT have solved the problem by creating informal"no talking"times.
"Everyone switches off Skype,Microsoft Messenger,e-mail,etc,and gets on with development,"he said.
The challenge of legacy systems
Maintaining complex legacy software systems is a challenge for agile programming departments.
Every time you upgrade legacy software,there is a new risk to the business,said Dave Heath,head of software engineering at The LateRooms Group.
"If you keep going,keep going,keep going,all you are doing is adding to the risk every day you leave it,"he told a meeting of Computer Weekly's 500 Club.
The answer,he said,is not to allow software to become dated,and that means prioritising upgrades.
In practice,said Heath,it is easy for businesses to put upgrades on the back burner,as there is always something more pressing to do.
"All of a sudden you have a system that becomes five years old,then 10 years old,so you have to invest and continually deal with things that are in technical debt,"
Refactoring–reworking the structure of legacy code to modernise it–is one solution.
Heath suggested that software developers spend 70%of their time developing,but set aside 30%of their time for refactoring,training and innovation.
"Introduce something like innovation time,where they can come up with an idea.That is how you get the team focused on things that make them happy,but you also make sure you don't get technical death,"he said.
Gus Power,CTO of Energized Work,agreed.
"Legacy systems are a real problem,and I see new ones being built every day.I have seen one case where they have seven systems that do 80%of what the other systems do,and they have never switched off the old systems,"he said.
And because of the way depreciation is calculated,Power pointed out that legacy systems fit uneasily on a company's books.
"They sit on the cost account book as a corporate asset when they are anything but a corporate asset,"he said.
Ultimately,the way software is budgeted for and accounted for needs to change,said Heath.With agile techniques,it doesn't make sense to set software budgets two years in advance.
"We need to fundamentally look at financing and the way we plan projects.We can't really do that big bang finance model up front,because it does not work,"he said.
