patkua@work

The intersection of technology and leadership

Page 30 of 53

Leaders act

I’ve been quiet on the blogging front because I’ve been busy doing other sorts of writing. One of my focal points is around leadership, both in teams in general, and around agile situations. I think it’s important that if you’re leading, you need to be seen to demonstrate the values and the suggestions that you speak of.

Wonderful, you have great intentions behind what you do. It’s even more powerful if you demonstrate the behaviours that you speak of. I think part of leading is knowing when to act. If you’re simply preaching at people, I don’t think you will be very effective as a leader.

What they don’t tell you about user stories

ShhAgile methods have a gap on how to do deal with requirements that often leaves business analysts confused about what to do. From an analyst’s point of view, user stories seem to be the only technique agile methods prescribe. When people are new to agile, they take this as agile’s “only” way of modelling requirements. What isn’t made explicit often gets forgotten, so I want to make this clear: Agile methods don’t discourage thorough analysis or modelling. They don’t discourage the use of diagrams and other visualisations that help people better understand and refine their domain representation. They want everyone to focus on value and communication by using the rights tools for the job.

When coaching analysts, I often find myself telling them, all the tools they draw upon to question, to challenge, to refine and capture their understanding is important. Agile methods focus on better understanding of value, not better note taking. Writing things down does not automatically translate into understanding between two people. Cockburn’s already demonstrated a model that talks about the richness of communication methods, with written documentation being one of the worst.

The best business analysts I’ve worked with have little need to write things down, having absorbed what needs to be done, understood the real requirements, and constantly available ready to help clarify them. Conversely, the worst business analysts see their job only as writing “requests” and “demands” down, doing little to question and challenge what is really needed versus what is merely articulated. These I call overpaid scribes.

Question what value your tools are using and if they help you either better understand or better communicate with other people. If you find modelling in UML helps you better see relationships, do so but avoid spending all your time polishing the model and getting the syntax correct. Be wary of investing yourself too much in one particular model or document that makes you potentially more resistant to changing it. Neal Ford describes this as Irrational Artefact Attachment. If you find yourself writing something down to remind yourself of what is important to get across, do so but don’t use it as a way to avoid helping others understand it.

Agile methods appear nebulous to many people because “user stories” simply appear. It’s not prescriptive about how you get there because there are simply too many different ways to get there. Whilst being prescriptive will help some projects, it would no doubt hurt many others.

Image of Shh! taken from Anthony Gattine’s flickr stream under the Creative Commons Licence

Fixing Notepad++ 5.5 Langs.xml

LangsXml Failed to LoadI upgraded to the latest version of Notepad++ (5.5) and noticed that I sometimes get some problems with a dialogue box that pops up, looking like the picture the right stating (Load Langs.xml failed!)

Having a quick look at the installation directory, it looks like a langs.xml file exists yet it has a 0KB size. I’m not sure what causes it yet (perhaps it’s if you kill the process mid-way using Task Manager) but all I did was take a copy of langs.model.xml and rename the copy as langs.xml. Fixes it all up!

A Guide to Receiving Feedback Part VI: It’s Okay To Disagree

DisagreeingAs a person receiving feedback, you may find you can’t understand what the other person is trying to tell you. You’ve already put significant effort shaping effective feedback out of whatever it is the donor gives you. First you focused on fact finding, uncovering your specific behaviours. You then asked some questions identifying how the donor interpreted the impact.

Remembering that effective feedback is aimed at helping you, the recipient, Strengthen Confidence or Improve Effectiveness, you may find, at some point, the donor’s feedback isn’t doing either. Perhaps you don’t remember your own behaviours, or you see the impact being different. It’s your responsiblitiy as a recipient to seek actions that help you Strengthen Confidence or Improve Effectiveness and if you cannot find out how changing your behaviour will help you do either, then it’s okay to disagree.

Make sure you thank the donor for their feedback, helping them understand how and why you the feedback doesn’t Strengthen Your Confidence or Improve Your Effectiveness. Only when you’ve done everything you possibly could to uncover effective feedback, then is it okay to disagree with the feedback.

Don’t feel like you have to respond and agree with every part of feedback. At some point, interpretation of impact requires a matter of perception, and people often remember facts quite differently from what actually happenned.

The image above is taken from Twilsoncom’s flickr stream under the creative commons licence

A Guide to Receiving Feedback Part V: Thank Them For Their Feedback

Give ThanksWhen someone gives you feedback (even if it’s not wrapped completely effectively), it’s important to thank them for taking the time to do so. As long as you uncover the important elements of effective feedback together, and agree on actions helping you Strengthen Confidence and Improve Effectiveness, then you personally benefited from the situation.

Avoid the need to justify every single part of the feedback and start with a “Thanks!” Acknowledging the person trying to help you goes a long way. Affirming the value of each piece of feedback helps the donor feel at ease. It assures them you are listening and aren’t reacting badly to their feedback. Creating this safe environment for the donor lets them focus on giving effective feedback, boosting their confidence as they continue with the rest of the feedback.

There’s no need to go all gushy and shower them with gratitudes. Start simple, using short positive affirmations, indicating to the donor you are listening to their feedback focusing on what it is they are trying to tell you.

Effective feedback takes time to give, and as a recipient you should thank the donor for taking their time to help you strengthen your confidence or improve your effectiveness.

Picture above comes from Fave’s Flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part IV: Apply It Immediately

A key principle to keep in mind when giving effective feedback is to do so in a timely manner. Feedback only helps the recipient if they have an opportunity to do something about it. It’s difficult to change a specific behaviour if a project’s finished or the feedback comes a year later.

If someone gives you the gift of feedback and you agree upon actions, seek the nearest opportunity to apply it. Applying the actions immediately reinforces the value of feedback. When the feedback donor sees a change in behaviour, they see that it helped the recipient become more effective. Applying it sooner than later creates opportunities for the donor to give new feedback, focused on strengthening confidence and encouraging more of the desired behaviours. More than helping the donor realise the value in their feedback, the agreed upon actions should help improve or continue the recipients’ effectiveness in what context they are working in.

Skiier Fallen OverAs an example, when you’re out skiing, applying actions from feedback will improve your effectiveness the most by applying it immediately. It may take some time to master it, to change conscious behaviour but it’s only useful if you do it while you’re on the slopes, not when you’re back from your skiing holiday.

Remember that not executing on actions immediately has other negative effects. Not doing anything about agreed upon actions sends a message that you don’t value the feedback, decreasing the likelihood the donor will give any feedback in the future (whether or not its focused on Strengthening Confidence or Improving Effectiveness). Not applying the actions immediately also makes it easier to forget what behaviour needs to change and it will be harder to get affirmation about if your effectiveness has improved.

Photo taken from Sunflower Dave’s Flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part III: Agree on Action

HandshakeThe biggest mistake when giving feedback is telling someone what to do (or what not to do). Ever been on the receiving end of feedback like that? Do you immediately recoil and feel yourself saying no? It’s natural because you don’t know how following their recommendation makes you more effective. When someone recommends a specific action, unwind the (ineffective) feedback to see how they ended at their recommendation. Find out what key behaviour triggered they observed and what impact it had. Here’s how you might do it:

Follow these steps:

  1. Acknowledge
  2. Establish what you’re about to do
  3. Ask for specific behaviour
  4. Ask for observed impact
  5. Generate alternative actions
  6. Agree on an action

Only after you both share the same context and background do you then want to move onto Agreeing on the Action. Asking someone to change their behaviour assumes it will fix the problem. Many times people suggest one thing not having the full context and actually, a better solution is something completely different.

Ensure that you both agree on the action because it will make the person receiving the feedback more effective, not because someone told them to.

Picture of handshake comes from Oooh.oooh’s flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part II: Observe First, Judge Later

SilentLet’s be honest. People aren’t used to hearing feedback, let alone listening out for characteristics of effective feedback. It’s easy to jump to feeling defensive and trying to justify everything and look for reasons why you behaved as you did. People with backgrounds in programming are also often quick to apply the labels: “Good” and “Bad”.

When receiving feedback, consciously slow down your reactions. Focus on understanding the situation, the facts. Then assess the impact. Avoid the temptation label the feedback as positive or negative, good or bad. Placing a value judgement immediately leads you to agreeing or disagreeing with it. Really listen to the feedback and confirm what you heard, first asking for the specific behaviour, followed by understanding how they perceive the impact.

Here’s an example:

Donor: “Last week I noticed you turning up for stand up three of out five days. I’m concerned because I think it indicates to other team members that their time is not valuable to them.”
Recipient: “You’re saying that I turned up late three out of five days?”
Donor: “Yes”
Recipient: “I only thought I was late for just one day. You’re also saying that my team mates are being affected by this? How are they expressing that their time is not valuable?”
Donor: “I’ve heard a few of them talk about if you’re not turning up on time, why should they?”
Recipient: “I had no idea about this”

The person giving the feedback will often give feedback that is ineffective, therefore as the recipient you may need to ask them questions to get back to the original observations. Focus on facts. Then focus on interpretative. Leave the action until last.

Donor: “You need to turn up on time for stand ups.”
Recipient: “It’s helpful for me to understand some specific examples. Have I not been turning up for stand ups on time?”
Donor: “No. You arrived late last week.”
Recipient: “I only thought I was late for just one day. Was I late more than that last week?”
Donor: “Yes. I thought you arrived late during stand up at least three times last week. It’s so annoying.”
Recipient: “I’m sorry to hear that you see it as annoying. It’d be helpful for me to understand why you see that as annoying.”
Donor: “It’s annoying because other team members have been complaining about if you’re not turning up, why should they.”
Recipient: “Ahh. So you’re saying that because I’m turned up late three times last week, then everyone else feels like they shouldn’t have to either.”
Donor: “Exactly.”

Whether or not a donor is giving you effective or ineffective feedback, they are trying to tell you something. Use the opportunity to listen to what they are trying to tell you, even if it is masked by emotion and suggested actions. Use the opportunity to uncover the elements of effective feedback. Avoid agreeing or disagreeing with a person immediately. Confirm what you are hearing. Uncover the facts and understand how they perceive the impact and both of you will understand what actions need to be taken and more importantly why.

Photo above taken from Borghetti’s flickr stream under the Creative Commons licence

A Guide to Receiving Feedback Part I: Ask for It

Asking For FeedbackI’m writing this guide to answer a question a trusted colleague asked me the other day. I think there are plenty of resources for how to give effective feedback (I’ve written a few myself) yet I can’t find as many about the other end, or how to go about receiving feedback. I’m planning on writing a series of these posts, so my first tip in this series is: Ask For Feedback.

I’m amazed at how many people go through life without asking for feedback. There are plenty of reasons why people don’t do so. Perhaps it’s because people are ineffective at giving feedback, perhaps people are fearful of the consequences it may have on their status, on their career, or their current position. Many organisations, teams and processes don’t really create a safe environment for people to receive effective feedback, only serving to fuel the cycle of not wanting to provide effective feedback. Poor HR processes tie performance evaluations to annual reviews that only occur once a year, adding to the vicious cycle of providing poor quality feedback.

Remember that effective feedback should be about Strengthening Confidence and Improving Effectiveness for the person receiving it. Anything else is ineffective.

The first step that you, as the person benefiting from the feedback, should do to break the cycle is simple; ask for it. Asking for feedback (particularly detached from performance evaluation cycles) starts to create a safe environment for the person giving feedback. It gives the donor permission to help you understand what things to continue doing (or do more of) and places where you might improve. You could start the conversation off like this:

“I value your opinions and I’d be interested in getting your feedback about how you think things are going. It would be helpful for me to understand specific examples focusing on behaviour where you can help me strengthen my confidence and improve my effectiveness.”

Make sure you give the person the opportunity to think about it:

“I’d like to get that feedback soon and would like to give you some time to think about it. Can we organise a time later in the week to cover this?”

Establish a time that works for the both of you – enough to let the donor collect their thoughts balanced against enough time for it to be relevant for the recipient. More importantly, ask for feedback frequently. Don’t wait until the end of a team, the end of a project or a whole year. You want feedback to be relevant and specific because relating feedback to recent events gives you the opportunity to apply it.

Photo above taken from GreyBlueSkies flickr stream under the Creative Commons licence

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑