I have been working with some good coaches recently, but the were not very comfortable with the agile paperwork and coaching bureaucracy areas of coaching.
Category: Leading change
Clarifying agile roles – speed dating?
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.”
Is it enough to say that the BA is the “universal translator” between business and IT?
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.
Analysing stakeholders – beyond the basic communication plan
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”.
Defining the value of your internal consulting team part 2 – your services
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.
The dark art of office politics for IT leaders (part one – why is it stressful?)
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”.
Using a moments of truth analysis to assess a team’s readiness for change
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.
Performance agreements – a first attempt for agile project team members
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.
How can you manage people on projects these days?
Life used to be easy for managers. We had good people who delivered lots of stuff and bad people who stuffed up lots of deliverables. It was easy to tell who the good guys and the bad guys were.
But then something significant happened. We discovered that work was not just about performing a set of predictable tasks. We started to realise that:
- Work was about adding value rather than destroying value rather than just delivering stuff; and
- We started to see value as something delivered through the interaction of entire teams and not through individual achievement.
Succession planning as an idea whose time has come
Everywhere I go I am starting to notice consistent problems or patterns of behaviour that hold back some of the best people in the teams I work with. I think they are starting to rank right up their with the Peter Principle as ways to stop good people from reaching their true potential and really contributing value to the teams they work with.
And they are all related to the managers in the team not having enough time to talk about succession planning.
James King 