One of the great pleasures of being practice director is welcoming aboard new consultants. With each consultant we add to the Agile Practice I feel both the practice and I are enriched. The practice gains new expertise as well as another perspective on various methodical issues we wrestle with. Likewise, I gain access to a set of experiences, insights and values that I might not have been privy to before. Adding a consultant to the practice is actually a most gratifying form of network effect. I feel particularly delighted to welcome Diana Larsen to Cutter through this post. Diana, of course, needs no introduction. So, instead of an introduction I will share an episode and Read more
Israel Gat served as Cutter Fellow and the Director of the Agile Product Management & Software Engineering Excellence practice from 2008 until 2015. Read more ...
We were not literally poor when I was a kid, but my parents had precious little disposable income. The free public library in which they registered me had a strict two-day book exchange policy. If I borrowed a book on Monday, I could not get a new one till Wednesday. It was cruel torture for a book worm like me: I would typically finish the book I borrowed the very same day and would impatiently count the nanoseconds remaining till I was eligible to borrow another book. Fast forward to 2014 and I am feeling like a stranger in paradise, spoiled rotten by any number of great books, articles, presentations and blog posts on any Read more
“Gaming the system” is the kind of phenomenon that makes pedantic software development managers end their careers in mental asylums. A metric is introduced in order to achieve a certain outcome. To enhance the prospects of achieving the desired outcome, individuals and/or teams are compensated on the measured value of the metric. Over time they learn how to “game it”; that is, skillfully improving the measured value irrespective of whether or not such improvements still are in good accord with the desired outcome. The means (i.e., the measured value of the metric) becomes the end. “Gaming it” manifests itself as failure over time of the measured performance to fully represent actual performance. For example, a Read more
In her October 4, 2011 HBS blog post Can HP Change its DNA?, Judith Hurwitz contrasts corporate DNA for hardware versus DNA for software, as follows: The DNA that has been in HP’s bones from the start is all about excellence in hardware engineering…. With hardware markets, money is spent upfront to develop a system. However, once that product is launched, revenue streams in quickly and evenly. .. By contrast, when software is delivered to the market, it may take a year or even several years before it becomes a well-accepted and profitable endeavor… This is what I’ve observed at HP. As it has tried to invest in software, again and again it has killed products off before Read more
Innovation is part of the curriculum in just about any Agile engagement I carry out for Cutter. To my way of thinking, the linkage between Agile and innovation is straightforward. Agile enables affordable experimentation. Experimentation begets discovery. Discovery is the first step toward innovation. Just about everyone of my clients responds heartily to this simple-minded derivation, and for a very good reason. Clients crave innovation as it gives them competitive advantage through the life cycle of the product. Hence, enhancing innovation is a very appealing message. I still have to meet a client who would say “well, you know, our problem is too much innovation…” Short-term engagement do not usually give me the opportunity to Read more
The delineation ‘functional vis-a-vis non-functional’ requirements has been used by many/most of us for quite a few years. Useful that it is, I find various Cutter clients needing a more granular delineation. For example, in a recent engagement the client has actually identified the following kinds of requirements: Functional “Traditional” non-functional Devops Technical debt (TD) Striking the balance between the four is a tricky business. It is hard enough to generate some kind of (fast changing) equilibrium between the first two. Doing so across all four is a stretch for most teams. It requires good grasp on numerous subject matters. Even if the team includes a member versed in devops and another one who is Read more
A couple of years ago I found myself immersed in a devops dialog with an executive of a fully integrated service provider. I forgot how many hundreds, if not thousands, of developers reported to her. While all might not have been well with the way software was produced in her organization, the bigger problem she was wrestling with was time-to-value. The software might be done, or even ‘done done’ as Agilists would often say, but its deployment unto the data centers owned and operated by the very same service provider was agonizingly slow. In particular, time to deployment of anything that touched legacy code was “infinite.” Figure 1: Wall of Confusion Slide By Patrick Debois Read more