Tag Archives: #almsummit

Scrum Renaissance

Are you sick and tired of rigidity and attitude in the Scrum community?  Me too.  So is Scrum.org.  Let’s get over it together so we can get some work done.

Stuff has been brewing in the Scrum world this autumn, and two big events aligned last month: the Professional Scrum Trainer global meetup followed by the ALM Summit.  I’m not a PST (yet), but the impact of the meetup was unmistakable as fired-up PSTs stormed the Summit and they and Scrum.org rolled out both conversations and official sessions with some of the new messaging around Scrum.

My PST colleague Martin is tackling a number of the substantive changes in his blog (“Are you doing Scrum? Really?” and others).  I think he captures well what I’m most excited about: the new language and the new approach do a lot to undo the rigidity and religious warring around Scrum.

To me, the first big hint of changes to come was when David Starr joined Scrum.org back in July.  In his announcement, he pointed out that he’s “more pragmatist than zealot” and wrote favorably about a long list of practices that many folks in the process community have made out to be “competitors of” or “incompatible with” Scrum for some reason.  I know David’s been involved in the Scrum.org world for a long time, but it struck me as potentially a big deal to have him officially on board.

Bringing a measure of tolerance to the process wars

In October, we got more evidence from Scrum.org that change was coming: “Scrum is Open for Modification and Extension“.  A coder might initially say “open to extension, closed to modification”, so it’s interesting to think about why they didn’t.  It’s gutsy for Scrum.org to put itself out there as willing to change the framework itself in response to community feedback.  Modification is formalized, which means it does not seem to be an invitation for immature teams to pick and choose and throw out and make up practices willy-nilly and call them “Scrum”.  I’m interested to see where that goes.

It had a good run

That brings us to the really big news: the death of Scrum But.

I have no doubt that Scrum But, as a concept, was intended to be helpful. I know this because I just finished co-authoring a slide deck built entirely around Scrum Buts: why your rationales are legitimate reactions to the difficulties of Scrum practice and should be heeded, and why a more thorough understanding of Scrum principles is almost always a better solution than a Scrum violation.  I am certain I was trying to be helpful.

Seriously, in the space of two weeks I went from “the trouble with your Scrum But deck is that you keep refusing to spell it with two Ts” to “you’re gonna have to throw out that Scrum But deck”.  Two weeks!  Is this a Renaissance or a Revolution?!

Scrum But is dead.  Long live the Scrum Curve!

The Scrum Curve: no buts about it

I stole this from Martin because it’s awesome and it’s a much more useful way to illustrate the point that matters: Scrum isn’t a boolean, it’s a continuum.  Teams may be doing Scrum to greater or lesser degrees.  Yes!  There is room for variability in practices that we can still call Scrum!  Now, instead of clucking (get it?) at teams for being “Scrum But”, we can help them refine and improve their Scrumminess to improve their performance. Instead of all or nothing, we can fully support incremental adoption and growth over time, including extension practices (like from Kanban) that working together take teams to Scrumfinity and beyond.

Update: It’s a good day for a Renaissance!  By delightful coincidence, Scrum.org rolled out their new front page today.  I’m excited to be engaged with what’s coming next!

Just look what they found space for!

Advertisements

ALM Summit: devgrrrl Evolution

I’m working on a blog post wrap-up of the 2011 ALM Summit experience, so today I did a little bit of white-glove research in the archives.

I can’t find archaeological evidence of my attendance at what was then still called p&p summit in 2006, but I know I was there because that’s where Peter Provost & Michael Puleio gave their “Agile Talk on Agility” which blew my mind and changed the way I do software and public speaking and made me a loyal Summiteer for life.

I did, however, find some real treasures: my p&p 2009 and 2007 (!) adventures in liveblogging.  They’re essentially my scribbled notes, so a lot of the actual content is completely unintelligible now, even to me, but they provide a window into my growth as an attendee and as a professional in this field.

Even at the time I was writing them, I knew perfectly well that those blog posts were an outlet for my insecurities as a dev and a #devgrrrl, so you’ll see lots of that in there (see also the posts in between, from TechEd 2008).  If you read them in chronological order, I think you’ll see a growing level of experience and confidence.

I switched to livetweeting the rebranded #almsummit in 2010.  By then, I was fully aware that the great value I get out of conferences isn’t the received wisdom from a speaker in a lecture hall and never has been and I’m not sorry.  (See also: my college, with an average class size < 20 and a high degree of informal access to faculty.)  In 2006, 2007 and 2009, it was clear that I learned more by talking with colleagues about the previous hour during the 15-minute coffee breaks than I did in the hour itself.  That’s why I always worked so hard to recruit a good group to come with me.  The other big change in 2010 was that I quit being afraid of the broader community, and I put myself out there to engage with them.  Maybe the interactivity of the Summit’s little Twitterverse helped: I started to see that highly skilled professionals struggle with the same issues as I do, or even struggle with issues my team had already, in our way, solved.  I even got retweeted!  In other words, I might have something to contribute!

Plus, I was thrilled to witness the impact of the community’s livetweeting on the entire 2010 Summit.  We stopped talking about Agile in a waterfall way (top-down, planned in advance) and started actually putting Agile Talk About Agility into practice (self-organizing, continuous feedback)!  It was like our collective lightbulb moment!  And, as Agile techniques are wont to do, it left me feeling smart and empowered.  I can do this!

The other big event in 2010, not recorded anywhere, was my chance meeting with Linda from Northwest Cadence during one of the aforementioned coffee breaks.  We hit it off, which set some slow-moving wheels in motion throughout 2011 and landed me where I am today.  It’s a good thing I’m not (too) afraid of the ALM community any more, because I’m up to my neck in it!

Stay tuned to the Northwest Cadence blog, where I’ll talk more about making the transition from acolyte to Platinum Sponsor at this year’s Summit…

Underpants Gnomes in Kanban

… or, no good joke goes unpunished

Kanban offers a lot of potential for targeted, specific, incremental change, but you will need to have or create a problem-solving culture to avoid stalling out.

Earlier this year I made the wisecrack around the office that my problem with Kanban is, it feels too much to me like the Underpants Gnomes:

  1. Visualize work
  2. ???
  3. Process improvement!

Northwest Cadence just got cheekier. You're welcome.

Steven, who thinks I’m funny, ran with it just a bit.

Last night at the ALM Summit, we had a great breakout (“Open Space“) session at which some serious agile luminaries held forth on the theories underpinning both Scrum and Kanban and process improvement in general.  Steven outed me and my joke, so now I think the heat’s on.  Can I unpack this idea and turn it into real learnings, or was it just a cheap shot?

Well, let’s put the obvious out there first.  Although Kanban does literally mean just “visual card” or “visual board”, Kanban in the context of software development process improvement doesn’t just say visualize work.  That’s only the first step.  There are supposed to be other steps after that.  Right?

Aren’t there?

This is where, for me, we start to run into issues.  I’m not being theoretical or cheeky here.  In my former organization, my team ran Scrum (-but) for 2.5 years; another nearby team made the decision from the executive level to implement “Lean-Kanban” instead.  They expressly agreed with something I’ve heard Kanban proponents advance as a strength: unlike Scrum, they could adopt Kanban without changing any of their existing process.  (They seemed awfully excited about that.)

They got great, in-depth training (which they kindly invited me to sit in on).  The following week, huge Kanban boards went up to visualize their entire portfolio.  The first thing they “learned” (unnecessary quotes because everybody on the team already knew it) was that they were massively overloaded: at least three times more work underway than they could possibly complete on time.

When a 12-person team’s Kanban board fills all the walls, floor-to-ceiling, of a 40-seat conference room, it’s covered in 3×3 post-its, and each team member needs four to six laminated South Park avatars to identify all the work they’re doing at any one time, they don’t need a high-priced consultant to tell them where the dysfunction—sorry, “opportunity”—is.

And how’d they address the dysfunction?  As far as I know, they didn’t.

Why not?  Honestly, I don’t know.  Kanban calls for teams to limit work in process (WIP) and it’s a fairly obvious next step in this case, in some form.  I know they learned about limiting WIP, because I was in their training classes.  It was easy for my friends on the dev and BA teams to blame upper management and stakeholders for failing to act, but I don’t know if they really fought for WIP limits or just rolled over.  I’m certain no one at any level sought out or embraced the pain of significant change.

A year and a half later, the Kanban-wallpaper was still up, and the team still said they were “doing Kanban”.  At a local Lean-Kanban conference, I got a chance to sit down with some of them during a break and asked how the process was going for them.

“It’d be fine if the BAs would quit dragging us developers into their ATDD meetings.  It takes up all our time and we can’t get enough code written.”

“Hey!  What do you expect when you’re so slow delivering code that we have nothing to UAT?  We don’t have anything else to do but work on future requirements.”

I gather that they still haven’t implemented WIP limits, at least not properly, and they’re not managing their queues in or out.  We’re sitting at a Kanban conference and these attendees are still near the point of food fighting because they’ve decided the dysfunction is each other instead of their process.

And that’s why I think the Underpants Gnomes are not just a one-liner in Kanban, but a real risk that should be taken seriously and planned for.  What happens when…

  • the team doesn’t know how to find the root cause of a dysfunction?
  • the team can’t agree on what the dysfunctions even are?
  • the team identifies a dysfunction, but doesn’t know how to solve it?
  • the team tries to solve a dysfunction but just replaces it with another?
  • the team’s organizational culture doesn’t support problem-solving?
  • the team isn’t empowered to make the changes they think are needed?

A team full of highly motivated problem-solvers with great communication and teamwork skills will probably get good results with Kanban, but honestly aren’t they all too busy building carbon-nanotube space elevators while curing cancer?  Or writing the book on process improvement?  Seriously, teams that natively possess awesome diagnosis and problem-solving skills, are they even having this conversation?

... and it's a Big Visible Display, too!

The rest of us need to pay attention to the Underpants Gnomes when we’re getting started in Kanban.

What’s your plan for Phase 2? Can you do it on your own or do you need help getting there?

Note: if you are/were on the team I’m talking about and I’ve gotten any of the story wrong, please send me additions or corrections or perspectives so I can update!