Navigation

Search

Categories

On this page

Appreciative Retrospective
Software Craftmanship 2009
Windows 7 Beta
Pair Programming smells
Behaviour Driven Database Development (BDDD)
The technology is there to build better software. are you doing it ?
Clean Code: A Handbook of Agile Software Craftsmanship
Workaround – Error while installing VS 2008 SP1 and .Net 3.5 SP1

Archive

Blogroll

Disclaimer
The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.

RSS 2.0 | Atom 1.0 | CDF

Send mail to the author(s) E-mail

Total Posts: 149
This Year: 2
This Month: 0
This Week: 0
Comments: 43

Sign In
Pick a theme:

# Monday, May 04, 2009
Monday, May 04, 2009 3:20:56 PM (GMT Daylight Time, UTC+01:00) ( Agile | Agile Retrospectives )

 
Recently I facilitated an Appreciative Retrospective for my team. An appreciative retrospective focuses on the positives “What did we do well? What worked ?”, instead of the usual “What went wrong, What can we do better” tone of retrospectives. This style of retrospective uses Appreciative Inquiry to identify what went so well.  There is no blame or negativity, and builds on the Prime Directive, that everyone in the team did the best job they could possibly do.

Appreciative Inquiry builds on the positives, and attempts to amplify the good things we have done, and ensure that what makes us good is identified and refined. We usually end up loosing sight of what works for us in retrospectives, as we focus on the problems to fix.

I followed retrospective plan described here Retrospective using Appreciative Inquiry. The goal for the retrospective was to find “Where and how we added value during the past sprint”

Setting the stage. (5 minutes)
To set the positive tone, ask each member of the team to write on a post-it, a note of appreciation to someone else on the team. When everyone has written their notes, go around the table and have them read it out loud.

Gather data (5 minutes)
This is a brainstorming exercise. Distribute post-its of 3 colours. On each coloured post-it, have everyone write the team’s successes, strengths and events during the past iteration. Use one colour for each. Write as many as possible. Stick these up on one section of the board.

Generate Insights

Brainstorm the future (10 minutes)
This is similar to the previous exercise but needs more creativity. Have the team time travel to the end of the next iteration. Imagine what their successes, strengths and events would be in the not so far future. What would they achieve if they keep doing the best they can.

Write these on the same coloured post-its as the previous exercise and stick them up on another part of the board.

Affinity Mapping (15 minutes)
Get the team to the board. Group the different post-its. It is ok to mix up the post-its. Look for common groups and themes, pull these out. Group them into their own sections on the board and circle and label them.

 photo (1) photo

Dot voting (5 minutes)

Have the team think about what groups/themes they want to sustain. Each member has two votes. Pick two groups with the most

Technorati Tags:

votes.

Decide what to do (15 minutes)

Ask the team, based on what they have identified as their future successes, strengths and positive events, what actions can they take do achieve them. This could be in the form of “do more of, keep doing” actions.  Pick two to three actions but not more.

Close the retrospective. ( 5 minutes)

I closed the retrospective with a Activity +/delta exercise.

photo (2)


My team found it very refreshing to focus on the brilliant work they’ve done, instead of being reminded of the few negative things that affected us. Variety in retrospectives was welcomed. Although the team wanted not to loose sight of negatives.

I recommend this style of retrospective, when the team is doing a lot of good things. However, make sure that any pressing issues during the past iteration are addressed. We had a post retrospective discussion about our stand-ups.

Try it for your team.

Comments [1] | | # 
# Sunday, January 11, 2009
Sunday, January 11, 2009 1:14:56 PM (GMT Standard Time, UTC+00:00) ( )

BBC Worldwide (my employer) is sponsoring a conference on software craftmanship on the 26th of February 2009. This is about the skills you need to build better software. This is about the refactoring skills, spotting code smells and habits that make you a better developer.

The programme and registration details are at Software Craftmanship 2009 

This conference is not about how to do Agile, or how to get started with TDD or how to get started with a certain technology. The conference is programming language agnostic and the skills can be applied to any programming language.

Comments [0] | | # 
Sunday, January 11, 2009 12:54:39 PM (GMT Standard Time, UTC+00:00) ( Windows )

Typing this from a laptop running Windows 7 Beta. This is an older laptop, which is now idle because it has been replaced by a new Dell Studio laptop. Toshiba Satellite M30, 1.5GB RAM, GeForce Go 5200 with 64MB video ram. The only problem was finding the driver for the GeForce Go 5200. I found the Vista 32 bit drivers for this from here. I’ve got full Aero running, it it’s quite snappy. All the other drivers are the normal Vista 32 bit drivers.

image

Win7 hasn’t picked up the power management utilities from Toshiba (?), trying to see if the utilities from my other Toshiba laptop will work on this. Looks very good so far. Think I’ll wait for Windows 7 to upgrade my main laptop to a 64 bit OS. I’m still not very happy with the driver support from nVidia, and ATI does not seem to be much different either.

Comments [0] | | # 
# Saturday, January 10, 2009
Saturday, January 10, 2009 7:38:42 PM (GMT Standard Time, UTC+00:00) ( Agile )

Stumbled across this blog entry by William Pietri. Made a list of some pair programming smells I have observed in the wild

1. Quiet Partner  - only one does all the talking, the other listens quietly, often looks bored and un-interested.

2. God Syndrome – the less experienced of the pair is afraid to ask questions. Not wanting to admit lack of knowledge. The superior of the pair zooms along assuming the other is following along.

3. Constant Arguing – over minor design decisions, egotistic reasons. not coming to conclusions.

4.  “My work is so boring, I don’t you to want to see it, let me slave away in the salt mines”

5. Going too fast – Either of the pair going too fast.” I know what I’m doing, just watch me”, and not bothering to explain.

6. Lack of focus - “Hey look at this other thing I’m doing”.

7. Quiet pair – ignoring partner, partner not interested. “I finished everything when you were having a cuppa”.

Ping Pong pairing

SO questions tagged with pair programming

Comments [0] | | # 
# Saturday, December 27, 2008
Saturday, December 27, 2008 11:20:26 AM (GMT Standard Time, UTC+00:00) ( .Net Data | Agile )

Pramod Sadalage, has written an article on Behaviour Driven DB development. http://www.methodsandtools.com/archive/archive.php?id=78.

He writes about adding behaviour to the domain model and how that behaviour is translates into database objects, with tests. In the project I'm working on, which driven by a Web UI I use the UI behaviour to build the presenter and  through this add behaviour to the domain model. It's at the last stage that I add the persistance, through Nhibernate.

Comments [0] | | # 
# Thursday, December 11, 2008
Thursday, December 11, 2008 8:03:25 PM (GMT Standard Time, UTC+00:00) ( .Net General | Agile )

here is a random thought I had today.

From what I've seen, in the past 2 years, agile practices have spread among the .Net community.  The .Net framework  gives us the power to do TDD and follow other agile principles.  the community is now empowered with a rich API , so that we don't have to worry about how to build things.  We now have to worry about what we can build and how to build it better.

We have been freed from the shackles of VB and classic asp, with a good OO framework, that is getting better. You name the problem and there is a very good .Net based tool to help you solve it. You want mocking , you have Rhino Mocks, you want persistence you have NHibernate, you want testing APIs, you have Nunit, Mbunit and what not. 

The technology and tools to build better software is here, are you using it ? if not what's stopping you ?

Comments [0] | | # 
# Wednesday, September 17, 2008
Wednesday, September 17, 2008 3:26:00 AM (GMT Daylight Time, UTC+01:00) ( Agile | Books | development )

Seriously, do yourself a favour and go buy this. Keep it on your desk, have it while pairing, use it to bash sense into someone.

Clean Code: A Handbook of Agile Software Craftsmanship . There’s a pretty good review of the book here http://www.markhneedham.com/blog/2008/09/15/clean-code-book-review/

Related Posts:
Martin Fowler Talk

Comments [0] | | # 
# Monday, August 18, 2008
Monday, August 18, 2008 10:58:32 PM (GMT Daylight Time, UTC+01:00) ( .Net General )

 

If you get an error with the message in the install log like;

dotnetfx35.exe failed with 0x80070643 - Fatal error during installation

It helps to run a manual cleanup of any .Net 3.5 framework installations before trying again. Use the automated cleanup tool here. Remove the .Net 3.5 version already installed. You may need to do it twice to do a complete cleanup. Then start the SP 1 setup again.

Comments [0] | | #