Agile from the Professional Services Perspective


Recently I was asked whether Agile is a viable proposition for Professional Service Organisations (PSO) to use in the management of projects? If so, what factors need to be taken into account?

Before answering this, it’s important to note that while Agile is a framework for Software Delivery, it is not a project managment methodology. This is a common misunderstanding. It is crucial to understand this when dealing with multi-discipline and multi-team projects.

In Scrum, (an Agile approach) an ideal team is made up of between 6 and 8 co-located members, all focused on the delivery of a product. If that product is independent of all other products then Agile is sufficiently structured to act as a quasi project management methodology. However, for all other types of project it is insufficient. Agile ignores all of those project management tasks required to ensure each team is working in a manner that supports and facilitates the work of the other dependent teams. It also ignores all those activities such as business case development, status reporting and change management that, while not delivery tasks per se, can be the difference between project success and failure.

That said, it is still true that from the perspective of a PSO Agile is the optimal mode of solution delivery. It allows for certainty in the engagement; as the customer is actively involved on a daily basis. It significantly reduces the gaps in engagement. For example, where the solution is handed over for UAT and the team waits for feedback before being able to finish. This in turn allows for greater resource utilisation and this means each project is potentially more profitable.

So why don’t all PSO’s use Agile all the time? Simple – often the customer can’t or won’t commit to the level of engagement required. You know the story, the key people needed to make decisions and sign off on the solution all have day jobs which prevent them from being available when they need to be. This means that the project stalls, or worse yet, takes the wrong direction when working on an ambiguous requirement. This is the typical scenario when dealing with smaller customers in particular.

An additional complication to the above comes with the customer’s lack of an internal IT function. Why is this a problem? Well, it prevents a project being truly Agile, as they will not have the capacity to automate the delivery of the solution into production (i.e. continuous integration/continuous delivery – CICD). CICD is a mandatory element of Agile projects which is often overlooked. Furthermore, if you don’t do it, then you aren’t truly Agile.

The PSO can set up CICD to deliver into an interim environment (usually a test environment); then manually release into production. This is a hybrid solution that will allow development to continue while the customer tests what has been delivered. Of course, in smaller projects the CICD overhead just isn’t worth it, as end to end the project is only going to be 1 or 2 sprints in duration (2-8 weeks). That is unless the customer wants to become Agile. In that case, setting up the automation mechanism becomes a proejct in its own right.

One other obstacle for a PSO using Agile to deliver a project is the contract itself. Many customers will view the initial statement of work as being a fixed price, no matter how you word it. The result is a rigidity in the project that prevents the team reacting to change in the way that Agile promotes. The change process has to be formal out of necessity for the PSO. It is the only way that a PSO can hold the customer to account for spurious changes, delays and the resulting cost overruns.



Agile in Mixed/Outsourced Environments


In 2011 I wrote a dissertation on Agile and outsourcing. After analysing all of the data I had collected along side that publicly available from various sources including Microsoft, Ambysoft ( and The Agile Alliance the only conclusion I could reach is that Agile and Outsourcing were incompatible. The fundamental obstacle was the contract between the vendor and the client.

Things have come a long way since then and it is possible to run projects in an agile manner. But only if the client understands the level of commitment required on their part. Having been on both sides of the contract I am finding that there is still a disconnect here. Often the expectation is that an Agile project can be run with the same level of customer engagement as a project run under a waterfall methodology, with a greater degree of success.

I exclude body shop engagements from the above as in those cases the reality is that the customer isn’t paying for the delivery of a project they are paying for the use of a specific type of resource/expertise.

So when are outsourced Agile projects successful? When the vendor is responsible for the delivery of the solution and has full commitment from the customer to be available at the agreed level. It all lies in the structure of the contract. The contract needs to be balanced and clear about the responsibilities of both parties and state the consequences from a delivery perspective if any of those responsibilities are not met.

Agile also does not work under a fixed price contract as the core tenet of Agile is the ability to deal with change. and fixed price is the antithesis of change.

Failure to acknowledge any of this is a recipe for disaster.



Embracing Creative Destruction to Get Ahead


In this recent post by Rohan Rajiv are some novel insights into what traditional companies need to do to get ahead of their rivals. While his focus is on the technology sector and how to compete against the big tech companies the lessons are valid for all. In particular the idea that the innovation curve is no longer contiguous.

The idea that innovation has jumped ahead and that there is a chasm between the market leaders and the traditionally solid performers should resonate no matter what industry you are in. It is just more evident in technology.

So, how does Rohan suggest that this chasm be bridged? By accepting that many of the tried and tested ideas that have made us reasonably sucessful will no longer to continue to bring success. Once this is understood it is easier to identify novel ways of challenging the status quo. Not all of them will work but those that do will accelerate business success. If a company takes a learn fast approach (see my earlier post for more on this idea) then the ideas that don’t work will encourage a culture of entreprenuerism within the company that will further accelerate success.

Over the years I have worked with a number of non-tech companies on transformation projects. The most successful of thes have seen the internal conversations revolove around how to manage the transition away from the traditional business model (e.g. we sell data products) to a new paradigm where the company is selling a technology based and data driven partnership with the customer.

Rohan’s over arching theme of “creative destruction” is one that the top tech firms have embraced wholeheartedly. For example Microsoft have stopped being Windows centric in the development of its productivity suite with updates oten being provided to other plattforms (iOS in particular) first. The idea is that they want a piece of every device out there. This is a variation of what Amazon has done with it’s market place. They want a piece of every online transaction and don’t care if they sell the product or someone else does.

Applying creative destruction in our professional and personal lives is not something that comes easy. However, if we are realistic, the days of a person holding a job for life are long gone and  there will be times in which it is essential for us to reinvent ourselves in order to stay relevant within constantly evolving industries.

A classic example of this is traditional manufacturing in western countries. Repetitive low skill jobs are either been performed by robots or have been moved off shore to countries with cheaper labour rates. The remaining manufacturing jobs are high tech and higly skilled. The result is a significant jump in unemployment while people retrain or find alternative low paid work (if it exists).

So no matter who we are and what we do, unless we embrace change we will find it increasingly difficult to keep up. Or as Rohan sums up “what got us here won’t get us there.”


A new form of Leadership.

Emotional Intelligence is often dismissed or overlooked in the eternal debate over what makes a great leader (as opposed to who was a great leader). But increasingly it is becoming evident that those leaders that consistently achieve great results not only have great communication, analytic and decision-making skills they are also able to tap into an emotional connection with those that follow them. Whether they are male or female these days it is critical that the modern leader is able to make that connection with the individual as well inspire the collective. So the message to the tough guy wannabe entrepreneur… get in touch with your feminine side!

Is the Cost of Innovation Worth it?

A great article explaining why focusing solely on a businesses current core strengths is not always a good thing. At least not in the long term.

I find it fascinating that many intelligent people fall into the trap of thinking that because their company has a competitive advantage in an area (whether  a market segment or a specific product) it means that they do not have to keep innovating. Often it’s born out of a fear of cannibalising the sales of existing products or what the market will think of their margins or a fear of competition. But look at three of the most successful companies going, Apple, Amazon and Microsoft.

First Apple is in no way shape or form afraid of cannibalising their own sales. If they were they would not have introduced the iPad Mini, the iPod touch or the iPhone 6 plus.

Second Amazon, Bezos has steadfastly ignored the markets desire to see Amazon’s profit margins increase. Instead Amazon continues to stick with margins that would barely allow others to continue operating. The strategy… grow market share. Amazon wants a share of every $ spent on line. This is the thinking that underpinned the Amazon Market place. Rather than competing with every online seller as well as with eBay, Amazon created a platform whereby everyone is a partner and pays them for the privilege. The pay off is starting to be seen as Amazon is now the first place most head when searching for products online.

Microsoft may not be first to the party but with pockets as deep as theirs they are able to play a long game. Don’t believe it? How about the Xbox it started out as the bit player in the console gaming market dominated by Sony and Nintendo. Now Nintendo are an after thought despite being the first to introduce motion sensors into gaming. Also the introduction of Office 365 subscriptions that include the right to install versions of office on multiple devices at no extra cost. Great for the consumer but not so good for the bottom line as they are foregoing revenue  on those sales in order to keep market share away from Google Docs (also Microsoft are still in the search game. Not nearly on the scale of Google but still enough for it to be worthwhile).

Speaking of Google it has been shown relying on advertising revenue to support a suite of free apps is not necessarily the best business model.

So next time you hear someone bemoaning the amount of money being invested into new product R&D tell them to stop being so short sighted and start thinking in terms of the long game!

BBC DMI failure

The failure of the BBC’s DMI programme is a prime example of why it is so important for senior IT management to insist on having fully engaged, committed and responsible business stakeholders. If that isn’t happening then the programme manager / CTO needs to put the programme on hold until the right people are involved from the business.

Design Thinking

Why are the likes of Amazon, Apple and Google successful and seemingly able to continually re-invent themselves? Design Thinking (i.e. thinking like a designer) may, in part, explain it. 

The other part of their success is the focus on customer interaction and ensuring that this is immediate, relevant and provides an outcome or resolution for both the customer and the organisation. Those less successful tend to focus on the outcome for the organisation only.

Combining a customer focus with design thinking and you end up with very creative ways of resolving customer issues or developing new products…

This article from Management Today gives some interesting examples and expands on Design Thinking:

Taking this approach as a Project Manager, a developer or an administrator could result in some novel outcomes for your projects and deliver game changing results for your client / employer.

The Agile Project Manager – Does it exist

Recently I attended a seminar on “Agile” software development. One of the statements made by the presenter was to the effect that once agile is implemented properly an organisation will quickly realise that they don’t need project managers. The reason… the close, frequent interaction between the business and developers means that the management of a project is handled almost as a by product.

I’m not convinced by this thinking, unless it is restricted to the simple case of a small project with a fully committed and engaged product owner. In more complex situations (e.g. Multiple agile development teams working on a project in parallel) someone is needed to keep everything lines up and remains on track. Sounds like a project manager (PM) to me…

So in this situation, what makes a Project Manager an Agile one? How can you recognise one? First and foremost an agile project manager will be able to facilitate two competing needs

  1. help the project accept and adapt to change
  2. prevent change impacting the project delivery

This is the challenge in agile, where it is possible to do everything the client asks but not everything they ask for should be done. If you only have a product owner and the scrum master then in complex environments the former is likely and without the checks and balances that a disciplined project manager brings to the table then projects will fail.

I do believe the nature of project management will change. With more and more projects being delivered using agile or lean methodologies it has to. The focus for a project manager will become ensuring the delivery of the right thing at the right time whether that is requirements, designs, code or a functioning product. This is essential when the paradigm is iterative.

Project managers will live and breathe the mantra “if you don’t need it now… it can wait” and every will focus on Just In Time delivery. Or it will once vendors and customers figure out how to work effectively together using agile…

Lessons Learned – not a one off activity

So many times I have been involved in projects where once the solution has been delivered a project manager, sponsor or vendor will say “now we need to review the project and record the lessons learned”. The idea being that the lessons can then be used to ensure those mistakes aren’t repeated, or that things that really worked well can be replicated on subsequent projects.

Sounds good, right? Wrong! Why should the next project be the beneficiary of your hard won lessons? A lessons learned log should be maintained throughout the life of a project. The log should be reviewed and discussed within the team regularly and include stakeholders or their representatives from the business. That way you can:

  1. prevent poor behaviour recurring
  2. identify good behaviour and encourage it to be repeated
  3. capture key business drivers that have been highlighted by any issues that have arisen
  4. highlight areas of conflict between business areas (e.g. Sales v marketing) and the best mechanism(s) for resolving the conflict.

By doing this throughout the life of a project, the project becomes self correcting as those individual experiences are shared with the team. This reenforces behaviours, establishes trust within the team and with the business and ultimately helps improve the chances for the successful delivery of the project. At the end of the day delivery is what it’s all about.