Friday, March 6, 2015

QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts:

  • Take Back Agile: "If this is agile, take it back."
  • Take Back Agile: "Give me my agile back."
  • Take Back Agile: "... to your team." 
The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done.

There are underpinnings to consider.

Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find our own "two questions" and focus on never stockpiling our pain.

Permission is a key type of safety. Ruud and I both talked about finding permission, and how our mental impersonators (your "inner forbidding boss") need re-calibrating. We discussed the context shift developers need in order to get permission, and how trust and permission can be obtained in a transactional way. 

But most of all, it starts with concern for our value:effort ratio. This relates to the lean concept of "perfection" (absolute value with zero waste) and Ruud explained that it can be addressed with the accumulation of small improvements (see 2-Second Lean for more details). 

There was about an hour's worth of stuff, so I'm not going to use up this space with a recap.

However, I got a story from a developer in my elevator ride from the interview I had with Ben Linders on Friday: His team started to estimate the time it would take to clean up the code in order to implement a feature. He said it was the moment that everything changed for the better. They didn't ask permisison, they just included it in the estimate instead of estimating the time to type the new feature's code onto the pile of rotting code that they already had.

This story resonated with me. If you are that developer, please contact me so I can write more about your journey. I've seen this before, and I would love to hear more.

Wednesday, March 4, 2015

On The Agile Manifesto

Everyone points to the four "preferences" part of the manifesto and ignores the more important first paragraph, and the far more important second page ("principles").

Key phrase: "We are uncovering better ways of developing software by doing it and helping others do it."

That's different than "we are cementing our idea of software development process by teaching it and certifying others to teach it." It's different from "we are making people feel better." It's different from "we don't write documentation" or "we force velocity as high as possible"

If we lose that key phrase, we lose it all.

Tuesday, February 17, 2015

Agile At Heart?

I feel safe to say that "being agile" is more than a mere state of mind, because an agile person or team has definite practices and tendencies that are not present in non-agile environments.

I don't doubt that there is a change in values, but I argue that those changes will have practical, daily results that can be seen.

Too many people hear/see "just a mindset" and think of the four tiny sentences in the front page of the manifesto (which skips over the first paragraph, which is by far the more important IMHO).

To wit: 
  • A team is working 80+ hours a week. 
  • The design and architecture were carved in stone last year. 
  • The members all "do their own work." 
  • Each team member has 18 tasks "in process" 
  • They're "debugging their way to release" without automation 
  • The last five retros have ended with "oh, well. We'll try to do better, I guess." 
  • They are all competing against each other for recognition/awards 
  • They have missed the last three releases. 
  • Tasks carry-over interminably 
  • Work is all component-level 
  • The burn-up graph shows parallel, diagonal lines. 
  • Everyone spends 4 hours a week "improving their estimating skills" 
  • There is no time for learning, because everyone's too busy 
  • "This code isn't testable" 
  • "Refactoring is too dangerous."

This is not an agile team. Even if they all have experienced a personal agile conversion, and have agile written in their hearts, this is not an agile team.

"Faith without works is dead" -- if their mindset and way of being doesn't show up at the office, then it's just an interesting philosophy they've heard about -- which doesn't apply here in a practical way.


The first value of the agile software manifesto? "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." If it's not early and continuous, then maybe we're not really agile.

The third? "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale." Delivering again.

Down a little further? "Working software is the primary measure of progress." Not actuals-mapped-to-estimates, but fully-integrated software stuff that runs and can be shown to work. 

Of the 12 principles, 3 of them are about delivering, but 5 of them are about working together (not working individually on the same thing).

That seems to suggest that teaming is more important even that frequent delivery. If we're not teaming on work, and we're not delivering, and we're not doing the hard work to make those things possible, how can we possibly be living the agile values?

That covers 8 of the principles. The other four? 

One is about continuous attention to technical excellence. 
One is about welcoming changing requirements. 
One is about trimming the fat via retrospectives. 
One is about maintaining sustainability.

If agile is a mindset and a set of values, then where is it evident that the values have been adopted in my (let's call it "fictitious" to protect reputations) example above?

The manifesto isn't merely philosophical, it's practical. It's pragmatic. Nobody did this because they love the fuzzy little programmers and want them to be happy -- they created XP, Scrum, etc because they wanted to be able to do work with some chance of success. We need the technical, organizational, and social skills in order to be successful.

You're aren't agile if you are ONLY agile at heart. You gotta walk that walk.

Sleep and Insight

An interesting article from Sara Mednick linked insight and sleep, but in her explanation on page 27 I saw some interesting echoes of the work done in 1920s by Graham Wallas. This is an excerpt from the paper linked above (emphasis mine):

The insight gain studied by Wagner et al. initially revealed itself in an implicit manner. 
Then, through a slow process (enhanced by sleep), it emerged from the nondeclarative into the declar- ative realms as a fully assembled insight into the task structure. 
The authors proposed that insight gain is not a pro- cedural learning process, since the reac- tion time data did not become faster with learning, which is the hallmark of procedural learning. 
Instead, all participants who gained insight (regardless of whether they were in the sleep or wake groups) actually showed a slowing in reaction time just prior to insight gain compared with participants who did not gain insight. 
“Specifically, the slow- ing of reaction time in solvers appears to reflect the presence of an incipient representation of the rule overlapping with that required for implicit task per- formance.” 
Nonsolvers’ reaction time continued to decrease as their proce- dural skills improved without declara- tive awareness. 
Solvers, on the other hand, showed a slowing in response while insight was emerging from non- declarative information into a declara- tive reportable result. The insight may, therefore, develop in a nondeclarative fashion, but the moment of ‘aha’ indi- cates the solidification of the informa- tion into a declarative thought. Thus, insight gain appears to contain aspects of both declarative and nondeclarative learning.
This sounds a lot like Wallas' ideas of "incubation" and "enlightnment" come to light again.


Wednesday, January 21, 2015

Smarter Teams

An interesting article was published in the New York Times recently reporting that, experimentally at least, teams have a measurable collective intelligence, and that this intelligence is drawn from unexpected wells.

We might expect that those teams had really smart leaders and high IQs in general than others. It seems reasonable in today's world where we respect individual skills and individual characteristics and bank so much on the charisma and dominating spirit of strong leaders. That is why it is so interesting that this theory is entirely wrong.

Instead, there are three reported attributes that seem to favor some teams:
  1. Equality
  2. Empathy
  3. More females in the population.
The second, empathy, was a bit surprising only because male developers pride themselves on separating their feelings from their work -- compartmentalizing the subjective from the subject matter. Maybe that was wrong all along also, and a barrier to passionate or fulfilling work.

In short, we don't need more Captain Kirk or more Mister Spock. Apparently, we're smarter to go with  Lt. Troi.

Pop over and take a look. I don't know that it will change the minds of individualistic hero-worshipping paternalistic organizations or leaders, but maybe it will start some conversations we've been needing to have for a long time. 

Tuesday, December 30, 2014

Other side of the CAR, not the POST.

First look at this video...

We can have a laugh at this poor lady's bad moment (and frankly, I did -- don't judge me).

But it is funny because we see this all the time in different forms. How many times have you seen a team crank up the size of its sprint "commitment" because they didn't make the last one?

How many times have you seen people struggle with a practice by doing it "wrong" over and over until they simply got sick of trying and quit?

When we're focused on something else (getting the release out, dealing with a bad review, feeling bad about a skill we need but don't have) we can easily get into this kind of a mess.

Here you know that she knew intuitively that her problem was that the gas cap was on the other side, but she somehow got it into her head that it was the wrong side of the post and not the car. She kept pulling up to one side and then the other, sure that she got on the right side of the post this time.

It was not the post that needed re-orienting, it was the car. It was easier and simpler to reorient when she knew what she needed to do, but that was only after she finally took responsibility for understanding and thinking through the problem -- which almost certainly meant letting go of something else she was mentally preoccupied with.

Are we driving in an attentional fog, too focused on what we're not doing to be able to accomplish what we really need?

Confession: Yeah, I've had the same kind of attention tunnel vision, and I've had days that were consumed in things that weren't work. I've spent many hours trying to work but trying to not put my full attention on it.

We can do better.

Here's what I'm learning:

  1. Intend to have accomplishments, or at least one, soon.
    Try the pomodoro technique perhaps so you're focusing in smaller bursts.
  2. Catch it sooner. Don't spend the whole day in attentional fog. 
  3. Recognize "overwhelm" and take a walk or a break rather than trying to push through.
  4. Consider taking time out and dealing with the distractions so you can have your whole brain back instead of dealing with the Ziergarnik effect.
  5. Use someone else's attention. Their focus will help support your focus.
I've not mastered this yet, but all of these things seem to be helping when I'm aware enough to "catch it sooner" and use one of these techniques. 

Monday, December 29, 2014

Years' End, Years' Begin

2014 was the year of the brain. 

I decided to put aside most of my other reading materials and concentrate on reading books about brain function. I read up on neuroleadership and cognitive science and motivation.

I got into a lot of content, and learned a lot of interesting things which should help me not only to coach and lead others, but to manage my own mental state better than I ever have before.

Some of that learning was from The Leadership Gift, where my involvement was kindly sponsored by Industrial Logic.

Underneath all of these studies and stories and new understandings, I learned a lot about empathy and sympathy and caring for others. What it means to be human is essentially that we're stumbling through a paltry handful of decades with impaired ability to gather, assess, judge, and accept reality. We're all from different places, with different mental models and mindsets, and we can work this all out together if we're willing to open up.

But we can. We can improve ourselves and we can support each other, and we don't have to be "stuck."  We can get "unstuck" if we're willing to learn, thing, examine, and put aside judgement and frustration for a little while and let our curiosity and natural intellect lead us to clarity.

That's a lot of stuff for a quick blog post.

Let's leave it here: I know enough (head-knowledge) to have a much better impact on my own behaviors and habits and on helping others deal with theirs than I've ever had before.

I'm still burning down the reading list, so 2014's Year Of The Brain will spill over a bit. But no rush now.

2015 is upon us.

2015 is the year I throw on as many skills as I can afford/tolerate/enjoy. Last year I learned a (very) little bit of Groovy and Swift and Javascript even though it was The Year of The Brain, because my work required it and I like learning new stuff.

But this year will be more intensely pursuing skills, using what I've learned about my brain in the meantime.

I intend to deepen my javascript skills and develop cloud computing skills. That's a lot to learn already, but will be fun.

I need and want to learn at least one proper functional language (python's semi-functional features, C# LINQ, etc don't count).

My son bought me a mandolin for Christmas. I'm going to play some songs on it publicly by the end of the year.  I'm also going to deepen my guitar skills. I will learn some sight-reading and some music theory. After all these years of playing, I should learn something about music, I think. ;-)

I don't know what other skills I'm going to learn, but I'm basically going to stop procrastinating and eat what's in front of my nose. I have awesome resources (computers, the internet, books, friends) and there's no reason I don't soak up a ton of tech in 12 months.

Wish me luck.