Achieving greater ‘agility’ is now a common ambition for many large scale software development organisations.  Capgemini UK already had an excellent reputation for software delivery, but were typically regulated by clients using a linear lifecycle and constrained by overly bureaucratic quality gateways.  Within this governance framework Capgemini’s customers were also uncovering changing business needs, causing change management issues that could not easily, or cost effectively, be resolved.

Solution

Capgemini UK felt they could improve this situation by combining their already established collaborative culture and disciplined delivery approach, with emerging Agile practices, for which they were also seeing a growing market demand.  To help them achieve their goal, the organisation hired Julian Holmes, co-founder at UPMentors, to ensure their software development projects combined their existing Rational Unified Process (RUP) principles with Agile practices, enabling them to deliver more effectively to meet customers’ changing needs. This solution became known as Agile RUP.

Encouraging the Agile RUP approach

Experienced practitioners rarely like to be told how to perform their role.  Therefore, Julian worked with a small group, who already successfully practiced and supported Agile methods, encouraging them to share their experiences and practices via wiki-pages and internal ‘social media’ tools. As the knowledge was circulated throughout the organisation, more practitioners were drawn to their success, adopting similar ways of working and sharing their own experiences.

Education is also key to transforming skills and behaviour, so Julian constantly introduced literature, developed and delivered webcasts, virtual and classroom learning on Agile RUP throughout the organisation.

Seeing the benefits

The organisation is now seeing increased customer demand and more contracts being won due to the proposal of an Agile RUP approach. Capgemini has a competitive advantage in being able to react rapidly to customers’ changing business needs, and for their clients. the closer engagement with the project allows them to continuously re-prioritise how their project budget is spent.

Demand for Agile RUP training sessions is increasing and the approach has attracted interest from other global business units, who are adopting it as their method of choice. Guidance continually evolves and becomes richer on the wiki, with the community continuing to grow to over 1,000 active members. Most importantly, the investment continues to be successful, mainly because it is completely visible and inclusive, the approach is being chosen rather than ‘applied’ to anyone and everyone has the opportunity to get involved, to learn and make a contribution.

How often do finance directors invest in a software development project only to be disappointed with the end result? You only have to see how HMRC reached a £71.25million settlement with EDS over problems with tax credit systems, to realise the damaging affect of ploughing money into an IT project which fails to deliver business value.

Of course, most software projects don’t result in expensive lawsuits like this, but many end up causing headaches for IT managers and finance directors which could be prevented through greater levels of collaboration, reacting quickly to business change and showing continual demonstrations of “real” progress. Building this trust between the business and their supplier is vital for the success of any software development project. FDs aren’t expected to have experience in delivering IT projects, and rely on their IT department to manage the supplier relationship. However, suppliers are often forced into a fixed-price contract for a project that promises to deliver more than the business needs.

Suppliers know they have one shot at obtaining a contract to deliver, so they help the business define everything the system might ever need to do, providing a fixed-price quotation, resulting in a large budget allocation, and a contract being secured with the cheapest bidder, to deliver a system at some point in the distant future. Unfortunately this approach typically results in dissatisfaction for the business, a breakdown of trust with the supplier, and a solution that doesn’t reflect the business’s future needs, or worse still, no solution at all.

This failure stems from a lack of trust, a flawed governance model, a false measure of progress, and a misunderstanding of risk. With such a lack of trust the business adopts a governance approach to oversee the project and keep the supplier honest, introducing “gateways” that want to see a measure of progress against governance objectives. Whilst sound in principle, these gateways are often misinterpreted and misused by those performing the governance, leading to measures that inadvertently encourage poor supplier behaviour, such as a focus on endless documentation, as opposed to demonstrating working solutions.

Whilst a one-shot procurement model with a defined budget need and no expected increases is an attractive option for the FD, little consideration is made for how the project will manage the change of business priorities that the organisation will have during the lifetime of the project.

Plus, by using a fixed price and scope delivery approach, it is difficult for an FD to determine an accurate return on investment. FDs are often led to think that the project is progressing well from measures of effort against plan. This lack of real progress would become apparent by asking just one question – what return would I get on a project if I had to stop it half-way through?

FDs can stop this vicious circle of project failure by encouraging a more progressive funding relationship with their IT suppliers. Before the project is contractually agreed, FDs should demand an agreement from suppliers where they regularly demonstrate a return on investment. This puts FDs back in control of the budget and relieves pressure on cash flow. Taking an agile and incremental approach to their software projects will help them maintain control on their budgets and validate the delivery of business objectives right from the start.

The core competencies that a recruiter should now be looking for are the behavioural skills. Whilst these are sometimes difficult to extract, a skilled recruiter with a competency based recruitment method should be able to identify applicants who will not only suit new ways of working but also enhance the team.

What are the competencies organisations should now be looking for?
Competencies such as being a team player, possessing excellent communication skills, the ability to pick up new skills quickly, flexibility, and a ‘can do’ attitude, to name just a few. Some organisations may already feature these as part of their profiles for candidates but these should now be a prominent part of the recruitment process, with new employees required to perform each to a high level on a daily basis.

What is driving the change in focus?
The growing adoption of Agile software development practices has significantly changed in the way project teams work. No longer are they required to work as technical specialists in silos but are now expected to work in cross-functional teams, the majority of which will become self-directing work teams. Employees are also expected to have direct customer contact, understand the business, and be able to actively participate in team meetings where they will have an equal standing and say in decisions regarding the project’s delivery plan.

The success of these Agile teams is directly related to the ability of the team to ‘gel’ together and deliver high quality software. This way of working is a significant departure from the traditional approaches to software development. The challenge for HR departments is to strategically align their recruitment policy and practices to support software teams and deliver candidates who will not only fit with the new ways of working, but enhance and develop it further to the benefit of the team, organisation and the customer.

Industry viewpoint by

Julian Holmes, Co-founder of UPMentors

However, have the parties really taken into consideration the OGC’s six key goals when setting out their proposals which include; delivering value for money, delivering projects to time, quality and cost, and showing that these must be considered at all times when planning a successful IT project?  Furthermore, are these proposals realistic and can they truly be fulfilled by the managers of government IT projects?

Julian Holmes, co-founder of UPMentors, examines where government IT projects are going wrong, looks at what realistically could and should change and what impact this would have on those who work in IT for the Government.

What has the current government been doing wrong?

The current government has established an approach to procuring IT solutions that only permits large scale consulting firms to have the opportunity to bid for their contracts. These procurements also typically request wholesale change and re-engineering of business processes and IT solutions. This is opposed to identifying step-change needs that can be delivered within shorter timeframes and deliver value earlier, for less financial exposure.

What obstacles do government IT project managers come up against?

Examples obstacles include:

• There is a lack of ‘business’ involvement, where civil service has not got the time to engage directly with the projects to ensure that they define their needs accurately. This can sometimes result in the civil service providing a ‘proxy’ to represent their needs on their behalf. This is often somebody who knows too little about the department or has no authority to make a decision and has to keep referring back to the real customer, therefore becoming a bottle neck to decision making.

• There can be an almost dogmatic demand for excessive documentation, where the civil service demands an approach to delivery where documentation is key, and the true demonstration of system delivery progress is overlooked, in favour of documentary paralysis.

• A misinterpretation of governance gateways can be a problem, where the need to demonstrate progress at major project milestones is interpreted as a requirement for documentation, that needs to be completed in accordance with a lengthy template. This could be without necessarily checking for the quality of the content or described solution.

• An overbearing change management process is all too common, where a lack of recognition for the natural need for change as a system is developed. This leads to the delivery and business teams wasting time and money executing a change management process, rather than spending time working on the system to be delivered.

How can they work towards removing any bureaucracy associated with IT projects?

Establishing a greater collaborative approach to working with suppliers can help remove any red tape associated with the project. An approach that encourages early results and doesn’t lock the government or the supplier into multi-year development projects can help speed up the process.

Will a change in government policy really help?

Both the Conservative and Labour parties have proposed policy changes, but need to ensure that these, in practice, really make a difference. By establishing shorter contracts with smaller objectives, which are opened up to a wider range of suppliers able to demonstrate value early will certainly help. However, for projects to stand a chance of being delivered successfully, the Government still need to ensure they commit their own resources to projects and not bury them in bureaucracy.

Is there another solution that could possibly help?

Many large scale delivery organisations feel they can’t take a different approach to delivery, because the government departments they work with are not open to change. If this working relationship could be altered to encourage greater collaboration, with recognition that change is always required during the life of a project, and a constant re-prioritisation of needs to ensure the project delivers the greatest value for the least investment as early as possible, then iterative and agile practices can significantly help to improve delivery success.

A desire to make this change for government projects does need to come from the supplier community, but also needs a similar desire and determination from within government. With current cost-cutting initiatives, it is this kind of smarter working practice that will enable both the Government and IT suppliers to deliver value to the tax-payer.

A simple commodity

I believe, as many others do, that this ‘badge’ has to all intents and purposes, become a bit of a scam.  Surely no one in their right mind would truly believe that such a certification is somehow equal to an official ‘qualification’?  Sure, it is a nice tag and one that is cost-effective and relatively easy to obtain, but the idea that many HR professionals are citing it as a ‘must-have’ requirement in job applications/criteria has left me quite bewildered.  It is not a qualification and it doesn’t prove anything; it is a commodity and labelling the title as a ‘must-have’ has simply fuelled an industry that is focused on supplying, promoting and primarily making money from its existence.

That said, I’m not suggesting that certification doesn’t have its place generally, but I believe it’s deceptive to those who are led to believe it is far more significant than it actually is.  A certification scheme that insists on demonstrable experience and includes the skills for successful project delivery would be a good step forward.  But the potential issue also includes the credibility of the assessors themselves, who are they?  How are they assessing and on what benchmark?  That combined with more confusion caused by yet another certification scheme doesn’t really fill me with much confidence or enthusiasm.

While I don’t claim to know all of the assessors for certifications of proven capability personally, I would imagine that they are highly credible, upstanding members of the software community; however, not all certification schemes have the same level of maturity, and as such it will be incredibly tough for this certification type to stand apart from mediocrity.

Keeping it in perspective

In an era where many in the IT industry feel compelled to attach a ‘certified’ badge to their name at every opportunity, we have to ask ourselves why people feel they have a need for certification.  Is it purely about differentiation in a difficult market? Is it to meet a certain criteria set out by their HR department or boss?  Or, do they truly believe they won’t be considered for the job without it?  Either way, people with any kind of certification would do well to keep such titles in perspective – I recently saw a job applicant with a PhD in computer science who listed his ‘Certified Scrum Master’ tag above his PhD credentials!

Consider certification ‘claims’ with caution

Some of this nonsensical behaviour unfortunately comes from how the recruitment process is conducted and how training budgets are spent (or wasted).  All too often, and sadly for most, job applications are ranked by a certification as opposed to making the relevant checks to uncover the real experience and success demonstrated by a potential candidate.  What also concerns me is that so many learning and development departments are setting targets for attendance at commodity training sessions where certification is immediately achieved – but is this really achieving anything worthwhile?  I don’t believe so, but how you measure people, will ultimately determine how they behave.

While I do agree with evidence-based certification where sensibly governed, I also believe that these worthier schemes will soon get lost in the haze of other less-credible ‘certification options’ if the rising popularity in commoditised training sessions is anything to go by.  Until such a time where a new evidence-based certification has gained momentum and has proven with some gravitas, to be worth its weight, I believe we must continue to consider any certification ‘claims’ with extreme caution.

What is a self directed work team?

Unlike software tools you can’t buy a self directed work team and configure them for immediate deployment. The level of independence a team has will depend on the organisational constraints placed on it. A company should define what it means by a ‘self directed work team’ up-front because at its purest level a team like this could potentially select members, determine remuneration, discipline team members, agree holiday leave and the list goes on.

Whilst some organisations may be comfortable with this, on the whole most would take the view that this way of working would only result in anarchy. It is therefore not appropriate for all organisations to aspire to and also takes time, experience and a particular culture to get to this level of maturity. For a team to achieve self direction it will follow an evolving and maturing development process, taking time and careful management.

The very nature of an industry, its complexity or its legal constraints will prevent most organisations achieving this pure level of self directed work teams; however this is not to say that organisations shouldn’t aspire to create a roadmap for teams and manage the level of self management that is acceptable to the organisation to deliver business value

So how can it be achieved?

The recommended approach is to start off with directed work teams and develop through the team lifecycle, increasing the level of responsibility as the team demonstrates its capability to handle the broader responsibilities of self management and not just the task at hand.  Here are some things to consider:

• What responsibilities will the team have?
• What are they accountable for?
• Do they have the support, resources, and control to deliver?
• Should all the responsibility be given on day one or should this be a staged programme based on the how the team develops?

The job of management is to understand and review the development of the team within defined parameters of self management. It is also their role to support them when challenges arise,  facilitate the team to overcome these obstacles and to keep external distractions at bay.  The diagram below illustrates how this can be achieved:

Managed Team — A group of people working together toward a common goal. The ‘what’ will happen, ‘where’ it will happen and ‘how’ it will happen is set by the organisation and/or the manager.

Self Managed Team – Is a group of people working together in their own way toward a common goal which is defined outside the team. The team decides their work schedule,  in what order, when to deliver, how, to what standards, and by whom.

Self Directed Team - A group of people working together in their own way toward a common goal which the team defines. They will perform all of the above but in addition also have input on recruitment to the team, training, compensation, performance management, discipline, and acts as a profit centre by defining its own future.

What are the challenges?

The move to an empowered team-based approach to software development is a huge change for the industry and will not be without its challenges.  Not all employees will welcome this change, such change will be perceived as a threat to some and as with any change programme it is to be feared. Many people prefer to work on their own the way they have done for many years, they may not want to learn new skills or collaborate with others.

By the nature of the industry specialists who are highly skilled  have operated in discipline silos working in isolation to produce software that works  often for them but no one else. In fact the way in which work has traditionally been organised has been a huge barrier to the concept of a ‘one team’ or ‘whole team’ approach to developing software.

The approach now is to form teams of ‘generalising specialists’ working together across disciplines, who are highly collaborative, task orientated, responsive to changes and organised to deliver quality software quicker, with cost  savings; a huge plus in this current economic environment. Such methods as Agile, lean and scum will offer a framework and principles in which to assist an organisation looking to ‘up their game’ in producing better quality software. However, it will place new challenges on individuals, teams and the organisations in terms of defining their approach, culture change, skills change, the way they communicate and their relationship with the customer.

What are the benefits to a cross functional team based approach to software development?

Whilst the challenges are not for the faint hearted, the benefits to an organisation, teams and an individual can be hugely beneficial. An individual has an opportunity to become an equal contributor, they can learn new skills and disciplines, they will interface with the customer and they will take responsibility and be accountable. This all adds up to increased job satisfaction, leading to a greater retention of talent within the organisation and less churn. The team benefits from learning to address such issues together like estimation, the risk value lifecycle, prioritisation of tasks, collaborating between themselves and the customer. The organisation will be able to deliver usable software early in the project, that can have instant benefits for their client and early commercial return for the developing organisation.

Delivering Business Value

Black Pepper 2010 Agile Workshop presentation

They will focus on delivering what is important and essential and not waste time on developing software that is a nice to have, saving time and money for the developing company and the client. The trust levels between the client and the customer significantly increase as confidence is developed over time when workable software is produced at regular intervals and the client gets exactly what he/she wants because they have been involved in the process of development, and delivery. An enhanced relationship between the organisation and the customer will increase the level of customer satisfaction and lead to further working opportunities.

So should your organisation be contemplating this change, or have started on the road to change already. My advice to you in solving the self directed team conundrum is to be conscious and clear about what ‘self direction’ means for your teams and your organisation. Organisations that do this well will have a competitive advantage over those who prefer to take the traditional route, or only dabble in a team-based approach. The benefits are there for the taking but it takes leadership and commitment to make it work. Are you up for the challenge?