The Hookup

My background for the last 27 years has been application systems development and integration. I have played every role from business analyst to developer to architect to project manager to team leader to director at one time or another. I know what gets application development teams motivated and excited about their job. I know what causes them to break down. I know what the distractions are and the inhibitors to effectiveness and efficiency. I also know the ROI on solving some of these problems.

Number 1 cheap answer to make software wonks happy and productive – The Hook Up.

They want the fastest workstation, the best software tools, the best technical environment and the most control over their own destiny that they can get.

When software developers are fighting against the toolset that they are using to build the software, and it’s inherent limitations, they are much less effective and efficient. Tools are cheap compared to devs – so we need to grow up and get over it.Continue Reading

Curation Collection #2

“Q: What change models work? Q: How ot be agents of change? (as coaches)” This was an insightful list of questions related to enterprise agile adoption.  I like questions because they are less likely than answers to lead to one-size-fits-all-suits-none solutions.

I like the cult of done.  I like the manifesto – I posted the poster included several places in my workplace.  Good reminder of why done is important.  “Done is the engine of MORE!”

An interesting look at the way that the “power culture” of an organization interacts with agile adoption strategy.  When your organizational culture has a high power index in the large, then every reorg or management change presents a challenge to agile adoption.  “When I see organizations with a high power differential, they keep falling back to command-and-control approaches, because the power differential is so ingrained in their culture.”

Interesting look at product from a VC perspective.  Caused me to ask how people see me as a product.  I work inside “the enterprise” I am not marketing product to VC, but I constantly market myself to others.  “CHICKEN LIVE IN CAGE. NO CAN HAVE PERSONALITY INSIDE CAGE.”  — smash cage, light barn on fire do that you win…

 – @paul_boos @bre @johannarothman #grimlockquotes

Agile Productivity

One of the hyped benefits of agile software development practices is increased productivity. It is also the benefit that I am most skeptical of. Software productivity is notoriously difficult to measure. That is because there are no relatively standard units of measurement of output.  Martin Fowler said this in 2003, and as far as I can tell it is still relatively correct.  This is true regardless of whether you are using agile practices or not. In fact, the measurement of software output itself is an expensive activity, so in any normal case study it would be hard to prove. Since books have been written on this topic, I do not feel the need to delve deeper into this topic, except to say that all of the problems described in Fred Brooks’ famous Mythical Man Month still exist today, and there has not been a universally adopted solution.

Nevertheless, I am not totally willing to call bullsh*t on the productivity benefit. There are three completely anecdotal reasons for this:

1) Agile practices tend to focus less on documentation and more on producing working software. This leads to spending less time on speculative documentation that ends up being revised many times. Rather than guessing what users want, agile teams build it as quickly as possible, and get feedback, and revise it, until it IS WHAT THE CUSTOMER WANTS! So from a productivity perspective, it is less work to deliver what the customer wants, not what they thought they wanted or what we thought they wanted. Is this real measurable productivity? NO – but it sure as hell feels good to both the developer and the customer.

2) The shorter measurement cycles that agile favors help resources focus on the needful, rather than the fanciful. This means that developers are focused on working in the next feature. Management theories put forth by Elliot Jacques talk about time span – the individuals ability to plan into the future. Developers typically do not a have long time span. I have often experienced developers who became overwhelmed trying to figure out what order to work in, and ended up being unproductive or paralyzed by unscoped tasks. The rhythm of consistent pacing, tends to allow the team to relax around planning, because there are regular intervals of planning activity, broken by longer periods of uninterrupted development. Is this real measurable productivity? NO – but the developers will tell you that they are able to relax and focus on solving technical problems rather than worrying about deadlines and planning.

3) The agile principle YAGNI (Ya Ain’t Gonna Need It) reduces the investment in complex architecture, or over-engineered solutions, or premature optimization. The principle is less about improving the productivity of individuals, and more about improving the output of the team. It is a principle that allows the team to hold itself accountable to deliver the smallest, thinnest, cheapest version of each capability, rather than the most ornate, most performant, most scalable, most beautiful version. Agile principles direct us to deliver an acceptable solution with the least effort, rather than an acceptable solution that anticipates all future events. Is this real measurable productivity? NO – but as I learned early in my career – the best way to get more done is to figure out all the things that don’t need to be done and not do them.

When I evaluate these reasons, I recognize that the perceived increase in productivity may be much greater than any actual increase, but at the same time, perceived increase in productivity can improve morale and reputation in ways that by themselves lead to real increases in productivity. Agile life cycle projects often feel less like a “death march” than gated life cycle projects, and that alone can lead to increased productivity and motivation.