patkua@work

The intersection of technology and leadership

Page 31 of 53

Agile Does Not Guarantee Success

October 8, 2009 / / 5 Comments

Businesses need to be comfortable that not all projects are going to succeed. Out of a portfolio of projects, people need to be comfortable that these projects will not achieve what they originally set out to do. Don’t expect that, even with agile methods and values guiding your teams, these projects will achieve what they set out to do.

Some projects aren’t set up for success. Poor organisational governance, leading to unrealistic expectations established from the outset often set up a project for a real death march. Or perhaps projects spun out of the whims of one set of people only to not understand what organisational capabilities they really have. Sometimes it comes down running a project with the wrong mix of skills and without a support structure in place that creates a time bomb waiting to explode.

Don’t forget that agile and lean methodologies cannot guarantee success. At the heart of it, agile will surface problems and make them visible. Organisations need to be prepared to confront the truth (many are not ready for this level of transparency) and support changes that will make it better.

For projects destined to fail, your best result is often to Fail Fast, take those lessons and then do something differently. Avoid the situation where a project sucks up resources that could be more effectively allocated. And don’t forget, just because a project didn’t achieve what it set out to do, it’s only a true failure if you don’t learn anything from it.

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.

Retrospecting Resources

September 28, 2009 / / 0 Comments

I was really pleased to stumble across a new site for Retrospectives dubbed the “Agile Retrospectives Resource Wiki“. I can’t find who put it together but thank you for putting it to the public. Some other resources that I know about and is worth making more linkable on the internet include:

  • Retrospective Facilitator’s Gathering – Wiki website detailing the yearly gathering of people passionate about facilitating retrospectives
  • Retrospectives – The first website Kerth put up describing the practice of Project Retrospectives.
  • Links to retrospective resources – A good collection of links to blogs, articles, etc that are related to retrospectives

I’m really pleased to fin

The Agile Mindset

September 22, 2009 / / 0 Comments

A lot of people focus on what it is you need to do to be agile, not realising it’s about the way that you approach situations and act rather than any one particular thing that you do. If you want to approach things differently, here are some recommendations.

Prepare to make mistakes
No one in the world is perfect. No one is great at everything. It’s even rarely to be good at something immediately. Therefore prepare yourself not to hit do everything you set out to do exactly the way that you do it. Remember that you only truly fail if you do not do the following….

Learn something
Forget about being taught. Every situations always presents an opportunity to learn. Successful situations provide an opportunity to understand why something was successful. Less than successful situations offer opportunities to do something differently if find yourself in the same situation. Note that this is different from avoiding a less than succesul situation.

I try to tell others that even when you’re teaching, you have so many opportunities for learning. You have the opportunity to learn how to communicate ideas differently. You have the opportunity to understand the limits of your own understanding. You have the opportunity to learn the contexts in which your ideas may actually be harmful instead of useful. You have the opportunity to practise listening. All of these let you…

Do things differently
Incrementing means building upon something that already exists. Iterating means doing the same thing over and over again. Iterating gives you the opportunity to prove the lessons learned actually work. They let you test ideas. They give you opportunities to experiment and try new ideas. Find real opportunities to truly iterate to let you do things differently.

Work in small cycles
Small cycles creates safety. Larger cycles encourage fear as you have more to lose as time goes by. Fear of failing encourages information hiding and deferral of issues.

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.

Agile 2009 Session Results Posted

September 16, 2009 / / 1 Comment

It’s been a few weeks and I’ve finally had a chance to go through all the photos and sticky notes from the “Climbing the Dreyfus Ladder of Agile Practices” workshop I ran at Agile 2009, as promised.

For those that didn’t get to attend, I asked five groups to pick one agile practice out of 12 choices and brainstorm specific behaviours they had observed people participate in. Based on their brainstorming, I then asked everyone to categorise them according to what different level in the Dreyfus Model of Skills Acquisition.

I found it fascinating to see firstly, what behaviours people witnessed, and even more fascinated by the way that groups then tried to classify them. Follow the link above to look at the results.

Reminder of a rule for Giving Feedback

September 3, 2009 / / 1 Comment

A trusted colleague recently asked me for some feedback on their work. I gave them some honest feedback, including a strong suggestion they make some changes since there was a strong potential for offence. Surprisingly, they chose not to take my recommendation and never explained why they disregarded it or helped me to better understand the underlying context.

Although I’m not offended, I’d be lying if I said that I wasn’t a little bit upset. Reflecting on this situation, I reminded myself about one golden rule about giving feedback… you need to be prepared for your feedback not to be accepted.

It’s the reverse of the what I find myself saying when giving advice on receiving feedback… it is okay to disagree with feedback someone gives you.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders Noren — Up ↑