Category: Leading change

Clarifying agile roles – speed dating?

On By James KingIn Agile development, Implementation, Leading change1 Comment

I went through this quick meeting with an agile class recently and I said I would post this for the crew to refer back to.

In agile teams there are a couple of core roles and then the rest depends on the kind of work the team does.  But we can give some more clarity than this, as I have previously discussed here.

Even so, the role of the Scrum Master or Product Owner or Tech Lead or even others will vary from project to project and even sprint to sprint.

So I often have people sit down together and actually tell each other what they think they are in the team for.  Essentially I get them to go through these questions that I got from a book called “Stand Back and Deliver.”

IMG_20160511_002553

Continue reading “Clarifying agile roles – speed dating?” →

Advertisements

Is it enough to say that the BA is the “universal translator” between business and IT?

On By James KingIn Idea management, Investigation, Leading changeLeave a comment

I often hear that we need a business analyst to translate what the business people say, so that technical people understand them. Then, I am told we need the BA to then translate what the technical people say, so that the business people understand them.

I guess it goes something like this:

It sounds good, but actually I don’t think it is true.

Continue reading “Is it enough to say that the BA is the “universal translator” between business and IT?” →

Analysing stakeholders – beyond the basic communication plan

On By James KingIn Implementation, Leading changeLeave a comment

A basic map of our stakeholders

Quite some time ago, I wrote an article on “creating a basic communication plan” and for many projects that is all you need.

But sometimes it is worth analysing your stakeholders in more detail. This article explores a couple of approaches that I like to use when I need to understand more about my end users or more about my “project stakeholders”.

Continue reading “Analysing stakeholders – beyond the basic communication plan” →

Defining the value of your internal consulting team part 2 – your services

On By James KingIn Implementation, Leading change, ObservationsLeave a comment

In my last article, I described an approach that you can use to define the purpose of an internal consulting team.

I used Sophie and her BA team as an example and I will continue to do so here. This time I will talk about the “Service catalogue” or list of services that your team provides to stakeholders in the business.

Our approach at a high level

Sophie and her managers have just defined what their team’s purpose is, so it should be easy to create a list of the services that be needed to achieve that purpose. But in reality, a lot of the work done by internal teams is “as per the stakeholder’s request” and not at all aligned to the team’s alleged reason for existence. So we will attack this problem from two angles

  • What Sophie and her managers think the team should be doing; and
  • What the team are actually doing at the moment.

We will then look at the gap and work out what to do about it.

Sorry, but it turns out to be a long article, so pour a cup of tea for yourself or just read one heading at a time.

Continue reading “Defining the value of your internal consulting team part 2 – your services” →

The dark art of office politics for IT leaders (part one – why is it stressful?)

On By James KingIn Arguing, Decisions, Leading change, Reflection1 Comment

Apparently office politics is a horrible thing that other people do.

But many of the emerging IT leaders I speak to get told they need to be better at “soft skills” and “influencing at a senior level”.  What this often means is get good a politics.

Sadly a lot of office politics seems to involve people playing games to get their own way at the expense of everyone else. This skill can be learned and might seem useful, but it is not what I am going to talk about here.  I am going to talk about “how do the good guys get the right outcomes when people have competing interests or needs and some people seem like knob-heads”.

Continue reading “The dark art of office politics for IT leaders (part one – why is it stressful?)” →

Using a moments of truth analysis to assess a team’s readiness for change

On By James KingIn Implementation, Investigation, Leading change1 Comment

I have previously blogged about a number of approaches to assessing a team’s readiness for change, including the 7-S framework and the arenas of change approach, but today I thought I would explain a less well known approach – the “moments of truth” assessment.

Actually I made it up so it is not too well understood outside of my own loungeroom.  The approach is essentially the same as the 7-S style of assessing the interaction of the multiple systems, skills, stucture and other elements of the team’s whole ecosystem. But this is a little different because we start by looking at when (and why) the team’s internal or external customers interact with it.  Then we assess the team’s ability to support those interactions.

Moment of truth(n)  a moment when a person or thing is put to the test

Collins English Dictionary as quoted at http://www.thefreedictionary.com

Any interaction with a client is “a moment of truth” for the team. It tests the connection between the team’s value proposition, strategy, implementation, staff, skills and systems and it generates the experience that lasts in the customer’s memory until he or she interacts with the team again.

A “moments of truth analysis” therefore starts by identifying the interactions a team has with its customers, stakeholders and potentially vendors.

Continue reading “Using a moments of truth analysis to assess a team’s readiness for change” →

Performance agreements – a first attempt for agile project team members

On By James KingIn Agile development, Capability growth, Leading changeLeave a comment

I was just reading an article on performance appraisals by Shane Hastie. It is a good summary of some of the issues that traditional performance appraisals cause on agile projects.

But it leaves two questions unanswered:

  • Where would you start if you actually had to do a performance agreement; and
  • How would you actually know what was expected of you if you didn’t?

The situation is made worse, according to the links in Shane’s article, when you want the team to be jointly accountable for shared success rather than individual success.  This is important if you want to work out how to evaluate testers or BA’s for example, because their purpose is to make the team successful rather than to stand out on their own.

Continue reading “Performance agreements – a first attempt for agile project team members” →