David Hussman gave a great session on coaching called “Coaching and Producing Value” at Agile 2009.  (Link to short description).

The first part of the workshop was an exercise for us to describe how we see ourselves as coaches.  My vision (top left in black below) at the time was “Change Agent … by the numbers”.  I know flexibility and adapting is good … and my favourite place to go in an Agile transition is Scrum.  Scrum is pretty structured.  For those new to Agile, this is a good thing.  On the other hand it can make adoption more difficult and increase resistance.  But it puts in the basic engine of change that can go a long way.  The advantage of clear rules and names is that it makes it difficult for organizations to water down Agile so that it becomes the same old process with a different name.

I loved this session since it comes at  adoption in a totally different direction… using the metaphor of producing music.

Most of the session was about Pre-Production. Check out the photo below.  David stresses the importance of understanding out clients’s world so that you understand how to lead them to a better place.  One key element of this is not being prescriptive - tell them about something that worked in another context and see if it resonates with them.

The second phase is Finding a Groove.  This is about helping the team find out what works and what doesn’t.  Again David, talked about story telling as an indirect way of sharing knowledge and suggesting ideas.

The final phase is Keeping the Band Together.  This is all about keeping things fresh through questioning.

All in all, this was a great session for me.

Luiz Claudio Parzianello and Rafael Prikladnicki gave a talk at Agile 2009 titled “Logical Levels and Statistical Games: A Powerful Strategy for Agile Adoption”.  Slides are available here.

On the surface this may seem like a rehash of standard trainers games, but that is missing the point.

One important aspect is that all the games are statistical and can be numerically measured so that it appeals to the left-brain scientific types that dominate the software industry.  The three games are outlined below.

The bottom left of the diagram show the NLP logical levels.   By asking specific questions related to identity and values, it is possible to get a shift in perspective that will provide an openness to learning about Agile.

After playing game #1 comparing the effect of large batches versus small, there are some hard hitting questions:

1. Who has decided to keep your team too slow? (by using large batches)
2. Why has your team agreed with that?
3. What stops your team from changing this situation?
4. Do delivery and time really matter to your managers?

These questions use the NLP meta model to help people uncover information that has been buried beneath their conscious awareness.   This can help them get unstuck from their waterfall world and be open to considering new ideas.  How cool is that?

The games plus the questions form a useful adoption tool. Check out the presentation and try out the questions – there are some real zingers there.  Once caveat – these are appropriate for a Brazilian context and may need some tuning for other locales.

I just blogged about Daniel Pink’s case around intrinsic and extrinsic motivation.  This is a good lead-in for why SMART goals may be damaging to your organization.

SMART stands for:

• Specific
• Measurable
• Achievable
• Relevant
• Time-bound

It is common management practice to tie employee ratings and annual bonus to the achievement of SMART objectives.  In light of the impact extrinsic motivators have on creativity, we must ask if this is really a good idea.  Bonuses or job progression that are linked to SMART objectives are extrinsic motivators, so we are going to end up killing creativity.  Oops.

I will go one step farther, and say that SMART objectives may be directly damaging to the organization since it provides unaligned goals for different individuals.

In the best case these are competing. I am working towards my goal and you towards yours.  Why would I want to help you since that will help you succeed and take away from my effort.  This been seen repeatedly in Agile teams where requirements for individual achievement undermine the team’s ability to function.

In the worst case actually conflicting.  For example, my goal is contrary to what is best for the company.  At that point I face the hard choice to do what is right and what is good for me.  I have seen this situation lots of times.  Managers in the company are provided specific goals that are not 100% in alignment with overall objectives.  That’s really the root of the problem.  Unless you can guarantee that goals (SMART or otherwise) are 100% in alignment with company goals you will run into this problem.  And even if goals are in alignment when they are created, what invariably happens is that there is drift in alignment as new information arrives.  Lean avoids this problem by focusing everyone on the top level company goal: profitability.  Anything else and your company will be wasting effort.

The last thing I’d like to touch on is what it means to be achievable. In IT, there is a lot of uncertainty about delivering software.  I have seen too many projects badly harmed by goals that have board level visibility.  With Agile projects there is some hope: work can be prioritized.  With more traditional projects, the common result is rushed work that leads to low quality and let’s of extra work and delay due to rework.  It can lead to compromised design, bad architecture, and a project that takes much longer than expected.

So watch out for SMART goals – they may not be.

Newsflash!

Incentives and rewards are harmful to tasks that involve creativity.  They bigger the reward, the more harmful.  This is a must-watch video. Many thanks to Yves for posting this is on his blog.

There is a mismatch between what science knows and what businesses does.  Incentives are only helpful for a small range of simple challenges where there is no requirement for creativity.

Maybe this is why I have done my best to ignore bonus plans and just do the right thing…

Daniel suggest 3 basic element that can unleash productivity:

1. Autonomy – Agile translation: self-organizing team.  Lean translation: Independent teams, Leadership by A3
2. Mastery – Agile translation: Retrospectives, Pairing, Craftmanship.  Lean translation: Mentorship, Quality
3. Purpose – Agile translation: Connection with business and working software.  Lean translation: Focus on Value

This fits very well with the mental outlook I use to help companies excel.

In the Agile space, David Harvey’s blog discusses Alfie Kohn’s book on this subject and comes to similar conclusions.

Check out my related post: SMART goals may not be that smart

George Schlitz and Giora Morein gave a great presentation/workshop on Agile Enablement Battlefield.  You can download the presentation here.

First off, let me say that I am not a big fan of military metaphors.  I like to think more in terms of growing understanding.

Anyway, the main point of this talk is that it is really helpful to draw an influence diagram with all the players involved in and surrounding and Agile project.  Colour code all the players so that you know where to focus your attention.

In the diagram, one can see that negative influencers (far right) may eventually impact the team, so this is the purpose of casting a wide net when drawing this out.

The fog of war is just a reminder that we often don’t know people’s real disposition so it’s a good idea to guess and then update the diagram as information becomes available.

Also, check out Portia Tung’s description of the session.

This is another talk from Agile 2009 – by Liz Sedly and Rachel Davies.   I think it is an excerpt from their new book - Agile Coaching – but I have not read it yet so can’t say for sure.  Yves Hanoulle says the book is good.

The 1 to 10 is pretty self-explanatory.  Post a comment if you would like elaboration or check out Mark Levison’s post on InfoQ.

The bonus section is what the audience contributed as their top tips.

Also, if you like this, check out my other post on 10 Temptations of an Agile Coach.

Jared Spool gave a pretty good banquet keynote for Agile 2009 on User Interface Engineering.  The main point is that is that very successful companies use amazing interfaces as a key competitive advantage.  And the key to this is good user experience design.

Case and point is Apple.  We watched an Apple video from the 80’s that showed Apple’s vision for the future of the computer (funny/sad was a plot element so long ago was about global climate change).  Everyone at Apple knew what the vision was and could explain it.  So what this means is that everyone is thinking about the long-term vision.  Every time they have a choice to make on design they can take a step in the right direction so that the future can be achieved in part through many many tiny shifts.

Good design is INVISIBLE.  NetFlicks is destroying their competition through a ridiculously high net promoter score (how likely someone is to refer a friend).  No one ever mentions their Web UI even though it rocks – it’s invisble: It does what it needs to and it’s easy.  How do they do it?  In part through a culture of excellence – employees are the top priority and the CEO puts this ahead of board meetings.  To support this they hire fast and fire fast.  They also pass the culture test.

How do you learn good user interface design?  Mentoring!  Good designers know what good design is, but cannot explain it.  Like chicken sexing.  (Makes me wonder how much we are kidding ourselves that good design can simply be taught through patterns or what not.)

The company test is a recipe for successful cultures.  All the companies with awesome user experience met the test even though they were radically different in many ways.

The last point about celebrating failure is critical.  If people are not making mistakes, then they are playing it safe.  And if they are playing it safe, the result is mediocrity not excellence.  There is a similar field of thought around innovation – it also requires support for failure.

If you need help building better UI, start with #2 – spend some time observing your users and then make it better.

Christopher Avery gave a very interesting talk at Agile 2009 called How to Develop Your Leadership Power Daily: An Agile Approach to Growth.  It was a very interesting talk about personal responsibility and how to grow – hence the title of this blog post.

Sidebar comment: This talk really has nothing to do with Agile so it appears that the conference program is branching out in new directions.  On the other hand, if you want to coach or build a high-performance team, then this is useful information.

The top left corner has the most important bit of information.  We are hard wired to not accept responsibility and would readily blame others.  As we are more self-aware we can progress from denial to blame to justification – all the way up to ladder to responsibility.   You can request a free poster here and there is a short description here.

The 3 keys are about how you can shift your own behaviour:

1. Intention – intend to change your behaviour so you can win!
2. Awareness – pay attention to your language and thinking.  Make a chart of how many times a day you can catch yourself not taking responsibility.  One way is to carry around change and give yourself a penny for noticing when you say something unresourceful and 10cents if you catch yourself before you say it.
3. Confront – you need be honest with yourself or you’re not going to get anywhere.

The daily practices are some additional tricks to help move towards personal responsibility.

The anxiety hierarchy is about how some words you use when talking to others can trigger defenses.  Approaching someone about a PROBLEM will result in getting their input on a consideration.

As an NLP Master Practitioner, there is a note in the corner to remind myself that it’s not that easy to shift behaviour.  We often have limiting beliefs and values conflicts that may need some shifting in order to make a persistent change.  Awareness is a good start, but in my experience often not enough.

I’m writing about a talk given by Paul Hodgetts at Agile 2009 called “ScrumMasters Considered Harmful – Where Did We Go Wrong?” (Link to full presentation).

So, why doesn’t the title of this blog post match?  The title is really catchy, but the the talk was more of an investigation and discussion of what the ScrumMaster role really entails.  Check out the Mind Map below.

Some of the interesting things to note are that there are a lot of roles that a ScrumMaster is supposed to take on if you are following Scrum – see the green checkmarks.  (If you are not following Scrum – why do you have a ScrumMaster?  Anyway, it’s a tough job!

One hot area  is around the role of Project Manager or Task Master – there is often a management expectation that they will play this role.  I have seen this many times.  Hint: a better answer is that work needs to come through the Product Manager and that the team is un-interrupted for the duration of the Sprint.  But every situation is different, so there is no always in this.

On the left in purple, can be seen a number of candidates for taking on the role of ScrumMaster.  It can be a tough role to fill.

Tonight Amr Elssamadisy from GembaSystems presented at the XPToronto/Agile User group.  There was a big turnout of almost 40 people and I think one person didn’t actually have a seat.

What follows are a series of notes from the talk without too much editing…

People’s reasons for wanting to hear about Technical Debt tonight

• People with short-term focus
• Technical Arguements
• Is it worth refactoring
• Currently living in Legacy Land
• Business value of paying down technical debt
• How?  (to fix)
• Best Practices
• Root causes

Examples of Technical Debt

• I have spent 3 years building legacy code web site with no unit tests.
• Code that has been copy and pasted.
• Code that is difficult to get under test: large classes, methods.
• Branching and duplication of the application.
• Duplication of functionality written by different people.

How does technical debt affect behaviour?

New requirements

• Dumbed-down solutions
• Fear of change.  Not sure what will happen.
• Question to ask: How hard is work this year compared to last year?
• Splinter IT group into siloed green team

Design

• What design?
• No new design
• No changed design
• Tons of band-aid solutions
• New features need to be workaround

Defects

• Only critical ones
• Lots and time and effort in regression ? $$$
• Many bugs don’t get fixed – bad code
• Often sketchy manual testing

Maintainability

• Goes down with technical debt
• Dead core after 5 years
• Inventor’s dilemma – productivity goes down over time.
• Difficult to get new people who can work with the code base.

Why do teams fall into this trap?

People follow cost of change curve.  It rises exponentially: requirements to analysis to design to test to production.  Code is fragile for everyone but the author.

Test-first development makes the cost of change linear.  Courage?  Not needed so much since you have a test harness.  Tests act as a signaling system to people working on the system that there is something they need to pay attention to.

“Programming as Theory Building” – this can only be learned through apprenticeship which is not practiced in corporate America.  So what do you use?  Documents don’t work – this results in a new paradigm and the level of mismatch leads to additional cost.  Perhaps pairing is the new apprenticeship model.

Breaking dependencies and adding test to legacy code

Low coupling and high cohesion are main design principles. –> Get teams to agree to “do no harm” to the design

Example of adding code into a function.  This will make cohesion worse.

1. Take the code to be modified and move the code to a new function.  (Extract method refactoring)
2. How hard is it to create the main object?  Probably really hard.
3. So, refactor to a new class (a sprout) instead so you can create it and test it.
4. And may need to create mock objects to make this work due to parameters.
5. Use refactoring to aggregate related sprouts.

Read Michael Feather’s book - Working Effectively with Legacy Code.

Like most things, this is a people problem.  And then we had an interesting digression into Christopher Avery’s material on personal responsibility.