leadership – Page 2 – Amateur Coach

Courageous Executives – Coping without one

The notion of a “Courageous Executive” is not a new one. However, what is changing, is the awareness of how significant this organisational pattern can be when it comes to disruption and innovation. Here’s a link from mid-2017 from one of my former employers on the topic.

Relying on a courageous executive to solve all of your “agile transformation” related problems only really stands a chance of working if they have enough authority/persuasiveness to be able to get their way in the CxO arena. That might be fine for forward thinking / dynamic / exciting / other-superlative organisations, but what if your organisation doesn’t have that open culture? Or you don’t have access to someone willing to stick their head over the parapet? What if (like a large percentage of the working population), you work for a late-majority or laggard organisation?

I’ve been thinking about this sort of thing recently. Mostly because many of the bigger problems I face in my work life these days are all around how my large bureaucratic clients can work effectively with large, bureaucratic suppliers and partners, when everyone states they want “to do agile” [sic] and yet are afraid to change anything about their operating or engagement models.

I’ve been trying to organise my thoughts around “difficult conversations that are simplified/made trivial if a courageous executive existed”. I’ve also been trying to organise any messaging I deliver to my clients to make it easier to convert an existing executive (perhaps with a courageous bias) into someone who can be labelled as a Courageous Executive [massive disclaimer: I’m in no way going anywhere near a formalised definition, just pushing the boundaries of what my gut feels like]. I’ll write up as I go and link to this post.

Dear Board, what sort of “Agile Transformation” are you really after?

My problem with an “Agile Transformation” as a term, is that it’s not really helpful when trying to talk to people.

OK maybe if I used the definition of an Agile Entity as a thing that continuously adapts and evolves to best take advantage of it’s environment, then an “Agile Transformation”, being pedantic, could represent that first step the Entity takes from it’s Creation State to the first Changed State, with the constraint that the Changed State includes a working mechanism for internally triggered evolution (irrespective of how effective).

However, that’s also an unhelpful definition, as I haven’t seen that interpretation in anyone at C-Level who “buys an Agile Transformation Engagement from a Consultancy Organisation”. And that’s what I wanted to write about here. What I see there is usually something along the lines of “We should be better at our IT Development. Other organisations have used Agile and they seem to be better at IT. Maybe we should get some of that Agile IT to increase our effectiveness”.

Therefore I’m parking that thought, and once I’ve worked out how to clearly articulate what my opinion is on that subject, I’ll link to it here.

In the mean time, this is a list of questions I think are worth knowing the answers to as soon as possible in the life of an “Agile Transformation Engagement”. Or even before one starts.

Agile Organisations have very different cultural styles to hierarchical / bureaucratic / “traditional” (for the defensive clients) organisations. A Transformation Initiative (if such a thing can exist) will be about helping an organisation transform itself culturally into something else, one with more pronounced Agile Characteristics and Traits. I think anything that maintains the cultural status quo (especially if it’s a “negative-in-the-context-of-an-agile-organisation” one) is heading towards the Lip Service end of the adoption scale.

Warning: Some of these questions can be tricky to ask without risking being fired :-). All of these are aimed at either the Sponsor of the Transformation Engagement, or the C-Level Board if it’s broad enough.

Scope

Question: Where do you WANT to draw the boundary for the Transformation Initiative?

Question: Where do you HAVE to draw the boundary for the Transformation Initiative?

Outcomes

Question: WHAT do you define as “a Successful Transformation”?

Question: WHY do you think you need “an Agile Transformation”?

Question: Are you “all-in” on this Transformation? What happens if it’s not successful? Do you need a Backup Plan (or Escape Plan)?

Question: If the Transformation results in jobs changing, CAN you update your policy / HR strategy etc to suit? WILL you?

Question: If the transformation results in making some people redundant if they are unable/unwilling to re-train to the target operating model (candidates include middle managers), WILL you make them redundant?

Question: What did you have to do in order to get Board buy-in for the need for “an Agile Transformation”?

Question: When do you “need Demonstrable Results”? Why then? What constitutes “Demonstrable Results”?

Question: Do you have a “Trusted Adviser” to fact-check what you’re being told? If not, what is your level of trust? How can that be increased?

Sustainability

Question: What’s your strategy for sustaining the Transformation Initiative after I’ve left?

Question: What would happen if “after a while” (e.g. a couple of years), your organisation reverted back to the operating model as it stands now? Do you have to prevent that?

Finances

Question: How much are you willing to invest? Over what time frame? Is any of that investment conditional on evidence of progress?

Question: Can you tolerate the “Agile Transformation Initiative” as an annual overhead cost to be paid before projects and change budgets are calculated?

Question: Can you tolerate the “Agile Transformation Initiative” as just another project and therefore will need to justify its budget?

Agile Brands

Question: Is there a perception in the “entity-under-consideration” that Brand A/B/C is the right one? Have conferences, articles, experiences etc influenced that perception?

Question: Is there a strategic goal of “Installing” / “Implementing” Brand X? Or is the strategic goal “Adopting” Brand X?

Question: What happens to your Credibility / Authority / Respectability if despite the prevailing “Brand X Bias”, an alternative Brand is Implemented / Adopted?

Janus and the art of partitioning

Why Janus? Well, not only is he the Roman God of Beginnings and Gateways (or doors, transitions, journeys, that sort of thing), he’s normally depicted with two heads, one looking to the past or beginning and the other looking to the future. Seems to resonate with what I try to do with my clients – help them along a journey.

Why this post? It was triggered by me reading the book Unlearn by Barry O’Reilly. The book helped me crystallise or make explicit something I think I’ve been doing often enough to be considered “typical behaviour” – the act of unlearning.

I’ve been thinking about how to use this new found explicit conscious awareness to help my current employer (as well as my current and future clients). My typical role on an engagement is some form of…no wait, this link might give you a sense. Alternatively choose any number of words from the following set and arrange in any order to give you my title (naturally, duplicates are encouraged) “agile/ninga/coach/therapist/comic/beer-buyer/disruptor/transformation/hygienist”. The key thing about my clients (and my current employer) is that their overall delivery maturity is nothing worth writing home about. They’re certainly no bleeding edge delivery outfit, constantly testing hypotheses by using practical experiments, with unicorn tendencies.

So who hires me? Mostly Laggards and Late Majority organisations (See Everett Roger’s book Diffusion of Innovations).

What does that mean for me? Generally, the mental models I have in my head for how “software delivery should work” are two or three decades(*) ahead of the executives and senior management types that I spend time with. That means that unless I take great care, I’ll end up using language that’s incongruous with the recipient’s world view. And there are enough snake oil salesmen out there to replace me, making it easy to put lipstick on a pig – see the Internet on cases where “agile transformations don’t work” or “agile transformations not delivering on orders of magnitude improvements” or variations on the theme. For me, that’s Janus looking forwards.

How am I trying to solve this? I learned a foreign language. This one’s called “Management from Yesteryear”. I learned it because if I was to stand any hope of working out if something I say is being misinterpreted, then I need to understand how it’s interpreted. Some people could call this empathy, but I disagree. It’s more a model of a person from the nineties (say), to help me understand how a real person would behave. For me, that’s Janus looking backwards.

So how does Barry’s book fit into all this? Well I realised that if my client needs to evolve by 20 years, they’ll need to go through an awful lot of unlearning and relearning. That’s assuming that if someone is going through that much evolution, they’re able to skip a few of the intermediate states. If that’s not possible, well that just increases the amount that needs to be learned and unlearned in a comparatively short space of time.

So what I need to do, is help them get starting along that journey, and supply the occasional nudge if they start going too far off track – say unlearning something that’s still relevant or learning something that isn’t helpful. That’s harder than it sounds, as it’s tricky to understand what off-track actually means, not to mention how on earth I’d be able to observe this. What would be ideal, is if they themselves could work out how to tell if they were going off track. A more realistic scenario is that I’d have a sense of how they’re thinking and try to use that to gauge the degree of discomfort they’re feeling and from that attempt to infer the degree of off-track-ness. That said, sometimes it’s helpful in the longer term to learn something, realise it’s incorrect and fix that. All adding yet more uncertainty into the “are they on track or not” overly simplistic question.

That’s where my internal-model-of-a-person-from-the-nineties comes in. I fancy myself in (very) amateur dramatics circles, as someone of the method acting school of thought. When working with someone, and I’m asking them to go through cycles of unlearning and learning, it seems only fair that a part of me goes along that journey with them. It’ll help me build some empathy. It’ll also help me spot when things aren’t going well, because in addition to seeing their expressions, I’ll be feeling similar things too. It’ll help them trust me a little more than otherwise. It’s a great way for us to discover potentially exciting new things that neither of us would have foreseen. And finally, that shared experience is also a good foundation for building some psychological safety.

A brief segue into psychological safety.

I’m trying this approach with my current client, and so far it’s been proving to be an interesting experiment. I’m not too clear about how cleanly I’m partitioning the me-from-now and the virtualised-me-from-the-nineties, but if nothing else, I do appear to have more empathy and connection with my client. So that seems to be positive. I’ll keep trying this approach and see if it gets any better or give’s me something different. Might even blog about this later.

(*) I know that sounds harsh, but for example organising teams by components and architectural layers for efficiency reasons is just so nineties. And not in a cool retro way.

The Importance of Psychological Safety

It’s vital for making mistakes and learning from them.

It’s not a new idea.

Hard to give. Easy to take away.

Children have a lot. It’s usually drummed out of them at school.

Adults don’t have much. People who do are seen as “brave”, “courageous”, “bold”.

It’s infectious. People who work with those with a lot of psychological safety, begin to feel safer.

Managing the risk of learning: Psychological safety in work teams – Amy C. Edmondson Associate Professor, Harvard Business School
Psychological Safety: The History, Renaissance, and Future of an Interpersonal Construct
High-Performing Teams Need Psychological Safety. Here’s How to Create It – Hbr.org

Team Stability vs Personal Freedom

Background

I’ve been thinking about a project team characteristic that I’d never previously worked with before. This project had a dedicated staffing stream of work, which supported an ongoing employee rotation plan as part of normal project execution. Any given team member would have a 9 month stint, after which they’d rotate off the account and go do something else. With the size of the project team as well as some contractual constraints, that amounted to about 3-4 people a month, or nearly 1 person a week.

The Bad News

A basic awareness of group dynamics as considered in Sociology, Psychology and whatever other -ology you the reader is fond of, leads to a conclusion that highly effective teams take a while to emerge from a group of people. These patterns have been articulated, perhaps most famously by Bruce Tuckman (i.e. Forming-Storming-Norming-Performing) but other variations and extensions have been suggested.

Tuckman_0

Of these stages, the Storming stage is the most difficult stage, and many groups never make it past this stage. Teams that do make it through this stage, have invested in the time it takes for individuals in a group to establish some form of social structure along with compatible working patterns, relationships etc. These individuals have learnt how to build on their collective strengths, as well as offset the weaknesses that each of them, as individuals, bring.

Team Effectiveness

Each swap made within a team reduces the stability of that team’s position in the team maturity model, and significant enough disturbances can move a team from a relatively comfortable “performing” state, down a notch, to “norming” and potentially even worse, a rather torrid “storming” state. The team would need to invest further in order to rebuild and develop into a high performing team. The practical upshot of this regular rotation is that the project team will always be struggling to maintain the highest potential performance.

Domain Knowledge

A second, more insidious side effect, is that the team as a whole may only really have a relatively shallow level of knowledge and expertise in the problem domain they’re solving. Picking up the basics of any new context is easy enough. However, to really build up a nuanced understanding of a domain, a person requires a decent amount of time to carefully mull over a stack of facts, figures and data points. I’d argue that it takes at least 3-6 months of focussed learning before enough is known about a new domain for significant decisions to be made safely. With a 9 month term, that suggests that really, a person only has, at most, 3-6 months of meaningful work before it’s time to move on.

A Sense of Purpose and Belonging

One of the joys of working in a highly motivated team with a strong sense of purpose, is the feeling of accomplishment when a milestone is reached (as long as that milestone is meaningful to the team). With team membership always having a tangible end date, it’s much harder to really get a sense of belonging to that team, and (deeply) feeling that sense of purpose. There’s the danger that an individual feels like they’re a replaceable cog in a machine – largely because that’s what will happen as everyone gets replaced fairly regularly.

The Good News

It’s not all bad news. On the plus side, it does put the individual’s “perspective” at the centre of the project’s thinking. As an individual would only be exposed to a problem domain for a finite period, it means that there is a regularly changing supply of new things for them to think about. That can include new problem domains, new implementation technologies. This can help keep the individual fresh, enthusiastic, and in an explicit learning mode for much more time than otherwise.

Additionally, the downsides are potentially easier to deal with. In the event that the individual isn’t compatible with the project and the demands, it’s easier for the individual to just “grin and bear it” for 9 months, as there’s light at the end of the tunnel, and the individual doesn’t have to do anything drastic (e.g. resign). Worst case and an earlier exit is required, that’s also likely to be a lot easier to deal.

Another advantage is that it can make something that isn’t long term sustainable (e.g. remoteness of location) something that is more sustainably managed, as it distributes the workload across a greater number of people than if the team were fixed.

An interesting potential positive, is that this forces a few XP principles into the team (if they’re not applying them already):

KISS: If nothing else, the team have to reduce the complexity of what is being built as there will be a regular (and ongoing) instances of a new person having to learn about what is being built. There’s relatively little that can be done to reduce the inherent complexity of the problem domain but navigation aids (e.g. context maps) will help and are recognisably important investments

Automated testing and test coverage: New starters generally go through an initial period of higher-than-normal anxiety as that’s when they’re operating almost entirely in the dark. As this is a regular occurrence, it’s unfeasible for a project team to “cheat” and ride it out (which is a possible approach if you’ve got a permanent team). Automated tests and a high coverage are a safety net, making it much less scary to work on code Again, that’s explicitly recognised as valuable.

Collective ownership: As no one person will be around permanently, it’s much harder for territories to be formed beyond team level boundaries (in a multi-team project) as the only things which are “stable enough” to be able to own anything (along with the typical behaviours of defending it, curating and growing it etc.) is a team. However, this is a double edged sword, as it’s also possible that in the face of a significant enough problem, some deflection might occur (e.g. “oh that’s not my/our fault. This was <Person X, now left>, they’re to blame”). This “no-responsibility-anywhere problem” is a normal part of collective ownership, it’s just more likely in this model than in stable team environments, as it’s far easier to blame someone who isn’t around.

Conclusion

I’m treating this project execution model as just another lever to be adjusted as necessary. My current focus is on optimising for a sustainable and resilient project team – one with a high enough morale to cope with the difficult circumstances that the project needs to execute within, with the employee characteristics that are available to me. In this instance, I’ve got over-supply of graduate and apprentice developers, but a scarcity of senior and lead developers. I also have a project location that’s a little too far away from home base for comfort, and a mandated work pattern that throws the work/life balance off kilter.

My key measures are employee engagement & feedback, general mood measures and team retrospectives (shareable content only). Additional measures include sickness days (as a potential visualisation of a deeper problem), as well as the levels of enthusiasm and participation in non-core work activities – e.g. community events etc.

My key feedback mechanisms are regular 1-2-1s (I’m trying to catch up with at least one project team member every day), open Q&A once a week and more formalised “account update” sessions once a quarter.

Power Models and Method Affinity

a.k.a. why are some people SAFe oriented, others DAD biased, yet others LeSS enthusiasts, and not forgetting the DSDM gang, the Nexus collective…and I’m running out of terms.

I’m sure there are a whole host of reasons, but during my time observing people, and knowing a bit about their past and what they’re like, it has led me to form an interesting (to me anyway) hypothesis. It’s to do with power.

A Brief History of Power

Without digging too far too much into Taylorism or others, there are a handful of basic power models that can theoretically exist in an organisation (heavily simplified for illustrative purposes, as real life is never this “simple”).

Power in the hierarchy, the higher up you go, the more power you have
Power in the middle management – sometimes disparagingly called the permafrost
Power on the edges – people on the ground in front of customers

These can manifest themselves onto a project context in a few ways (note for want of better options, I’m labelling these categories with overloaded terms)

Power lies with the “planners” – e.g. project managers, PMO
Power lies with the “architects” – EAs, Solution Architects
Power lies with the “developers” – developers, testers, BAs

Human nature is such that we flock towards things that are like us. Planners are more likely to favour other planners, and work using systems where the balance of power is in their direction. The same sort of thing is true for the Architects and the Developers.

Methods

And now we get to the Methods part of this blog. I’m going to focus on agile methods, and agile scaling frameworks. And in particular, how these methods and frameworks are perceived, at least initially. That bit is key. Most of this “natural affinity” stuff is emotional in nature, and not fundamentally driven by rational thinking (hint: there’s a lot of religion in this area). As there are lots of them out there, I’ll just pick the three major ones (based entirely on how often clients talk to me about agile at scale, and nothing remotely scientific).

SAFe

The overall guidance is dominated by the navigable map. It has several terms that will be comforting and reassuring to hierarchical type organisations with traditional reporting lines and financial controls – Programme / Portfolio Management, Enterprise Architect, as well as some guidance on mixing waterfall and agile deliveries. This looks to be solidly planted in the middle of the “Planners” camp.

Based on the hypothesis, likely proponents and allies are to be found within PMO, Project Governance,Configuration Managers, hierarchical organisations with a centralised power model, and organisations that perceive themselves to be traditional with a rich history / heritage.

DAD

The first thing that strikes you when you first look at DAD is that it’s rammed to the rafters with choices. It has a risk-value lifecycle (but you can choose others), many options on how to achieve pretty much any delivery related goal that you may have – from big ticket items such as considering the future – how much architectural insight do you need, to very focussed options like the right level of modelling to use. And that’s just part of the “Identify Initial Technical Strategy” goal. This resonates well with those with an architectural bias – architecture is mostly about decision making and communication.

Likely proponents and allies are to be found in technical leadership – Architects, DBAs, and organisations with a strong technical bias.

LeSS

The navigation map for LeSS in contrast to the previous two, looks relatively uncluttered. There are large concepts identified (such as Systems Thinking, Adoption) but these are all located around the periphery of the diagram. Slap bang in the middle is the engine, and those are feature teams. This puts the Developer at the centre of the universe (as it were).

Likely proponents and allies are to be found within teams and individuals using Scrum and XP on a regular / daily basis, and organisations that “have a small company vibe”, which may be startups on a growth spurt, or organisations in a highly fluid environment with significant localised decision making.

The Goldilocks Solution

As the heading suggests, I think the right mix for any given organisation is somewhere in the middle. Power isn’t solely contained within a single area (though granted, in many cases, the vast majority of the power is indeed concentrated that way), and any scaled agile adoption strategy will need to understand and accommodate that to increase the chances of tangible benefits being felt by the organisation.

Feedback

As this is just a hypothesis I’ve got, I’d love to hear what you think, whether you’ve observed things that support this theory, disprove it entirely, or somewhere in between.

A culture of learning

It’s no secret that teams that have a “culture of learning” outperform similar teams that don’t care about that sort of thing. The Internet’s full of articles extolling the virtues of such a culture, along countless articles offering suggestions on things to do that would help you develop your learning culture. There’s a lot of good sense out there, but in my experience, it’s not really possible to develop (or introduce) a “learning culture” as a discrete thing. There is no carrot & stick solution that’s resilient to real life.

The best I’ve been able to do is make it possible for my teams to believe that it’s worth learning new things, growing and sharing. Mostly because it’s more fun that way. As a species, we are if nothing else, driven by emotions. Hopefully positive ones.

Learning new things is a risky business. For a start, if it’s something difficult, or requires lots of practice to master, then you’re going to get things wrong. A lot. Making a mistake is often seen “in the corporate world” as a bad thing. With penalties like “poor performance ratings” if you’re an employee, and terminated contracts if you’re self employed. Ironic really, as we tend to learn the most valuable stuff while making mistakes. So another thing that I do to help my teams, is make it OK to make mistakes, to break things. On one project, that was a counter – everyone was allowed 3 epic fails. On another project, it was “as many as we needed to in order to do the right thing by our customers” (we were very user need driven so we had lots of empathy with our users).

On an explicit front, we introduced “Lunch and Learn sessions” – once a week, for 30 minutes. The list of topics was on a (Product) Backlog – well, a whiteboard with a load of post-it notes on it. Anyone could add things to the backlog, and re-order things as they saw fit, with a deadline of the morning of the lunch&learn day. It started off as me giving the talks, which after a couple of months, saw others offering themselves up as speakers for a subject they were keen on. It wasn’t limited to digital development either. One speaker wanted to talk about macro photography. We were able to round up guest speakers from other projects, and they were usually delighted at the chance, and in payment, we would give a talk to their team in exchange. One session was a live demo – our accessibility specialist brought in a blindfold and some headphones, and we were to try and use the website that we were building, but from the perspective of a blind user. Talk about an eye opener!

On a subtle angle, we used lots of pairing and collaboration techniques to spread the knowledge about, as part of “doing the day job”. We tried to get the default model for solving a complex problem into one where a person finds a teammate with some time and they work it together. So by necessity, we introduced a little slack time to help with this. Irrespective of role, seniority or time on project, we all tried to treat each other as equals (part of our team charter that we signed up to when joining). That made it “OK” for information to flow around, and made it part of being in this team.

If you think all of this sounds like hard work, well you’re spot on. We had to invest heavily into creating the conditions that would make a learning culture more likely to happen, and we had to do it in a way that didn’t completely alienate us from the rest of the world (though there was a rumour that we laughed more than everyone else in the building put together! And despite such frivolity, we were easily the most effective team in the building). We had to sustain the effort too, as we were looking to build a lot of good habits (once an activity becomes a habit, it becomes significantly easier to do as there’s no longer the need for conscious willpower).

No can be a great response

Fear. The desire to please. To not look stupid. Bravado. Saying no is hard. It might be confrontational. You might upset them. The world might end. Aargh! Better to say yes and suffer in silence. Martyr yourself.

No to a feature request when your team’s already got a hundred.
No to a suggestion that clearly doesn’t make sense with everything else you’re doing.
No to another task in your in tray that you won’t get to for ages.

Learn to say no. But say it graciously. You’ll build integrity that way. It’s better than leaving your customer hanging, believing that you’ll do something you’re not going to.

Hiring Developers

“We need 6 developers to start in 2 weeks!”

“We have to have 2+ years’ experience of everything in the full stack”

“We’ve not got that much development work for the next couple of sprints, so another project can pay for 50% of our developers’ time and get some work done, and we save money”

Any of these sound familiar? If so, you might be trying to have your cake and eat it. “Agile” ways of working move the centre of power into the delivery team, which can be hard to deal with, especially if you’re in a more “traditional position of power”, like a Project Manager or the Head of Department.

One of the lesser understood principle in the agile manifesto is the subject of websites such as http://12thprinciple.org/

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

What does that mean in practice when your teams begin to detect a skills shortage? If you’re in a leadership position, you might be tempted to try and fix this – after all, that’s what you’re supposed to do right? Deal with those pesky blockers. You might need to know what the scale of the problem is, and seeing as you recruit in whole numbers, you might need to translate the size of the problem into a “number of developers”. What sort of skillset should they have? Your team’s trying to do some complex stuff, so you’ll need someone who could do all of it right? Your management structure or your client is complaining that work isn’t going fast enough to meet a key date so you’ve got to increase your capacity somehow?

It’s worth taking a step back to think about just what the team is responsible for. It’s pretty obvious that they’re responsible for doing the actual work. What can sometimes be overlooked, is that they’re also responsible for how they do the work. And that includes who does the work – part of the team’s responsibility is to make sure it has all of the skills needed within the team. If they’re detecting a skills shortage, they’re best placed to try and find the right fit.

As a leader, you’ve got to worry about your organisational recruitment – pay and conditions, legal requirements, that sort of thing. But don’t let the mechanics of recruitment be your only process – make sure you’re recruiting the right person for the team. You’re not looking for a generic skillset, you’re looking for someone to fill the very team specific hole they’ve got. And they know exactly what that hole looks like. I’ve had the most success when I’ve let the teams recruit their team members, and the leaders sort out the paperwork.

And as for the third example at the beginning – my only real advice is to avoid doing that. Teams are entities in their own right and it’s well worth thinking about them as atomic units. Chopping and changing internal team structures is generally only really good for disrupting the work. If your team’s got a little slack time, use it productively – pay off some technical debt (there’s always some). If you’re in the ideal situation, then why not just reward the team with some R&R? They’ve probably earnt it.

Building credibility

There are a lot of approaches to building a good relationship with your client. All the ones I’ve seen boil down into a couple of basic themes:

Option A: keep telling them to trust you and believe you. Maybe one day they will
Option B: Keep your promises and do stuff for them. Let the evidence do the talking

Most of the projects I’ve seen that end up with a confrontational relationship between supplier and customer have used a variation of Option A. For a long time. Customers get frustrated when they think they’re being lied to. And not doing what you say counts as lying.

One of my recent clients had been burnt badly by the curse of large failing IT projects. Their operational units were disengaged with their IT Department as they’d been let down for the best part of a decade by cancelled projects, cost overruns and major defects. Like many others in that situation, they’ve done what they could to work around their “substandard” technology. You’ve seen this too – businesses running on strange Excel spreadsheets with even stranger macros.

What we did could be considered by “old fashioned IT Departments” to be tantamount to treason – we integrated with the business. So much so that we requested that at least one representative of the business be part of our delivery team and be part of doing the work. And we wanted regular access to the operational unit so we could run workshops, run demos etc. Sadly, they had to draw the line at the delivery team being located on the operational unit’s floor (no desk space).

And we did stuff. Iterative development models have an end-of-sprint demo event, so we demoed what we’d built to the business. They’d give us feedback, and two weeks later, they saw the effects. They saw us listening to them and doing what they asked immediately. Their voices mattered. We never told them to believe us or to trust us. We never had to. We just demonstrated that we were trustworthy and they took the initiative. Part of being trustworthy was saying “no” (with a good reason) when we needed to.

And when we launched the first version of the system, trust was even more important. Because now their customers (the public) would also see the system, what we’d built had an effect on how the customer perceived the business. So, when demo after demo we showed them the changes we’d been making because of what their customers found difficult or confusing, the goodwill that created was simply huge. We’d shown the business that not only did we listen to them, we listened to the people they thought were important – their customers.

That’s a lot of credibility.