MasterCard Marries Enterprise Arch & Agile

Going to John Baker’s meetup tomorrow.


Leave a comment

October 8, 2013 · 3:20 PM

Getting Out Of Sticky Note Prison

My team, a biz funk team, has been doing Scrum for nearly two years.  And we like it.  I like it.  But recently I’ve begun to wonder if I’m falling into a “see sticky, do sticky” rut.  A sticky note prison of sorts.
Meaning, I’ll do what I need to do to get the task completed, even if it goes against my instincts about the best way to do a task.  For example, instead of meeting with someone face to face to share feedback, I’ll send them an email.  I’ll send out surveys even as my gut says the survey isn’t going to be helpful.  I’ll spam potential meeting goers to close a task and risk alienating them for future events.  See sticky, do sticky.
Part of the problem is that my initial tasking isn’t perfect, and then I don’t always go back and refactor my tasks when I think of a better / different approach.  What seemed like a good idea in sprint planning doesn’t always seem like a good idea a week later when I am doing the work.  But this is partly because I’m a little tired of forcing all my work onto a colored square of paper.  Sometimes — and this is potentially blasphemous — it feels good to simply follow my instincts when trying to get something done.
My attempts to break out of this sticky prison has led me to miss a few stories, something I never ever did in the past.  And, strangely, I feel good about the way the missed stories ended up, even though in one case it took me three sprints to close it out.  I feel good about it because I did the story right, and I didn’t let my bad story writing / bad tasking stop me from doing the story right.
Could I simply task better / write better AC?  Probably.  The good news is — and I’m very excited about this — my team is moving from Scrum to Scrumban this week.  We’re going to have a weekly grooming / tasking session, and then just-in-time tasking for any new stories.  I’m interested to see if the removal of the artificial two-week timebox removes the perverse incentive to move stickies, even if the ultimate objective of the story is only being tangentially addressed.  And perhaps the shorter grooming  cycle and JIT tasking will help me write tasks that are better / more relevant.
Stay tuned.


Filed under Uncategorized

Getting Down With The Biz Funk Burndown

We now have six business and functional teams that have adopted some agile / lean practices, and only one of them uses a sprint or release burndown.  Why is this number so low?  Should our agile coaches be pushing harder for biz funk burndowns?

Well, when you roll out agile / lean practices using the “take out menu” approach, which gives more power to the team to select what practices they see value in, you’ll find that not many of them chose the burndown to start.  To put some numbers to this sentiment, of our six biz funk agile teams, here are the most commonly selected ceremonies / artifacts / roles:

  1. Daily (or 3x / wk) Standup (6)
  2. Product Backlog (6)
  3. User Stories (6)
  4. Digital Task Board (6)
  5. Demo (4)
  6. Clear Product Owner role (2)
  7. Retrospective (2)
  8. Sprint Planning (2)
  9. Burndown (1)
  10. Effective WIP limits (1)
  11. Release Planning (0)
  12. Story Mapping (0)
A few thoughts about why this might be:
  • Not always having a clear Product Owner (allowing the PO role to be handled RACI matrix style)
  • Comfort with the status quo of scrambling towards dates also has folks comfortable with not really knowing on / off track
  • Continuous flow lean teams don’t need a sprint burndown
That said, our content dev teams, when writing 1,200 page books like this, can certainly use a “Book Burndown” to show if they are on / off track.
To me, burndowns are most useful to two people: 1. the Product Owner who wants to sleep better at night knowing her team is on track and 2. the sponsor who wants to sleep better at night knowing her investment is on track.
My hypothesis is that the low-burndown demand is a maturity thing: going from no burndown to having POs and teams and sponsors demand a burndown takes time.  The impact of a standup is immediate and mostly obvious (although I’d argue one big benefit of a standup — that it is easier for new team members to get up to speed in a team that has a standup — is not so obvious).  A burndown’s value is less obvious to the team and might even feel punitive (we’re working as fast we can, so why do we need a burndown!).  But if a key sponsor is consistently asking if the, say, content for the book is on track, the burndown will be very helpful.  So I just need to find the right sponsor and coach them to ask the right questions to the the biz funk content team that is mature enough to get a burndown working.
No data to back this up (yet), but I’m starting to believe that there are two leading indicators that a team is mature: 1. consistent use of video for ceremonies with remote participants, and 2.  use of a release burndown (or cycle time).
Non-Required Reading:


Filed under Uncategorized

New Google & Spotify Agile / Lean Practitioners Meetups!

Join us on July 16th and August 13th!

Leave a comment

Filed under Uncategorized

A New Biz Funk Meetup?

Nothing scheduled yet, but this looks like an interesting meetup group around lean content development.  Count me in!

Leave a comment

Filed under agile event

The Takeout Menu Approach to Biz Funk Agile / Lean

Okay, so you are a business or functional team, and you’ve decided to “go agile.”  Where to start? Help me out, coach!

Start by forgetting agile (or “lean“) for a second.  Instead, think about what you know: you know your team all the work you need to get done.  Now what about your work or your team presents the biggest problem or opportunity?  Is it that you have tons of unaligned stakeholders?  Or your team has low levels of trust?  Or perhaps your team is focused more on tasks and less on outcome, and you want to empower and enable your team to take on more responsibility and think more about outcome?

After this moment of self-reflection, now look at the menu of values.  Which value presents the biggest problem or opportunity?

Let’s say, for the sake of this example, that your team is not always in sync.  If that’s the case, you can consider scheduling a daily or semi-daily standup.  Start with this.  Coach the team so that they understand the value of the standup, and what the yesterday / today / impediment standup is doing for the team.  If the team tries to solve problems in the standup, create a “parking lot” of items that you can discuss after you’ve conducted your standup.

After a few weeks, reassess.  Is the team more in sync?  If so, go back to the values.  Now what value causes you to stay up a night?  Is it the fact that you have no way to show if you are on track?  If so, consider release planning.

And so on.  In this way, your team can adopt the practices that work best for them.  You don’t have to do it all at once.  You can make progress incrementally and focus on improving the biggest problem or opportunity within your team.

For those of you who like things to be literal, I’ve put the values and ceremonies / artifacts on an actual menu:

Biz Funk Takeout Menu


Filed under Agile for Business & Functional Teams

List of Companies That Are Using Biz Funk (AKA Non-Software or Non-Developer) Agile

I have been unable to find a simple list of companies that are using agile / lean for biz funk purposes (e.g., marketing, content development, finance, etc).  So I figured I’d create my own list.  I’ve only included examples that I could verify with at least one source.  Not a perfect method, since not everything on the internet is truthy, and some of the links are a few years old, but it is a start.  So consider this list to be one of those “living documents.”  And you can help to keep it alive!  If you know of another company that is using biz funk agile, please feel free to suggest it (and your source) in the comments.

Company Name, Team Type, Comment / Source(s):


Filed under Agile for Business & Functional Teams, Agile Library