What's it like to digitalise?

15. September 2015

Arbeiten Sie schon agil?

Die Energie, die agile Projekte und agile Teamstrukturen in ein Unternehmen bringen, ist ansteckend. Sie kann gerade in Umbruchsituationen vermeiden, dass sich Silos bilden, und dass Angst vor Veränderung eintritt. Ganz im Gegenteil, sie schweißt zusammen und wird ein Treiber der neuen Prozesse und Strukturen.

Mein Fazit der letzten 2 Jahre: Agile Teams zu führen, ist eine echte Leadership-Herausforderung, aber die Dynamik der tollen Zusammenarbeit aller rockt! Ich will mehr!

Hier ein Artikel, den ich in diesem Zusammenhang für den FAMAB Blog geschrieben habe: http://famab.de/blog/arbeiten-sie-schon-agil/

9. July 2015

If change is good, why do we resist?

We all love change, n’est-ce pas?

Being an agent for change. Driving change. Creating new ways of working, processes, business models… all that is great and something most business people would say they enjoy and stand for. So why is it that when change “happens” on a larger scale, many people have a strong degree of resistance to it, find it hard to participate in a constructive way. Even when they know and believe that the path the business is currently on, is no longer viable?

Surely only those who are living in the past want for things to remain as they are. Most people I know consider themselves agile, flexible, modern, driven, adaptable… what is it that creates defiance to new processes, structures, software in them?

What’s annoying you, Paul?

When asked about why he thought everything was so annoying, a friend, let’s call him Paul, told me: “Well, I am not involved, I am just told I will have to do x, y and z in the future”. A “they” vs. “us” or worse, “me” perception and attitude is a killer to constructive change.

It’s all about ownership

See, people like Paul are used to running with their part of the business. They have freedom to move in their own field of expertise. If Paul’s business is now going through a major change process, Paul will not have the same degree to decide, but the capital mistake the programme owner, senior management or whoever has initiated the change process has made is lack of involvement. Paul doesn’t feel ownership, he has not been able to contribute and his rather normal reaction to a fait accompli, which has been created by someone else, but which strongly impacts his part of the business is at least to stall. Paul crosses his arms and says: “No one spoke with me about this, how can “they” know this works?” – and finds 10 reasons why the new approach will be utterly useless.

At this point, this particular change process needs to be considered a failure.

You want someone to embrace an idea: you need to at least convince that person. But much better: involve them in the creation of the idea, make them own it. Every wise woman will know how to influence her partner, so that he considers major ideas to be his own.

This is no different in business: you make me want to do something? I will invest myself, time and effort and I will then live new developments and motivate and convince others.

Of course, communicating with people, bringing them on board is time consuming at the start of a programme or project when management expects quick wins and results. But there really is no alternative, anything else is lethal for the outcome. Respect needs to be shown to those in the business who have knowledge, no matter their title or place in the hierarchy.

There is no news in all of this

All this is not new and it isn’t rocket science. In fact, it was taught in universities quite a while ago. The digital world brings a lot of truly new factors with it, this isn’t one.

Today, techniques like workshopping, prototyping and early stage UX testing can help and they provide powerful tools to expedite changes and engage executives, developers, anyone involved alike.

Bring on Mr. John P. Kotter and his book “Leading Change”, written in 1996. It is still valid. Here are his 8 steps to be taken in the right order as a recommendation for leaders who need to successfully tranform businesses.

An article by Mr. Kotter from 2007 really sums this up, and I encourage anyone involved in a changing/evolving organisation to read it, he concludes with: “In reality, even successful change efforts are messy and full of surprises. But just as a relatively simple vision is needed to guide people through a major change, so a vision of the change process can reduce the error rate. And fewer errors can spell the difference between success and failure.” (https://hbr.org/2007/01/leading-change-why-transformation-efforts-fail).

Having said all that: there’s also attitude to consider. Paul might have not been such a sceptic if he worked in a collaborative environment. If a company’s culture is toxic, lacking trust on all levels and cynicism prevailing in every day business life, change will be much harder to manage, than in a trusting, positive, hands-on environment. Kind of obvious, really.

I leave you with some lyrics by Jack Johnson from “Change”:

“Just when you were getting used to this place
You were getting used to these bones
You were getting used to the changes
Well the change won’t leave you alone

You finally caught up with the pace
The tough just might have got going
You thought you could trust all the faces
Well they’re only on one side of the coin

All these changes
Different stages
Turning page after page after page
It gets stranger day by day”

Keep moving, keep changing.

4. June 2015

“Beige” is frustrating – a rant

This is something that really bugs me and it has to come out.

Chances are, that when you are reading this, I am preaching to the wrong target audience as you are all with me, but I am (and here I get to use my favourite English word of all times) flabberghasted (!), annoyed, outraged and simply furious at how people can have leadership titles on their business cards, but not have one iota of courage in them to make decisions (good or bad) drive issues forward (rightly or wrongly) in order to move the business, a project, people ahead?

How can some people be perfectly content to be employed to lead people and projects and repeatedly, for weeks, sit in meetings, typing into their laptops or crossing their arms, which end with “ah well, we’ll talk about this again sometime” with no sense of urgency, time passing and no urge to take things into their own hands?

Is it not frustrating to never see any results and accomplishments?

No, quite the opposite! When spoken to directly, how can they not sink into a deep puddle of shame when hearing themselves say things like “Well, I only set the framework. The content, processes and decisions as to how to move forward are not my responsibility”. What? Well, whose are they then? Sorry, I don’t understand.

I am fully aware and not born yesterday: business decisions depend on more factors than one pushy person who sometimes rushes ahead of herself. I might polarise, but at least my team and I try to make things happen.

Of course, I am attackable and I believe non-deciders are delighted to point out shortcomings : I do not always remember to fill in request or report forms, I sometimes need to take detours and revise my plans or accept we need to do things differently, but how can a person be content to just write reports and pass on information, never leaving any marks on anything he or she does, shape how an organisation works, create products, decide or suggest how you deal with the money you have available.

A really good friend of mine calls people who escape her memory “beige”.

I wish I could ignore the colour (is it one?) beige, it is bland, neither here nor there, with no edge against the chili red spice you place in front of it, it blends into the background but – and this is important: you need to remind yourself lest you forget: it keeps looming there, even if you ignore it.

I like people in all real colours: warm, edgy, hot, soothingly cool, dark as the night – so I think I will need to take that beige canvas and paint it over this weekend with lots of sunny yellow.

Rant over.

4. June 2015

The “Annoying” Agile Development Team

“Enough of you and your annoying agile development stuff already!”

I laughed a lot at this outcry a friend (let’s call her Lisa) reported she had heard from her boss in a quick update meeting recently.

How did that happen?

Wasn’t this guy just proudly showing their shareholders progress in their latest product, raving about the quick prototyping process you’d gone through?

I wasn’t too popular when I said I found this reaction not all that surprising, it has happened to me before in business building situations, and it might be amplified in a situation where a business is under pressure to digitally transform.

The “Huddle” Effect

Agile software development methods are fantastic, aren’t they? You are quick to show results, you can react to business demands super fast, everyone is motivated, the culture of the team changes fast to become truly collaborative and multi-disciplinary rather than insular, you can adjust to changing budgets, you feel completely in the driving seat, empowered and responsible for the sake of the business. All this is great – yet you are “annoying” – how is that possible?

Well, what might have happened is that my friend just “lost” her executive. An executive in agile working processes is not necessarily the most popular role. Hamid Shojaee of Scrumhub.com about executives: “Then there are these guys – they generally get in the way, but it turns out you can’t build many products without them”.

Hang on, you might say when reading this, I am an executive, and I love the way my people work? You might, but even if you’re a hands-on leader with a strong operational focus, you are likely to have additional points on your agenda, some of them might even counter-act the goals of your scrum teams or squads and that might be perfectly reasonable.

“The Executive” and the Scrum Team

I mentioned empowerment a little earlier. Agile teams are empowered: to make decisions, to shape parts of the company, to swap priorities within their work – especially in more traditional businesses this will come as a breath of fresh air to the culture, and it will be motivating.

The executive now getting in the way might be a result of:

A: Project teams requesting to much attention for detail and time.

There may not yet be an established culture of linking and managing various scrum teams, so that they see a greater, joint responsibility, but that each team requests attention and decision-making (or maybe money) from the “annoyed boss”. Spotify speak about aligned autonomy in their video about Engineering Culture. This cannot be fixed through a traditional Project Management Office (PMO) with NPV calculation for project realisation and ressource alignment, it will have to do with the Scrum Masters working really closely together, defining joint targets and thus solving quite a few of their issues themselves.

B: The boss not being coached well enough

Hang on? Executive coaching? No, that’s not what I am talking about. Agile organisations are not necessarily easy to manage and it will take time for teams to adjust, learn and become efficient, at least a year, if not more. And, executives also belong to that team. So, an agile coach (as some people today call experienced Scrum Masters) also has the role of coaching the executive into living an agile role and needs to understand the constraints this person might face.

The executive, on the other hand, also needs to understand her or his role in the team and this may well vary from the role she or he are used to in more traditional project work (receive proposal, spend a long time making sure it’s perfect, sign off, don’t hear anything for months, big presentation, everyone’s nervous about meeting expectations etc.).

So, what happened to the friend? Why was she annoying and are they still on speaking terms?

Well, after talking this through for a while Lisa realised she was actually being pushy. Coming out of a sprint review, developer retro and sprint planning, she felt important adjustments needed to be made to the project scope. And, because her pace had become, let’s say, “agile”, she came across as overbearing and with an inappropriate urgency for her boss, who had (she didn’t know) just come out of a politically difficult negotiation and had a flight to catch. When he realised this wasn’t actually a matter of life and (electronic) death, he got annoyed and told her so (and wished he could go back to the world of presentations for a bit).

Resolution: they had a 30min meeting, which Lisa prepared properly, presented the status directly on the test system and right there a time and budget extension was signed off on.

So, even in the new world, old rules count: put yourself in your audience’s place and be to the point to save both your time.

Agreeing rules for collaborating is key, so that the boss isn’t perceived as slow and blocking the agile process and that the “product” is not taking an unrealistically large part of executive attention . Not much new there, then!

Sources:

1) Intro to SCRUM (by scrumhub.com): https://youtu.be/XU0llRltyFM

2) Spotify’s agile engineering methods, part 1: https://youtu.be/Mpsn3WaI_4k

13. April 2015

Can we please workshop that?

It might seem really odd that a question like that really put a smile on my face, but it did and here is why:

Running workshops including gaming techniques to create results rather than “meetings” is something we introduced as part of the agile software development process.

Soon after that, I noticed that my motivation to participate in “normal” larger meetings in other parts of the organisation decreased more and more. Why? I guess I just didn’t feel as engaged, I felt everything was too theoretical and I also thought I was wasting my time as often I switched off for quite a long time.

So, I started using simple workshop and gaming techniques more and more in reviews, in working through complex inter-departmental issues and every time it felt that valuable insight was gained. None of these meetings had anything to do with software or other technology developments by the way.

Therefore, when this colleague from a different part of the organisation asked me if we could “workshop” this topic next time, it made me pretty happy because we had made an impact on desired ways of working without imposing anything top-down.

Now, workshops and games are by no means the one-size-fits-all solution, but they:

create an open, participative atmosphere
energise the room
make people think (properly)
achieve consensus or democratic results
create a “we” effect
create a level playing field, eliminate personal issues
can create powerful results and point to further to dos beyond the workshop scope
are fun

Well, of course you can’t run every meeting as a workshop, but if you are looking to gather and group issues related to a broader topic and then drill down on the real core of a problem, when you have more than, say, at least 3 participants, they help.

I’d argue that workshop techniques help you prepare better for meetings (if only considering the material required), but you will have to be organised, moreso than just walking into a room and saying “right, what’s this meeting about now” when you’re supposed to be running it (and we have all done that).

What you need:

time to prepare the workshop and some idea of the tools you want to use
time to follow up (digest the results into manageable text, to dos, etc. (we use Confluence and Jira to handle this)
all relevant material
enough space in your meeting room/area
to be awake
patience – the workshop might move into a different direction than you might anticipate – but that’s all about being agile, and unless a group fully goes off on a tangent, which is entirely off topic, their focus might be more important than the original purpose of you getting-together
good judgement of the participants – how do they function as a group? Is there trust?

There are of course, countless books written on the topic and you can just about pick and choose any of them. One book and web site, which were recommended to me and which I find pretty easy to use without over-complicating things is Gamestorming (and no, I have no relation business or other, to the publishers and authors):

http://www.gamestorming.com/

So if you like what you read and saw: happy workshopping!

7. April 2015

People as “resources” – you only get what you give

“Get it straight buster – I’m not here to say Please, I’m here to tell you what to do and if self-preservation is an instinct you possess you’d better f***ing do it and do it quick.”- The Wolf, Pulp Fiction

Hm, might not want to try this at work, but it’s inspiring, Mr. Tarantino….

In a previous article I mentioned the requirement for top management to engage and motivate employees to invest themselves in the business in a situation of complete flux, restructuring, which may or may not make entire lines of today’s work obsolete.

If you decide to embark on a major change programme, if technology starts becoming part of your workflow, you will require “ressources”, in this case, this means people, who know the business and who may become key to making your project a success. These “ressources”, however, are not just numbers in your planning tool and it might come as a surprise that not everyone will jump through hoops to make change happen.

Agile structures and automation can create insecurity

People need orientation and becoming “agile” and introducing technology or automated processes creates insecurity around jobs, accuracy of work, and their in their own value to the business.

People in an organisation position themselves against others by the current status quo: job titles, salary, benefits, holidays, information rights – these are based often on job descriptions and tenure. Sounds like old economy? It is…. but it still is reality in a vast majority of companies.

Today… of course we want people to work differently… deliver on their day job (see job description) as well as contribute to project A, B, C, at any given time, be exposed to tools they never used, use and display different skills and adapt to a very different pace at work with much less predictability in planning, less regularity, swapping roles and fields of activity with high frequency – become “agile”, you know.

We may ask people to contribute to (agile, this is turning into buzzword bingo, I know) development projects and shape the company’s digital future, processes, structure, possibly field of activity through their work, who so far have not had any decision-making-power whatsoever.

The fact they didn’t have that power should come as no surprise in a more or less top-down world, but it’s worth: their managers would not have been empowered either…. at least not to the same extent as is now required.

Why is this difficult when you’re working on reshaping the business for the digital world?

I see different issues:

1. New skill-set requirement

In agile (software) development processes, which follow a certain pattern, commitment and decision-making is required not only from the Product Owner from a technical perspective, but also very much so from the “content owner” and his or her staff. These people have business knowledge and are now being involved in reshaping the business.

New processes, methods of working and doing business are being developed in highly effective, if personnel consuming workshops, things happen fast, new tools are being used widely (Jira, Confluence, PM Software, you name it), concepts are being derived from blue sky thinking, prototyping commences quickly, results are being seen, adjustments are being made – and things change fast. Everyone starts talking in technical terms, as an example: people who have used data in the past now speak about data models and start understanding SQL.

All in all that’s pretty cool, I think.

However, in a world where decision-making was always very clearly defined and was situated more or less solely at the top of an organisation, you are now asking “normal” employees to take on responsibility to a much larger degree, you ask them to display and tap into a different skill set than they needed to use previously (and they weren’t recruited for that).

Some people can’t just dig out analytical, conceptual thinking, a technological understanding and a highly structured way of communicating with developers or become process designers. And they should not feel less valuable for it, it’s not their fault. They must not be forgotten, it is them who continue doing the line jobs whilst everything else is in flux.

2. “This is not my job”

Whilst some people may rise to the callenge and love being exposed to different tasks, others might shy away from these “special projects”. They will retreat to their job description and current salary and say they weren’t hired to do “project work” and that they’re not being paid for it. This can be a display of insecurity, if so, try to encourage! It can, however also be an display of distancing oneself from the business. I question if it is possible to manage these people out of that corner and into motivated, flexible project contributors, they are not agents for change, they are resistant to it. Personally, I doubt that you want these people involved in what is shaping the future of your business.

You might want to test if you can pull them out of their corner and make them part of a new structure and get them to accept new ways of working, but that is a bit further down the line.

3. “What’s in it for me?”

Most employees are motivated by compensation. The second biggest motivator is career development, which over time leads to, correct, more money. A lot of people expect extra compensation, a bonus, a new job when they engage in project work, which in a business is often communicated as introducing groundbreaking change in a company. So people asked to contribute feel their work is more valuable than the line work they have been doing so far and they request to see what’s in it for them if it’s so important for the company.

Some “how to” thoughts on projects and people:

So, here you are, you have decided you need to change the way you go about developing your company further. And, you will need people to help you do it:

0. Breathe

Risk is you’re juggling lots of balls, everything is new for you, you sometimes feel like a headless chicken… make sure you take time to breathe and clear your head. Managing this is tough, and sometimes it is unnerving to deal with people and their issues. Yup…. but it’s unavoidable if this is to go right… just make sure you treat yourself well enough to then also treat others correctly.

1. Assess your culture

Is it normal for people across the business to contribute to important developments in the business? Are their views valued and their participation encouraged? If this is not the case, consider how you can explain why this is now changing and why you seek their input now. Expect people you have not interacted with or just given orders to to be sceptical. Expect people to come to you for pay rises or job spec changes.

2. Manage expectations about compensation

Communicate clearly what people participating in this process may expect in terms of additional compensation. If it is nothing, if you believe you can expect this as part of their normal jobs: say so.

3. Know your people:

It might seem like an obvious one, but you should know your people, you should know their skill set in their current job, you should know their degree of commitment to the business, their previous experiences, how they express themselves verbally, how quickly they grasp new stuff, how structured or maybe full on creative they are. If you don’t, do a skill-set analysis ahead of staffing your projects. These people are important, they will help scope your new, at least partly digitalised business. Spend some time with them, you will need to rely on them.

4. Identify the gaps:

It is most likely that you will not have all the people power you require to go through with such a big transformation in-house. Identify early what skills you’re missing, where you need them when (as well as for how long) and decide on whether to hire and train or whether to bring in consultants (who also require training), it is most likely you’ll use a mix of both. An article on consultants and managing this change will follow.

5. Delegate authority properly – define borders

Once someone is responsible for a whole project, or even a workstream, an Epic, for defining an API, whatever it may be: they are! You need to trust them and give them the required freedom to deliver results, and it is important to be straight to them that you will hold them accountable for results.

Having said that: this environment can get very pressurised and since all you’re doing is “new” there are limited best practice samples one can gain back-up from, so you need to offer yourself as back-up. Do not leave people alone, it is ok not to know which option to choose from time to time, be available – and ensure you are trusted enough so that people feel it is ok to come to you when they have hit a wall.

6. Project v. Line Targets

Always a fun one. But the rift might get more significant in this situation. Consult team leads and others on realistic line targets. If you take away a third of the FTEs from a business unit for conceptualisation, testing, protoyping, you can’t expect the same output. Seems an obvious one. But isn’t. Unrealistic expectations will lead to pressure build, frustration and feelings of failure, probably in exactly those employees you most rely on.

7. Don’t be a “Steering Committee Only” Manager

Join a workstream. Participate actively. Not as a leader, just as a project contributor, go through the motions, understand what the actual work is like, don’t become a “steering committee only” manager. Just a thought…

I know a lot of the above sounds absolutely normal, but it isn’t. Experience shows that you will get suboptimal results when your people aren’t motivated or if they are scared. Experience also shows that once something goes wrong on the people level, much management time is needed to either make things right or manage someone out of the organisation.

While writing this, a song kept popping into my head: here is my reference back to the “New Radicals”: “You only get what you give”, – true, and a good pick-me-up song for a workshop break!

6. April 2015

Digitalisation – let’s rebuild the business (or maybe let’s wait?)

“In a chronically leaking boat, energy devoted to changing vessels is more productive than energy devoted to patching leak” – Warren Buffet

That sinking feeling that something “big” needs to be done

It might start with a shift in the competitve environment, a technological requirement from one part of the business, which turns out to spark a chain reaction. At some point, you will hear more and more of the following within an organisation: “I can’t do the tasks I am asked to do now, because I don’t have the tools/information etc.”. Or: “if we continue to do things the way we do, we won’t be able to meet our targets”. And mostly, also “I don’t have the people with the right skill set to do this”. Risk is: if no action is taken, things will slow down, frustration will start seeping in, results will decline.

It is possible to hide behind this trend for a while, because everyone is busy in their jobs as it is. But really only: for a while. Because whether you are facing regulatory changes or competitive threat, there will come a point in time when there’s a serious deadline, when something needs to have happened by a certain date. So, can you afford not to start doing “something” today?

Hierarchical leaders and change

I have been known to be one of the tedious “naggers”, always with a view to the future deliverables or better solutions, and how to get to them, as well as outlining the risk of “stalling”. This is, by the way, super annoying for most hierarchical business leaders in less advanced and competitive industries, who prefer to live in the “here and now”, who simply find change exhausting, and when change requires technology and serious commitment and step changes (and lots of money), they find it simply scary.

It is in these organisations, I find, that the very top management does not understand the intricacies of the business, the nuts and bolts, the creaks and the many workarounds created to “make do” over time. Whilst that in itself is a problem, the real problem in my view is that this type of leader does not know the people in the business well enough, their motivators, their skills and experiences, their capabilities, their leadership potential. Why? Because they assume that the directives they gives are being executed without being questioned and that things will run smoothly unless someone screws up. Top-down to the bone. If something does not work, the solution is to find the culprit.

So, if the business landscape slowly shifts around such a business, if all of a sudden competitive threat increases, is it possible to still blame someone who works for you? Or maybe, maybe leaders may need to recognise that either they have missed the boat instead of driving it, and even if that is not yet the case, they’d better move quickly, but of course they won’t know how… cue back to the fear factor.

So, how do you get over that fear?

There is no easy way around that: making drastic changes to ones business model is scary. All of a sudden, technology terms senior management have never been confronted with are thrown around without anyone even blinking. I still chuckle at the reaction of a CEO when first confronted with the term “Master-Slave relationship” when discussing data processes, but it is a good illustration (and yes, for everyone in the Depeche Mode generation, that song WILL pop into your mind).

Senior management now have to understand their business in more detail than they used to (have to) do, no, now they also have to make decisions based on technology and (if the business is that advanced) data trends, nothing they are experts in, so of course it is scary. I believe, however, the scariest thing is the time required, the personal effort and strength it requires to lead such fundamental change processes, or even the entire refocussing of the business.

If top management does not embrace changing the business model, possibly the business purpose wholeheartedly, people will notice, people being all sorts of stakeholders including your shareholders. Without a strong sense of ownership and some sort of “contract” with the senior leadership team, the “project” is doomed, in one way or another, from the start. You will also “need” the people you might have thrown directives at previously, really need them, their insight, their expertise, their time and most of all: their total commitment. We will talk about people more in a different article, but for any CEO or senior manager starting on a path as groundbreaking as digitalisation of their business:

This must matter!

Even if you were “tagging along just fine” before embarking on this journey, you won’t if you fail to go through with it. Detours, flat tires, all permitted, but one thing needs to be clear: going back to the “old ways” won’t be an option. So, will it be tedious? Will it be a huge amount of work? A massive personal effort? Is there risk? Will one have to radically evolve as a leader? Will people be asked to leave? Will people you don’t want to walk away?

The answer to this is: absolutely (possibly minus the last point).

So, if embarking on this journey appears interesting and has raised curiousity – bear with me for views on external consultants, freelancers, agile software development projects, re-aligning teams, renewed skill-set assessment, resistance, conflict and mediation, power struggles and motivation. Go with me through the motions of a journey through digitalisation and change… and please share your views and experiences!

16. March 2015

Digitalisation – A view from the ops room

Everyone is talking about digitalisation – the concept, the need for it, the threat of not doing it, doing it too slowly. The requirement for agile organisations, more efficient, automated work processes….

But what does it mean to go through with it, to live digitalisation?

Hopefully, some of my thoughts can trigger an exchange of experiences about how digitalisation impacts on structure, people, culture, execution times, the pull between time intensive projects and expectations on line results?

How do you lead digitalisation and what is different from “projects” as we all know them?
How do you ensure you continuously challenge your ways of working, your business model and value chain? Do you need to create “challenger” companies externally to ensure you move fast enough?
How do you take those employees and other stakeholders not so comfortable with change, technology and flexible roles with you (and what can you do when that’s not possible?).
How do you deal with detours and, occasionally, failure (in a world without blueprint, this is inevitable).
How do you cope with decision-making in an uncertain environment and about things (aka technology) you might not be entirely familiar with?
Stakeholders will need to be managed, but how much time should you invest? Does it really have to cost THAT much (time/money/equipment/project working space?)?

The list goes on.

So, thank you for reading – and for your contributions.