patkua@work

The intersection of technology and leadership

Category: Management (Page 7 of 8)

Agile lets people be people

March 2, 2010 / / 2 Comments

When you introduce agile methods to very traditional organisations there’s a side effect most people underestimate. This is, I believe, where the first line in the manifesto is most appropriate:

Individuals and interactions over processes and tools

Traditional organisations are geared for efficiency – keeping individuals busy to the point where you lose overall effectiveness if you ever need to synchronise between parts (which you inevitably do for software these days). Calling a meeting is frowned upon as it takes up lots of time, so out of necessity, most communication occurs over email or IM. As Alistair Cockburn pointed out a long time ago, these are pretty ineffective channels of communication. Relying solely on these types of channels only turns to a build up of frustration as issues go unheard by the right set of ears. In traditional environments, these often turn into build ups set to explode at the most random of moments.

BrokenBottle

Image from Nic Jacka’s flickr stream under the Creative Commons licence

Perhaps you’ve seen it? Think about when one person hijacks a meeting to highlight an issue (typically important one) not being addressed, or when someone spontaneously shouts at someone for no apparent reason. It might even be as bad as someone having a temper tantrum, literally throwing things across the room. Traditional environments often do not provide mechanisms as outlets for this.

Therefore, when introducing practices such as daily stand ups, planning meetings and retrospectives, the first few times you run them, expect an avalanche of unresolved issues and emotions to ensue. This is fine. Expect this from some of the quieter members as you give them explicit permission to talk about important things that need resolution where traditional structures have not given them that permission to talk about them.

Treat it as you would the opening of a previously shaken soft drink bottle for the first time. You’ll have to be ready to clean up some of the spilt liquid, but you don’t have to worry about picking up broken glass. Now that the bottle’s open, you can work to address the real issue at hand.

Leaders act

November 25, 2009 / / 2 Comments

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.

Consequences of Hiding Information

October 5, 2009 / / 2 Comments

Last week reminded me how hard communication is to get right. Last week reminded me of how important it is to be visible with information as early as possible. Last week reminded me of what happens with the people involved don’t have access to information early.

Successful teams applying agile principles quickly involve those impacted by the situation, equipping them with as much information as early as possible. These teams call upon agile practices such as daily stand up meetings, retrospectives, and frequent showcases to achieve this. Better and earlier access to information helps all parties involved come up with more options. More options creates more opportunities to have better conversations, and more opportunities to collaborate to meet everyone’s needs, and ultimately end up with a solution that everyone is more likely to feel committed to.

Compare this to those teams who hoard information, selecting and filtering the information others hear. Filtering and transforming information limits the number of options, often adding additional stress because the team now how to come up with the perfect option. Even with contributions from others, the pool of options will often be tainted by solutions not entirely appropriate or relevant. More importantly, if the people affected by a decision aren’t involved, they will end up less committed to the solution and often, cause more problems because of resentment.

No one likes to be handed decisions. That’s why the Agile Manifesto emphasises “Individuals and Interactions”, and a key principle of Lean Thinking is “Respect for People”.

The moral? Remember to involve the appropriate people in the decision making process as early as possible. Even if you suspect there is only going to be one solution, be transparent with the information you do have in the hope you may end up with more options, or at least, the outcome is no surprise.

Respect is in the currency of geeks

September 20, 2009 / / 1 Comment

A work colleague pointed me out to this fascinating article called, “The unspoken truth about managing geeks” that I think anyone working in IT needs to know about.

There are some great bites of information in there that I picked up including:

  • Avoid laying blame on stereotypes and look at the system that drives out certain behaviours (such as those factors amplifying stereotypical behaviour)
  • Geeks trust people who help get the job done. Geeks find ways to work around people who don’t.
  • Unlike in almost every other area, it’s often not how you say something that matters, it’s what you say. Maybe it’s because of logic but geeks detect when things don’t quite add up.

I suggest you read everything in the article. I don’t necessarily think all of it is accurate at all of the same time but it’s well written and gives people insight into why geeks often behave as they do.

97 Things Every Project Manager Should Know

August 24, 2009 / / 1 Comment

It looks like I have become a published author along with three other ThoughtWorks‘ colleagues (Adrian Wible, Joe Zenevitch, and Anupam Kundu) in the “97 Things Every Software Project Manager Should Know” book.

97 Things Every Project Manager Should Know

I contributed two tips, “Documents as a Means, Not an End” and “You Are Not In Control“.

You can buy it the print or ebook version of the book with a 30% discount via the Orielly.com website, using the code ABF09. Congratulations to all the other contributors to the book, including the author who organised the book, Barbee Davis.

Why ISO9001 standards fail

April 20, 2009 / / 4 Comments

Systems and standards with good intentions are naught without proper execution. Unfortunately this is where most people get let down. People adopting agile fall into the same traps, but at least the Agile Manifesto guides people in terms of values.

Here’s how I’ve seen ISO9001 being communicated at various clients:

  • ISO9001 is a quality management system
  • A core part of ISO9001 is about control and documenting processes
  • ISO9001 is about continuous improvement

Seems harmless right? Unfortunately the way that people interpret this is as the following. ISO9001 is a quality management system. Quality management system = control and documenting processes. Control and documenting processes = continuous improvement.

Unfortunately most people never escape out of the control and documentation requirements, and the fear of failing and audit that leads to a micro-optimisation. This is why the manifesto talks about “uncovering better ways of developing software by doing it and helping others do it” and prioritising “individuals and interactions over processes and tools“.

Am I missing something?

March 15, 2009 / / 1 Comment

It’s about time I probably asked this question about the new Manifesto for Software Craftsmanship, but seriously, am I missing something?

Firstly, the whole idea about craftsmanship applied to software isn’t too much of a new idea. I remember reading Software Craftsmanship: The New Imperative when it first came out, and how the Pragmatic’s also talked about this concept.

I’m probably biased a little bit because I probably believed in what craftsmanship stood for before being fully immersed in agile for the last five(?) years. A part of me understands why this is important for agilistas. After all, I hear of stories all of the time where in many organisations that focus solely on Scrum without adopting any developer discipline still have a “crappy codebase”.

Yet I worry that it focuses on the wrong problem. I worry that it may be addressing a symptom, not a cause. I worry that it will further split our industry into two camps, those who craft (or should craft) software, and everyone else.

The real question I ask myself when going into new organisations and with new teams is, “Do people care about the quality in their work?” This question applies to all parts of an organisation, all parts of a team, not just developers.

So I’m jetlagged, tired and honestly just ranting a little bit, but I still ask the question, “Am I missing something?”.

Estimates degrade over time

January 15, 2009 / / 7 Comments

Project management is a funny thing. It seems like once something is converted into a number, the number is often all that matters to traditional schools of project management. Plans get created, promises get made, yet little diligence goes into ensuring the number is based on sound thinking, and that the basis for that number remains correct. Maybe that also explains the state of the current banking industry, though that’s another post entirely.

Most people fail to understand that estimates have a half life, and often a very short one. Even results produced with agile estimation techniques, have an expiry date that is often ignored. Magic numbers (aka, the estimates) have an expiry date because in order for them to be even slightly reasonable, they need assumptions to be made, and it is often these assumptions that expire. Gantt charts are awful at highlighting what those assumptions are, let alone tracking when they fail to be met.

burntnumbers
Image of burnt numbers provided by Dead Scene under the Creative Commons licence

A recommended practice for agile estimation is to get the people who are going to do the work, to estimate. Put these estimates on a shelf to ripen for a year and, presto, you have a new team to which, the original estimates no longer apply. Even given the same team, set to work on something else only to return to the system, will have lost some flow, forgotten some things and need more time than if they just continued to work on the same system. Environments often change, and the underlying needs for the business change even more frequently.

What can we do about it? I refer to Lean Software Development’s principle of the Last Responsible Moment, to not only make decisions, but when collecting (and keeping) estimates. Collect estimates now if it helps you make a better decision, discarding the estimates if you choose not to immediately implement the project. You set yourself up for failure if you choose to estimate now, knowing that the project is to be shelved for “only three” months and keeping those numbers as if they are in any way relevant. If you don’t need to make a decision now, work out when you need to make the decision and defer collecting estimates until just before then.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑