Tag Archives: scrum

June 20, 2016

Managing Cross-Team Dependencies with a Dependency Board

By Stephanie Davis

DependencyBoardPlease welcome new guest blogger, Terry Winslow, as she explains the Dependency Board in use at Valpak.  Terry is an Agile Project Leader at Valpak.  This means she wears many hats as ScrumMaster, Kanban Lead, and Agile Project Manager.

One of the biggest challenges in agile is managing cross-team dependencies.   Cross-team dependencies exist when two or more teams need each other to deliver an end-to-end increment of working software.  Over Valpak’s 4+ years of agile development we have learned that cross-team dependencies are a way of life.  But how do you manage these dependencies?  There is no magic one-size-fits-all answer.  Like many things in agile, management of cross-team dependencies has evolved over time.

When Valpak started our agile journey we had the daily Scrum of Scrum standup.  The Product Owner and ScrumMaster of each agile team would meet daily and discuss cross-team dependencies.  At that time, our code base was so interrelated that code changes made by one team would affect other teams.  These daily standups were needed to coordinate code changes and releases.  As our code base became more decoupled these Scrum of Scrum standups were held twice a week.

Eventually, we discontinued the Scrum of Scrums all together.  The work of managing cross-team dependencies fell on the ScrumMasters to coordinate between the Scrum teams.  The ScrumMasters coordinate cross-team dependencies with other teams while grooming stories for upcoming sprints.  While the ScrumMasters do a great job, we wanted a way to visually see the dependencies.  That is where the dependency board was born.

The left side of the board has a row for each team along with a column to place user stories that have dependencies for the current sprint.  Along the top are columns for groups that are required to help complete stories.  These groups could be other Scrum teams, database administrators, architects, or subject matter experts.

Each sprint, the ScrumMasters display the user stories that have dependencies on the left side of the board and indicate which people are needed from other Scrum teams using the columns.  A dependency meeting is scheduled after all Scrum planning meetings are completed.  The ScrumMaster for each Scrum team reviews the user stories and the team members needed to complete the story.  All ScrumMasters agree that the needed team members have either 1) a corresponding user story on the other teams Scrum board or 2) have included the needed work in support time.  If there are any discrepancies, the two ScrumMasters work it out with their teams and Product Owners before the end of the day.  This could include pushing a story out a sprint until the needed team members are available.

The dependency board is a great way to visualize cross-team dependencies.  It allows teams to commit to working together to complete working software.  By setting a scheduled meeting to review the dependency board, we make sure that all teams are aware of any cross-team dependencies and we don’t have any cross-team dependency surprises later on in the sprint.

1 Comment   |  tags: | posted in Uncategorized

February 25, 2013

The Sprint Review Rut

By Stephanie Davis

After a full year of back-to-back sprinting  here at Valpak , the teams fell into a Sprint Review rut.  It’s my job to coach, inspire and motivate them right out of that rut.  So, here’s the approach I took …

As we head into our 25th Sprint Review tomorrow, I realize that it may feel like Groundhogs Day for some.  With that mindset, I think we may have fallen into a rut.  The last few Sprint Reviews have had some noticeable issues (not just noticed by me, but by our stakeholders) … team members arriving late, awkward hand-offs between presenters, dead air due to apparent lack of preparation, etc.

That said, I’d like for us to be thinking about the Sprint Reviews a little differently going forward.  Let’s all channel our inner entrepreneur and think of our team as our own company and our stakeholders as our clients.  So, you are presenting to your clients and you want them to renew/continue their contract with you for another sprint.  This is precisely what companies like AgileThought go through with each Sprint Review and we can learn a lot from them.  Remember, your team is your company, your stakeholders are your clients, and you want your clients to continue to do business with you.  With that kind of mindset you are sure to deliver a successful Sprint Review each and every time.

But, it didn’t end there.  Our Agile Coach, Ryan Dorrell (CTO of AgileThought) provided more words of wisdom …

25 Sprint Reviews?  Wow – congratulations again!

But you’ve done this meeting 25 times now…is it getting boring?  Is it getting old?  Feeling stale?  Feeling like the same thing over and over and over?

Let me tell you the story of what I’m working on right now.   About half my time right now is spent working on a project for a client where we are building two mobile apps for the – one iOS, one Android.  We have a sprint review meetings every two weeks.  The product owner sees the builds all throughout the sprint – he downloads regular builds, gives feedback, and we’ve worked with him to define acceptance criteria.   There should be no surprises.  But yet I’m always a little anxious about sprint reviews.  I want it to go well.  I want the product owner to say “wow, this is really awesome – amazing work” at the end of the review.   I want to exceed his expectations, even when we’ve been setting his expectations all sprint with complete transparency.  He knows what the product looks like, and knows what he’s going to see.  My anxiety is probably based on the fact that he’s our customer – his company pays good money to hire us to do work for them.  They don’t have to use AgileThought as a development firm.  It’s our teams job to have there be no doubt that they should use anyone else.

Compare that situation and mindset to the one you may be in.   In an internally focused role, it’s very easy to fall into the trap of not seeing your internal business customers and stakeholders as actual customers.  It’s easy to think of them as just other employees that work with.  It’s easy to miss the fact that for each team, for each sprint, there are significant dollar costs.  Customers, even internal ones, need value for the dollar.  To echo Stephanie’s point, I want you to see your customer (product owner) as the customer whose expectations you need to exceed.  Have the mindset that your product owner could go find another team to do the work that you are doing.  Maybe they can find someone who can do it faster or better or cheaper.    If there was a chance that, after each sprint, the product owner would decide whether or not to keep using your team…would that change your mindset?   Product owners are partners but also customers with the team – we owe it to them as customers to treat them as if they have a choice.  They very well might have a choice and you might not be aware of that (I’ve seen this happen).   In your next sprint review, if you aren’t a little nervous – I would ask yourself why.

If you to have fallen into a rut when it comes to your Sprint Reviews, consider this way of thinking to up your game.

5 Comments   |  tags: , , | posted in Uncategorized

October 25, 2012

Agile Halloween Tribute: Top 10 Things That Scare The Hell Out of Me

By Stephanie Davis

young_frankensteinNo large-scale Agile transformation is ever easy and Valpak is no different.  Day in and day out I see things that scare the hell out of me.  With that, I have for you the top 10 things that scare the hell out of me.  Feel free to offer up some of your own too.

 

Top 10 Things That Scare The Hell Out Of Me

1.  Everything takes 8 hours … Estimating tasks during planning can be scary for some team members, but what scares me even more is when some estimate every task to be 8 hours.  Seriously!  From a word change on a screen to a new workflow, everything takes 8 hours?

2.  Waiting on requirements … Or really, waiting on anything for that matter.  Instead of waiting, keep moving forward.  I mean you are sprinting, in fact.  Or even better, go collaborate with that person you’re waiting on to get the task done together.  Now that is the Agile way!

3.  Over-confident teams convinced they are high-performing … Confidence is a powerful asset to a team, but too much can be a bad thing.  Over-confident teams believe that they are already high-performing, so no further improvements can make them any better.  Cap the confidence and strive to be more and more Agile each day.

4.  Stand-ups that linger … The daily 15-minute stand-up can be terrifying when it’s let to linger on and on and on.  ScrumMasters can do us all a favor by keeping the stand-up moving along and calling it “done” when all statuses have been spoken.   It’s inevitable that there will be conversations that follow the stand-up (with the Product Owner, with Stakeholders, between team members) but the ScrumMaster can release the rest of the team to get back to work.

5.  Demos of screen shots instead of working software … This is probably the most controversial one.  I know, I know, sometimes screen shots are the most practical approach to the demonstration of a given feature, especially where a series of time-consuming steps are involved.  Where able to be successfully demonstrated within the time box of the demo, I prefer to see working software.  Maybe that’s just me, but it gives me a warm-fuzzy.

6.  Everything needs a spike … Spike to think, spike to meet, spike to talk to another team, spike to say “Good Morning”; everything needs a spike!  Don’t get me wrong.  There is certainly a time and place for a spike.  However, spikes can be susceptible to abuse if not careful.  No matter what your role, don’t be afraid to challenge the need for a spike.

7.  Throwing in the towel too soon … I’m shocked when on day 2 of an 8 day sprint, team members start tossing out stories (all other things unchanged, of course).  Really?!  What makes this so impossible just 2 days after we planned and committed to doing it? I’m a firm believer in encouraging teams that the impossible is possible.  This is easier with some than others.  A good reality check is important in the last half of the sprint but meanwhile, let’s give it the ‘ole college try!

8.  ScrumMasters waiting for impediments to be served up on a platter … Only in fiction do team members serve up impediments to their ScrumMasters like a nicely wrapped gift.  In reality, team members are constantly impeded by one thing or another, but never really bring it up in the stand-up nor do they mention it to their ScrumMaster.  It’s the ScrumMaster’s job to smell out impediments like a drug sniffing German Sheppard and attack them like a Pit Bull.

9.  Laptops in retrospectives … I realize that we are in the Digital Age, but laptops are not needed in retrospectives.  The whole team should be fully engaged in the retrospective.  If some team members are on their laptops (focused on something else), it really ruins the collaborative learning mood of the whole retrospective.

10.  Stories with words like “analysis”, “development”, and “testing” … I spent 14+ years applying Waterfall methods and I know a Waterfall phase when I see one.  Words like “analysis, “development”, and “testing” are best used with tasks, not stories.  When applied to stories, they wreak of Waterfall and make my skin crawl.

1 Comment   |  tags: , , | posted in Uncategorized

October 4, 2012

Agile / Lean at Savings.com: Interview With Joe Zulli, CTO

By Stephanie Davis

Some of you may recall that back in June we had some big news around here … not a baby, not a wedding, but an acquisition!  In June, Cox Target Media (the provider of Valpak) acquired Savings.com, a leading online source for coupons, deals, and expert savings advice.  As a result of the acquisition, I’ve been heavily involved in a series of synergy projects between Valpak and Savings.com which has allowed me to get to know their products, process, and people much better.  First off, they have a great product with over 100,000 coupon codes for top national merchants (Now, I am officially addicted to searching for coupon codes before I online shop!).  Second, I was thrilled to learn that their process is heavily rooted in both Agile and Lean. Third, their people are quite frankly the best in the business and super cool too.

Four months into this relationship and I’m now ready to share with you more about Agile and Lean at Savings.com through the words of their CTO, Joe Zulli.  What follows are Joe’s responses to a series of interview questions I presented him with.  I thought I’d end up doing some editing of his responses but after reading them, they are so worth sharing in their original format.  I hope you enjoy as much as I did!  My favorite quote is the very last sentence … “If it’s not fun, you’re doing it wrong!”

If you want to connect with Joe, he’s on Twitter @JoeZulli .

What Agile methodologies (XP, Scrum, Kanban, etc) do you use mostly?

We follow the Scrum methodology (daily standups, planning meetings, story pointing, etc…) pretty closely. We have also integrated bits and pieces of XP into our development process, but we stopped doing the parts that weren’t working for us (such as pair-programming).

How have you adapted that Agile methodology to suit the needs of your organization?

I try to be as open-minded and non-dogmatic as possible when it comes to any methodologies we use. We’ve tried a lot of different things over the years, kept what worked, and dropped or modified what didn’t. One example of where we have had to modify the “typical” Agile process is in the fact that we practice continuous deployment at Savings.com. In other words, we deploy to production multiple times a day. Before we started doing continuous deployment, everything fit much more neatly into the ideal Agile package. We had two week sprint cycles, with every sprint capped off in single, big release. With moving to continuous deployment, we’ve had to decouple the planning schedule from the release schedule. This brought about significant challenges, such as how to do acceptance testing when software is going so quickly into production.

How many Agile teams?  How many team members? What are the roles on your Agile teams?

We have a varying number of Agile teams depending on how many core initiatives we have every quarter. A “core initiative” is our name for the big projects that we decide to tackle that quarter. We usually have between three and 5, including an “Operations” initiative which is generally a bucket of smaller changes that need to be made to keep the core business running smoothly while we experiment with other growth opportunities. Each team typically has about 3-4 engineers, 1 product manager, and 1-2 business owners. Even though the teams are separate, we do planning, demos, and retrospectives as one big group. This is to help keep everyone in the loop with what’s going on across the initiatives, and facilitate knowledge sharing. Just how much should be kept to the smaller teams, vs. shared with the larger organization is something we’re still tinkering with.

How long have you been doing Agile and/or Lean?  What benefits have you found?

I’ve been doing Agile personally for the last 10 years. There are too many benefits to name, but if I had to choose one, I’d say that the most important benefit is that it’s much easier to change strategy and pivot a project. This makes experimentation and risk taking much more feasible. Being able to try out new ideas and turn on a dime is critical, not only for startups, but for larger companies as well that do not want to become obsolete.

What makes you a Lean Start-up?

Lean Startup and Agile really go hand-in-hand. I can go on forever about Lean Startup, but for our purposes here, I’ll discuss it in reference to Agile. Lean startup is a scientific and systematic approach to turning an idea, or vision, into a viable business. One way to think of it, is as the scientific method for startups. Most recent scientific breakthroughs were achieved not as one singular stroke of genius, but rather as a series of smaller experiments to prove or disprove a single hypothesis. The beauty of the scientific method is that you always win. Even when your hypothesis is disproven, you still come out better off because you’ve gained valuable knowledge that will make your next hypothesis that much better. Repeat-process enough times, and you will have the breakthrough you were hoping for (assuming you don’t give up first). In Lean Startup, we believe the same concept can be applied to business. After all, what really is a “vision” other than a collection of hypotheses? If you can break a vision down into a prioritized set of assumptions, then efficiently test those assumptions, you will have much more success, in much less time, for much less money, than if you just build everything whole-hog without testing your assumptions along the way.

Above all, Lean Startup is a redefinition of what it means to make progress. The Agile Manifesto states that “Working software is the primary measure of progress.” Leans Startup, on the other hand, defines the primary measurement of progress as validated learning. After all, what good is working software if it doesn’t move you forward as a business by making your customers happy. Sure, you may have thousands of lines of beautiful code, but did you really make progress if your company is no better off? Probably not. When you follow this new definition of progress, you stop worrying about “velocity” and how much code gets delivered, and start focusing on how you can learn the most the fastest. Sometimes a simple phone interview with a half a dozen prospective customers will get you a lot closer to where you need to be as a company than writing half a million lines of code.

What have been you greatest challenges to using Agile and how are you overcoming them?

In the early days, the greatest challenge was in getting everyone to buy into such a big change in how we were doing things. People get stuck in their ways, and telling someone that the way they’ve been doing things for years is wrong (or at least not ideal) is hard to swallow. It took a bit of persistence, but eventually everyone saw the light.

Nowadays, our biggest challenge is the fact that our team is distributed geographically. Our main tech center is in Santa Barbara, while most of the business folks are in LA. Add to that, the fact that we also have a team in the UK, and various consultants all over the place, and it adds up to a pretty distributed team. Not being able to just walk over to a person and ask a question forces us to be a lot more disciplined in our approach to Scrum. We really need to get as much as we can out of things like standup calls, because they are one of the few times a day information is exchanged across the whole team. When you have the luxury of having a local team, much more information gets transferred via osmosis.

What sorts of Agile technical practices have you adopted (CI, automation, etc.)?

We’ve invested very heavily in automation. We do CI, automated builds, and have a fully automated deployment process, which includes taking backup snapshots of the database, etc… We use JUnit and Selenium as out primary testing tools. Being able to automate everything that you possibly can is obviously really important when you’re deploying all the time :).

Describe a typical iteration in your Agile process?

Our sprints last one week. Coding starts on Wednesday and ends on Monday. A typical week looks like this:

  • Friday: The executives and stakeholders meet to agree on goals and discuss priorities for the upcoming sprint. The backlog is reprioritized one final time, and the top X number of story points are pulled out and made into the next sprint.
  • Tuesday: Big meeting day. No coding happens on Tuesday, but rather the day is dedicated to process and design. Tuesday’s meetings contain:
    • A retrospective of the previous sprint with a Start/Stop/Continue meeting
    • Demos from tech and product of all the new stuff created in the last sprint
    • An update from the business owners on all on how features released in prior sprints are performing.
    • Breakouts and design sessions for all of the tickets in the upcoming sprint. This is where all of the tickets get broken down and tasked out.
  • Wednesday – Monday: Heads down coding for the tech team (as much as possible).

What was your world like before Agile?  Would you ever go back to that?

Everything was far slower paced and less efficient. I definitely won’t be going back to the Dark Ages before Agile. Even more so, I would definitely not go back to the days before we did continuous deployment. And even more than that, I wouldn’t go back to not being a Lean Startup.

What’s the key for you and your teams in being more and more Agile each day?

Two things: The first is to be dedicated as a team to constant improvement. That’s not always as easy as it sounds. You have to build a culture where constructive criticism is not only allowed, but is expected from every person on the Agile team. Solving a problem is often quicker and easier than identifying the problem in the first place. You need a team that is dedicated to breaking through bottlenecks and fixing “broken windows.”

The second is the need to constantly experiment. You need to get out of your comfort-zone and try new things process-wise. Most ideas won’t work, but some will, and the ones that do will make all of the others worth it. Bite off change a little at a time. I remember vividly when I first heard about continuous deployment. We were deploying every two weeks at the time, and I thought the ideal of deploying 20 times a day was the stupidest thing I ever heard! But then I started to hear some great success stories, so I decided to try it out by taking baby steps. First, we went from bi-weekly deployments, to once a week. Everybody loved it. Then we went to twice a week. Again, everybody loved it. Then we started deploying every day. I’ll never forget the first time I heard someone complain because they missed the daily release train by 5 minutes and had to wait a WHOLE 23 HOURS AND 55 MINUTES!!!!!!!! to deploy their awesome new feature! This was unacceptable! We needed to deploy more often! It’s funny how addictive it gets, and that’s how it should be. Improving the process of your daily job should be addictive. It should be fun. If it’s not fun, you’re doing it wrong!

Leave a comment   |  tags: , , | posted in Uncategorized

July 19, 2012

Sprint Planning, Team Capacity Calculator

By Stephanie Davis

Some of our Product Owners and managers expressed an interest in the ScrumMasters refining the team capacity calculations that we facilitate during sprint planning.  There may be hundreds of these online, but attached is our version of a Team Capacity Calculator.  The best approach is to bring this spreadsheet up on the big screen and fill it in live at the start of sprint planning.

Hope others may find it useful.  Feedback welcome!

TeamCapacityCalculator

6 Comments   |  tags: , , | posted in Uncategorized

June 13, 2012

Our Evolution of Sprint Reviews

By Stephanie Davis

Since going full-fledged Agile in the Fall of 2011, Valpak’s approach to Sprint Reviews has evolved.  Towards scaling Agile, we’ve been regularly inspecting and adapting (as you would expect) across our 9 Scrums and 1 Kanban team.  Today, we have a Sprint Review approach in place that operates like a well-oiled machine and also scales well as you add more teams.   Let me share with you the evolution of our Sprint Reviews.  But first, some background on our Scrum process …

At Valpak, we sprint in 2-week iterations running from a Monday to a Friday across 9 teams and 50+ team members.  Because of heavily integrated systems and environments, all teams sprint on the same common sprint schedule.  This means that all teams hold Sprint Planning and Sprint Reviews on the same day.

Sprint Review 1.0: The Every-Team-For-Themselves Approach

Our first take at Sprint Reviews was pure madness!  Each ScrumMaster would schedule a separate 1 to 2 hour meeting on the same Friday for each Scrum team.  That’s nine 1 to 2 hour meetings within an 8 hour business day and on a Friday no less!  That approach works fine for Sprint Planning, which doesn’t involve the stakeholders, but royally sucks for Sprint Reviews.  As much as the ScrumMasters tried to coordinate the independent Sprint Reviews, stakeholders would receive overlapping meeting notices and were forced to decide which Sprint Review to attend and which to miss.  With much confusion and chaos, we quickly discovered that teams had many stakeholders in common and that we needed a Sprint Review approach that allows stakeholders to see demonstrations from all the Scrum teams they have a stake in.  It’s just not possible to be in two, three, or even nine places at once!  Logistically this approach just didn’t scale. 

Sprint Review 2.0:  The 180-Minute-Marathon-Mob Approach

Our second take at Sprint Reviews solved the logistical problems of the 1.0 approach and scaled much better, but still wasn’t quite right.  Our 2.0 approach was basically a single Sprint Review across all 9 Scrum teams.  Quite frankly, it was an exhausting 180-minute marathon with a mob of stakeholders in the biggest room we could find.  Each team would go up to the front of the room and present for about 20 minutes.  This included a review of the Sprint accomplishments and metrics from the ScrumMaster followed by a demonstration of working software by the team members.  This approach certainly proved that we can successfully aggregate the Sprint Reviews across all teams for all stakeholders, but it had some challenges of it’s own.  First off, trying to pay attention to anything or anyone for 3 hours straight is a challenge; even more so when you have people that aren’t necessarily professional speakers.  Second, there was just too much dead air and awkward pauses with constant switching of speakers, teams, laptops, decks, etc.  The result was a disengaged audience of stakeholders.

Sprint Review 3.0:  The Science Fair Approach

The challenges of the 2.0 approach to our Sprint Reviews led us to a modified approach we call “The Science Fair”.  Our 180-minute marathon of Sprint Reviews was shortened to 90-minutes with each team presenting for just 10 minutes each.  Within that 10 minutes, the ScrumMaster provides a condensed version of the Sprint accomplishments and metrics and the team demonstrates only the sexy stuff (via live demo and/or presentation format depending on the feature).  Oh and, we now incorporate handheld and table-top microphones to better project the voices of the speakers.  Following that 90-minute period, we hold a one hour Science Fair in the cube areas where the teams sit.  Just like parents viewing student experiments at a school Science Fair, this hour is for stakeholders, at their own pace, to make the rounds to each team they have an interest in for any given sprint.  Stakeholders can informally visit with each of the teams (and their ScrumMaster and Product Owners) at their everyday work spaces to ask questions and see greater detail on what was accomplished during the sprint.   This might be in the form of casual Q&A or real life demonstrations of working software.  Over time, we have found the shortened Sprint Reviews keep the audience engaged and the Science Fair meets the needs of stakeholders wanting greater detail or more personalized attention.

One thing is for certain … that is change!  We are bound to further evolve our approach to Sprint Reviews again and again and again.  That’s right, we most certainly will inspect and adapt and, this time next year, we might be doing something completely different.  All in all, we are doing what works for us today in keeping with our Agile ways.

7 Comments   |  tags: , , | posted in Uncategorized

April 20, 2012

An Agile Light Bulb Moment: Forming Projects Around Teams

By Stephanie Davis

It’s great when you have a light bulb moment.  It’s even better when you inspire a light bulb moment in others.

The other day, I had the pleasure of speaking with several managers from another Tampa Bay company about Valpak’s Agile transformation.  I use the word “pleasure” thoughtfully because I genuinely enjoy talking to others about the Agile transformation taking place here at Valpak.  It’s a great story and I love to share it!   Anyhow, apparently how I explained our project initiation process resulted in a light bulb moment for them, or at least that’s what the guy said.  They are moving towards Agile and seeking advice and experiences from other companies having recently transformed.    So, let me explain what I explained to them and you can decide if it’s a light bulb moment.

From whence we came …

Used to be that when a project was initiated, a team would be formed around the project.  In most cases, the team members were already assigned to multiple projects 30% here, 50% there, and so on just waiting for their phase (analysis, design, development, QA, etc.) to start in the waterfall process.  Team members were not necessarily dedicated, just committed.  So, with project plans changing as they do, a team member would typically end up being pulled in multiple directions, reporting to multiple masters, across many projects all at the same time.  From a people perspective, this is not a fun place to be (remember, “multitasking” is the new 4-letter word).  The result was low morale from all the project whiplash going on.

… to where we are now.

Today, under our Agile structure of 8 Scrums and 2 Kanbans, we have naturally experienced a shift in our project initiation process.  Now, when a project is requested, we evaluate the request based on the existing Scrum and Kanban teams and we form the project around the teams.  Sometimes this means breaking up the project to fit the vision and/or skill of the teams.  So, as opposed to forming a team around a project, we are now forming a project around teams.

Let’s take a look at a real world example.  Most recently, we enhanced our Valpak.com website with photo galleries on some of the business profile pages.  This project was ultimately broken down into multiple stories across three teams:

  • One team to upload the photos into our order entry system,
  • One team to store the photos in our content management system, and
  • One team to display the photos on the web page.

While coordination and collaboration across teams can not (and should not) be under-estimated, this beats a team of 30 people working over 6 months in a waterfall process any day.  By forming the project around the teams, team members are able to remain focused and dedicated to their product vision, thus resolving the project whiplash and leading to improved morale.

You may ask, “What if a project is requested that doesn’t fit the vision and/or skill of any of the Scrum or Kanban teams?”  Easy!  It becomes an investment decision.  Is the company willing to invest in a new Scrum and/or Kanban in order to fulfill the request?  This could mean hiring new people to staff new teams and/or pulling people from existing teams to form a new team.  Either way, it’s a leadership decision as to whether to invest in the new idea or impact the investment in an old idea.  In fact, we’ve actually had this happen.  We didn’t start out with 8 Scrums and 2 Kanbans.  Investment decisions were made over time that led us to where we are today.  It’s all about adapting.  It’s indeed Agile!

Leave a comment   |  tags: , , | posted in Uncategorized

March 16, 2012

The Power of the Backlog

By Stephanie Davis

The power of the backlog is incredible in a Scrum world.  If stories are the promise of a future conversation, then the mighty backlog can certainly start, end, or even influence a conversation.

The backlog can start a conversation … “Do you have it on your backlog?”

The backlog is a conversation starter when something new is identified as being a valuable enhancement to a given product.  Of course, value is generally subjective, but in this case, value is in the eye of the Product Owner with input from all the various stakeholders.  Maybe this sort of conversation is started from an executive, a stakeholder, the team, or even the true end user themselves.  Regardless, the backlog is that Scrum-sacred home where cool, hopefully valuable things go to wait until their story is planned into a sprint (and become part of the sprint backlog).  Even if the story never gets planned into a sprint, there is some satisfaction to the person that came up with the idea that it has been considered and is “on the backlog”.   As a ScrumMaster, I know that I feel satisfied when the Product Owner says, “Yep, I’ve got that on the  backlog already”.  If the idea is truly proven to be the next most valuable thing to work on, it should be planned into an upcoming sprint.  If not, it had it’s time on the backlog and maybe it falls off or is killed someday.  Call me sadistic, but I actually enjoy the killing of the occasional low-value backlog item.

The backlog can end a conversation just the same … “That’s not on our sprint backlog. Let’s backlog it for now.”

The backlog is a conversation end-er when something is brought up that isn’t on the current sprint backlog.  It’s amazing how much of an impediment (possible) future work can become if allowed to run wild.  In the old days of traditional waterfall project management, this was called scope creep and typically handled like a change request under whatever change management policy may have existed.  In most cases, meetings were called, the change was assessed, guess-timates were given, and friends or enemies were made as some change committee yeah-ed or nah-ed it.  All of that took time, time away from the team working on the approved scope of the project; more time in some cases than others depending on the degree of the change and the corporate bureaucracy in place.    Under Scrum, the power of the backlog makes clear what is in the current sprint backlog and what should be “backlogged” for a future sprint.  This means the team remains focused on the current sprint.

The backlog influences conversation … “We might want to add another developer to the team. I’ve got a 2 year backlog built up!”

The backlog influences conversations day in and day out throughout the life of the product.  One might even say, the backlog speaks.  The backlog says …

  • How much technical debt still exists for a product (especially if you religiously capture bugs and such in the backlog).
  • How much value remains to be implemented for the product.
  • Whether continued investment in a product or Scrum will continue for 1,2, 3 or however many months/years.
  • All that the team accomplished and the value delivered in past sprints.
  • And, so much more!

So, next time you overhear things like “it’s on the backlog”, “backlog it”, or “it’s not on our sprint backlog”, just remember that it’s all in the power of the backlog.

1 Comment   |  tags: , , , , , | posted in Uncategorized

February 28, 2012

A Scrum Board Is Worth A Thousand Words

By Stephanie Davis

Last week, we had three tours in three days around here.    Yes, I said “tours”.  “A tour of what?”, you may ask.  A tour of our Agile transformation!  Now, understand you-me that tours are typically reserved for our state-of-the-art manufacturing facility (not a plug, just a reality).   At first, I didn’t realize there was much of a show to be had with all our old cubicles and dingy carpet, but apparently I was all wrong.  The tours were such a hit that we’re now making a video!  Yes, that’s right, a video… an Agile transformation video.

We gave tours to three different groups, two stakeholder groups and one VIP.  Each tour began at our local copy of The Agile Manifesto where we explained the values and principles that guide us.  Then, the tour moved into our beloved Scrum Pit (a.k.a., “The Pig Sty”) where we used the 9 Scrum Boards to visually eplain how Scrum works.  Last but not least, we walked the tour groups through the bullpen areas for 6 of our 9 Scrum teams to demonstrate the open collaboration environment we’ve established.

The mere fact that we had three tours in three days really demonstrated two things to me: 1) Our leadership is proud of what we’ve accomplished with our Agile transformation in just 8 sprints and 2) we’ve really done well by way of “visible information radiators”.  Like the old saying, “A picture is worth a thousand words”, a Scrum Board is worth a thousand  words too!  Our towering walls of magnetic whiteboards with index cards seemingly-chaotic, yet intentionally-placed  really seemed to leave quite the impression with our tour groups.  I know now that having handed them a document or an illustration or shown information buried in some tool wouldn’t have nearly the impact.  Our visible information radiators worked!  At the time of the tours, we were mid-way through the 8th sprint across 9 Scrum teams, and progress (or lack thereof) was clearly visible within a 360° view of the Scrum Pit.    I guess what I’m getting at here is simple … When your hand gets tired of writing story after story or task after task and you’ve got paper cuts on both hands, just remember that a well-constructed, well-maintained Scrum Board is the ultimate visible information radiator and worth a thousand words.

Leave a comment   |  tags: , , , , | posted in Uncategorized

February 24, 2012

Story Points: What’s The Point?

By Stephanie Davis

So, what’s the point of Story Points?  9 Scrum teams and 8 sprints into our Agile transformation and it seems that some still struggle with the proper use of Story Points, a common relative estimating technique.  That said, I put together the following tips on this topic to help my teams (hopefully they will be of help to your teams as well).

  1. Story points are a relative measure of effort to done, NOT complexity, NOT priority, NOT sequence.  Something that is highly complex might take very little effort to complete and might be considered 1 or 2 or 3 story points. On the other hand, a 13 point story might be worth further decomposing into smaller, independent stories.
  2. A common technique for story points is the use of the famous Fibonacci sequence of 0 1 2 3 5 8 13, 0 being hardly any effort and 13 being the most effort.  Commit it to memory! Say it frontwards, backwards, forwards until you make it a habit.  Or, make a game of it and get some Planning Poker cards for your teams.
  3. Story points must always be established before tasks and task hours.  You can do them as part of backlog grooming, at the start of your sprint planning, or even negotiate them over e-mail, but never-ever do tasks and task hours before you establish story points.  If you do, you basically negate the benefit of your relative estimating technique.
  4. After establishing story points for stories within a given sprint, you should be able to group all the 13’s and the 8’s and the 5’s and so on and they be of relatively the same effort.  Make a point of thinking about it that way during your Sprint Planning.  Furthermore, you can use the task hours you come up with in Sprint Planning to make sure it all jives.  If you have a 13 point story and a 3 point story and both have just 6 hours of tasks then it is questionable as to whether you got the story points right or if you’ve considered all tasks.
  5. Story points are determined by the Team (based on all that has to be accomplished to meet your definition of done).  It’s not about just analysis or just QA or just coding.  The ScrumMaster and the Product Owner do not determine story points.
  6. There is indeed such thing as a zero point story if it’s something that the team has relatively no effort for.

The point of Story Points is to someday stop having to think about all those tedious task hours.  If you know your team’s velocity of story points over time, you can use story points to determine what can nicely fit within a sprint.  For instance, I know that some of my teams at full capacity are 40-ish story point teams.  With that knowledge, the Product Owner can select 40-ish points of stories for the team to work on in any given sprint.

1 Comment   |  tags: , , , | posted in Uncategorized