Focus on customer satisfaction rather than instant gratification

I've been playing with the thought today that Agile (when done well) results in customer satisfaction, not necessarily instant gratification. It may be certainly possible to have both every once in a while, but when faced with a decision that would provide either/or, I'd favor customer satisfaction over instant gratification.

A counter example that I often see is when a development team (or perhaps their managers, or both) use Agile as an excuse to deliver less than what the customer expects, and convinces the customer (against their will) that we need to deliver more frequently in order to be more Agile. While I certainly agree that frequent delivery is very important to an Agile team, it's much more important to me that as an Agile team we give our customer's the dial that let's them decide whether rapid delivery or more features is more important. I also think it's important for everyone to regularly get together and negotiate where the dial ought to be, but that the arguments made towards where to move the dial are grounded in what is going to maximize the amount of value (whether economic, knowledge or otherwise) will be delivered. There's certainly a lot of different contexts involved here, and it really depends on where a particular product is within it's lifecycle. If it's much earlier, and you have a smaller audience, then you can get away with a lot more trimming. As the product evolves, so do expectations of what it takes to deliver.

Instead I tend to see people use "we're Agile now so we need to deliver fast and small" as the argument regardless of context. Unfortunately, I've seen this lead to customers being unsatisfied, and turning their frustration towards Agile development, rather than the people who abuse it.

To me, the most interesting question is why this sort of thing happens. I have two theories...

My first theory is that this is grounded in short-term thinking, and if you were to trace back to root cause most likely comes back to a poor strategy for trying to get ahead in the infinite game of "Corporate Survival." More specifically, these are people who banking on maximizing output rather than outcome, and try to capture as much credit as they can based on quantity and not quality. I'd like to think that there is a karma component to this game that eventually compensates for these types of moves. Maybe that's just wishful thinking on my part. :)

The second theory is based on more innocent examples that I've seen, where I think that the root cause comes from insufficient trust and lack of safety. I've seen a tendency for people to get too consumed by doing what is expected by their role or job description and expect others to do the same. It becomes taboo for someone to ask someone in a different role to do something that they don't expect is part of the other person's role. Conversely, it's also taboo to do anything for someone that isn't defined by their role. Unfortunately this leaves a lot of gaps on the conversations that need to happen between people in order to deliver a successful outcome. Eventually people make decisions by default when they don't feel safe enough to ask the right questions. I feel that good leaders are able to spot when this is going to happen and break down impediments that come from this type of thinking.

Finally, I think delivering fast is important, just not at breakneck speed. Delivering fast, and guaranteeing customer satisfaction allows people to delay decisions to the point where one has the best information for making a decision. It's a formula that has worked well in many industries (not just software development). But if what you are doing is making you sacrifice one for the other, then perhaps you might want to take a step back and see if you have other options. But after exploring all my options, if I had to decide between customer satisfaction and instant gratification, I'd definitely choose customer satisfaction. How about you?

Agile Roots Notes

Here are my notes from the conference. A treasure of ideas that I can come back to uncovering.

-------------------------------------------------
Sue McKinney - IBM (Agile in economic downturn)
-------------------------------------------------

trust
step up without stifling innovation
step back without ---
influence not authority
why collaborative leadership?
stand back and deliver
leaders empowered to change within scope of influence

-------------------------------------------------
There's Only Us Panel (Distilled)
-------------------------------------------------

The purpose of trust is to increase productivity of the whole.
Individual productivity can thrive in an environment without trust,
but doesn't necessarily benefit the whole.
Trust needs conflict in order to grow.
Conflict slows down productivity (it fights against the purpose of trust)
Conflict is resolved by the combination of courage and collaboration.
Resolving conflict builds trust.
Avoiding conflict weakens trust.

-------------------------------------------------
Better Agile Through Stealing (John Rusk)
-------------------------------------------------
Responding to change

Evidence Based Management
Crystal history

Individual & Interactions

Positive Organizational Psychology
(popular practices work because they have these traits)
Deliberate Practice
Authenticity
Managers are being themselves more skillfully
Being yourself is consistent with trust
You can learn it by yourself, but it takes time

Customer collaboration over contract negotiation

Principled Negotiation
Getting to Yes
Quality Based Selection
Winner's Curse
Economics - 205 years

Earned Value - the long term view

Political Skill + Authenticity + Time = Trust

Make connections outside

Influence inside

www.agilekiwi.com
john@agilekiwi.com

-------------------------------------------------
Agile Infrastructure (Andrew Schafer)
-------------------------------------------------

Planning vs. Engineering

Developers
Product Owners
Testers
Executives
System Administrators
Database Admins
Net Engs
Designers
Usability Experts

Circle of Happiness

Who is working on a web app?
End of shrink wrap
Clouds are rising
Where does that web app run?
Who takes care of those servers
How do you interact with them

Engineering
Version Control
Build From Source

Puppet - Infrastructure is Code
Semantics
Reproducible
Maintainable
Extensible
Shareable

But why?
Backlog of requests
Config of critical services are often not documented and must be
recreated
Work on the biggest fire


Deployments and upgrades are expensive, tedious, and error prone
The chance that dev, test, and prod are configed the same -> 0
Hardware failure can be catastrophic
Heavy weight change control processes seem like a good idea
More and More Systems to Manage
Virtual Machines
More machines to configure
Do not make golden images
Really foil balls

WTD?

Infrastructure is code - automate everything
People spend time making decisions, not doing tedious work over and
over
No longer managing servers, manage services
Take advantage of processes and tools we have for software development

Planning
Communication
Collaboration
Estimation
Prioritization

Non-functional requirements
Requirements are requirements
A web app is the infrastructure
Without infrastructure there is no app
A change in usage patterns can crush the infrastructure

Requires collaboration between dev and ops
Developers vs. Operations
Wall of Confusion
Boundary Objects
Community of interest ???
Brian Marick - Boundary Objects

Plan for infrastructure requirements
But be willing and able to change them
Short feedback loops
Operations' Customer is the App
If the infrastructure isn't working nothing is
Create a culture of collaboration
Most important statement from the manifesto

Often forgotten and most important phrase of the manifesto (it's first
after all)
We are uncovering better ways of developing software by doing it and
helping others to do it.

Throwing bodies at work that is taken for granted when it could be
automated -- that is the meatcloud.

imvu -- Automated deployment
Last responsible moment for infrastructure was 6 months ago

-------------------------------------------------
Agile Architecture (Jon House)
-------------------------------------------------

Agile - way of doing things
Arch - means of doing things

Drivers for architecture usually business oriented

Agile

Flexible
Mitigating Risk
Understandable - visible
Scalable - Adjustable


Design
Strategic
High - Level
Scalable
Adoptable

Focused on Application Architecture

Presentation
Domain Logic
External Systems

Identifying common functionality
Customized code

-------------------------------------------------
Brian Marick (Artisanal Retro-futurism Team Scale Anarcho-Syndicalism)
-------------------------------------------------

they don't care as much about cheese as we do
don't complain at the samurai bar
replace it all!
gov't
corp.
trade unions
workers' solidarity - "One team"
workers' self-management - "self-organizing teams"
direct action
in contrast from hoping someone from above will swoop in and help you
where's my jetpack?
where's my emergent design?
infinite in all directions - endless possibility
limited in most directions
"ignore people like me"
"what would make our lives best, now let's change the context to that"
sense of naivety that is key to success - hope

i and i over p and t
"I know you think you are helping, but you're not"
not respectable to talk about process and tools

promiscuous pairing
pair programming ping-pong
how to move bodies in space

Celebrate the Gosh-Wow Brigade
Bringing ruby folks back into the fold

What do we do now, what's needed?

Need reminders
arxta.net

-------------------------------------------------
Israel Gat (Four principles, four cultures, one mirror)
-------------------------------------------------

Timeless principles
Intrinsic Obstacles

agile principles - disruptive - in positive manner
bypass or overcome obstacles

re-crossing the chasm between customer and vendor
the "sausage syndrome"

"codify" agile principles in contracts

75% organizations using Scrum will not succeed
they are supposed to make dysfunctions transparent to fix them, not
adapt and hide them

market development myth

Cultural Duality

how we do things around here in order to succeed
how wo do software in order to succeed
introduce conflict

Taxonomy of Core Cultures

collaboration
control
cultivation
competence

actuality
possibility
personal
impersonal

some cultures look at data in the future
what could be accomplished next year, the year after

some cultures pay attention to what is happening today

how cultures make decisions
"data is the only thing that matters" vs "personal"

recovery of patient depends on collaboration with nurse

each corporation has a psychic center, too, which consists of vision,
etc...

agile rollout strategies

build on strengths of the current culture
assume you are in a control culture
control, very methodical, very rigorous


move toward an adjacent culture
move from control to collaboration, or control to competence
takes years to change your character, and a lot of investment

move toward an opposite culture - unlikely to succeed (personality
transplant)

scaling and culture
expect success to beget success

scale up
likely to be least disruptive up to a point
you will probably stay within the culture in which you already
demonstrated success

scale out
adding local culture(s) into the mix
various variants of distributed agile might not be optimal, but their
use is inevitable
key to success is minimizing implementation variances against
manifesto practices

scale diagonally
take success in agile r&d to drive change in downstream functions is
an effective strategy
as long as you are mindful of the cultural boundaries you are crossing

limit on scaling
beyond the joint infrastructure that serves constituencies affected by Agile
the data the culture pays attention to
the process by which decisions are made

using your mirror to determine your core culture
whatever your current culture might be, it is easier to build on the
strengths
no single culture is right for agile

behavioral changes through tools
good agile tools are likely to induce behavioral changes (in good
time)
data - single source of truth
process - natural and automatic - like the response to an exciting
video game

principles for applying timeless principles
know thyself
be true to thyself (don't assimilate the way salesforce did it)
behavioral changes through tools (joint agile infrastructure over
explicit cultural change pushes)
other cultures are part of your mirror
the essence of organizational health is cultural balance a condition
in which the tendency toward excess that characterizes any 'pure'
organizational culture is mitigated by the opposing tendencies of the
other cultures

-------------------------------------------------
Alex Pukinskis (Facilitating a Product Council)
-------------------------------------------------

Agile is like beer (1 or 2 ok, 6 or 7) - getting drunk on agile

Release-oriented
1. Bring your ideas
2. Details and Voting
3. Final Backlogs
4. Retrospective

Too much work.
Stakeholder Stress
Diner menu
Pet Projects
Bias toward churn
Everyone's got an opinion
They're all wrong

Bias toward stability
Easy to maintain
The clouds lift

Stories: too granular for VPs
Stakeholders relax
Create a visible kanban

Sit with each stakeholder
You'll get stable stakeholder support
Agile is like a dream, again

--------------------------------------
Pollyanna Pixton (The leadership tipping point workshop)
-------------------------------------------------

Leadership tools from her experience
When using these tools, Agile will emerge
Stand Back and Deliver (June 29)
'Old school' 80% - manages changes, knows the answers, bureaucratic,
leader decides
Positional power - stops making decisions based on all the information

'New school' - embraces change - fosters new ideas - collaborates -
gives ownership - influential
the answers are in yor organization
none of us are as smart as all of us
collaboration model
open environment - right people - foster innovation - step back - and
let them work
step up without stifling innovation
step back and keep focus
how do you step aside
unleash talent
increase productivity
develop great solutions
how?
give ownership and NOT TAKING IT BACK
by giving solutions we take ownership
use authentic motivation
* foster collaboration
teams collaborate to make their decisions
* let people choose
let people choose how, what, and when
have to trust that they'll find the missing piece, and they do
* provide meaningful work
trust first and...
suspicion is a permanent condition
create a culture of trust as a leader - fosters trust in the organization
you can't make people trust each other
a team that has not built trust yet
remove debilitating fear

step back tips
team figure out how
create a safe place to fail
get the right people on the bus in the right seats
get the wrong people off the bus
how do you know when a team is struggling

Red Flags
When they are always waiting for me before they take the next step
(usually involves just talking to someone else)
Everyone talks about a general problem that they are experiencing (a
theme of symptoms), but
won't speak up about any specific out of fear that I might disagree,
or that they'll cause conflict among themselves.
No updates
Silence
Ashen faces
Non participations
Changes in hours worked
Closed door discussions
Too busy to retrospect
Working on the wrong things
what to do
get the team back on track without sacrificing integrit
don't ask what's wrong
or where stuck
describe work, approach, path they went down, and why they went that
way
help discover a new view
zero gravity thinker

step up tips
reinforce ownership
don't give answers
don't give them the solutions
tell stories, experiences
ask questions
questions that help people discover solutions
how would you like to solve it?
what would you like me to do?
what would you ask?

macro-leadership tool
cube - stand back
remove barriers
help teams grow, make it a bigger cube
when they start coming out of the cube - step up

purpose - considerations - results
tighter boundaries

Your cube?
Results
Customer Satisfaction
Quality
Commitments met
Development team satisfaction

How does your cube align with your team's cube
your tipping point? practice.

If there is a silent resistance to my suggestion - step back - let
them figure it out.

-------------------------------------------------
James Shore (Simultaneous phases)
-------------------------------------------------

Scrumerfall
Testers helping the team understand if the are doing everything they
need to do to create bug free code
Continual, Incremental, Planning and Requirements


Current Iteration - Task, Task
Backlog - Next two iterations - Story, Story
Roadmap - Next three months - MMF, MMF, MMF
Vision: This release and a bit of the future - Vision

Programming Errors
TDD, PP, Energized Work
Design Errors
Slack, Simple Design, Incremental Design, Refactoring, Fix Bugs Promptly
Requirements Errors
On-Site Customers, Customer Tests, Bring Testers Forward, Customer
Review
Process Errors
Root-Cause Analysis, Fix your process, Exploratory Testing

"An example would be helpful about now"

There's Only Us Panel

Early on in the conference there was a panel of "experts" discussing the debating the topic of "There's only us" even though we tend to falling back to blaming "them". Much of the debate centered around trust, and some members of the panel were purposely playing devil's advocate to trust--which for me sharpened the reason of what the purpose of trust is in delivering software. I took all of the chaos from the panel discussion and tried to distill it here. It still feels like it is lacking in some dimensions, but here's a first draft.

The purpose of trust is to increase productivity of the whole.
Individual productivity can thrive in an environment without trust, but doesn't necessarily benefit the whole.
Tension can rise as individual productivity begins to level out during attempts to gain trust.
Trust needs conflict in order to grow.
Conflict slows down productivity.
Interesting relationship in that conflict fights against the purpose of trust, even though trust needs conflict in order to grow.
Conflict is resolved through the combination of courage and collaboration.
Resolving conflict builds trust.
Avoiding conflict weakens trust.
Avoiding conflict ties back to fear -- or lack of courage.
Attempting to resolve conflict without collaboration never really resolves conflict. It shatters it into smaller pieces and scatters them all around.

Eureka....I mean Heijunka

I know I've heard the idea before. I was in a reading group about reading the book called "The Goal" (I didn't read the book unfortunately and it's sitting on my bookshelf). But we talked about how the book talked about eliminating bottlenecks.

I've been kanban-curious for a little while now. My blog might indicate that my interest started about two weeks shy of a month now, and I was hoping to try kanban in about a month back then. (Our team almost did this week, but let's not go there today.) But I've been fumbling around like an idiot about the whole thing, almost with this intuitive notion that it will somehow help the team (or at least give us a new way to look at breaking some habits) but I've had no idea why. I've sort of gotten the idea that we can easily point out bottlenecks, and bring ourselves to collaborate and get things done right at the right moment.

<somewhatRelatedDistraction>
I sometimes sense this recurring theme at random times that collaboration, and work getting done happen right at the best possible time whether we like it or not (and whether we use kanban boards or not). More concretely, people tend to fixate on something (an arbitrary date, or a significant related event) and wait for it to happen. Then whatever it is that everyone was waiting for just happens (and yet we still act surprised). But this fate-based theory usually leaves me with a visualization of a lot of people just waiting for something unexpected to happen--wasting a lot of time. Perhaps I can disprove this idea by having a simple way of having the group show themselves when the right time is for certain events to happen. Or maybe I'm just drinking too much of the kanban kool-aid now.
</somewhatRelatedDistraction>

Anyways...I've read Jeff Patton's article on Oversimplified Kanban many times now. I've lost count. I don't know why it's taken me so many times to get through it. I keep jumping to the other articles on Kanban as well, but end up back here because it seems like the right starter kit (which is right where I'm at now). Eventually we can try out some ideas from David Anderson or Arlo Belshee, but Jeff Patton's approach is more familiar to what our team is used to. Or perhaps we just tune the WIP limits and columns until it just works.

Now back to the title. I've skipped over this part of Jeff Patton's blog for sometime, and finally hit on what I've been looking for all along. Heijunka. This is the process of smoothing and leveling until everything is produced at a constant and predictable rate.

Then from there, we see if we can play with our constraints even more to see if it's possible to increase the rate. I'm guessing we can also find other ways outside of the kanban system to improve the rate (training, automating, eliminating waste, and probably more) all the while detecting the unevenness that returns to see if we're making the right improvements. It seems like it'll be a challenge to find the right zoom level of a timespan to say what's smooth and what isn't. Perhaps this changes too as we get more and more smooth.

Smooth or not, I really like the concreteness of everything I'm hearing about kanban. The way it is tuned is so simple. We actually know for sure if we are actually making a change. Some unmentioned experts might refer to these limits as training wheels, but they're experts, I'm not.

Looking at how we work right now, it's easy to just say...it's working, why change it? I'm looking at this opportunistically to say that we are at the best possible moment for being able to tell if this is a change for the better. If it is, and I'm letting the opportunity pass me by, then I'm simply wasting more. If it isn't, then at least that's one more thing to reflect back on, and find other ways to improve.

Well...There are a few details I still need to work out to be honest. As others teams are using what we're doing now as a model to get started, this is going to be quite a shift. Probably not one that others just getting started are ready for. And there are already some contexts that I know we have dealt with where I fear this won't work--at least not given what I currently know about kanban. Just give me two more weeks and I'll try to work out the details.

Clojure function inspired by tweets between Lisa Crispin and Brett Pettichord

It's so much better to see the results from the REPL.

user=> (defn testing [dev tester]
(if (and (= dev 'f) (<= (compare tester 'b) 0)) (testing dev tester) 'ship))
#'user/testing
user=> (testing 'a 'b)
ship
user=> (testing 'f 'c)
ship
user=> (testing 'f 'b)
java.lang.StackOverflowError (NO_SOURCE_FILE:0)

Thinking about Kanban

I've been giving some thought to trying Kanban in about a month or so. The nature of the work that I'm hearing may be coming our way sounds like it may lend itself well to trying Kanban. For almost the last year or so, we've tried to force our work to fit into having one major ongoing project at a time, and a steady stream of small unrelated enhancements. For some reason, this forcing seems to constantly leave gaps where some people on the team are always too busy all of the time, and some people on the team aren't ever busy enough.

I don't suspect that Kanban is going to solve this problem, but it might do a better job at exposing the problem and providing a different perspective on the solution. I suspect that we may either have too much specialization on the team, or not enough people in the right specialties. I'm hoping that through combining Kanban with reflection, we can clearly start to determine how much work-in-progress we can tackle given our current set of resources and their specialties, and maybe try to figure out an answer such as "What if we had one more developer, or one more tester, or a dedicated project manager? What would that mean for the work in progress as a whole?" I'm well aware of The Mythical Man Month, but the idea here would not be to try to speed up a single project, but rather, an infinite collection of unrelated backlog items.

I do like the idea of throwing out estimation. I respect the work that has been done with Planning Poker, and other forms of estimation, but there is something very liberating about tossing that to the side, and tossing sprints aside, and just constantly working to move work in progress items to a release ready state. After all, the manifesto says nothing about sprints. The highest priority is satisfying the customer through frequent releases.

I'm trying to come up with some clever, cynical ways to break Kanban so that I can detect ways that it might get abused. The first one that came to mind is that work may get stuck for everyone, and nothing moves anywhere, and the limiting of work is an excuse to not do anything. I'm hoping that if a daily standup is done right (David Anderson's description at http://www.agilemanagement.net/Articles/Weblog/KanbaninAction.html seems pretty good) that this shouldn't happen.

I've read through http://theagileexecutive.com/2009/05/11/john-heintz-on-the-lean-kanban-2009-conference/ and I want to go through some of the links and really start to build a strong mental model of all of the reinforcing concepts. I've had my eye on various articles on http://www.poppendieck.com/ for some time now, and I feel like it will become much more clear after reading one of their books.

But in the end, it really couldn't hurt to just try it. It seems pretty natural already to what some teams were already doing without being given any direction before.

Clean Code

I've been reading Uncle Bob's book "Clean Code: A Handbook of Agile Software Craftsmanship" and so far really been enjoying it. For me it is somewhat validating, and I'm starting to realize why I have certain code habits. I'm only a couple of chapters into it, but I'm going into it with a couple of expectations.

1) I'm hoping to beef up my own skills. I'm by no means perfect, and I'm hoping this book will help me when I am writing code.

2) More importantly I'm hoping this will be a helpful reference for me when mentoring my team members so that we can all work together to elevate the quality of the code we produce.

We'll see how it goes, and what unexpected lessons I learn from this bokk.