Tag Archives: agile

Valpak’s First Ever Hackathon, Made Possible By Agile

ab132284bcc711e2a47922000ae90d5b_7With over a year and a half into our Agile journey here at Valpak, now was the right time for our first ever hackathon.  So, hack we did!

Since we were indeed hackathon virgins, we sought advise from our sister company, Savings.com, who has been doing quarterly hackathons for quite some time now.  Being a West coast startup, they are much closer to Silicon Valley than we are, so they obviously caught the hackathon bug a lot sooner.  Our friends at Savings.com provided lots of insights from their past experiences but the most important takeaway was to make sure to “have fun”.  So, fun we had!

The Build Up

The hackathon was announced about two weeks prior to the actual event date with a quick, one-hour information session hosted by our Software Engineering Director and our Architect.  Since we sprint continuously in two week intervals around here, this allowed the Scrum teams enough advance notice to plan the event into their sprint capacity. The hackathon schedule looked something like this:

  • Thursday 3:00pm – Kick Off
  • Thursday 4:00pm through Monday 9:30am – Execution
  • Monday 9:30am – Presentations / Demonstrations / Awards

People from both the technical and business side of the house were encouraged (strictly voluntary, of course) to self-organize teams (5 person limit) around an idea of their choosing.  The only condition was that the idea be related in some way, shape, or form to a Valpak product or process.  That said, being in the business of saving people money leaves a pretty broad spectrum of ideas to be had.  A cork board was hung in a highly visible area as a seed board for ideas.  Anyone, and I mean anyone, could come up with an idea and post it to the seed board in search of other team members to hack with them or to get the attention of a team seeking an idea.   At last count, we had well over 25 ideas on the seed board (not to mention the ideas that people didn’t post because they wanted to save their thunder for the demonstration).  Teams were asked to submit their team name, idea, and team member names by the day before the kick off.  We ended up with 13 hackathon teams of 31 people comprised as follows:

  • 5 of 13 teams were one-man teams
  • 4 of 31 people were on two teams
  • 4 of 31 people were from the business side (non-IT)
  • 6 of the 13 teams worked across assigned Scrum team boundaries

The Kick Off

Coincidentally-on-purpose, we scheduled the hackathon kick off to directly follow a long-awaited IT organization cookout and kick ball game at the park.  The teams were so amp’ed up from playing kick ball in the park that the kick off was extremely spirited, to say the least.  So, kicked off we were … with kick ball!  By 3:00pm that Thursday, we all piled into our largest conference room (body odor and all) and all 13 teams got up one by one to introduce their team and describe their idea.  We had ideas running the gamut from utilities to help us save time to widgets and apps that will amaze customers to an entirely new platform architecture using up and coming technologies.

Hacking, Hacking, Hacking

Immediately following the kick off, teams began hacking away at their ideas.  So, hacking we did!  Teams had from about 4:00pm Thursday to 9:30am Monday to get as far along as possible on their ideas (teams could and did hack through the weekend if they chose too).    Teams were also able to work wherever they chose during the hackathon, office, home, a pub, wherever.  During the hacking period, the Software Engineering Director and the Architect made rounds to keep teams “unstuck” (that was another wise tip from our Savings.com pals).  Also, several of us leaders made sure that the teams were well fed and hydrated with everything from Krispy Kreme to pizzas to Red Bull and of course we had lots of leftovers from the cook out too.

Show & Tell

Monday morning rolls around and all 13 teams … Vicious & Delicious, Darth Vatr, A-Hacker, and so on … take their turn at the podium to demonstrate what they accomplished to a panel of judges and a room packed full of eager stakeholders.  The judges were the President of Cox Target Media / Valpak, the CIO (my boss), the Digital Innovation Director, and the Software Engineering Director.  The judges awarded trophies for Best Innovation, Ready For Primetime, and Nice Try.  Everyone was absolutely blown away!  All 13 ideas were viable and most teams achieved what they set out to accomplish, and in such a short time frame too.

A Look Back

As I look back on our first ever hackathon experience, I can’t help but think that so much of this was made possible by Agile … our culture, our mindset, our values.  Under the old waterfall world, we would have struggled to self-organize around a thing like a hackathon, not to mention the nightmare logistics of disrupting multiple conflicting Gantt schedules with mobs of anxious stakeholders waiting at the end of a death march.  In the old days. we were used to being told what to do by a document or by management.  Self-organization didn’t come easy to us back then.  We were waterfall zombies!  We didn’t have the capacity to dream up new ideas and we certainly didn’t have the autonomy to hack away at them.  The hackathon was our opportunity to truly practice our new found autonomy and that we did…. people picked who they worked with, what they worked on, when they worked, where they worked, and how they worked.  Oh the times they have changed!

While there are some things that we might change the next go round, like not scheduling over Mother’s Day weekend or maybe mandatory deodorant after kick ball, what we we did was hugely successful and ultimately fun too.  I, for one, can’t wait for the next one!

“Agile just doesn’t work for us”

I bet I grabbed your attention with that title.  Before you proceed on, please be warned that this post is definitely more of a rant.  But, if you can’t occasionally rant on your own blog, then what’s it good for anyhow?

To those that say “Agile just doesn’t work for us”, I say bullshit!  For some reason, some people think their company / organization / product is so different from the rest of the world that a process like Agile will not work for them.  When it comes to work, we are all more alike than different.  Those same people tend to look for every opportunity to blame any issue on Agile.    The team didn’t get a user story done … “Agile just doesn’t work for us”.  A stakeholder made a late change … “Agile just doesn’t work for us”.  I can’t make it to the stand-up on time … “Agile just doesn’t work for us”.  We had a bad retrospective … “Agile just doesn’t work for us”.  We deployed a bug to production … “Agile just doesn’t work for us”.  It rained today … “Agile just isn’t working for us”.  You get the point, I’m sure.

Now, don’t get me wrong … I totally get statements like “This isn’t Agile” or “We aren’t being Agile”; that, I can deal with.  Just don’t make rash statements that insinuate that the process is to blame for what is a problem that would / may exist regardless of Agile.  In other words, don’t hate the process, hate the weaknesses in ourselves that the process exacerbates … whatever it may be, lack of discipline, poor collaboration, no accountability, bad leadership, etc.

Dig deeper beyond the rash statement and you will find that often it is not the process that doesn’t work for us, but rather we don’t work for the process.  When I hear “Agile just doesn’t work for us”, I like to probe further with questions like …

  • What specifically do you think is not working about Agile?
  • What have you done to try to solve the problem?
  • Would this / did this / could this problem exist under any other process?

So, to all those that are quick to say “Agile just doesn’t work for us”, don’t be a hater.  Look within your own locus of control (never thought I’d have the opportunity to use that phrase beyond college) before you jump to judgement about a process that has worked successfully for many diverse companies all over the world for many years.

The Sprint Review Rut

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.

I’m Agile! Now what?

We here at Valpak are 1 year and 3 months into our Agile journey (not a destination, but a journey indeed).  We’ve transformed and scaled from 6 Scrum teams and 4 Kanban teams (October 2011 was Sprint 1) to 10 Scrum teams, 3 Kanban teams, and all the elements that comprise the Scaled Agile Framework (SAFe) including a release train, a Portfolio Kanban, and an Architecture Kanban. We’ve even got business, project, and personal Kanban boards popping up left and right.  And if that wasn’t enough, we’ve produced a video on our Agile Transformation and are just about to have a case study published in a book.  Plus, all along the way I’ve been blogging about our transformation.  So, that leads me to ask, “I’m Agile! Now what?”

In the 1+ year we’ve been doing Agile, we’ve managed to become very good at some of the basics … sprint planning, stand-ups, retrospectives, etc.  Teams go through the motions of Scrum in a lather-rinse-repeat fashion sprint after sprint after sprint.  We are doing Agile!  Now we need to be Agile!  To me, truly being Agile involves the conscious embrace of the Agile mindset such that it becomes deeply intertwined within our culture, values, and beliefs as a company and in everything we do each and every day; all the problem solving, creating, decision making, innovating, and direction setting that goes into running and growing the business.

So now that we are Agile, we keep on keepin’ on … that means we keep sprinting! It’s pretty clear that never ends.  While we continue to sprint merrily along, I continue to support and grow Agile across the organization as Director of Agile Leadership.  With that in mind,  I’ve outlined some 2013 goals for us that are specific to where we are at in our transformations and journey:

  1. My team of Agile Project Leaders, as well as some other interested folk, will pursue the PMI-ACP (Project Management Institute – Agile Certified Practitioner) this year.  This means there will be more than just me with a relevant certification in hand.  We can debate the value / need of certifications all you want, but it most certainly represents a commitment to Agile here at Valpak.
  2. We will further scale the process and teams to support the needs of the business.  This might mean starting teams, stopping teams, merging teams, or re-assigning team members.  Again, all based on the needs of the business throughout 2013.
  3. With 1+ years under their belts, all of the ScrumMasters (titled “Agile Project Leaders”) will truly step into the role of Agile coach, embodying the Agile mindset and, not just facilitating, but coaching teams too.
  4. By continually improving our estimating and planning, all teams will become more and more predictable over time by their velocity and story points will become second nature to our teams.
  5. We will become masters at (okay, maybe not masters, but at least really good at) writing user stories.  We will decompose stories just right and write meaningful (maybe even measurable) “so that” statements.
  6. Our backlogs will be so well groomed that each team will have 2 to 3 sprints worth of stories penciled in and priorities will be evident by the order of the stories in the backlog.
  7. We will send a handful of our best and brightest to the Agile 2013 conference to develop and network in hopes that they will return to further evangelize Agile across the organization.
  8. Teams will strive to become high performing teams by not just doing Agile but being Agile.
  9. We will give back to the Agile community by sharing our story with anyone willing to listen and encouraging others in their Agile transformation.

Roastin’ Agile: 1st Anniversary of Agile at Valpak

October 2012 marked the 1st anniversary of Agile here at Valpak.   It was October 17th of 2011 that we started Sprint #1 across multiple Scrum teams and haven’t stopped sprinting since.  In recognition of this momentous occasion, what better than a roast of the man himself, Agile.  We all know that we roast the ones that can take it and the ones we respect the most.  So, let’s roast Agile!

Agile arrived to the roast wearing his favorite “Respect The Sprint” shirt, care of http://www.AgileThought.com.

The structure of the roast was an open mic format, so teams (or anyone for that matter) could come up to the podium at any time to present or say a few words.  Most teams found or created videos for the event.  One Scrum team created a video spoof of a scene from the Office Space movie; the scene where they take the printer out and beat the crap out of it.

Since Agile couldn’t speak for himself, he brought along his playlist of music in response to being roasted.  Agile’s playlist was a diverse mix of tunes:

“Back In Black”, AC/DC
“Don’t Play No Game That I Can’t Win”, Beastie Boys & Santigold
“Revolution”, The Beatles
“Get Up Stand Up”, Bob Marley
“Ain’t No Rest for the Wicked”, Cage the Elephant
“Should I Stay Or Should I Go”, The Clash
“Titanium”, David Guetta & Sia
“You’ve Got Another Thing Comin’ “, Judas Priest
“Die Another Day”, Madonna
“Don’t Tread On Me”, Metallica
“Uprising”, Muse
“Rock Star”, N.E.R.D.
“I Wanna Be Sedated”, Ramones
“Sympathy for the Devil”, The Rolling Stones
“Working Man”, Rush
“Stuck in the Middle with You”, Stealers Wheel
“Kiss Off”, Violent Femmes
“Seven Nation Army”, The White Stripes
“Don’t Tread On Me”, 311

All attendees received a party favor of a Pomodoro timer along with instructions for trying out the The Pomodoro Technique, a personal time-boxing method. The Pomodoro timers were each imprinted with “Be Agile @ Valpak”.

If you ever have a a need to celebrate something, have some fun, or just blow off some steam, I would definitely recommend the roast format.

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

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.

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

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!

Release Dates in Agile, Not Taboo

I’ve heard a lot lately about how it’s not-so-Agile to set release dates for major features, epics, and projects.  Some are uncomfortable being given a date (mainly teams) and others are uncomfortable without a date in hand (mainly, Product Owners, executives, and stakeholders).

This very much a myth to be dispelled.  Dates do not go away with Agile!  Rather, it is how we predict and communicate dates that should change.

With Agile, release dates are fixed based on time-boxed iterations.  In our case, we tend to release after every sprint, so there is always a release date every two weeks.  Therefore, by nature of time-boxing, the schedule is a fixed constraint.  With the schedule being a fixed constraint (as is cost based on team size), it is scope that remains flexible.  So, the scope that is included in any given release is flexible based on what the team was able to accomplish, what stories get dropped, what natural disaster impeded the team, who was out sick, and so on and so forth.  Whether that scope accomplished is acceptable for release to production is always a Product Owner decision.

Second, what’s critical to understand is that in Agile we PREDICT.  We predict dates for major features, epics, and projects.  In fact, everything we do in Scrum is in support of us all getting better and better at predicting or being predictable rather … Capacity, story points, velocity, release planning, etc. Furthermore, the closer you get to any given date, the better you are at predicting it and the greater the confidence too.

With that understanding, how we communicate dates needs to be adapted for our Agile world.  First, we should modify our language.  Rather than say “Project X will be released on 7/1” let’s say “Project X is predicted to release on 7/1 and the team has an 80% confidence in that date”. Second, we should always remember that with schedule and cost as fixed constraints, scope is flexible. So, we might say “Project X 1.0 with A and B features is predicted to release on 7/1 and the team has an 80% confidence in that date”.

With some education around this topic we will all be better able to talk dates without the taboo of it not being Agile.

Talking Work Podcast: Goin’ Agile!

Give a listen to my guest spot on the Talking Work podcast on goin’ Agile.  Enjoy!


The Power of the Backlog

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.