patkua@work

The intersection of technology and leadership

Category: Philosophy (Page 3 of 3)

Action is louder than words

July 14, 2008 / / 0 Comments

It’s easy to execute a particular practice. The difficult part is executing the practice well. This applies with any trade, any profession and anything we do. That’s why we have professional sports people, professional tradespeople, and professions in general. It takes a long time to get good at anything.

One thing I’ve learned from observing great leaders and less than great leaders is that those that make a big difference follow the words they say. Less than great leaders talk in one way, yet act completely incongruently with what they said. Some leaders don’t realise this, believing that what they say is enough to motivate people. The result is that people get confused, defaulting to the behaviour they see, not the words that are spoken.

The lesson here: It’s important understand what people hear because that can be different, and to ensure that what you do follows what you say if you really want the message to get across.

Barriers to learning

June 26, 2008 / / 0 Comments

One of my most memorable conversations during training went something like this…

Student: Aren’t these just best practices? I don’t see how this is agile estimation. How is this agile?
Me: Hmmm. I guess they are best practices. I see many agile teams frequently apply all these techniques when they do some estimation. Let me ask you about your current project. Do you get people who will do the work to give you estimates?
Student: No. Either we have a group of architects to estimate the work, or I estimate the effort for the team.
Me: Do you try to make make sure more than two people estimate?
Student: No. One person should be good enough to estimate.
Me: Do you try to understand or uncover the assumptions that person is making during estimation?
Student: Sure. We ask them to write their assumptions down.
Me: Do you use relative estimation?
Student: No.
Me: So you’re telling me that even though these are best practices, you’re not necessarily doing any of them?
Student: Yes. But I don’t see how this is agile.

When people get fixated with disagreeing about something, they stop listening and stop learning. Drawing them out of this corner can be a really difficult task. In this particular case, the student wanted clear evidence that agile was something else and wasn’t prepared to hear about estimation best practices being normal best practices when working in a most agile methodologies.

A state of mind

April 6, 2008 / / 0 Comments

I was reminded today of a simple principle, especially when working in new environments and with new people to, “Keep an open mind”. Easy to say, yet first hand observation of others seems to imply it’s hard to do. I’ve seen a lot of people come into a new environment, judge a situation and state an outcome.

They share nothing about what they are concerned about, what they observed, and why they reached the conclusions they did. It’s no wonder that people can’t relate to the outcome immediately. Keeping an open mind helps to resolve jumping to solutions too early. Better yet, sharing your mind and the process you went through helps others to relate to you and for you to realise if you got any of it wrong.

Secret Sauce: Embedded Coaching

January 28, 2008 / / 0 Comments

One of the biggest teases developers use on their peers when they move into a non-developer or a less developer focused role is to tag them as “Post-technical”. I’ve heard this term ever since I joined the industry. My other interests around team work, organisational processes, coaching and training seem congruent with this attitude.

How do I try to balance these roles? Embedded coaching.

It’s as simple as working in the role of a developer and a coach at the same time. There’s something about working “on the front lines”, so to speak, that earns you a certain level of respect that you wouldn’t get if you were on the same team in the role of a project manager, or something you wouldn’t earn if you visited as a coach or advisor. It lets you build that trust and rapport on a daily basis that gives you insight into the things that drive people mad, or the things others may not feel comfortable stepping up and saying out loud.

Of course, there are benefits to also doing coaching from an outside point of view though I do think that embedded coaching is undervalued and often unavailable due to the delicate mix of skills required.

Software Architects Of Today

December 12, 2007 / / 0 Comments

Shouldn’t be sitting in ivory towers dispensing design documents or ideas with no basis of reality.

They should be coding. They should hang around to see how their decisions pan out.

They should be hunting down smells, listening to the team about painful areas, thinking about how to turn them around. They should work with the team to co-ordinate a strategy for redesign or a series of refactoring to turn complex code into simpler designs.

They should be sharing their experience in collaborative ways with the team to create several design choices, to clarify the pros and cons and to refine them to a best choice.

They should still be looking at the bigger picture, and always looking for ways to share that big picture. Part of it might be an XP Metaphor (or the Shared Vision). It might come out looking like an architecture diagram.

I’m sure of missed some things, and I know for a fact, most software architects can’t meet even these. Fortunately I get to work with many who do.

Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑