Agile Case Study: Self-discipline is a fraud - MPJ's Musings - Fun Fun Function

A case study that highlights some key reasons why agile works ... when agile works.  I've seen this in large agile adoption,  everybody goes around with new task lists, new checkboxes, new procedure guides.  But the work itself gets lost in the shuffle and the old politics, tensions and procrastination by meeting sets in.



The heart of agile is simplicity.  Get started, give yourself a target, and then using all means necessary get something out the door.  MJP's story about 8AM Sharp demonstrates the challenge,  we quickly learn just how hard something is to get "Done-Done",  and so it becomes harder to start,  especially in an environment where business reality forces us to give up on that perfect goal and settle for something less done in the end.  



I've seen success where early in the process, management set a hard sprint limit to 2 weeks and stuck to it.  Yes, we struggled for months to deliver anything that felt valuable to either the development team or the business.  But that struggle proved valuable,  we learned to stop punting problems downstream, and added new roles and tools for automation that cut out much of the repetitive busywork in building, releasing, and even testing.   We learned to negotiate better the conditions of success, to prioritize features against key persona.   We got inventive, and discovered new ways of reusing code that better fit the overall delivery process we actually needed, different from the one we had envisioned at the start.



The habitual timebox,  the cadence of the team, is what fueled success.

Business Analogy for Pair Programming

In the Atlanta Craftsmanship meetup this past Monday we discussed TDD and pair programming followed by a live practice of the ping-pong technique.   What was interesting is how many of the side conversations  involved folks struggling to gain management acceptance for these techniques.   It just seems to fly in the face of common sense to have two resources as expensive as developers working on the same problem.

I think I'm going to try a new conversation with my management and  use some tried and true management advice from Deming in support of paired programming vs traditional silos of development.

I found David Joyce's post Deming’s 14 Points to be a good source of new arguments:

Point 3:  Cease dependence on mass inspection.
Eliminate the dependence on inspection to achieve quality. Eliminate the need for inspection on a mass basis by building quality into the product in the first place.

Longer cycles of QA, formal code reviews, static code tools:  even if these methods of inspection could find every bug in every release,  they will always find them too late.  Top late when compared to cost to fix a problem right after it is created..   Beyond that Pair programming validates more than just the basic implementation,  you're discussing the assumptions, the risks, the benefits of the choices being made.

Point 6. Institute training on the job:
Institute modern methods of training on the job.

Deming recommends training by doing.  Pair programming keeps knowledge flowing among all team members.  Nobody becomes a sole expert on any part of the code and the best tools can be vetted and adopted quickly.

8. Drive out fear:
Drive out fear so that everyone may work effectively for the company.

Techies fear being wrong, fear ridicule from their peers.  Paring means talking, talking builds trust, trust eliminates fear.  Without fearing what your co-workers think,  you have freedom to disagree, freedom to experiment, and freedom to innovate.

9. Break down barriers:
Break down barriers between departments. People in research, design, sales, technology and production must work as a team.

Pairing is all about seeing a problem from more than one perspective.  Becoming comfortable with different opinions and interpretations between peers builds the very same skills that support communication with the business.   

13. Encourage education:
Institute a vigorous programme of education and self-improvement.

Let's be honest, a good programmer could not care less about what their 'manager' thinks of their skills. The validation that matters comes from their peers.  Pairing provides consistent and immediate reward for your continued learning,  every day you get to impress somebody else with the knowledge you've picked up.

Technical Debt Analogy - Paying the Gremlin Bond?

Ward Cunningham's 'Technical Debt' discussion is a favorite metaphor to help the business relate why not all IT spending can be on new features. However, after a crazy semi-annual install, I find that perhaps there needs to be an extension to the metaphor, the Gremlin Bond.

Homeowners in the South are familiar with a form of insurance known as a Termite Bond. We pay an exterminator to regularly apply pesticides and bait traps around our homes to ward off infestation.  To wait until you see evidence of termite damage is insanity.  At the point you know the termites are there, you might as well start shopping for a new house.

Code gremlins also quietly accumulate, often asymptomatically, until it's too late to remedy things without going to scorched earth and rebuilding from scratch.  Time spent writing automated tests, refactoring, code reviews, and upgrading system components is the Gremlin Bond.  Less sexy than building a new house every couple of years,  but far more predictable and therefore manageable cost over time.

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?

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?

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 identify...at 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)-ah...it 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 http://chaosinmotion.com/blog/?p=622 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.

Look to the code before blaming your new global resources.

I hear it all the time, "Our offshore team members are having a heck of time meeting our project goals for time and quality". But are you to quick to blame the new people when it's old code that is actually at fault?

Consider the following little history:

An application I had inherited used EHCache to reduce load on Database by storing application defaults. It was optimized to preload all Caches at Server startup time. As a result the code has always been a little slow to start up, what with 62 separate objects, each configured as its own independent cache loader.

The real pain began once the company added new global resources to the project, the offshore team members were consistently missing deadlines, and quality, well ... it left us 'underwhelmed'. I'm embarrassed to say this state of affairs lasted 6 months. Until one day - adopting some agile team practices, I chanced upon the real root of the problem.

Turns out this DB chatty load process could take up to ONE HOUR to load all 62 caches for the offshore team! Suffice it to say, it's probably unreasonable to expect a highly productive developer when the developer can hope at best to confirm only 4-5 changes per day...

New Lessons to Live By?

* Make time with sit with new team members as they integrate with your code, new eyes will reveal old problems!
* Demos don't lie, I'm sure the offshore team had mentioned "things ran slow", too bad we had accepted "slow" in the US side.
* Test network latency early and often, it is a hurdle you can't just throw hardware at!
* Code needs unit-tests. Unit tests would have forced us to design for DB independence, improving both US and offshore productivity for incremental changes to the 'legacy code'