I love spending time with my son.  He frequently reminds me that sometimes, life perceived through the eyes of a child is a pretty acceptable way to go.  I was a bit naive going into father hood and thought that I'd be the one doing all of the teaching. Yet every day I spend with my son teaches me something new about how to look at work or personal life in a different way.

Dave and I are in the process of collaborating to produce a new version of our Agile Training Course and I've had the chance to sit and reflect a bit on the Agile Process.  When you're deep into project execution, it's easy to loose site of the forest for the trees and it's good to take a step back now again (distinct and separate from your post-mortems) and look at the big picture.  Of late, I've been mentally musing about how to look at the process through the eyes of a child, and what that view can teach us as Agile practitioners and trainers.

Story time is where it's at

My son loves story time...alot.  He likes it so much that he usually forgets that the next logical step after story time is bedtime (which he doesn't like so much).  Grabbing a few books or the latest Highlights High Five issue and curling up on the couch with mom and dad makes his day.  And for us it's fun to watch him learn in the process; letters, numbers, words, and getting the moral of the story.  He asks questions, he recognizes inconsistencies when we try to shortcut or gloss over story elements, etc.

For Agile practitioners, story time is definitely where it's at.  User stories and their prioritization/refinement over time are your backlog, your requirements, your road map for what you're going to build.  YOU SHOULD LOVE STORY TIME.  The initial generation of backlog, while important, takes a back seat IMHO to the sprint planning session.  This critical planning period at the beginning of each iteration is your "story time". It is your shot at learning all the letters, numbers, and semantics of what is important to your project owner, and by extension your users.  And it's important because the outcomes of story time are going to govern your work days for the next iteration.  So, grab your backlog, ask questions, point out inconsistencies, and really focus on learning all the details that will make your team successful over the next iteration.  And don't worry, bedtime is a full two weeks away.

The best made plans...

Most, if not all, parents already know this, but it bears repeating for expecting or adoptive parents: Get used to being late or having plans foiled at the last minute.  Illness, tantrums, an innate desire to not wear pants today...I've seen it all.  I've even left a half-full cart of groceries in the Whole Foods aisle (sorry stock persons!) and walked out to try again later.

You're screaming right now and I understand you're upset.  But you can scream in the car on the way home, not in the grocery store.

We can't always control what our children do, but we can certainly control where they do it and clearly illustrate the consequences of their actions.

The Agile process embraces change during the development cycle of a project.  This is a standard Agile 101 statement.  It embraces change by allowing change to happen (adding/removing stories from backlog, changing priorities, etc.) at predefined points in the cycle.  Still, some Agile teams get a little bit antsy when a client or project owner starts talking about wholesale changes to their process.  This nervous response can happen for a couple of reasons. Is the Scrum Master doing his/her job? Why is the team hearing from the project owner mid-sprint? Another option is simply the ingrained aversion for changing horses mid-stream.  I see this on teams who have switched from a sequential delivery model in their recent past.  Message: change happens. Get used to it. You can't control what your clients want...but Agile gives you a toolbox to control when change happens, and provides metrics for you to illustrate for your clients the consequences of their decisions.  Use these tools and enforce the process!

Open your ears and listen

Betcha' thought this was the section where I talk about getting my son to listen?  On the contrary...My son and I were spending some time together the other day and under his watchful eye I was helping him build an enormous house of blocks.  I take direction pretty well, but I was apparently frustrating the heck out him by building the ramparts on the roof into a really neat and symmetrical pattern that I thought anyone might like.  Finally, I got the hook...via blood curdling scream to stop what I was doing.  I was present with him and engaging in some good old fashioned child's play, but I wasn't listening to what he wanted.  Once I mashed the blocks up on the roof into the pattern he wanted, all was well in the universe.

How often do we, as architects or developers, build a really neat function or feature that we like, but turns out to be the antithesis of what the client wanted? Far too often.  We love tools and widgets and gadgets and technical challenges but the client doesn't care.  I worked on a project at a previous company where I spent two hours elaborating a user story into a several child user stories with tons of tasks that was going to turn into a really cool technical solution that was going to take me a week to build and test.  The client looked at it and said,

Ummm, all I want you to do is add my ABC layer to the map.

Curses!  Esoteric technical solution foiled again by selfish client. Wrong!  Once I stopped to listen to what the client wanted, I was able to deliver the correct solution in as long as it took to fire up ArcMap, add a layer, and bounce the ArcGIS Server service.  Stop and take a listen every once in awhile and you may be amazed at what you learn.

It's OK to say "No"

One of the things I really struggle with as a parent is the actual act of being a "Parent" when I need to be.  I want my son to think I'm fun and cool and to always say he loves me and it took me a lot of frustrated evenings after bed time to learn what so many parents already have: I can be his friend later, I need to be his parent now.  This means not starting a wrestling match when mom is trying to get him into the bath. It means not flying off the handle when he says I'm mean or he doesn't like me.  It means saying "No" sometimes even when I know that "Yes" will bring a smile or a giggle.

I like numbers.  I was a math geek in school even though that wasn't my chosen major so I love the numbers that our Agile instrumentation generates for me throughout a project.  Why?  Because they help me say "No" when I need to.  Even better, it allows me to say it and illustrate why diplomatically and matter-of-fact-ly without the typical posturing and table slapping between client and consultant.  If my team's velocity and resource allocation is determined by 6 or 7 actual productive working hours during a day, and there are 10 days in an iteration, then I can show the client a fixed number of hours and the allocation of those hours to what my team feels is achievable.

No, based on current story prioritization and available resources you cannot have that super-duper-new-fangled-thing-you-just- thought-of.  However we can enter it as a high priority item for the next iteration and reprioritize other stories accordingly.  If you wish to increase velocity I can add an additional developer to the team next iteration and we can discuss the financial impact of that change.

In addition to being the servant leader, it's OK for the Scrum Master to be a good parent and say "No" once in awhile. If the project owner throws a tantrum, please see "The best laid plans..." above.

Relax, Regression is Natural

Having spent a couple of years watching my son grow and change, my wife and I have recognized that he goes through cycles of development where there are short bursts of physical growth or learning in a particular area.  If he's growing like a weed, that energy isn't going into learning new words or actually hitting the toilet at potty time.  When he's sponging up new words, writing skills, etc., then he's not physically growing as fast.  And occasionally, word enunciation or behavior will regress because his body or his brain are busy doing other important kid things.

Regression in this case is not regression of the code base or feature set of an application.  What I mean by regression for the purposes of this post, is the natural ebb and flow of successes and productivity that occurs an any Agile team.  Things can go pretty rough on a new Agile team...poor acceptance or backlog achievement stats, uncertainty at certain points in the process, etc.  All these growing pains typically work themselves out.  As an Agile team becomes more mature, planning and velocity get better and things really start to hum.  Stories get spontaneously added to backlog by your team, individuals swoop in take backlog from others if they finish early, team members pull more backlog into an iteration mid-stream, etc.  But even on teams that have been doing this stuff for awhile, there is regression.  A completely new or unforeseen technical issue rears its head, a team member is out with an extended illness. Death in the family, job stress...Hey, maybe you're just having a bad week.  The key here is to never blame the process for your team's inability to succeed.  Energy is being put elsewhere to ensure a healthy, mature team over the longer term. Regression happens, relax.

The rules apply to everybody

We eat dinner as a family at the kitchen table every night.  TV off, no distractions, just the three of us and the two begging canines circling the mobile food delivery system that is my 3 year old.  We've been working on table manners lately: use your utensils, chew with your mouth closed, use a napkin, the standard stuff.  So the other night I'm correcting my son for some infraction that I no longer recall and while I'm talking to him I slouch to one side and bring my elbows up on the table.  I am promptly interrupted by, "Papa you sit up straight and keep your elbows off the table!"  Momentarily defeated, I am reminded that there can't be two sets of rules in the house.

Ever work on team where the rules don't apply to everybody?  Maybe it's a team member that is chronically late for, or jesu forfend, skips stand ups entirely.  Maybe it's the scrum master who decides you're going to skip the post mortem this time. Maybe it's allowing a project owner to interject major issues in the middle of a sprint.  First of all,  the ground rules should have all been dealt with during the project fit check, just before inception. Second, the same rules apply to every body.  I don't care if you've got the most seniority, I don't care if you've been "12th level black belt scrum master certified", and I certainly don't care if you think you're the smartest or most productive one on the team.  We all succeed and fail as a unit and therefore, we all follow the same rules.  In short, it doesn't matter what the specific nuts and bolts of your particular Agile process are; it matters most that the entire team realizes they all play by the same rules, none of which are optional.