The Fates of a successful IT project

When Agile came up, it had a high barrier to entry, mainly because it was a real shift from traditional software development methods, but also because of its jargon and ceremonies: stand-up, iteration, card, points, technical debt, owner, customer, retrospective, etc. But now that Agile is mainstream, most companies have tried these things out, more or less successfully, and the initial mindset of challenging the “status quo” is probably long gone.

That is the reason why in this post I would like to come back on the three principles that are the most essential to a healthy IT project, and have proven very valuable in my career as an Iteration Manager or Tech Lead: Transparency, Team, and Waste. While they could be applied to any methodology, I will relate those principles to Agile practices, so that you have something concrete to take away.


What if you’re project is not going well at all? What if you have disengaged stakeholders, unhappy customers, low morale within the team, and no clear view as to where the project is going and when it can be completed? In this case people will have the tendency to become defensive, protective, even maybe secretive. Things could go political very quickly.

One of my colleagues once said Agile should simply be called “transparent delivery“. If you want to avoid inflating the bubble, keeping the project stakeholders in touch with the reality using clear representations on the project status from different perspectives (business, budget, technical) is really important. Make sure that project indicators and signs are in place from day one, clearly visible, and seen and understood by all. In an Agile project, there are usually various “information radiators” for that purpose. The project or iteration wall is definitely one of them. Also, having a visible backlog is essential to customers and product owners. Finally, technical indicators like bug counts, build lights, or tech debt are useful for developers and testers.

If you are unlucky and the bubble is already close to bursting, a little bit of courage and honesty can make a difference. In this situation you may find that mid-level or top-level executives are usually much more pragmatic than managers and will be more helpful and supportive if you have a plain honest conversation about the project. In my case I found that inviting them to the showcase and depicting things as they are can pay off, as long as you can propose changes to improve the situation.


The most important thing in an IT project is the team. Let me repeat that: the most important thing is the team. What does it mean? If you are in a project that goes bad, then leave the angry customers, the money, and the managers raised eyebrows aside. Instead, focus on regrouping the team.

Now it is fair to wonder “What makes a winning team?“. In my experience, beyond anything else (talent, salary, environment), the two main ingredients are morale and trust. Tuckman’s forming-storming-norming-performing model details the different phases the team will go through before it can be effective. I believe maintaining morale greatly helps having a “norming” team, while trust is the key to reaching the “performing” state.

To raise or maintain morale, I like to use Appreciative Inquiry during retrospectives. Each participant writes down something she is grateful the person seating next to her did in the last iteration. Notes should be read aloud, and each team member leaves with an energising post-it to stick to its monitor. Another technique is to use humour as often as possible. Below is an example where the team gathered funny statements in the stories management tool

Screen Shot 2013-11-16 at 12.21.09 PM

I love this technique because it proves that people talk and listen to each other, and that they are having fun. It also helps bridge the gap between introvert and extravert.

Establishing trust is probably more difficult. The Wikipedia page about Tuckman’s group development model mentions (about the norming state):

The danger here is that members may be so focused on preventing conflict that they are reluctant to share controversial ideas.

Indeed, an element of gaining trust is to challenge each other, particularly on sore points that make the team inefficient. I always found that people will trust you even more if you disagree with them. Also empowerment is important. Letting the team taking responsibilities for design discussions, organising showcases or important meetings with key stakeholders, or teaching junior developers (through pairing) will provide the reward they need for a both ways trust relationship.


In the last 5 years, lean principles have become increasingly popular within the IT industry. Preached by Eric Ries in his The Lean Startup book, principles like continuous deployment, lightweight processes, failing fast, or pivoting really help IT organisations refocusing their effort on discovering the shape and form of a product as it is being developed. It dramatically reduces waste by starting with nothing and building cheaply and effectively during the journey.

For me the underlying fundamental principle of a lean and agile team is really to cut the nonsense: do only what is strictly necessary for delivering a good product as early as possible. There are so many things that IT teams produce, which will never see the light of day, or are pure wasted time, it is astounding! To use an analogy with Taxis, it is a bit as if the driver would take you to your destination but going through another city, maybe because he thinks that is where you want to go. If you are in this cab, make sure you stop him at the city outskirts.

Again several techniques are on offer to reduce waste. Early user testing (before the product is built or the story delivered) will assure that you develop the right product. Prioritising the backlog with the customer and/or product owner frequently ensures the team delivers the most important stories first (and maybe only). Story kick-off with most of the team members (and particularly BAs and QAs) ensures that we all understand what needs to be built and the developers do not go on a tangent. Finally having clear and detailed acceptance criteria will guide the developers throughout the delivery of the story, forcing them to focus in fulfilling those criteria only.


The table below recaps the three fundamental principles of a successful IT team/project and the corresponding techniques I recommend you apply.


  • Information Radiators (iteration wall, backlog, technical debt, build lights)
  • Plain and honest showcases


  • Appreciative enquiry during retrospectives
  • Humour, like statements of the week
  • Empower the team with design discussions, showcase organisation, or technical challenges


  • Lean principles
  • Early user testing
  • Stories prioritisation, kick-off, and precise acceptance criteria

Be disruptive, be yourself

What is the best attitude to adopt when coaching teams disruptive and innovative techniques? I am often balanced between being over detached or over involved. Naturally, I am more of the flesh and bone kind of person, being more confortable when things get personal. But as a consultant, particularly at the beginning of a gig, you can’t do that. So there’s been a few cases where I have had to push myself, behave differently, consciously, do something I would not naturally be inclined to do.

At ThoughtWorks we are required to intervene when projects are going astray, or when productivity is low. The emotional impact of having someone external invading your personal space, this very space you may have nurture and cherished for many years (if you are a long term, loyal and dedicated employee) is huge. I have worked with colleagues who can very easily appear as experts and distill deep thoughts and knowledge in a very effective manner. Me, on the other hand, I really like to sit down with people, discuss, balance, counter balance, agree more than challenge. In short, I am more of a facilitator. So, back to this client you have to convince you are here for the greater good. If you are too prescriptive, then he/she may think you are an a**hole. If you are too nice then he/she might wonder why your rates are so high. So here is how I have gone about it on previous projects: be disruptive, then emphatic, then yourself.

Be disruptive

Take a risk. It does not have to be a massive one. It can be as simple as organising a team lunch straight away. Simply, do something different from what the team is used to, on the very first day. I few examples. During stand-up ask the team to clear the Iteration wall of all cards they don’t currently work on. Rip a card and burn it (or just put it in the bin). Spend one hour with a dev asking technical questions, even if you are a PM/IM, etc…  The reason for doing that is to show that you are ready to put your a** on the line to get things changed. It may be perceived as a bit cocky initially, but it pays off, if you do what follows.

Be emphatic

If you managed to establish yourself as a change catalyst, people will naturally come to you  to share concerns. That is, if you are receptive. At this point you should do your best to listen, take note, and do something if you can. This is also a very appropriate time to get to understand the root issues that the team are having, and talk to the deciders/leaders to see how to address them. If at this point, if you manage to ID and remove a blocker you’ve set yourself up for success.

Be yourself

There is always a tipping point in an engagement (unless it is a very short one), where you start feeling confortable enough, and know the people well enough, to act naturally, as if you were a full-time staff. In the past I have sometimes felt a bit awkward when this happened, because somehow, as a highly paid consultant, I always felt I had to deliver value in a productive way, 100% of the time. Well, I now realise that most clients value more your ability to integrate in their team/organisation than your expertise. This is why I strongly recommend to be yourself, as the best way to position yourself at them same level than your customers. Of course, if you have a strong personality, have been a consultant for 20 years, then maybe I should say tame yourself…

I hope this few lines can help anyone who is starting a new job or a new gig as a consultant. It certainly did help me.