Being in my ninth year of applying the processes and technical practices of Agile and Lean software development, people are sometimes surprised to hear me say that Scrum is still my preferred process. Let me explain.
I consult with all sorts of companies looking to adopt elements of process and practice from the Agile/Lean offerings. Whether it's Scrum, Test-Driven Development, User Stories, Test Automation, Continuous Integration, Agile Estimation and Planning, Sprint Planning, or Sprint Retrospective facilitation, one challenge pervades across most scenarios. I have come to call it The Discipline Deficit.
I was recently catching up on episodes of The Java Posse, and came to the one that features an Open Spaces topic I convened at last year's Java Posse Roundup, Should We Shoot Agile in the Head? It was a vibrant conversation with plenty of input from experienced people. At the 49:50 in the recording, D. J. Hagberg posed an excellent question:
"Is Agile[/Lean] as good as it gets?"
I added Lean, since the question really applies to both, their overlap being so great.
The short answer is no.
There is one question I can guarantee someone will ask as I begin an engagement with a new client. It usually comes in the second half of the first major session I have, called the Agile Orientation. By that point in the initial training, we have covered the roles and components of Scrum, using it as the primary (and my favored) option for an effective Agile process in most businesses. The looks on at least a few faces at that point let me know that people are starting to process just how disparate their current work life is from what I am describing. One of the more outspoken folks usually asks something like this:
If Agile requires all these things, and we can only implement part of it, is it still worth doing?
The answer is yes, with one caveat. A partial adoption results in partial benefits, so expectations should be adjusted accordingly.
After an Agile adoption is underway and the feedback mechanisms of most Agile processes begin to function, one or more team members usually ask me something like the following:
Is it just my company that has a hard time with Agile?
No, it's not just your company. However, don't take comfort in that.
I shared something on Twitter that I think sums up why companies have a hard time with Agile:
Agile practices and processes serve motivated, self-directed teams who work hard. It does not create them. @barryhawkins
This installment of the Ask an Agile Coach series is a question normally asked by persons outside my field, but lately I have been asking it myself:
What is an Agile Coach?
Good question. I am not sure anymore.
Welcome to another installment of Ask an Agile Coach. Today's question centers around how to structure teams in light of constrained skill sets in an organization:
What technical roles, other than QA, can be successfully shared across scrum teams? DBA, UX, etc.? - @jakejgordon
Strive to have people in dedicated teams; only share in order to get work from concept to customer.
Hello readers, apologies for the lack of posts lately; lots of work at hand. Today's Ask an Agile Coach question comes from a comment on the last installment, which is rephrased here. In one form or another, I have gotten this question for years now:
Should I count partially complete user stories in my velocity? For example, if I have a 100-point story that's almost done, should I add 80 points to my delivered points total for this sprint?
The answer is no, you should not.
Today's installment in the Agile with External Clients series covers the topic of testing. A decade after The Agile Manifesto and over 16 years since Scrum and XP came on the scene, I still encounter a large number of teams where the use of testing is lip service at best and non-existent all too often. In this context, testing means the use of frameworks like xUnit et al to create of a suite of unit, integration, and functional tests that exercise a body of code by executing it and making assertions about the outcome of that execution at multiple levels of focus and granularity. Of all the practices of Agile software development, both process and technical, testing is the one people most readily acknowledge the value of while at the same time avoiding it altogether. So, let me make this quite plain:
Testing is not optional.