the measure of Awesome
Development at work has been trending well in the new year and the team is getting excited about our formal incorporation of practices such as TDD and pair programming.
I'm definitely perceive an intangible benefit in culture and fun. With a full test suite and engaged developers working out loud coding is fun again.
I give a lot of thought to developer efficiency and generating metrics around our output is very important to me. We are at a point in this iteration where I have too many stories in progress and it is taking a few extra days to get work completed and accepted. This does not concern me greatly since this is a new team and it usually takes a few turns to get into a rhythm. I was walking down the hall and one of developers said that things are going 'Awesome'. I said "Great, but awesome is not a metric".
Since then he and the rest of the team have risen to the challenge and we have some demonstrable facts in low bug counts and high numbers of actual hours (hands on keyboard time) logged.
I'll have a clue in a few weeks and 'know' in a few iterations that TDD and pair programming have raised productivity in this team. For right now I do think things have improved and I feel that our velocity is going to increase. IMHO my personal job satisfaction has increased.
So I may have been nieve last week in saying awesome is not a metric. I'm now thinking that awesome must a metic with a correlation to both employee retention and code quality. We simply have not developed the tools to measure and understand this thing we call 'awesome'. I can only observe the secondary effects that occur when there is "awesome" within a team.
This is kind of like gravity. Science can only measure the effects of gravity but you can't run without it. And running beats floating back and forth aimlessly any day.....
Jugaad – India’s Agile style
I’ve been reading about India’s concept of Jugaad, possibly poised to enter our buzzword vocabulary since it came up in the context of what Obama can learn from that country.
Where the Agile Manifesto starts with “Individuals and Interactions” the Harvard Business Review kicks off Jugaad with “Thrift not Waste”.
All too often I’ve seen Agile work because a scarcity of resources (money, time or knowledge) pushed an otherwise waterfall loving group into giving Agile a shot. The tenants of Jugaad resonate with me as a more general philosophy about how to get things accomplished then Agile’s focus on “working software”.
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value
Working software over comprehensive documentation
Jugaad (quoted from HBR):
It feels like we are talking about the same thing. Get a team together and empower them to solve the necessary problem. Nowhere is there a concept of ‘throw money at the problem’ or ‘hire more consultants’. Plan for change and change plans in order to achieve success.
I’m on a barcamp high today. We could have had a conference with a big budget, focused our marketing on the demographic of web designers/developers, planned it from an executive committee and wrote a gant chart tracking the critical path from start to finish. It would have been a big show, but it would not have been barcamp and it would not have been awesome.
Software engineers learned that top down does not work. Indian’s entrepreneurs espousing that top down does not work.
Spend a few moments today to consider if you think top down, centralized control of food production is a good idea: http://foodfreedom.wordpress.com/2010/04/24/s-510-is-hissing-in-the-grass/
Project Management is critical for Useless projects
This about this:
If you have a project with an estimated cost of $1MM and you expect a return of $1.1MM then strict governance and process controls are critical to success. A variance of 10% will take you from profitability to a loss.
If you have a project with the same estimated $1MM cost but an expected return of $50MM then project management is less critical. a 10% variance will not really matter in the big picture. Given my fictional example even a 100% to 500% cost overrun could happen and keep the "success" label.
So the take home message is that project management is critical for useless projects. If you have a great project then even with terrible project management you will still be successful.
In my own experience we run a might tighter governance on the weekly 'Features and Maintenance' sprint team as opposed to the month long 'bigger feature' sprint.
So put your bad PMs on key initiatives and shuffle the best to the menial tasks.
And get yourself on a 'no-fail' path by ensuring that all your projects have large ROI with logarithmic (hockey stick) growth.
I love reading articles by fearless people with 'tenure' at IEEE!
http://www2.computer.org/portal/web/computingnow/0709/whatsnew/software-r
Peeling back the onion of stupidity
I've mentioned the book Adrenaline Junkies
Today's pattern is the 'Onion of Stupidity'. This is a common pattern where you build up hack upon workaround upon compromise, inject a little shortsightedness and wind up seeing a good chunk of your effort goes into cleaning it up. A colleague here promoted the term "technical debt" to describe issues were we these types of issues and help us prioritize them. I'm thinking that my Onion is more about 'strategy debt'. The onion is usually built with best intentions at all sides.
Peeling back the layers of stupidity is tedious and takes time, but cutting through it makes everyone in the room cry.
I'm sure we have all been here. I had 2 instances of it today at work, and one with an old friend. He wanted me to update some joomla modules and I said yes. I go to ssh and wget the files and find out there is no ssh. Without that I have to download the files, extract then and upload lots of little ones. Then I find that some of the original files are edited so the have to be diffed. Now I have to download the files and diff them. Then I want to check but can't run it without the database. I just restored my local ubuntu image and don't yet have MySQL. So I go to install MySQL and don't have connectivity yet between the VirtualBox and osx....
So the first layer of this Onion that I must peel is to fix Bridged Ethernet. Or I cut the darn thing and move the site to a real hosting company.
So while I'm pretty much out of luck on my personal life here at my day job we all got together with a commitment to peel back our layers of issues as a team and focus on building out a solid foundation. Hopefully the only onions we will have are the ones served on the sliders upstairs.....
Tags
Blogroll
Credits
Midlife Crisis Tour!
