patkua@work

The intersection of technology and leadership

Page 41 of 53

Retrospectives: Making Issues More Visible

Magnifying GlassI remember reading about the Cause, Made Visible and Not Related story on Esther Derby’s blog a while back. My biggest takeaway was that retrospectives aren’t normally the Cause of issues, instead creating Visibility into the issues already present. People constantly surprise me when they say that don’t like retrospectives because it doesn’t fix their issues. Guess what? Simply holding a retrospective won’t magically fix all your issues because it isn’t the Cause of them. Yet how do you go about fixing your issues if you don’t take the time to identify what issues you have, what impact they’re having and how you’re going to fix the true Cause?

Image taken from Dr Pat’s Flickr photostream under the Creative Commons licence.

Maven FAQ

Maven only has 20 FAQs on its page here. I’ve been working with it on a project recently, and frankly I had plenty more than 20 to ask. Here’s my list of a few things that I hope will help people when they’re searching for answers not described well in the Maven documentation.

How do I get a plain file (*.txt) included into my deployment file (i.e. jar, war, ear)?
Maven’s default file structure looks like ${projectBase}/src/main. The compile target looks for production code under ${projectBase}/src/main/java. It looks for other files to include with your production deployment in ${projectBase}/src/main/resources. Adding your file to that directory will automatically include them in your deployment file.

When Maven downloads its dependencies, where does it store those files on a windows machine?
Look for files under C:\Documents and Settings\${userName}\.m2\repository.

Why doesn’t a feature from JDK5 or 6 work?
By default, Maven compiles against JDK1.3. Set the source and target JDK where you have your compile target:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <configuration>
        <source>1.5</source>
        <target>1.5</target>
    </configuration>
</plugin>

How can I create a single deployment file with all dependent libraries merged?
Instead of using the maven-jar-plugin plugin, use the maven-assembly-plugin. Here’s an example

<plugin>
     <artifactId>maven-assembly-plugin</artifactId>
     <configuration>
          <descriptorRefs>
               <descriptorRef>jar-with-dependencies</descriptorRef>
          </descriptorRefs>
          <archive>
               <manifest>
                    <mainClass>com.thekua.spikes.App</mainClass>
               </manifest>
          </archive>
     </configuration>
     <executions>
          <execution>
               <id>make-assembly</id>
               <phase>package</phase>
               <goals>
                    <goal>attached</goal>
               </goals>
          </execution>
     </executions>
</plugin>

Office 2007 Woes: Insert New Worksheet

Excel 2007 is quite a horrible experience. Someone recently told me a story where apparently, Micro$oft said that it’s easier for new users to learn, yet would take three weeks of re-training for existing office users. Shame I fall into the latter crowd and not the former. Read on if you are wondering where your worksheets went and want to insert a new worksheet. Continue reading

Unhelpful Error Messages in Maven

What’s wrong with this: “Cannot execute mojo: resources. It requires a project with an existing pom.xml, but the build is not using one.”

How about? What are you talking mojo to me for? What is going wrong and how do I fix it?

Perhaps something like this would be a better error message: “Maven is looking for the pom.xml file and cannot find it. Maven assumes this file is in the directory you are running it from. If you are running Maven in a different directory, perhaps you might want to use the –file switch.”

What do you have more of? (Part 2)

My last post triggered a few comments, with having a common goal for a team to rally around somehow also implied groupthink, and thus, Wisdom of the Crowds is a better alternative. I want to clarify a few things:

The point of the original post?
Organisations where I’ve seen them have successful delivery, they also had, what I would consider, true teams. People working together towards a common goal. I’ve also observed many other organisations struggling to deliver, and often, because of multi-project context switching, they had what I would describe as “groups of people” instead of a true team.

Not all teams have groupthink
When I think back to great teams I’ve worked on, the individuals complement each other strengths and, at least in my experience, respond better to unplanned events. Talking about the “taboo” topics is fine because everyone is already comfortable working with each other. I compare this experience to what I see around committees, newly formed teams, or even teams that remain unbalanced (due to a particularly strong member or something) where other participants are too polite, or don’t want to cause a commotion even though it may be the right thing to do.

Understandably, when Felix saw my diagram, he (rightly) feared groupthink. In my experience, I feel it is symptom of poor performing teams, and is more likely to happen with “groups of people” (think of all those traditional project managers who make a decision for the team!). I do acknowledge it can still happen in a high performing team.

I believe the trick to making this work is having a leader in the team that ensures that conflict is handled in a safe environment, not simply quashed, silenced or bullied away as these eventually lead to group think.

Wisdom of the crowds don’t necessarily mean all crowds are wise
When I see many groups of people, I don’t automatically see a lot of wisdom. It takes another step before you can benefit from wisdom of the crowds. Often it means asking the right question, the right amount of diversity, and a lot of independence to actually benefit from it. I see the right question the same as having the right goal shared amongst people. It doesn’t necessarily mean everyone is doing exactly the same thing to get there, it just means that everyone is pointing in the right direction.

Not all crowds are wise

An example: Brainstorming using sticky notes is one way that I’ve worked in that avoids groupthink and tries to harness the wisdom of crowds. In my last team, we used it to come up with different solutions to tackle a key design problem (note the shared goal!) We each wrote ideas down independently on sticky notes before presenting them to each other. We even spent some time investigating and proving out a number of solutions to gather some hard data about the pros and cons. What made it work was that we all understood what it was we were all trying to get to (the shared goal), not necessarily how we get there. I felt that this was an example of a real team, a situation where everyone was comfortable disagreeing with each other, and openly discussing each option. It certainly didn’t feel like a committee or a random collection of people. I can only imagine what the outcome would be if we did though.

Once again, your comments welcome.

What do you have more of?

When I go into different organisations, I see many of the people doing the work (analysis, development and testing) split across multiple projects. In my experience there are plenty of reasons why this is just a bad idea, and probably the biggest one that I see is that the split priorities for an individual conflict with a model for ideal teamwork.

What does your organisation have more of? Teams or groups of people “working together”?

Teams and Groups of people

There’s a big difference between the two, particularly if your organisation is interested in tapping into the benefits of teams. Unfortunately most of the time organisations miss the mark.

How can you convert groups of people into teams?
Split priorities create natural conflicts between groups. A lot of management theory I’ve read describes how to get the most out of teams by rallying them towards a shared goal or set of goals. At the individual level, setting different goals for different people establishes a dynamic that, at some point, individuals’ priorities will conflict and without a broader shared goal, will go unresolved. Setting the same priority for everyone is, in effect, putting everyone into the same team. Leaving people split across multiple projects, is in effect, setting different sets of priorities for an individual.

The Agile Coach Role

I’ve previously written an article for InfoQ about how agile coaches act when working with teams. For this particular entry, I want to investigate what jobs or roles you might consider trying to either focus on part-time or try full-time to develop the habits and skills necessary to be an even more effective agile coach.

At the XP2008 conference I spoke with both Liz Sedley and Rachel Davies, two other agile coaches, who ran a workshop about agile coaching. We talked about the different skills an agile coach might need and some of the duties they might perform. We talked about overlaps with other jobs and concluded that an agile coach may do some training, yet only being a trainer doesn’t make you an agile coach (there’s more to it). Below is a diagram that hopefully makes it clear some of the responsibilities that overlap with a number of other roles.

Agile Coach Development Model

As you can see in the diagram above, an agile coach may do many of the things you see full time facilitators, full time trainers, and full time coaches do. Yet doing each of these roles by themselves without the real experience garnered from agile projects does not make them an agile coach.

Using this as a model for career development

Even though I just put this diagram together to help others visualise this model, this is exactly what I’ve been using to further improve my skills as an agile coach. More recently, I’ve been in the role of a full time coach and trainer both internally and externally, and especially fortunate to work closely with other full time trainers to benefit from their experience. That experience has given me a better understanding of how people learn and a broader set of techniques to draw upon when helping others understand the concepts and principles.

Earlier to that, my focus had been towards better facilitation practice, reading books about good facilitation skills, and eagerly applying this during the projects that I’ve worked on. This has been particularly useful in executing the Retrospective practice. Beyond that, I’ve been lucky enough to work on many different agile projects in a development role, benefiting from others’ experiences through observation.

Just an agile coach role

I’d be keen to hear what other full time or part time roles other agile coaches have attempted for short amounts of time in order to develop the skills that will make them a better agile coach. Please leave a comment if you have a suggestion.

Been busy presenting around England

Not much to update other than I’ve returned from Canada and have been busy running a couple of presentations around the place, most recently heading up to Manchester for a night to help Alex Scordellis out with the Manchester Geek Night he’s running regularly. I ran a session called The Agile Primer, essentially an introduction to agile methods. We had a great turn out and I particularly enjoyed the discussion that ensued both during the session and at the pub afterwards. It still seems that, at least in that one pub up north, they shut relatively early. My only regret about the trip was that I didn’t get to stay longer and see Manchester because the weather was so nice.

Yesterday I helped out an analyst group with their Master Class on Agile. Liz Keogh and I pair-presented on ThoughtWorks’ experiences and lessons learned with distributed development, titling the session Distributed Agile: An Oxymoron?. We then followed this up with the XP Lego Game that helped people keep awake after plenty of talking and a heavy lunch.

All the slides and resources, you can continue to find on my page of presentations and papers.

Action is louder than words

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.

« Older posts Newer posts »

© 2024 patkua@work

Theme by Anders NorenUp ↑