Notes from a Tool User

Quick Links Week #8

Hopefully its obvious to all and sundry that this blog and been transformed. As you can see I’m in the middle of launching a new business site: Agile Pain Relief Consulting. The blog will always be called “Notes From A Tool User” and notesfromatooluser.com will always work but from now on it will be a 301 redirect to this site. The upshot – please do not adjust your set it is functioning as intended.

The transformation is far from complete – some structural work and alot of writing left do. Please excuse the mess. In the mean time I’m going to get this blog back on track.

This weeks Quick Links:

We’re hearing alot about Toyota’s woes in the news. Hal Macomber thinks the common claim that Toyota lost it’s focus in attempting to become the world’s largest car manufacturer is wrong, read: What Is Going on with Toyota and Toyota’s Lesson for Project Managers for more.

Dave Nicolete (riffing on some comments by Dave Rooney) suggests a simple way for estimating a teams initial velocity for its first few iterations. This is the problem that teams new to Agile have, management want an initial estimate of how much work will get done before the product is released and the team don’t have enough experience to give it.

Sandy Walsh (a former colleague from Andyne Computing) is writing an interesting series on the importance of readable code: A Tale of Two Code Bases and Your Code is the Other Team Member .… 

In Goal-Oriented Daily Stand-Ups, Joakim Karlsson offers the idea of setting a daily team goal which helps to ensure that the individual tasks towards the team’s goals.

In the early ‘80s the department of Computing Science at Queen’s University got its first Vax 11/780, at the time my father complained that professors no longer talked instead they emailed each other even though their offices were on 10 ft apart. Phil Jeffs notices the problem continues: Don't email me. I'm sat right next to you.

Ottawa Scrum Users Group for January

The Ottawa Scrum Users Group is running a “Release Grooming Meeting” on Jan 28 at 6:30pm. Location the QNX offices 175 Terence Mathews Crescent Ottawa.

The agenda: January's meeting will be a round-table discussion on the 'Release Grooming Meeting'.

The product backlog for this meeting will be: Topics which the group would like to see over the next year.
A discussion topic for the initial backlog is:

• Storypoints - tips/tricks, estimating, absolute vs relative, maximum size, etc
• Business value vs ROI
• The lifecycle of a story
• Release planning meeting
• Focus on a Scrum role - Business Owner, Scrum Master, etc
• Scrum artifacts and their usefulness
• Adopting/Advocating Scrum
• The role of QA
• how do you know when a story is done?
• working with debts (design, testing, bugs)
• bug tracking systems: are they really needed?
• when Scrum doesn't work so well (e.g. software maintenance)
• what makes the perfect Scrum team (size, member profiles, skill sets, attitude, etc.)

Please feel free to add any other topics leading up to the meeting (via the Meetup group)

During the final third of the night, we will be discussing the idea of running our user group like a Scrum project.
Pizza and refreshments will be served!

For a variety of interesting reasons Ottawa has two Agile user groups – the Scrum Users Group and Agile Ottawa. Both groups are open and happy to help members of any Agile tribe.

Quick Links Week #7

Sorry for the missing a week – I’ve got serious business site renovations going on stay tuned for an announcement in the next week or two (Note this is an estimate and not a commitment).

Jonathan Rasmusson offers the Drucker Exercise a simple way to get a team to gel at the start of a project. I think I might use this with the next team I coach to help break down those initial barriers.

The Mostly Free Detroit Agile Conference a great little conference in Dearbon Michigan (a bit far from Ottawa). Which leads to Matt Heusser: Conferences on the cheap – Matt offers ways of doing conferences for much less than the expected rate.

I keep on hearing about Continuous Deployment and while I think that most teams are not ready for this by a long shot – its one hell of a goal. Eric Reis introduced me to a great case study from Ash Mauyra. The downside of being an outside coach is I rarely get to see clients make it to this level. Usually they let go of their outside consultants long before they get to this stage. Way to got Ash.

Over at Cutter Jim Highsmith has some good reminders around Self-discipline and Self-organization. Short, simple and sweet.

A very large list of on line collaboration tools. Might be useful assuming that you feel you really need distributed teams (see Self Inflicted Agile Injuries).

A Community of Thinkers - A personal commitment

In December Liz Keogh, Eric Willeke and Jean Tabaka finding themselves in Boulder at the same time got together at the Rally offices. In only a day they managed to draft a statement of the beliefs and respect. If we all agree to follow them and respect each other many of the rifts that have appear in the Agile community in the past year will start to heal (see the comments under Jean’s post: “Escalation” for examples of those rifts. Also see the Cutter 2010 predictions).

Agile Quick Links Week #6

I’m back in the saddle after having taking a couple of weeks off the internet.

This week we open with a pair of posts around TDD. First up Scott Miller of Atomic Objects ran a simple experiment: Faster, better, cheaper! TDD wins in a simple experiment and then earlier this year Mike (GeePaw) Hill wrote: How TDD and Pairing Increase Production a good explanation as to why it works.

Xavier Quesada Allue aka Mr Visual offers: Build a taskboard in 10 steps.

Not a blog post but a useful tool: Sonar from Codehaus may give a way of measuring some (but not all) of your technical debt.

Dean Leffingwell uses Little’s Law, Queuing Theory and Starbucks to show us why large backlogs are not Agile: An Agile Illusion: How That Nice Backlog is Actually Decreasing Your Team’s Agility

Anyone who has taken Agile Training from has heard my remarks about team size. Johanna Rothman gives us: “Ideal” Team Size and Ratios – I’m with her more 9-10 people on a team and you will get separate sub teams forming. On the subject of how many testers/writers does a team need? I like to start with one of each and add developers until they’re at capacity.

Richard Lawrence is chugging away and creating new versions of Cuke4Nuke – a version of cucumber that allows you write your step definitions in .NET: Screencast: Testing Web Applications in .NET with Cuke4Nuke and WatiN

Michael Dubkaov shows us why its a good idea for developers to have some slack time: Kanban Psychology. Can You Say No?

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Self Inflicted Agile Injuries

Offshoring is frequently promoted as a way to produce great products for far less money. So many software development companies boast about sending large amounts of their work to India or China to reduce costs. Unfortunately in doing so they’re often reluctant to pay the price to create and maintain high performance distributed teams.

Agile works on the basis of a few simple principles:

• Short Feedback loops – which leads to iterations, TDD, …
• Radical Transparency – which leads to daily standup, demo/review, …
• Face to Face Communications – which leads to high trust, group problem solving, …
• Value – which leads to eliminating waste
• Continuous Improvement – which leads to retrospective, adoption of engineering practices.

Thinking back on every project that I’ve ever worked on (Agile or not) the quality of communications was a good predictor of the success. So when we run distributed teams there has to be a focus on making the communications work.

At best the typical approach to this problem is to buy web cams, fancy video conferencing software and conduct our meetings sitting in front of them. But that misses the point – these devices improve the quality of communications but not enough. They don’t build trust. To really build trust you have to meet face to face for at least a week. Unfortunately trust is weakened through the course of the year, so it has to be renewed. At a minimum team members need to visit each other twice a year.

So if you really want to get a high performing team – don’t underestimate the real costs, budget for travel – a minimum of twice a year to build and maintain trust. Don’t short change your distributed teams.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Agile Quick Links Week #5

This edition of the Agile Quick Links is being brought to you from a hotel room in Santa Clara.

Matt Heusser takes on one of my favorite recent peeves with: The Fishing Maturity Model.

Gojko Adzic writes about a recent XPDay 09 session: Shock therapy agile adoption at 7Digital. The good news with this shock therapy is that no humans appear to have been harmed in the process.

High Performance teams (see: "The Wisdom of Teams" by Jon Katzenbach and Douglas Smith) is important background for Agile teams. In “What makes a true team” The Financial Post has effectively done a good job of summarizing Katzenbach and Smith.

Looking for good Lean games, I was reminded of the Theory of Constraints dice game: What is the Dice Game or Match-Bowl Experiment? (quick description) and The Dice Game(s) – better explanation and a chance to fire people if the dice don’t their way :-)

Like clock work every 2-3 months someone on the Scrum Development mailing lists asks: “Can the Product Owner and the Scrum Master the same Person?”. Thanks to Boris Gloger we now have 10 reasons to say no.

We’ve all seen the results of individual rewards – pay someone to fix bugs – you will breed bug writers. Reward Firefighters (on a team) and you will get firefighters. Laszlo Szalvay wrote: Personal Heroics vs. Team Success.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Random Notes on Staying A Little Bit Organized

Almost exactly three years ago I was trying to use David Allen's "Getting Things Done" (GTD) system and I wasn’t seeing the benefits he promised. In the end I just found that it helped me thrash. I suspect the problem was more my focus than his system – but at end of the day his approach just didn’t resonate with me.

Today my system is a little closer to a hybrid of Mark Forester’s AutoFocus and Francesco Cirillo’s Pomodoro Technique. I still use MLO as my task manager but on a more granular level than I used to. Instead of slaving over MLO constantly now I use to help generate my list for the day. I use MLO to keep track of a large list of tasks. Mostly I just use the outline to remind of thinks I want to tackle. Daily I glance at the TODO view to make sure that there isn't anything that is date sensitive that I've lost track of. Once it comes to committing to tasks for a day I often use Index cards using MLO, email and anything else as inputs. At the end of a day (sometimes two) I take anything that remains in the card and put into MLO. Then I tear up the card that's probably the most fun part.

Other habits

• I sweep my tabs in firefox every few days and move stuff to reading lists in MLO.
• Once/Twice a week I go offline and go through my email.
• Once a week I take some time to reflect - what is going well; needs improvement; what need do I have the energy to improve; what one thing can I do next week to improve it. Aka a retrospective. This is the hardest one to maintain - because you're tempted to skip it and get more "work" done. Yet its the most important because it drives real improvement.

I use the Pomodoro Technique for:

• a reminder to stay on task
• a way of doing rough estimation every morning

Also on a two monitor setup under Win7 I dock MLO on the far left and leave it in outline mode where I can always see other things I want to do.

Other tools I use: ClipMate Clipboard Extender - because it allows me handle more than one item in the clipboard and to clean (i.e. remove html etc).

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Quick Agile Links #4

I’m working with a client who runs a documentation team, so I was delighted to discover: HeraTech a  new blog dedicated to applying Agile to Techinical Writing.

Preparing for TEDxOttawa this past I saw a couple of great talks: Dan Pink on the Surprising Science of Motivation (hint individual rewards don’t work) and Dan Gilbert on Our Mistaken Expectations (he demonstrates that we’re really bad judges of value).

Henrik Mintzberg revisits Dan’s point to say: No More Executive Bonuses!

I love seeing Agile applied in interesting places and seeing how it adapts – so I offer you the Agile Lawyers Association – it seems like a great idea but the website needs a bit of work.

Michael Sahota visits one of favorite topics – Joseph Pelrine and “Coaching Self-Organizing Teams”. I wrote about this last year: Coaching Self Organizing Teams and Part II.

Finally Ilja Preuss gives a some great tips on keeping time in a meeting (Agile or otherwise).

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Quick Agile Links Week #3

This week I’m leading off with a pair of items on the Brain and recovering from challenging Cognitive tasks: Cognitive Recovery Time and A Dream Interpretation: Tuneups for the Brain (NY Times – login required). The first suggests that your brain needs some recovery time after doing something “challenged” your brain. The second reinforces the importance of sleep and dreams in integrating ideas and information. What this says for TEDx attendees next week – I’m not sure expect that we presenters will have to work hard to make our ideas stick. I also think its a bad sign for the typical two-three day Agile training course.

Joe Little shares his: Agile Principles – examples: all WIP is bad, bad news doesn’t get better with age, You learn the fastest by small mistakes.

Ilja Preuss says something that’s been on my mind for a while: Index Cards are Tools, too!

Johanna Rothmann tells “How Not to Win Friends and Influence People” – I’m only disappointed that she didn’t name names.

Finally Abby Fichtner reminds us: Agile Leadership: Methodology Ain't Enough

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

I’m Speaking at TEDx Ottawa

Its just been announced I’m speaking at TEDx Ottawa (a mini TED – ideas worth spreading) next weekend on my favourite topic: “Learning Best Approaches for Your Brain.” I’m pretty good company sharing the stage with the founder of Bridgehead, a man who has run across the Sahara and many more besides. I would invite you to rush out and buy a ticket – but attendance is limited to 100 people and the tickets sold out a long time ago. On the upside the entire event will be recorded and available on line so you will be able to see all the talks at a later date. Now I’m off to shrink my presentation from its original 90 minutes to the 15 that TED requires.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Why use an Agile Coach?

From time to time I get asked the question why use an Agile Coach I’ve read a book or taken a CSM course. It seems pretty easy. So why would I want to hire a coach?

With just a single team this is basically right, a good coach will still make a difference but you can bootstrap your efforts on your own.

So why use a coach:

• You want to get going faster
• You want to avoid the mistakes that most people make when they start (Scrummerfall, Command and Control Management).
• You’ve started and don’t know how to deal with the organizational impediments that Agile has revealed
• You want to scale
• You want to recover an “Agile Attempt” that went off the rails
• You want to recover a traditional project that is late and over budget
• You’re struggling to Agile in a hostile environment
• …

The reasons vary with each client, but in my mind it boils down to the fact that Agile is easy to describe and hard to do.

Update: Don Grey and Esther Derby have already written on this topic. Great minds think alike.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Quick Agile Links #2

Following from last week, I’m doing a weekly series of posts on interesting Agile Links I’ve seen in the past week.

Steven “Doc” List, has a pair of posts on blame: A Culture of Blame and With Blame Goes Guilt – a healthy reminder about where we should place our focus.

Mike Dwyer: Lessons Learned with Distributed Scrums – his experience mirrors my own working with a distributed/dispersed Agile team. Distributed is still painful but tools like this go a little way to minimizing the pain.

Tool Vendors Reply to My Agile Challenge

Last week I challenged Agile Tool Vendors and the post got a little bit of attention, I got replies from Rally: How Agile is Rally?; Danube: How Agile is Danube? and MicroTool: How We Use Agile to Develop Our Tools.

In addition there were several comments with replies: Robert Dempsey:

CEO and Founder of Atlantic Dominion Solutions. We developed Scrum'd: http://www.scrumd.com. A great post and an excellent challenge. To answer your questions:

# Your Definition of Done

We define done for each user story. Acceptance criteria includes the behavior a user can expect from the app when using it, the workflow for the feature, that it needs to be tested (and how it will be tested), any validations that occur, and if there is documentation for the feature that it is updated.

# Whether you use TDD? Or at least Unit Testing?

We do full TDD for all of our stories. We didn't start out that way, however now that we have a full test suite we keep it that way. Also, if a bug is found, then a test needs to be written for that and then the code fixed.

# What do you do for Acceptance Testing?

We have staging servers set up for internal testing. We also have a few select customers that we let into our staging servers, and I show (in person) some of our current and potential clients the features to get their feedback as well. In addition, we use Get Satisfaction for our support site, and ask that commenters who suggested features that we implement to check out the release and see if it's what they wanted.

# How often do you release?

This depends. We try to do monthly releases. Sometimes it longer, but typically it's less. The release schedule really depends on the importance of features to our user community.

# What did you learn in your last retrospective?

You don't always get it right the first time, however anything you do release needs to work correctly. Also, continuous integration is a huge help as your product gets bigger, and of course, testing is an absolute necessity. We would rather delay a release to ensure quality than release stuff that won't work.

Marcin Niebudek (creator of TinyPM)

I like challenges, so...

Our DoD for stories:

• code meeting minimal requirements committed
• unit tests passing
• feature is working under FF, Chrome and Opera
• feature is working without any significant failures under IE
• feature is tested and accepted by at least one team member that was not implementing the story

Our DoD for release:

• WAR and .exe distros built successfully
• all unit test passing
• all functional bugs fixed
• all UI bugs fixed or small UI bugs (mostly for IE) at least scheduled to be fixed
• installation and upgrade documentation updated
• installation tested on Windows and Linux
• new features list updates at product web site

Do we use TDD? Well I would not say that becuase our coverage is not 100% which means some of our code is not unit tested (glue code), but yes we do unit testing with "test first" style for all domain and business logic code and we tend to shift into BDD style right now.

As our Product Owner is also one of active developers, for acceptance testing we tend to verify features within a team as we have strong and common vision of a product within the team (see also acceptance in our DoD for stories). It's a low ceremony process (as all our processes in the team)

How often do we release? Every 2-3 months.

What have we learned from our last retrospective? That we need to shift into feature branches to be able to release small stories more often while the big ones are still in progress.

Do you see any flaws or warning signs in what I've posted here? Go on, say it... we're always happy to improve...

It would be fun to hear from Target Process, ThoughtWorks Mingle team, VersionOne, AgileBuddy, anyone else I might have missed.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.

Quick Agile Links

An idea shamelessly stolen from O’Reilly Radar. Every week I will publish a short article with 4-6 relevant Agile links. I’m open to feedback on the frequency etc.

Given last weeks announcement from Jerry Weinberg, it seemed appropriate to kick of with a couple of items related to him:

• Jerry as “freaking people Ninja” - Eric Nehrlich (the Unrepentant Generalist) reflects on a session at AYE with Jerry.
• “The View from Jerry’s Shoulders” looks over his writing and comments on his many books. While I like alot of Jerry’s books I will admit that I’ve found “An Introduction to General Systems Thinking” a tough slog. I gather that The Fifth Discipline: The Art & Practice of The Learning Organization (Peter Senge), maybe more to reading abilities. YMMV.

The Scrum Alliance twittered about a new list: Scrum Alliance community discussion group: “All healthy discussion is welcome. Differences in opinion and thought are encouraged. Spam, abusive language and direct advertisements/attacks aimed at splintering the community's energy are prohibited and violators will be warned/banned. Heated debate, differences of opinion, methods other than Scrum or desire for a different SA community group are all open topics. Please be respectful of each other and be mindful that email is often toneless and can therefore be easily taken wrong.” My take – this is a good place to discuss issues that would get you kicked off ScrumDev.

Given/When/Then And Example Tables Using the Robot Framework – Shows how to BDD/ATDD style grammar’s in RobotFramework.

The Airplane Factory game: “The Airplane Factory Game is a simple game to introduce people to Agile and SCRUM. And also, it could be easily adapted to Lean, XP, etc. This article will explain briefly the game, showing the rules, some tips and results. Also, you will be able to download it” I’ve not had a chance to try this game yet – but the premise does seem interesting.

Caveat Emptor - if you buy any of the books after clicking on my link I get 4% of the price. In all likelihood that means I might be able to afford a coffee or two.

If you enjoyed this post, subscribe now to get free updates.

If you want to bring Mark into your organization for Training, Coaching or Consulting please visit the corporate site: The Agile Consortium.