Post-agilism (p&p, day 2)

The Agile forest for the Agile trees: too much attention to individual practices than understanding the broad principles; form over substance

Sounds like the difference between "Agile Tragedy" and "Agile Comedy" is communication, practically an encounter session. Telling truths, even when difficult. Bi-directional.

Aha: Agile is about trust, building it, maintaining it, specifically earning it.

Zen agile, neo-agile, postagile... can jettison all 12+ practices and still be little-a agile

Shared understanding of what "done-done" looks like
Empowered, own the problem, it is the team's to suck or shine
Incremental understanding; learn as you go about all aspects of what's going on (including each other, the business area, the customer, etc.)... must accept that you don't know up-front... must seek to learn continuously

Warning signs

• Silent team room
• Afraid to change existing code
• Customer unavailable
• Don't ship frequently

When off-track

• Talk talk talk (yay!!)
• Ask how we'll solve the problem(s) together
• Guide, don't bully (oops)
• Gotta listen, too (hmm)
  

Pair programming reduces context-switching costs: much less likely to interrupt and distract two people who are engaged in an activity than one person when you don't know what they're doing. Context cop(s) important, take (kick) side chatter out of the room... then can be a noisy vigorous team room but will be focused and happy

"Let's say you have an agile team, and you have team members who don't want to be agile. You can't fire them, and you can't promote them. Where can you put them to minimize the damage?" (Ted rules!) It's better to bring them into the team, but if you can't, then you've either got to figure out how to be a team without them, or just don't do the hyper-team thing at all, which is a valid option.

Peter Provost rules!

OMG Steve McConnell (p&p, day 2)

Basic motivations for agile:

Developers: want less overhead, want to focus on "real" work
Customers: want flexibility

Value delivery keeps up with cost

"Especially useful when schedule and resources are fixed, and mission is to provide maximum business value within those constraints"

Agile Manifesto (ca. 2001)

"Reduced emphasis on long-range predictability of features--especially of the combination of cost, schedule and features"

Variation of methodologies is really about the balance of up-front work vs. in-iteration

In-phase defect removal goal is always 100%, at least in theory

Aha: in addition to code defects, can also find requirements defects, architecture/design defects... leaving major testing to end allows build-up of latent defects (all kinds), unexpected fix time

("Evolutionary Delivery" illustrated with arbitrary 25% balance, looks good for us)

Packaged methodologies

XP: developer focused; abandoned more often than retained
Scrum: workflow/management focused; retained more often than abandoned

Few projects use all the practices of a given method; claim of "synergy" among practices is invalid

Useful practices

• Short release cycles (1-4 weeks): does not have to be externally to the customer; virtually always valuable
• Rolling-wave planning: long-term (2-12 months); detailed (30-60 days)
• Timebox development: commit to delivering fixed set of functionality in given timeframe; high morale, visible progress; need a rest period or different activity between sprints
  
• Empowered, small, cross-functional teams: include all stakeholders needed to make binding decisions
  
• Active management (coach, Scrum Master): "Theory Y" style; remove barriers to good work
  
• Coding standards
• Frequent integration & test: daily build and smoke test (no point building if don't also test that build is OK); note that you don't have to deliver new functionality every day, nor even check code in every day
  
• Automated regression test (TDD): virtually always a good practice with new development, problematic for existing/legacy systems
• Postmortem for each release

Hit or miss

• Customer-provided acceptance tests: ongoing participation hard to sustain; customer testers don't always know meaningful comprehensive tests
  
• Daily stand-up meetings: a good idea that can go too far; less often, shorter, can be OK
• Simple design: don't oversimplify; must fully satisfy known requirements
  
• Test-first development: culture shift is difficult, high discipline required, worth the effort
• 40-hour work week: we really mean a sustainable pace of work

Problematic

• System metaphor
• Onsite customer
• Collective code ownership
• Pair programming: good if used selectively
• Refactoring: prone to abuse

Legacy

Overhyped, buzzwordy, has led to cynicism

Not the best solution for every company, just for many; there are still cases where sequential dev is the best fit

Best outcomes

Importance of short, iterative and/or incremental cycles
Die Waterfall die!
Check-and-balance against overly bureaucratic CMM
Reality check against "omniscience" of requirements, planning, design

In conclusion:

Steve McConnell is a great communicator. I feel like this stuff is really accessible to folks at all tech levels, which makes it helpful for me in taking the Gospel back to our stakeholders.

Getting rid of postal mail advertising packets

Those advertising and coupon packages that fall apart in my mailbox really make me angry, especially because the packages themselves don't contain any information about how to get rid of them. When I first moved in here, I started calling the "advertise with us!" phone numbers until I reached someone with information about how to get off their lists. I had to make my request in writing by postal mail, and both of them advised that they will only honor a removal for two years!

It's been two years. Grrr.

But, good news! The two offenders that recently showed up, falling apart, in my mailbox, now accept removal requests online! Neither one of them says anything on their site about the two-year limit, but my guess is it's still in effect. They keep hoping you'll sell your house to someone who likes their crap.

As a public service, and a personal reminder for myself in two years, I present:

Remove your address from the ShopWise® mailing list

Remove your address from the ValPak mailing list

Remove your address, phone and/or email from Direct Marketing Association lists¹

__________
¹ Don't hold your breath about spammers honoring your DMA preferences, obviously.