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.

Self-Awareness at the roundtable

At the Salt Lake Agile Roundtable yesterday, I brought up the topic of Self-Awareness. This was inspired from a catch-phrase that Alistair Cockburn had been talking about (as have the regulars at the Roundtable). You can read where this catch-phrase comes from here. (Note, there is a bit of an inside joke--which I don't entirely get because I wasn't there from the beginning--of how this catch-phrase is rapidly transforming into industry lore, and I inadvertently helped this joke along by referring to this catch-phrase as if everyone present at the meeting had already known about it).

I had most recently had a discussion with Alistair while he was visiting Overstock.com (where I work) to train us on Agile, Crystal, and Scrum. We were talking at lunch about Crystal when he brought this catch-phrase up. I had heard it repeated at the Roundtable before and thought it was an interesting quote, but really didn't understand enough about Crystal to understand what was meant by "Crystal is about self-awareness." As Alistair was describing what you might find that is different on a team that practices Crystal, he gave a hypothetical story about how a team is aware of everyone's mood, and even aware of the mood of people outside the team who may be crucial to the project's success. I interrupted him saying "wait, isn't that awareness of other people, not self-awareness". I don't recall his exact response, but I believe it was somewhere along the lines of "Exactly." This was an immediate, and powerful "Aha" moment for me, and it conjured up memories as when I've read various texts from the Dalai Lama on Compassion, and other texts on eastern mysticism and in this instance I just began getting this very strong connection between these texts and software development.

I told this same story at the Roundtable, and I could literally feel that some members of the Roundtable had felt this same type of "Aha" moment before (we have them all of the time at the Roundtable), but I think everyone got a rise out of the fact that they could literally visualize Alistair making such a simple remark, and how it would lead to such a powerful "Aha" moment.

So the "real" topic here was some of the exploration that I wanted to do with "Self-Awareness". Everything up to this point was merely context to get the group onto the same plane as me. So I had spent the last day or so thinking about some simple questions about "Self-Awareness". The type of questions that I already had some notion of an answer, but I thought it would be great for exploring other people's ideas at a forum such as the Roundtable.

My first question that I wanted to explore was whether or not there were mechanical approaches to getting this type of awareness from the group (say like McCarthy's check in protocol), or if it was a matter of tuning your methodology to have the properties found on Crystal teams.

Now pause for a second. If you take the fluff out of my question, the answer seems really obvious. It's basically, "How do you find out about other people's feelings?" You'd think that there were a million simple answers (there are) but you have to remember that we are dealing with technical people doing technical stuff, and things like emotion and awareness suddenly seem like foreign matter.

So the answers that the members of the Roundtable started out as straightforward as you might expect once you distill the question, but are received as revelation given the way that we have trained ourselves to remove emotion from our craft. Some suggested approaches from the group included simply asking the team members how they felt, or gathering various hints in the types of things your peers are saying or not saying (in their body language). Someone else suggested that you really needed to have good soft skills to be able to extract these this type of data. Other suggestions were to use the "Fist-to-Five consensus" to see where people's emotions are at on a particular decision. Also suggested was a ternary alternative using: thumbs up, thumbs to the side, or thumbs down.

The more interesting question that I had was basically, what advantage (or value) does having Self-Awareness give you while working on software projects. Jonathan House had a perfect answer in saying that Self-Awareness is your early warning system (my #1 Aha for the day). He told a story that I won't repeat because I'll probably mess it up completely. This was again a very natural answer, but I find it humorous that we sometimes have to remind ourselves of these situations where our technical expertise, and thirst for empirical data, sometimes prevent us from having plain common sense. I think if you apply this to Scrum, you can see how this empowers the team to remove quite a few impediments on their own, which certainly is going to lead to some productivity gains.

I've continued to think about this some more, and I do think that the property of Crystal "Personal Safety (the freedom to speak out without fear of reprisal)" certainly makes it easier to get higher fidelity meter readings on the team's morale, but the more subtle techniques (body language, reading between the lines) are also useful as the team works on gaining personal safety. In fact, I'd wager that it can be helpful to try to validate or question these subtle hints every once in a while to see how accurate you are (and especially in the case where the weather report isn't looking too great). This in turn points to the power of co-locating your team so that you can pick up these signals more quickly.

In conclusion, I had a lot of fun with this topic, and the members of the Roundtable were able to come up with some very profound answers which also led to a lot of "Ahas" at the end of the Roundtable.