I’ve been a Mike Cohn groupie for as long as I can remember. Mike has written, what I consider to be, three of the seminal books on agile approaches for software development. I’ll leave it as an exercise for you to lookup the books, but he’s really been one of the leading voices on how to “do Scrum” and “do Agile” for an incredibly long time.
I took my CSPO class from Mike and Ken Schwaber, just so I could learn from two of the “masters” in my agile journey. And when anyone asks me for a recommendation of an instructor for a CSM or CSPO class, Mike is at the top of my list. I remember sending all of our potential ScrumMasters at iContact years ago to Mike’s CSM classes. My logic was, that if we were going to spend the money, we might as well go to the best.
Now that I’m looking at the start of this article, I’m almost embarrassed as to how much of a Mike Cohn groupie I am. But I digress…
What is it?
If you’ve been a tester in an agile team you’ve probably experienced Scrummer-fall like behavior. The challenge is to how best describe it. One way is to look at your activity chart. If on day 1-8 of a 10 day sprint you’ve been largely idle and waiting for code to “show up” for testing. Then on day 8-9, suddenly and magically everything arrives on your doorstep for testing. And you rush forward testing all of the teams’ output…only to fail to have sufficient capacity to get your job done. Then you’ve experienced Scrummer-fall.
Basically, it’s applying waterfall process behaviors within the confines of an agile iteration. On the outside, you’re agile. But it’s only a façade. On the inside your team is still subscribing to waterfall principles & behaviors, which means that testing is always done after the developers are completely done with their work and they throw it “over the wall” for testing. It also means that feedback, either on defects or functional acceptance, is occurring quite late as well.
My motivation for this article isn’t to slam or denigrate any of the scaling frameworks (and those that continue to emerge). Full disclosure, I’m a SAFE SPC and I find significant value in leveraging “some” framework for agile at scale.
That being said, I have a great concern that I want to share. I think we’re losing some of the original thinking and approaches from early instances of agile. The methods grew out of small teams doing big things.
But as we’ve gone forward and introduced agility into larger instances (enterprises, large-scale companies, distributed projects, etc.), I’m afraid that we’re losing the very essence of agility that made it attractive in the first place. Things like:
- Small teams
- Simple, focused solutions
- Just enough
- Face-to-face collaboration
- Working code
- High value delivery
A week or so ago, out of a bit of frustration I posted the following comment on LinedIn:
Weird. Every day I see more and more "Agile Coaches" and they seem to have less and less experience. Does real experience matter anymore?
I received quite a few comments. Some of them are below:
- What's interesting is applying experience to different situations. As you know from last year Bob we transformed a product team under your coaching, I am now applying the same approach at a different firm. The objective is the same but the different people, process, tools and culture make it a different puzzle. Ask me in 6 months if experience matters - my guess is yes.
- I have noticed the same thing. Qualifications for being a coach are becoming "I was standing in the room when someone said agile". You get what you pay for.
- Sounds like you need a certification...that will solve the problem :)
I get bombarded with different points of view from agile coaching firms all of the time. This one crossed my screen from Mike Cottmeyer just this morning.
http://www.leadingagile.com/2015/03/lets-acknowledge-safe-for-what-it-is-and-move-on/
and here’s a snippet from Mike’s post, just to give you some flavor:
So… I want to say this one more time for emphasis… either you create the conditions to do agile well… or you do something else. SAFe is that something else.
We can say that SAFe is a cop out… or isn’t really agile… or that it’s the second coming of RUP… but don’t underestimate the complexity, the risk, or the cost of totally refactoring an enterprise to be the kind of organization that can really do agile at any kind of scale. Some organizations simply can’t or won’t invest in this. At the end of the day small batches are better than big batches. Iterative and incremental is better than waterfall, even if it isn’t agile.
If you’ve any experience in agile approaches for software development, one of the common arguments surrounds documentation. Mostly it centers on software requirements, but it also extends to other forms of documentation, for example design or user centered documentation.
Many agile teams struggle with documentation. My experience aligns with folks leaning one of two ways:
- Either they continue to write requirement documentation (and literally ALL documentation) as if they were still operating in a Waterfall environment, or
- They write user stories that are so terse as to be hardly useful in describing the customer’s expectations. And they often stop writing anything else.
In other words, they go to the extremes of documentation instead of finding a healthy, lean, and communicative balance. One of the reasons for this seems to be our view of documentation as being the sole “repository” for product and team knowledge. While that’s true, I also like to remind agile teams that there is another viable form or place for that knowledge – which is the teams’ memory. Since many of the agile ceremonies are whole team events, I like to ask teams to use their collective memory as part of their product information and knowledge archive.
If you’re unfamiliar with the phenomenon, we’re in the middle of conference season right now in the US. Quite a few software and testing centric conferences are scheduled every year in late spring and early summer and then fall. Two times a year, I’m on the road for 4-6 weeks attending and sharing at wide variety of conferences.
It’s something that I enjoy doing although the travel can be quite tiring. One of the great things about it is that it provides me with new ideas. And if you know me, many of those ideas end up in my writing.
Here are a few…
Alan Cyment: Another Look at Shu-Ha-Ri
Alan Cyment gave a wonderful Pecha Kucha talk at the recent Scrum Gathering in Phoenix.
In it, he challenged the use of the Shu-Ha-Ri model or metaphor on a couple of levels –
- Is a martial arts metaphor really the best way to describe the growth dynamics of agile instances?
- Are there really only three phases of agile adoption?
- Often in Shu-Ha-Ri we can revert as well or regress in our learning.
- The notion is that the Coach is a Sensei…and others aren’t?
Alan’s metaphor was much simpler, yet I believe richer.
In late 2014 I ran an open space at the Raleigh Scrum Coaches Retreat with this title. You can read more about that session here.
I then got the opportunity to run the session again at the Phoenix Scrum Gathering in May 2015. The session was well attended with the room full at around 100+ people. So the dynamics were a bit different from the retreat.
Instead of focusing on those bad expressions, I want to instead share some of the new themes I heard in this session.
So I published the book in late January 2015, so just a few months ago. I wanted to share some of the happening around the book.
Sales
Have been incredibly brisk, both in the US and abroad. The first month or so was quite slow. But we’re now starting to see momentum gaining sharply.
There also another trend, folks are buying larger “chunks” of the books in PDF format to help in their organizational agile transformation efforts. We’ve had 4-5 large purchases of copies for just this purpose. We hope to see that trend continue as well.
