Saturday, July 2, 2011

What makes Agile / Lean Work?

I have a theory.

Agile and Lean development practices are not magic, they are also not revolutionary. And it doesn't really matter which flavor you choose. What makes Agile and Lean work is that they simply provide a recipe for following what the management gurus have been saying for the past century. If you want to increases productivity give regular, actionable, feedback.

As an example, take a podcast from Manager Tools on Over Assigning and Delegating Work which breaks down Peter Drucker's advice on how much work to assign to employees.

The key to doing this well as an organization is for all the employees, at all levels, to develop excellent skills at prioritizing work. Even though there is always more work than can be done, the goal is to in each day, week, month ... Do what is the Most Valuable for the company at that time.

To me, this explains the power of the retrospective. Having these regularly (and not like your "performance reviews" are regular - one a year under duress) is how you gather actionable feedback on how well you prioritized your work and goals. A very basic question to ask in each retrospective - is what you did valuable? Was it the most valuable?

Tuesday, February 8, 2011

Practice makes Perfect... thoughts on software testing & professionalism

Which camp are you in? Should we overlook Christina Aguilera's Superbowl faux pas as a moment of human fallibility? Should we strip her of her citizenship and deport her to outer Mongolia for disrespecting the national anthem?

I think the whole affair provides us a good opportunity to reflect on the standards of professionalism. As a friend of mine pointed out, it was an easy mistake to make, could of happened to anybody, she doesn't deserve to be picked to death for it. This is true. On the other hand, in this context she was more than just anybody, she was supposed to be a professional. Being professional means you don't make 'easy' mistakes. It means that when the eyes of a nation are on you, you perform flawlessly, disregarding any but the most unforeseeable events.

Professionals are held to a higher standard. We expect them to practice, to drill, to repeat their performance hundreds of times. We expect them to accept criticism, to seek feedback, and to work out the kinks. As an audience, we don't accept seeing a beta-test on game day.

Which camp are you in?

Do you let project timelines drive shipping untested code to your customers? Do you shrug your shoulders at each new reported bug and say 'well I'm only human'?

Do you use automated testing so that each feature is practiced hundreds of times to work out all the kinks? Do you look at each new bug and ask "How could I have missed that?", and then take action to ensure it can never happen again?

Athletes and performers who "practice, practice, practice" are rewarded by defect free performances. Software developers who "test, test, test" are rewarded by defect free code. In either case, mistakes do and will still happen. But why waste your audience's respect and patience on the easy ones?

Sunday, January 30, 2011

Code, like food, has a MeatCake stage

What's your legacy code base look like? If you swap out "refrigerator" for "Source Control" does the following sketch from George Carlin sound eerily familiar to your team's refactoring discussions?

"Perhaps the worst thing that can happen is to reach into the refrigerator and come out with something that you cannot all. You literally do not know what it is! Could be meat...could be cake. Usually, at a time like this, I'll bluff:
'Honey, is this good?'
'Well, what is it?'
'I don't know...I've never seen anything like it. It looks like...MEATCAKE!'
'Well, smell it!'
'(sniff)-ah, (sniff) has absolutely no smell whatsoever!'
'It's good! Somebody is saving it. It'll turn up in something.'

The hilariously on target post by William Woody at shows just how quickly our best intentions quickly go astray. We try to predict the future and we end up with meatcake code, interfaces and frameworks that do nothing, except get in the way of developing new features.