The Transformation Blog

While many took exception to my last article on the demise of Nokia, I will continue to raise the question on the relationship between Agile software/product development promises and the real world results of companies championing Agile values and methods. RIM is the latest example in what is surely not the last of a company that has, to varying degrees, championed Agile as a way of building better products more quickly.  In my last Nokia article, many accused me of playing loose with the facts. This time I will let others comment first before...

As we work with clients who are moving up the Agile maturity curve there is increasing interest in the subject of Lean management frameworks for complementing Agile practices.  Because the two value systems and supporting management techniques share so much in common, it’s often helpful to compare and contrast the two in order to better understand how they fit together.

While most of the Agile community is comfortable promoting Agile and Scrum practices as relatively simple and straight forward, they overlook the fact that in many organizations these new “required” practices are anything but simple to implement.  The reality is that there are devilish details to concern yourself with when nurturing Agile process, planning, engineering and organizational change that you wont read or hear about from those promoting “Agile by the book”.

In recent weeks, there has been increased discussion among some in the Agile PMI community who are seeking empirical proof for how and why autonomy and team empowerment actually works. What I find interesting is how difficult it is for Agilists to provide much more than anecdotal evidence supporting this foundational Agile principle.

This discussion interested me because I have reached beyond the Agile community over the last year to learn more about how human performance is influenced by our work environments and our cognitive biases

The last few months at Gear Stream has revealed a recurring client challenge that I’d like to highlight that has the potential to undermine Agile success and worse, introduce outcomes nearly as dysfunctional as those we’re seeking to eradicate with Agile.  What is this challenge you ask?  Agile teams routinely lack insight and appreciation for who their real customers are.

Are you a Scrum-Bot?   What’s that you ask?  You know, Scrum-Bot… the people we program with Scrum, wind-up, put in a box-about the size of two weeks, and watch as they work furiously to complete the tasks that have been assigned inside the box, only to be asked to do it all over again in another two weeks.  Sounds like fun, doesn’t it?