This is a guest blog post by my colleague: Chris Waggoner. Enjoy!
Estimation of time and effort until you’re done is one of those things that every inquiring manager wants to know. In an effort to provide “accurate” estimates, companies and people spend countless hours generating list of task and debating the duration of each task. When it comes to developing software these estimates are rarely correct and often grossly wrong. The estimates are wrong because in building software that we are often building something that has never been built before. When we find ourselves being pressured to estimate something we’ve never done we tend to SWAG (PMI for Sophisticated Wild Ass Guess) the answer in man-days and/or hours without understanding or knowing all the potential variables in play. Here in lies the problem with traditional software estimation methodologies: within a short amount of time spent there are diminishing returns on effort versus value. That is to say, early in the traditional process the value of spending more time estimating doesn’t provide a higher certainty of when we will be done.
Over the past few months I’ve been coaching my clients who are in the early stages of adopting agile approaches for software. Most of them are adopting Scrum, but a few are adopting Kanban.
Universally, one of their complaints is that their teams aren’t “stepping up” to the
- Empowerment
- Responsibility
- Accountability
- Passion & Energy
- Creativity
That is implied as part of the culture of self-directed, agile teams.
To say that they are disappointed is an understatement. And these comments are coming from all levels of the client leadership teams.
In 2009 I first published Scrum Product Ownership. In 2013, I followed it up with a second edition. The book has been a popular read for those who are looking for a solid overview of what it takes to be a competent and craft-focused Product Owner.
Here’s what a new Product Owner from Spotify had to say about the book:
“I was recommended your book “Scrum Product Ownership - Balancing Value from the Inside Out” by senior colleagues at Spotify as the one book to read when new to product owning. After recently finishing reading it, I fully agree and will keep recommending your book to anyone getting started as a product owner.
I just wanted to say thank you for making the start of the ride less bumpy and for great advice that I will keep returning to as I gain experience.”
I share this because it helps to set the stage for this article and where my inspiration lies.
Giving feedback is one of the things I like most about agile methods. There’s this thing about it though. It’s not that easy to give effective feedback. Lately, I’ve been hearing agile team members start their feedback with the following statements:
- I don’t want to rain on your parade, but...
- I don’t mean to be negative, but...
- I don’t mean to criticize, but...
- I don’t mean for you to take this the wrong way, but...
And then there’s the Ricky Bobby quote from the movie Talladega Nights regarding – “With all due respect…”
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.
