Plea for Agility

Not so much a blog as a plea for agility.

I'm an Agile guy. I'm not a "white-robbed pointy hat" Agile guy, but a capital A, Agile, guy, and I think it works. In fact I know it works cause I've seen it work, I've been there, done that, want to do it again.

In the recent past I have heard some conversations and seen some things that have made my Agile bones shiver.

The first, was a conversational snippet that I overheard from a Product Owner...

"the cost of re-factoring is far too expensive - 

we need more up-front design" 

Now, in no way am I saying "no design", but, how about Just-Enough-Design. ThoughtWorks has a whitepaper on it (http://www.thoughtworks.com/insights/articles/providing-just-enough-design-can-make-agile-software-delivery-more-successful), in that paper, Eewei Chen says, by doing 'big-up-front' design, we ‘hedge our bets’ too early on getting the design perfect before any development or usability testing has even taken place.

Captain Crom over at TheAgilePirate.Net has a great article on a social experiment he witnessed (http://theagilepirate.net/archives/104), his learning's are a real eye-opener, in the end he came up with a great philosophy for design, paraphrased by me...

"explain why it does something rather 

than what it should do"

I would also add to this "and also why it should not do something and the justification of this decision". To me this is the essence of innovation. By giving creative people space to work within a rule set, aka the why, they can create new and interesting ways of "the what"

This fits nicely with the Agile manifesto - "Working software over comprehensive documentation" - it doesn't take a long time to explain why something should behave in a certain way, it does take a long time to explain what it should do in every situation possible. And even better often this can be done in a picture or diagram.

Radan Skoric thinks that not re-factoring often and allowing the bugs to be fixed in maintenance mode is "self-evident why that is bad", well, common sense is not that common, and good practice is even less common (http://www.toptal.com/freelance/large-scale-refactoring) - but, I TOTALLY AGREE!

The second bone shivering experience was when in the daily stand-up a team member looked at an active work item and not only didn't know what it was seemed to be looking at it like it was the first time. To make things worse this was active for two days - not pending or not-started - but active.

"I'm not sure what that [active] task is"

This may not sound all that bad, maybe he forgot for a minute what it was, or he moved it accidentally (this is an online task board), but it was more the way he looked at it. There was pure confusion on his face. This is a task that he should be intimate with; it was his only task; it was assigned during sprint planning and a discussion about it with the senior developer had already happened. How can it be that this is the 'first time' he is looking at it.

To round out this, yet another mish-mash of thoughts and ramblings, I wanted to show this graph.

http://sehlhorst.smugmug.com/photos/132682875-O.png

This is outlines the cost of refactoring, or at least not refactoring often enough. The biggest benefit I have seen from continual refactoring is that it does not become a burden, never is it "oh no I'm going to be stuck down in this code for weeks refactoring", it's just a part of every day development. It becomes, "I saw something that wasn't quite right, so I fixed it", and therefore it wasn't a big deal. This is seen in the “Broken Window Theory” (check out http://pragprog.com/the-pragmatic-programmer/extracts/software-entropy), I love this theory and full believe that it happens every day in software development, especially in a dev-shop where there is a loose methodology and no governing body making sure that the windows are fixed quickly.

War & Snorkels

'We are at war!'

This was the statement a well-known software company CEO recently made in a speech, to describe the everyday battle against business competitors. It was the first time I had thought of software development as war, and it made sense to me.  As this impassioned CEO went on to talk about the differences between leadership and management, I started to connect dots I had not previously seen. Software is war and to win the war you need a strong military leader, not a manager.

History disproves the Whitfield and Strong song War ('What is it good for? Absolutely nothing'). While wars cause terrible tragedy, they have led to some extremely important technological advancements. The American Civil War gave us the snorkel and the submarine; World War 1, air traffic control and sanitary napkins; and WWII gave us penicillin and the first computer used for decryption. War is great for innovation. As the old saying goes, 'necessity is the mother of invention'.

War has not only encouraged technological advancements but process and methodology advancements as well. A recent paper by McKenna and Whitty called 'Agile is Not the End-Game of Project Management Methodologies' contains a great chart depicting the explosion (pun intended) of methodologies that wars initiated (http://eprints.usq.edu.au/23649/1/Agile%20is%20Not%20the%20End-Game%20of%20Project%20Management%20Methodologies.pdf#!).

Is innovation so hard in day to day life because we don't consider the 'enemy' encircling us whenever we write a line of code or attend a meeting? Is the level of 'necessity' not high enough? Is innovation lacking due to the pressures of daily trench warfare - for example, that the sales guy has sold something we don't yet have? Is it due to a lack of 'basic training' - does everyone in your team know how to use the tools they have been given, or not? So many of us have the weapons of mass instruction, but not the skills to implement them.

If software is war, the battles are the scrum sprints. Each battle defines your progress, each win encourages the troops, each defeat means a re-think of the battle plan, each loss, a reorganization. With any software development, but particularly within an Agile environment where innovation and communication are key, having the right leader at the helm inspiring the team to do their best every day, not just at release time, is so important. A great military leader is not the shy, retiring type; they are engaging, enthusiastic, have the weaponry knowledge of a foot soldier, the political know-how of a senator, the business sense of an entrepreneur, and the planning foresight of a soothsayer. Winston Churchill said 'we will fight them on the beaches' but it's how we are in the trenches, not just on the beaches, that makes the real difference. If each day you are doing your best, following processes, and learning and refining your art, then the day you are face to face with the enemy you will have the muscle memory to perform under pressure and win the final battle: the one that signifies the end of the war, and the great software release.

Changing Y

Finishing up a job and getting ready to start a new one is like the end of the year at school. I feel like taking my chair out to the yard an hosing it down - did you do that in primary school?

I can already hear my uncle-in-law saying, " you've got another new job?", as a reluctant member of gen-y, so I gots to thinking...why is it a big deal to change jobs?

If I look at a timeline of my younger days, now slowly disappearing into a memory (can you hear the tiny violins?)

How did I continually move to the next 'thing'? Because I got better at doing those things, I passed, I graduated.

So, why stop?

Now, whenever I get to that point of 'I can't learn anything more from being here - and I can't teach them anything more', then it's time for me to go.

Never confuse efficiency with a liver complaint

Having a 3 year old and a 10 month old means that I end up watching a lot of children's television. No not bad parenting (well not that bad), but we do live in the 21st century and the TV is a great baby sitter and central to the living room.

It does however have its advantages; one being the guise of "looking after the kids", being able to watch all your own childhood favourites. From Tron, Toy Story, the Goonies, Dumbo, and other Disney classics, to The Wizard of Oz, and Mary Poppins. Like most 3 year olds my daughter is obsessed with a movie for about a week, then on to the next one. Well a few weeks back, Mary Poppins was the flavour of the week (think it actually lasted two weeks!), and in that time I ended up watching it a few times - my attention span is much longer than hers so I watched it a lot more than she did! Within the movie there are a few great management and project managements dos and don'ts, here are some of my favs.

1. Never confuse efficiency with a liver complaint 

In this scene Mr Banks and his wife are talking about previous nannies and why they have left.

Mr. Banks: My dear, never confuse efficiency with a liver complaint.

This to me, says listen to what your team is saying, and what they are not saying. If your team is complaining about something - is it efficiency or liver spots? If they aren't complaining about something - who are they complaining too! Undoubtedly there is something to "have a little whinge" about - why aren't they telling you about it! What is this doing to your reputation and the rep of your team?

2. A spoon full of sugar

Bert, the chimney sweep, sings this:

Bert:  A spoon full of sugar, that is, all it takes,
        it changes bread and water into tea and cakes
        A spoon full of sugar goes a long long way,
        have yourself a healthy helping everyday

Bet you were thinking it was the other "spoon full of sugar" lyrics right! This shows us that what we are expecting is not always what we get, so open your eyes, your ears and mouth, cause sometimes its up to you to take the sugar and, more importantly, the medicine.

3. 6:02 pm

This is the scene when Mr Banks arrives home from work:

Mr Banks: I run my home precisely on schedule.
               At 6:01, I march through my door.
               My slippers, sherry, and pipe are due at 6:02.
               Consistent is the life I lead!

For me, this is two lessons wrapped in one. The first is about work life balance. If you have kids especially, getting home in time to spend some quality time with them before bed is important for their growth and your state of mind. But, even those without kids need balance and long hours at the office is not the way to achieve. In my experience long hours mean lots of unproductive time either its the reason for the long hours now, or worse.

The second is about consistency. Not many of us enjoy change, but unfortunately, it is inevitable. So be prepared for it, embrace it, and try your best to move on.

4.  Winifred, please don't be emotional.

In this scene Mr Banks is talking to his wife.

Mr. Banks: Winifred, please don't be emotional.

I'm not one for emotions.

I was going to leave it there but, as with change, emotions are inevitable also. And especially as a man, I must make an effort to understand emotions and realize that peoples feelings (yuck) are important - especially within a team environment.

5. Go fly a kite

When Mr Banks realizes that there is more to life than work and money, he goes to fly a kite with his kids.

Mr Banks:  With tuppence for paper and string
                you can have your own set of wings,
                with your feet on the ground
                you're a bird in flight,
                with your fist holding tight
                to the string of your kite.

Go fly a kite - could be seen as an insult, so be careful how you pitch this one :)

Personally, I see it as a call for innovation. Firstly, the kids have to "invent", and "create", their kites. Then they "imagine" they are like a bird. All sounds pretty much like innovation to me. The key part here is to remember to be grounded (with your first holding tight) - that is remember that innovation within a business must reflect the goals of the business (See my previous post on FedEx day)

6. I never explain anything.

This is a scene between Mark and Mr Banks.

Mr. Banks: Just a moment, Mary Poppins. What is the meaning of this outrage?
Mary Poppins: I beg your pardon?
Mr. Banks: Will you be good enough to explain all this?
Mary Poppins: First of all, I would like to make one thing quite clear.
Mr. Banks: Yes?
Mary Poppins: I never explain anything.

This is one is a don't rather than a do. If you have magical powers and can jump in to chalk drawings and fly using your umbrella, good for you, the rest of us probably have to explain ourselves once in a while. So be careful. Take notes. Record. Don't be the FBI, but make sure that when a decision that needs to be made is made by the right person and it is recorded that they did so.



So that is it. Watch Mary Poppins again, it's a classic. Let me know other movies that you think have a hidden PM undertone and I'll review them too!

The Magic Bass Player

I recently attended the inaugural PMI Australia conference in Sydney. I had a great time, learnt lots, and made some new friends and contacts. I had a few new ideas for posts and you will hear about them over the coming months.

One of the keynote speakers was Cassandra Wilkinson, co-founder of Sydney's FBi radio and a heap of other diverse things (http://en.wikipedia.org/wiki/Cassandra_Wilkinson). Her talk was extremely fascinating and one story struck a chord with me (pardon the pun), so I will attempt to do it justice here...

The Magic Bass Player.

The lead guitarist has his solos and his great riffs - he could be in another band tomorrow.

The singer has his songs and his great voice - he could get a gig in any band.

But the bass player, all he has is the band, so he puts all his effort into making sure that the band continues and is successful. He is the guy who, when the drummer sleeps with the singers girlfriend, gets them back in the room together. When the guitarist is shipped off to rehab, he is the one who sneaks the guy out and hits the pub for a drink.

Why is the magic bass player important? Cause without him there is no band, without him the band falls apart.

It could be said that the same is true for the project manager and the project. He wouldn't be without the project. He keeps the project running. He makes sure that the project sponsor and the tech lead maintain a healthy relationship, etc.

Cass also talked about the difference between dreams and plans. Imagine if Martin Luther King had not said "I have a dream", but instead, "I have a plan". What would the response have been? When will it be completed? How much will it cost? What are the steps in this plan? Who is involved in the plan?

This resonated with me as I have felt this way coming out of strategy sessions where a plan was proposed but no details of the plan. At the time I was annoyed that there was a plan with no details, and I annoyed my managers by asking the same questions as above. But perhaps it was just wording or even worse my comprehension the wording that made me annoyed. Instead of me believing in the dream, I was left asking specific questions about a plan. I think this is a good lesson for Project Managers and Managers alike: We need to create something to believe in not just something to follow.

Well, hopefully you get the gist of the Magic Bass Player story, and if you get to hear Cass speak I highly recommend it.