Saturday, January 21, 2017

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 awhile 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 found then, even before Daniel Pink's gave simple ways to say it, when we had the opportunity to 'do it right', was the outline of 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 business' 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% teams were doing something, but it wasn't Agile. 45% of teams, while focussed on business value, weren't meaningfully improving software quality. As a result, due to Scrum or Scrum-like process, these teams are only marginally more productive.

As a result of this homogenization, the tyrannical circumstances Agile was to dispell 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:
  2. If you are a developer or architect then also check out:
  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, fulltime in your enterprise applications then read and watch the videos again.
Once your 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

Friday, January 13, 2017

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: