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 …

It would seem that the devops discussion is mostly driven by development’s incentives, and appropriately so, given developers’ focus on building functionality for the business user. So it’s no surprise that development is the originator of the whole devops lifecycle, but are there any dangers lurking in a one-sided focus on devops issues?

A hefty majority of devops articles come from writers of the development persuasion who are motivated by the legitimate frustrations of the application deployment process. The movement to agile development has been a key contributor in the increase of handicaps encountered as a result of more frequent transitions from development to operations IT groups. Online and verbal discussions identify the primary challenge as getting IT operations to be more creative and flexible in their approach to changes coming from the application development discipline.

Given its critical 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 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 …

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 …

Agile 2011 has been something of an epiphany for me. The confluence of workshops, discussions and interactions with Cutter presenters in the conference led me to thinking of the shape of things to come in quite a different manner than I used to. In particular, I reached the conclusion the forthcoming 2011-2021 vintage will be quite different from the tried and true Agile 2001-2011 vintage.

I have no doubt the nuts-and-bolts of Agile will continue to be a major component of the Agile “curriculum.” You simply must get the Agile practices working at the team level. Metaphorically speaking, you are building towers in the sand if your teams are not proficient in the Agile method. Stand up meetings, retrospectives, cycle times and other Agile constructs and ceremonies are the foundations on which you build an enterprise level Agile roll-out.

Having Read more …

The devops phenomenon is gaining traction in enterprises worldwide and its results have been turning heads in the business and user community. Bridging the gap between projects and operations, devops has the ability to deploy and manage business services in “real time.”

The July 2011 Cutter IT Journal, with Guest Editor Patrick Debois, will examine both the opportunities and challenges created by the devops movement. Proposals of interest are due 29 April 2011.

To respond, please visit http://www.cutter.com/content-and-analysis/journals-and-reports/cutter-it-journal/callforpapers03.html

The Scrum v. Kanban debate has been relentlessly raging for the past eighteen months. One could only watch with fascination as polarized camps formed around what is after all a fairly dry software method issue. The intensity of emotions this debate generated could almost be compared with those expressed in the debate about abortions.

As a practitioner who uses both methods, I tend to view them as arrows in my quiver. Each method has its strengths and weaknesses. The important thing is suitability to the target environment, not the theoretical pros and cons. For example, one could prefer to use Scrum in development and Kanban in service delivery.

A macro trend is starting to change the playing fields for the two methods. I am referring to the splitting of the software testing process to two parts:

Unit testing by development. Read more …