Agility, Adaptability, and Alignment

It often starts as a seemingly plain training request. Having decided to go the agile route, a client would like Cutter to train a certain number of employees in one agile method or another. We collect data on the demographics of the target population: architects, UI designers, product managers, project managers, developers, testers, and so on. We then move on to discuss the way these folks are geographically dispersed and what the team structure for the launched agile teams will be. Once these parameters have been nailed down, it largely becomes a matter of figuring out the logistics for training and coaching. A fairly straightforward process for rolling out the agile process, one might say.

The catch, time and time again, is that the problem to be solved had been defined from the outset in too narrow a manner. Naturally Read more …

Big, Lean and BSM: Late Night Thoughts on the January 30 “Big Agile” Webinar

Since we announced the forthcoming “Big Agile” webinar (click here for details), I have been exposed to numerous questions and comments about “Big” vis-a-vis “Lean” in the Agile context.  The intensity of some of these discourses was so high that I decided to comment on the subject in advance of the webinar. A lively debate during the webinar is, of course, goodness. In contrast, starting the webinar with a potentially gross misunderstanding as to where we are coming from and where we are heading is not too desirable.

In general, “big”, to me, can be “lean”. As a matter of fact, big should be lean as otherwise scale will quite possibly pose a problem.

Specifically, in the Agile context I expect “Big Agile” to incorporate various elements of Lean. For example:

Utilize Value Stream Mapping Measure Cycle Time Read more …

Washing IT

Colleague Stephen Andriole preempted me with his excellent 2012 prediction Valuation Models Will Overweight the Importance of Cloud Delivery. I could not agree more with his over-arching message:

Wall Street will dramatically modify their valuation models of software and technology services companies to overweight the importance of cloud delivery.

Human nature being what it is, I expect we will be witnessing a ton of “washing” in 2012 and beyond. In particular:

Cloud washing SaaS washing Multit-tenant washing

Your investment style is, of course, your own private business. For example, you might be very successful using The Greater Fool Theory.

However, if you are into Value Investing, I would allow myself a word of caution. For all three – Cloud, SaaS, Multi-tenant – it is a matter of the balance between the pros and cons in the Read more …

Code Does Not Hype

It is the story of my adult life. A VC dispatches me to some city to perform due diligence on a company he/she contemplates investing in. Upon arrival I meet the “reception committee.” It usually includes the CEO, the CTO and the CMO. Nine times out of ten the folks on the committee are intelligent, knowledgeable and accomplished. Moreover, they do their very best to charm me.

I still remember the reception committee from the due diligence on Tideway I did for Apax Partners some seven years ago. The folks were awesome. I am fairly certain they could convince birds to fly off the tree if they chose to apply their very many talents toward this end. I really don’t know whether Apax (who invested in Tideway) and BMC (who acquired Tideway at a later time) consider Read more …

Half-Life Metrics

“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 team is likely to develop the capacity to produce code with a low level of Cyclomatic complexity per class1 if the team gets measured on this Read more …

The Runway of Software Products

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 they had time to mature.

True that this characterization might be, the “runway” available for software products to mature and take off  is both Read more …

A Seven Year Retrospective

I felt like a psychiatrist in October 2004. An endless stream of strangers was coming to my office to complain about the software I was responsible for. I did not need to ask the classic question “How did you feel about the software bug?!” – I was proactively advised how the person calling upon me – every person! – felt about it… Some actually reverted to Hebrew (my native tongue) in order to make doubly certain I did not miss any nuance of their disappointment, dismay, despair, anger, anxiety and anguish. The only saving grace I had was that I have just been hired to turn the product around. It was a little difficult to implicate me after a few days on the jobs for problems that had evolved and accumulated over years of neglect.

The situation with the product I was Read more …

The Three Faces of Innovation

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 watch the progress a company makes, or fails to make, with innovation. In long-term engagements I am noticing more and more that the {Agile Read more …

A New Arithmetic for the Backlog

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 familiar with  technical debt techniques, it might take a long learning curve for the team to develop the cross-domain knowledge required for informed interactions Read more …

Our Walls are Thicker

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 and Andrew Shafer

As the dialog took place a short time Read more …