Has Agile Lost It's Way?

When I got started with Agile in 2007 it was new. Most of us had been delivering software for a while and while we loved developing solutions we hated the often tyrannical circumstances we endured doing it. We knew what worked: lots of unit testing, iterative/incremental development, lots of collaboration, transparency, etc. But until Agile (for me, XP, and Scrum), we didn't know how to pull it all together. What we found, before Daniel Pink gave simple ways to say it, was that when we had the opportunity to 'do it right,' we were on a path to mastery, autonomy, and purpose in our daily work.

Agilists associate the birth of "Agile" with The Snowbird Conference in 2001 and The Agile Manifesto. If we focus on the unmet needs of businesses and governments relying on software then it goes farther back still.  Let's just say Agile's about 16, a teenager. It shows.

Agile has become a big business promising homogenized faster, better, and cheaper delivery to the masses. I would guess that 70% or more of teams who call themselves Agile aren't. At least by my definition but, I'm a tough grader who expects the use of XP engineering practices.

In 2012 Thoughtworks' published an Agile Fluency Model to describe levels of Agility from One Star Teams focused on delivering business value to Four Star Teams optimizing entire eco-systems. Their data suggested that 15% of teams were doing something, but it wasn't Agile. 45% of teams, while focusing on business value, weren't meaningfully improving software quality. As a result, due to Scrum or Scrum-like processes, these teams are only marginally more productive.

As a result of this homogenization, the tyrannical circumstances Agile was to dispel are back for too many. As the market grew, "consultants" with no more than a scrum class and a half-read, frequently derivative book popped up to feed on the Agile sales frenzy, the essence started getting lost.

Turns out that greater transparency can also lead to micro-management and ever more unrealistic expectations on a team. You get worse, not better code. You get less not more shared understanding. Even when you've had some success by focussing solely on visible business value, you may hear, "Wow, we've gotten faster since leaving waterfall. Bet you can go twice as fast! Indeed, you must! Find more process improvements!"

If this is sounding familiar to you I'm sorry. Here's what I suggest you might reference to find the essence:

1. Read the original sources:
• Extreme Programming Explained: Embrace Change
• The Scrum Guide
2. If you are a developer or architect then also check out:
• Clean Code: A Handbook of Agile Software Craftsmanship
• Clean Coders: watch as many videos as you can afford
3. If you are an Architect add these to the above:
• Read Clean Code
• Watch the Architecture, Tech Debt, and TDD videos at Clean Coders
• If you haven't written a line of code in 10 years, and think this is all craziness then spend the next month coding, full-time in your enterprise applications then read and watch the videos again.

Once you are done, happy New Years' 2006! Please don't stop now. Next up:

1. RSA ANIMATE: Drive: The surprising truth about what motivates us
2. Kanban: Successful Evolutionary Change for Your Technology Business
3. The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses
4. Large-Scale Scrum: More with LeSS
5. The DevOps Handbook
6. BADASS: Making Users Awesome

Ok, happy New Years' 2017! We're not done. So much has happened since Agile was born. Not all of it captured above. Keep in mind that you have to know the rules before you can successfully break them. You should also check into Modern Agile. 

Finally Finished the Kanban Book Summary!

Yes! Finally finished the seven-part summary of "Kanban: Successful Evolutionary Change for Your Technology Business by David Andersen. Part one starts here.

Of all the summaries so far, this is one of my favorites. The summaries are written as study guides or review materials.

The Kanban book fills in the blanks regarding why Scrum and XP work the way they do and how to improve their processes in a way that minimizes resistance to change and maximizes value delivered.

Kanban is not a methodology for software delivery. It is a change management system for improving the implementation of any delivery framework or process. It is reasonable to say that using the system to improve a waterfall process would lead to Scrum/XP/Lean Start Up like processes. This may explain why some think Kanban is a delivery methodology - applying its principles will suggest process improvements that likely converge towards the processes that are taken to define today's "Agile."

But that too is perhaps misleading. Agile is a mindset growing from of a set of principles and values we apply to improving our ability to deliver value through software delivery. Is is not a process or a framework - despite industry marketing machine claims to the contrary. It uses processes and frameworks and it is our job to improve them. If you agree then you'll enjoy getting involved with Modern Agile.

David Andersen's application of Lean principles to software delivery and their synthesis with the Agile mindset makes Kanban a valuable tool. Here are the summaries:

• Kanban Summary 1 of 7: Intro, Benefits, Kaizen
• Kanban Summary 2 of 7: Value Stream and Basic System Cadences
• Kanban Summary 3 of 7: WIP Limits and Classes of Service
• Kanban Summary 4 of 7: Metrics, Projects, and Operational Reviews
• Kanban Summary 5 of 7: Goals, 12 Steps, and Striking a New Bargain
• Kanban Summary 6 of 7: Improve - Bottlenecks and Waste
• Kanban Summary 7 of 7: Improve - Reduce Variability, Resolve Issues

Old Originals (1978-1993)

In no particular order...

1. Ande
2. As I Fell
3. Feel Male Persuasion
4. Fool for your love
5. London
6. Road Sketches
7. Simple
8. Teas'n your persuasive