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.

See http://www.agilemanifesto.org/principles.html

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.

Fascinating.