I’ve written before about the Agile backlash I see coming. But what I’ve been wondering is: what comes next?

One idea comes from James Noble and others who have suggested Post-Modern Programming. I like the idea, it helps us understand the world better and it helps reposition our view of software development but it doesn’t tell us to do anything differently. Post-Modern programming is more a philosophical understanding than a prescription.

Myself I’m a big proponent of Learning Based Software Development. While this changes the emphasis on in software development I’ve yet to develop the ideas into a proposal for anything more than … well ideas.

Actually Learning Based Software Development (yes I just invented the term so lets invent the abbreviation LBSD) can be seen as a software specific version of Knowledge Based Product Development. (Sorry, one of the entries with messed up formatting.)

This week I stumbled across a blog by Jason Gorman in which he discusses Post-Agile. This is the first time I’ve heard the term and it seems I’m a little late to the party. (Also a sign that I need to get to XTC a bit more regularly.)

It appears from what Jason says that opinion is divided on what “Post Agile” means yet but one possible explanation is: Being informed by the Agile/Lean movement but not following any prescribed methodology. If that is what it means than good, it could be what I’m looking for.

But boy, Post-Agile is such a pretentious title.

First an apology: I’ve been very busy the last few weeks so I’ve not been blogging so much. Naturally the creation and launch of Software Strategy has kept me busy and so has the company’s first client where I am far busier than I have been for a long time. Add to this friends and family visiting from abroad and a few things have had to give….

Despite this I wanted to capture a quote I read this week which I think is very wise.

Last weeks Economist carried a profile of Gerald Grinstein, no I hadn’t heard of him before either. Turns out he is the boss of Delta Airlines and what he said was this:

“Chance favours the prepared mind”

Which when you think about it is so true. If you spend time thinking about where you are, what needs doing, what options are available and how things might unfold then when chance occurs you know whether to grasp it or not.

This is what worries me about being so very busy. When I’m busy busy, and when see companies who are busy “doing stuff” I find so often that opportunities are missed and much of the stuff that gets done isn’t necessarily the right stuff.

For example: I often advise people to keep a work diary (or journal as some would call it.) Writing a journal is not really about recording what happened but thinking about what the implications are and what might happen next. As such it is an act of reflection. I find that when I get busy my journal (and blogging!) get squeezed, but when this happens I loose direction and although I’m busy I am less effective.

So this is a reminder that in the middle of this very busy period I still need to find time to think and prepare my mind.

A couple of weeks ago I raised the topic of How Agile Teams fail. Well in recent conversations and observations I’ve been reminded of two more modes of Agile failure. (Maybe reminded is the wrong word, maybe I could say I’ve spotted patterns, having one or two cases logged in my mind some more examples have focused my thoughts.)

One mode is where the developers simply state they are doing Agile. We can call this Fake-Agile. By simply stating they are Agile the team can then ignore documentation, avoid project management, and generally hack.

Frankly this isn’t Agile and it gives Agile a bad name. I’m sure some examples of this are genuine attempts to become Agile but without real understanding or experience it is difficult.

The lesson here is: Simply stating you are Agile does not make you Agile.

I’ve also been reminded of this by recent TDD experiences. A team I am working with has decided they want to start doing Test First Development. However nobody has done it before and three weeks after voting to do this there is little sign of it being done. This isn’t necessarily the team’s fault, although they want to do it they don’t really know how.

Think about it. When I decided I wanted to drive a car I hard to learn to do it. The same with skiing, wine tasting, and lots of academic subjects. Sure I can pick some of it up by just doing it, and if I’m really clever, lucky or something else I might just succeed – like the way I first learned to programme.

But generally, wanting to do something isn’t enough to actually do it. You need help and advice.

y solution is to arrange some training and coaching for the team to help them start doing TDD. Once we have that in place I expect things will change.

The second Agile failure mode is a bit more complicated. I’ve seen it a couple of times now and I suspect its behind many Agile failure. It happens like this…

A team are trying to adopt Agile, but they are also working with new technology. The new technology could be technology new to the team, it could be technology new on the market (perhaps a beta release from a vendor) or it could be newly introduced technology. Whatever, the team need to learn the technology.

So we have New Process and New Technology.

The first sign is exploding cards. Teams write cards to represent the work they are doing to do at the start of the iteration but when the iteration gets underway it turns out the cards were vast understatements, both in terms of the time required and the work required.

(By the way, you need a card and board system to spot exploding cards, a software tool will simply hide the problem.)

In some cases progress is slow and few, if any cards are complete. Perhaps people say things like “the card is 80% complete.” In Agile iterations 80% counts as zero. It is either done or it is not done.

In other cases, where teams recognise the extra work involved they may write more cards – hence the expression exploding cards. Here developers start work on a card and realise/find there is far more work than they anticipated. They break this down into several smaller tasks and the number of cards multiply. In one case I saw developers took to folding the cards in half to fit them on the white board.

There are techniques for dealing with this situation. Writing cards to represent the extra work is one, and you may need to add more frequent re-prioritisation.

Another technique is time-boxing: where developers have to guillotine their activities at some point and just go with the best they know so far.

And another is investigation: where an investigation task (probably time-boxed) is conducted before the actual work itself. This can help split tasks down.

But, all these extra techniques for dealing with this situation are relatively advanced. An advanced Agile team may simply take these problems in their stride. For a team new to Agile this situation can be off putting, some people may take it as evidence that Agile does not work and it may even lead to project collapse.

Such projects were probably going to end up in a mess whether they are run Agile or not. Because of the new technology the project is uncharted waters and the amount of learning and investigation needed is very high. Therefore, even with traditional project management techniques the project will probably hit problems.

Here the advantage of Agile is that you know the problems are happening much earlier and not just at the end. But, if they team is new to Agile then you may loose the project and the Agile practices too.

The solution here… Not sure I know one. Some projects will always slip and even fail no matter how well you try to manage them.

If there is a solution it lies in seeking help, involving people who have done these things before – either Agile or the technology. Training and coaching can help too, whether in the new technology or new process.

What is the lesson from all of this? Well if there is one it is simply that Agile Software Development may look easy but it isn’t. Getting to be Agile is not simply a case of reading one book, it is a case of reading many books, talking to many people, working with experienced practitioners, having training, coaching and trying again when things don’t work out.

It isn’t easy being Agile.

Something else I discovered at the ACCU conference: Bicycle Repair Workshop.  Should I name to originator?  Or should I let her live in quite anonymity?  Perhaps I should actually seek permission to talk about this here, but then was it not Picasso who said “great artists steal.”  (No I did ask permission.)

First the name: its a straight take from Monty Python.

What it is, is a forum where software developers at the company can gather and talk about the problems they are currently encountering.  The originator envisaged a forum for people to talk about process issues, and specifically Agile practices but its free form enough to let people take in what they want.

The workshop takes up an hour or so on a regular basis, I can’t recall it it is weekly, bi-weekly.  There is a bit of fun (cakes supplied) and people turn up only if they have something to contribute – so a self selecting group.

Like the book groups and Tech-Talks that I’ve created in the past the forum gives people the opportunity to talk about the issues they face.  By exposing, explaining and naming the problem/issue/challenge/opportunity it becomes more manageable.  By explaining it people are forced to make some sense of it to themselves and then to other people.  And when other people see it they can help.

In one of his books Gerry Weinberg (Secrets of Consulting I think) compared problems in companies to moss.  In the dark, moss grows and becomes bigger.  Exposed to light moss dies.  Problems are the same, when you hide them they become worse, expose them and it becomes easier to deal with.

I see this happening when people gather in a pub or coffee bar, or stand around the water cooler and moan about things in their work place.  They know what is wrong but they feel helpless to act.  So bar and water cooler conversations don’t result in much action.  Often these problems don’t get talked about in official forums either:

• because these problems shouldn’t exist, e.g. the according to the official process manual these things shouldn’t happen
• because office politics gets in the way, e.g. everyone knows that X needs to change but nobody feels they can say it
• because somethings we can’t talk about, e.g. Fred under performs and needs to be let go
• because solving the problem needs resources and we all know the company won’t spend money
• because we are embarrassed to admit to our own problems

The advantage of the semi-official forum, like Bicycle Repair Workshops and book groups is that people are freed of these constrains and can talk more freely.  For managers this posses a problem: too much support and involvement with the forum will make it official and kill it, too little support and it will turn into another moaning shop and nothing will happen.

By creating a forum people are allowed to talk about a problem and expose it to the light.  The advantage of the Bicycle Repair Workshop is that it is directly asking for and discussing these issues.  I occasionally facilitated a Tech Talk into such a forum, and the books we studied in book group lead to discussions about problems bit I never tackled the issues head on, on a regular basis.

Of course it mights be possible to have too many forums.  All of these activities take time and commitment.  A company running bicycle repair workshops, book groups, Tech Talks and what ever else may over tax people.

These three types of forum share another thing in common.  They can be created through bottom-up action.  You don’t need to be a manager to create them, you can just do it.

On the other hand, if you are a manager then then can create other types of forums. I’m working with a company now to help them revise their development process and become more Agile.  One of these things I’m doing it running twice monthly improvement meetings, kind of reverse-retrospectives.  These are more official so have a different flavour.

In all these cases the real problem is turning information and learning into action.

One of the questions that was posed at ACCU conference was “What are the downsides of Agile development?” – and “What does Agile failure look like?”

I have tried to answer the first question before but failed myself.  One downside is that the Product Owner role – typically filled by a Business Analyst, Product Manager, Customer or other proxy-customer – is given an immense work load.  This is a subject James Noble has done some work on.

What happens is that Product Owners have to keep doing their original job and service the needs of an Agile team.  As the Agile team becomes more productive they ask more and more of the owner.  Consequently the owner gets maxed out and themselves becomes unproductive.

However when I thought about this I don’t think the failure is a failure of Agile, I think it is a failure of the business.  Put it this way: for years “the business” has been complaining that software teams do not deliver what they want.  Now along comes Agile and says “we will deliver exactly what you want” but “you need to tell us exactly what you want.” 

It is no longer enough to set half a dozen developers working on a problem and expect them to come up with the right thing.  If customers want what they ask for then they need to tell the developers exactly what they want in detail.

The second question, “What does Agile failure look like?” is hard to answer because we don’t have many case studies of failed projects.  This isn’t just true of Agile projects, it is true of many IT projects.  Companies don’t like to talk about failure. 

Still I can see several failure modes for Agile:

• Teams fall back to the old way of doing things: I’ve only heard about this not seen it myself.  Typically it occurs when you bring in a lot of consultants to make your team and process Agile.  Things work when the consultants are there but when they leave teams fall back to the old way of doing things.  Unit test break and aren’t fixed, planning meeting are missed, quality slips and deadlines are missed.  The presence of consultants gives the team a backbone but knowledge is not really transfered to the existing team.
• Failure to get management buy in: Agile is often introduced at the bottom of the hierarchy, by developers at the code face.  Eventually there comes a point when managers need to support it or stop it.  This doesn’t happen and the development process is left in a random state.
• Failure to get developer buy in: this occurs when management buy into Agile but developers don’t.  They don’t want to write tests, do code reviews or pair, believe in technology over visual planning, etc.  Again the process is left in a random state.  I expect to hear more about these types of failure in future.

The common theme here is not that Agile fails, after all IT projects and processes fail all the time so there is nothing new or special here.  Failure of an Agile project looks a lot like the failure of a Waterfall or RUP project.

Rather Agile fails when you fail to see the benefits of the new approach.  So when you do a little bit but not enough to improve quality, improve delivery dates, and make things predictable.

Both questions are good questions and deserve more attention.

As I mentioned last time, I came back from the ACCU conference with a bunch of notes and a lot of thoughts.  Recording them in this blog seems like a good way of remembering and sharing these thoughts.

Last time I referred to the Great TDD debate.  At the conference Mary Poppendieck reminded us of the key principle behind TDD and other forms of unit (especially automated) testing when she quoted from one of the original Toyota sources:

• Testing to find defects is waste: the defects should not be there in the first place so any attempt to find them is waste.
• Testing to prevent defects is essential: defects slip in, we should catch them as soon as possible so create systems with tests that prevent defects.

Hopefully it should be obvious were TDD fits it: TDD is there to prevent defects and reduce waste.  However, testing later in the cycle, e.g. system test, is waste and although it may be necessary right now we want to get away from faults, testing and waste.

On the face of it this is bad news for software testers.  If we start testing to prevent waste rather than find waste then they are out of a job.  Well I have three reassuring thoughts for software testers, they will not be unemployed anytime soon because:

• Few organizations can actually implement this principle, some will always need testers.
• We have a lot of code out there where nobody prevented the defeats and therefore needs testing.
• Testing itself is an activity that can add value to products –  as Oracle considered last year.

Also, most of the software test managers I have ever worked with have been keen to point out that they would rather conduct Quality Assurance than Test.  Too often these activities are lumped together but when you think about it they are very different.

So, in the short term testers have plenty of work, in the long term their future is in quality assurance – a more value add activity.

Now at this point a lot of people tell me I’m an idealist.  After all, everyone knows software is buggy, has always been buggy, and always will be buggy.  I remember being taught at University how every piece of software contained an infinite number of bugs.

I asked Mary Poppendieck about this, her answer was basically: you get what you expect, if you expect to get bugs then you will.

Well, maybe I am an idealist.  But what is wrong with wanting software without bugs?  What is wrong with setting my sights higher?

I got back yesterday from the 2007 ACCU Conference. Once again this was a great conference. Lots of good stuff on Agile and Lean (Mary and Tom Poppendieck delivered a keynote), software management, programming in general, Java, C# and C++.

I mainly kept myself to the management and agile sessions. Also I was involved with a lot of ACCU business type stuff occurring around the conference. It is about the time when all the key players in the ACCU are in the same place and a lot of association business gets done. As well as delivering my own session and taking the stage with Mark Shuttleworth and Mark Poppendieck I was in meetings about the ACCU journals, growing membership, conference organising and a host of discussions about the association.

Over the next few blog entries I’ll try and debrief myself and highlight the things I feel I learnt and need to remember. My comments from this time last year still stand, the best speakers are no necessarily the ones you expect them to be. (Apologies for that blog entry, its one of the ones with formatting problems.)

Right now here are a few bullet points.

I met three people who are separately working on projects that compile the same code base to Java and C#. These people have the code in one language and have some pre-processor step which makes the syntactic modifications so it can compile for the other. Is this a trend? Will we one day have Java# ?

Ed Sykes and Jan-Klass Kollhof did a really good session. They set out to produce a distributed algorithm using Python and JavaScript in web browsers. They just about succeeded but actually their session was far more interesting for what it said about systems with emergent behaviours. They also took a stab at futurology and suggested Web 4.0 Distributed Computing. You heard it here first!

The great Test Driven Development debate rumbled on. Well, when I say debate it is a bit one sided. There are a few people who think TDD is not a good practice then there are the vast majority of people who have tried it think it is a good practise that improve quality.

Mary Poppendieck presented some figures from Mike Cohn’s book Agile Estimating and Planning. Before introducing TDD Cohn’s company had 10 faults per 1000 lines of code, after 3 months of TDD this had fallen to 3 per 1000 lines.

For me this debate is a little like the Black Adder scene were the Captain (Tom Baker) says to Black Adder (Rowan Atkinson):

“Crew? Opinion is divided on the matter, all the other captains say you need a crew and I say you don’t”.

Gail Ollis did a good session on Advocating Agility, one of her first slides quoted the start of A.A.Milne’s Winnie the Pooh:

“HERE is Edward Bear, coming downstairs now, bump, bump,
bump, on the back of his head, behind Christopher Robin. It is,
as far as he knows, the only way of coming downstairs, but
sometimes he feels that there really is another way, if only he
could stop bumping for a moment and think of it.”

Gail had spotted the great sentiment expressed here: we do painful things because we simply don’t know how else we might do them and don’t take the time to find out. I left intending to use this quote myself.

In looking for this quote on the web just now I seen that neither Gail or myself is the first to spot this, its all over the place and often associated with change.

OK, thats a first stab at debriefing the conference, over the next few entries I’ll write more.

I attended a project retrospectives training session last week.  Although I’ve run quite a few retrospectives over the years I’ve never been trained in them.  My guide has been Norm Kerth’s Project Retrospectives book and a whole bunch of ideas I’ve picked up over the years.

This training session was organised and run by Rachel Davies and Diana Larson.  It drew on Diana’s new book Agile Retrospectives. 

Although the book and the training is aimed at Agile practitioners it could be used by other teams – its just that Agile teams are more likely to do this stuff.

The world outside of software development is also catching onto retrospectives.  In part this is thanks to the US Army and Marines who call them After Action Reviews (AAR).  Now they have a macho name and the backing of some generals they seem to be cropping up all over the place.

That said, I still think Retrospectives – or AAR to give them a more fashionable name – are still more talked about then practised.  The training session gave me an opportunity to reflect on this paradox (as well as learning some new techniques and improving my facilitation style.)

So why is it retrospectives get a lot of talk and little action?

There seem to be three basic failure modes.  First is retrospectives that don’t happen.  Usually the reason given is lack of time.  However I think this only an excuse to hide behind.  When people want to do something they do it, if something is important time is made for it.  Conversely when something is low priority or someone doesn’t really want to do it then there is not enough time.  We are all busy people, lack of time really means “is not a priority for me.”

I think one of the reasons people don’t want to do retrospectives is because they are scared of what might come out of it.  Individuals could be criticised, companies could be found wanting or someone may say something they are not supposed to say. 

Retrospectives expose the lie that your boss/manager/leader knows best.  By definition retrospectives are about asking teams what they can do better.  Traditionally we are brought up to expect that someone in authority, someone with a “big brain”, knows best.  So retrospectives can be threatening to managers who feel they are loosing some power.

Which brings us to the second common failure: ineffective results.  Simple formulaic retrospectives, perhaps they simply ask “What do we do right?  What do we do wrong?” and perhaps they limit the whole thing to an hour, and perhaps the team leader or project manager acts as facilitators.

Such retrospectives are unlikely to uncover deep thoughts because they are not asking the questions that will cause people to reflect deeply about the whole project.  Having a authority figure lead the retrospective will also cut off reflection, by leading this person is exercising their authority and sending a clear message “I am still in charge.”

Finally, the third failure mode of retrospectives is: Lack of action.  Things the team decide to do aren’t acted on.  This is actually closely related to the first two.  If it is hard to find the time for a retrospective do you have the time to make the change?  More likely you are risk averse.

And if the authority figure isn’t open themselves then they are not going to be fully behind the change.  This will be clear to anyone tasked with making the change.  That is, if anyone can be persuaded to take on the task.

Arie de Geus pointed out in his book The Living Company that when you have more people involved in making a decision it might take longer to actually make the decision but taking action once the decision is made will be quicker.  This is because more people were involved in making the decision.  If a retrospective is half hearted then any decisions will not have wide buy-in so taking action will be a slow process.

So what’s the answer to these problems?

Well I think I’ve realised were I was making my mistake.  Like many other people I’ve been seeing retrospectives in isolation.  As some kind of plug in solution, nicely self-contained.  But they are not, this was the mistake.

I’ve realised that retrospectives need to be embedded in a learning culture.  I used to think they could be one of the early tools to use in creating such a culture, now I realise they are an advanced tool to be brought in once you have the culture in place. 

An organization that does retrospectives is an advanced learning organization.  Most organisations are not learning organisations let alone advanced ones so it is hardly surprising that retrospectives are missing.

When you have such a culture not only do people value learning but it is a priority for them.  They make time for learning events.  They value the results and they take action.

In such a culture people feel less threatened by what might come out of a retrospective because they are accustomed to deep thinking and reflection.  Everyone knows the rules and people are open to insights and change.

In a learning culture managers have already accepted that the team knows best.  They have already changed the view of their role from command-and-control and “boss knows best”.  They define their role more in terms of helping individuals and teams learn and advance.  Neither are they threatened by loss of authority.

Finally, when you have such a culture, when people are not scared or threatened, when everyone appreciates the value of holding a retrospective then change does happen, people do follow through on the action identified in the retrospective.

So, how do we create such an advanced learning organization?  Well, that will have to wait for another blog entry and even my book.  In the meantime, if I can help with a retrospective or creating a learning culture please get in touch.

The SPA conference is on this week and I’m not there. SPA is a good conference but being so close to the ACCU conference I need a very good reason to go. Since I’m not speaking there I’ve skipped it.

The BCS SPA group also holds monthly meetings which I sometimes go along to. About three weeks ago I went along to a very interesting talk entitles “Large-Scale Agile Application Development”. In fact the talk was actually about how BT had adopted Agile development techniques. This was quite a challenge as those who know BT know that it is a very large company, a traditional telco and at one time a nationalised industry. There could be few more challenging environments into which to introduce Agile.

BT haven’t completed their Agile transition but it seems to be going well. Fortunately they had high level management backing on their side and all the kind of resources big companies can bring to bear on these problems: training, off-site boot-camps, consultants (mainly from Exoftware) and other resources.

I was particularly impressed by two of their ideas.

First was a plastic credit card like “pledge card.” I’ve seen these done by political parties in the past but this one was for “BT Core Agile Delivery Practises.” On one side was the Agile manifesto and on the other was BT’s core practises:

• • Customer collaboration

• • User stories

• • Iterative development

• • Automated testing
  • Continuous integration

The card strikes me as good because a) it was a constant reminder of the practises, b) it was very corporate so endorsed the idea that the company wanted this to happen.

The second idea was a pre-printed task card with the main fields a developer would use. I’ve seen index cards put through a laser printer before but this was more structured. It contained fields to help describe the work task, the priority and the acceptance criteria. Again good for re-enforcing the corporate message (“This is what we want”) and a reminder to teams as to what they needed to do. My only criticism might be that for such a small card it had a lot of fields to complete.

BT seems to have invested a lot in this programme. They had sent lots of people on training courses and held lots of off-site meetings and training.

They also spent a lot of time and money using coaching techniques. In fact they used pair-coaching with an experienced coach working with a new coach to help train the coach. To my mind this approach vindicates the coaching approach and shows how powerful it can be.

That say, it does seem the coaching model in use was very much drawn from the Agile coaching model rather than the model used by business coaches. The difference is that the Agile model is much more directive about what needs doing while the business model is much more open. Both have their place, I just wish Agile coaches were more aware of the other model and how it can help.

I went to a meeting of the UK Product Managers Forum last night.  This was the first time I have been to a meeting of this group and it is the first time that the group has held an event in London.  Naturally these two firsts are not unconnected!

I enjoyed the meeting, Ian Mapp of Respond spoke about the development of the product management function within the company.  This was very interesting itself, and as is so often the case the conversations with the other attendees was even more interesting.

These conversations support my belief that Product Management is not a well established role in the UK software industry.  When the product management doesn’t exist in a company there is a vacuum.  Without any guidance software developers will just develop the things they think are a good idea.  If there is a compelling need for your product this isn’t a problem in the short run: people need your product, good or bad they will buy it.

Nature abhors a vacuum and the same is true when product management is missing.  Somehow the vacuum will get filled.  In small companies it is often the founder(s), the CEO, CTO or similar who fulfils the role.  They often do it on gut feeling. If they are lucky they are right and the companies grow but then they don’t have the time to do it.

Sooner or later someone steps into the role.  It might be a project manager, a developer, an architect or even a tester.  These people do their best but they have other demands on their time – the job they should be doing.  There is competition not just for their time but their prioritisation decisions will be influenced by their duel roles.  Neither have they been trained for the role.

A lot of software development does wrong right here.  Without good product management to give customers a voice inside the organization companies will spend more time developing more features to sell fewer products.

(Product management can exist under the wrong name, I’ve met Architects who are really Product Managers and I’ve seen Project Manager roles advertised which are really Product Management jobs.  This just confuses things!)

The second thing I noticed at the meeting was how tight the profession is.  Most people knew of the Silicon Valley Product Group, 280 Group and Pragmatic Marketing.  Those of us who have ad product management training had had it through one of these groups in the US.  Again this is a sign of how underdeveloped the role is in the UK.  I believe this is about to change, Co-herence have licensed courses from the US and plan to deliver them in London.

The UK is not short of software companies.  It is short of product managers and product management skills.  Fixing the development process must involve product management.

If you are developing software application there are three things you must do:

1. Create a product management role (business analysis if you are in house)
2. Use source code control
3. Have a repeatable build process and run it at least once a night

If you aren’t doing these things then don’t bother leaving home, in fact, don’t even bother getting out of bed.  The scary thing is: most companies struggle to score two out of three on this list. 

(If I just scared you and you want help e-mail me, more on this next week.)

As an aside, Respond’s product is a customer feedback (i.e. complaints) management system.  Ian suggested that in some industries, notably airlines and mobile telecoms, the company got very little traction.  His conclusion was that for these companies customer service is not a high priority.  I can see his logic, if the companies in these sectors are not willing to spend money then it is reasonable to conclude that the companies do not see customer service as a priority.  One of the audience, form a major UK mobile phone operator took exception to this.  They claimed their company did take the issue of customer service and retention (churn) seriously. 

I’m in the process of reviewing my mobile telephone.  I’ve been with the same provider for 5 years now but I don’t feel like a valued customer.  The company has a memory like a goldfish – i.e. none – I might as well have been with them a year or a month.  I’d like to switch to another provider but a) I’m not convinced anyone else is better, b) it looks like my provider is actually the cheapest!