June 11, 2015
Many software development teams seem to treat “Agile” and “Project Planning” as if they were mutually exclusive concepts. The tendency, it seems, is to simply jump straight into Agile iterations — at best starting with an Iteration Zero — and then trust that things will sort themselves out strictly through a team-based Scrum-like approach.
In practice, though, teams seem to regularly run into trouble with this sort of naïve approach to starting up an Agile project — especially any sort of large, ambitious project operating within the context of a major enterprise.
Rather than proceeding blindly ahead with nothing more than faith in Agile iterations as a panacea, here are some of the planning considerations that I think projects should explicitly address at their outset, before their first sprint.
March 21, 2015
For those who have not yet heard of it, the Scaled Agile Framework, or SAFe® for short, is a “publicly available framework for applying lean/agile practices at Enterprise scale.”
I believe that the SAFe model offers a number of benefits to those who may be considering its use. Let me enumerate them.
December 14, 2014
I sometimes wonder if many of us in Information Technology are yet taking an informed perspective when contemplating investments in new software development efforts. Here are several things I think we should be keeping in mind.
December 4, 2014
Some of the most troublesome topics in software development are those surrounding defects:
Let me introduce my thoughts on this topic with a little story.
November 19, 2014
I’ve written in the past about the importance of understanding polarities and how they need to be managed.
My previous post involving Polarity Management concerned process improvement, but the topic is equally relevant to other aspects of software development.
A polarity is most simply defined as a complex problem that has no solution. It might also be stated as an either/or question that has no single right answer. A more complete definition might be “A set of two opposing or contradictory extremes permitting wide variation along a spectrum of choices, with both opposing poles offering advantages and disadvantages.”
The pros and cons of a polarity are often represented in the form of a polarity map, in which each quadrant represents the pros or cons of one pole or another.
Now that we know what a polarity is, let’s look at a number of different polarities that need to be commonly addressed during a software development project.
September 8, 2014
It occurred to me recently that there are really three essential functions of management.
Strategy: setting a direction for your organization.
Alignment: getting organizational resources lined up to execute the strategy.
Execution: delivering expected results as part of the fulfillment of your strategy.
One might argue that there are many more functions of management, but I think it is helpful to understand that these three are the primary and in fact essential functions, and that all the other things managers do must be understood to support one or more of these three functions.
Let’s take a look, then, at the essential nature of these three functions.
August 1, 2014
In order to survive and thrive, any organization must possess the following four characteristics.
November 23, 2013
A sure sign of danger on a software development project occurs whenever anyone says, “Don’t worry about the problem – just trust the process.”
This danger is equally present whether the process to be followed is of the waterfall variety, or of an agile persuasion.
The chief danger is not in picking the wrong process, but in placing an excess of faith in any process, no matter what it is.
October 11, 2013
Software development has often been managed using a predictive planning model based on the following principles.
August 28, 2013
Elimination of waste is one of the core principles of lean. But we often think of waste and its elimination in purely economic terms: a particular lean improvement saved a certain number of dollars, or a certain number of hours per year.
There is also value, though, in visualizing waste in the form of organizational friction: the resistance that workers encounter when trying to do their jobs, or when trying to change the way that their jobs are done.
I say this because, in my experience, managers and workers often have different motivations when it comes to lean. Managers are often motivated by numbers, especially when they figure prominently in their annual goals and objectives, and especially when they have dollar signs in front of them.
As managers, though, we need to realize that these sorts of quantitative measures are in some sense just an abstraction of what is happening on the floor, or wherever the work gets done in our organizations.