Implementing scrum for non-software teams

When we hired a new CTO at Valore, we rolled out agile/scrum with our product and engineering teams. We had been in the waterfall dark ages. We predictably experienced every bad outcomes one could expect from a misaligned development process. It took some time for the team to understand it, get comfortable with it, and realize the many benefits of it.

A sampling of the many benefits we have experienced from adopting scrum include:

  • Increased transparency resulting in better stakeholder expectation setting and prioritization
  • More engagement from the development team which translates into higher quality work
  • Improved planning, both with accuracy of timing, as well as visibility
  • Reduced churn on work. Better visibility and planning made moving to a just-in-time creation of user stories possible. That reduced wasteful cycles of requirements gathering
  • More valuable output. Value measured as quicker time to market (time is money), higher ROI (by pushing MVP features/products), and higher quality software (from engaged teams)

Agile and scrum are often thought of as software-specific processes that ‘tech people’ do. I have never quite understood that perspective. Agile takes complex work, and breaks it into small, meaningful chunks to help teams execute better. It also helps set clear responsibility boundaries between people involved in the process.

Nothing (ok – well the manifest does state software in a couple cases) says non-software teams cannot use agile. I had been thinking about how it would work in a non-software world for a while. My internet research came up with few, if any, examples of scrum adoption for non-software teams. Nothing detailed out the experiences, do’s/don’ts or best practices of scrum for non-software teams.

As with everything, doing is better than thinking, so why not give it a shot? Try it in the real world and see what happens. So, I rolled scrum out to my operations team. Keep in mind, this is not an engineering ops team (DevOps/TechOps/etc). This team focuses on moving widgets, handling customer service, processing inventory, and combating fraud.

The results are not conclusive yet. We are only a couple months into the adoption, I do want to highlight some of the things we have learned in our adoption so far. share those with anyone who might be considering a similar move with a non-engineering team.

  1. Commit to full adoption
    • Start formally and with the most basic, yet complete form of scrum. That means anointing a ‘product’ owner, determining what a point means, defining the ‘definition of done,’ two week sprint cycles (no shorter), retrospectives, stand-ups, and user stories in one (and only one) backlog. If you can invest in training, do it. The team must have a foundation and understand what they are getting into, if they are to be successful.
  2. Treat ‘ongoing work’ explicitly and try to kill it
    • The operations team has a variety of things they do every day (i.e. answer customer support tickets). This work must still occur to keep our business running. Do not shy away from this work or including it in the sprint. The team should be explicit about what they must do and how much time it takes them to complete these tasks. Discuss that effort before every sprint commitment. This should give the team has a clear sense of how that will impact the rest of the stories that they commit to. If you do not make this clear, the team is not in a position to be successful. Over time, the product owner should think about these activities and how to kill them. This is no different than tech debt. Automate the work or at least figure out ways to cut the effort needed to complete it. This will allow the team to complete more valuable, strategic work.
  3. Dependencies on third parties (internal and external) are tricky
    • Third party dependencies can kill any sprint, regardless of whether it’s software or not. A non-software team will be more dependent on third parties than others. This doesn’t change the fact that such dependencies are a challenge to the successful completion of the team. Putting your team into a scrum process will highlight dependencies exist, internal and external, that get in the way of progress.
  4. User stories are critical
    • It will take time for the team to get a good feel for what is an appropriate acceptance criteria. The team needs to think of what the business-valuable deliverables would be for a particular story. It will not be production software, but it can still be well defined. Keep user stories focused on the “As a ____, I want to ____, so that I can _____.” Keeping the narrative focused on the expected user benefit (and why) will help the team deliver the right things.
  5. The team must iterate
    • Empower the team to evolve the process, as with any other implementation of scrum. They must do retrospectives, and they must fully own whatever they adopt. The process is theirs now, as long as they stay true to the values and principles of agile.

Those are just a few of the early take-aways on the adoption of scrum by a non-software team. As this matures more, I will update everyone on how it’s going and what else we’ve learned along the way. Many of the results that I listed at the beginning of the post are also coming true for the operations team. Who would not want a team to experience those benefits? If you are on the fence about it, I say jump right in and go for it.

Have you used an agile process for a non-software team? What was your experience?


The World Health Organization estimates that 15% of the world population is disabled. After the initial shock about that statistic sets in (that is a lot more than I expected), you may ask why I’m writing about it.

People with disabilities are on the web every day, trying to use your product, just like their non-disabled peers. However, I’m willing to bet that accessibility is an afterthought as you design and build. That does not make you a bad person. Far from it. It just makes you unaware. Unaware that you are ignoring a significant number of users who may find your site, who may want to signup for your site or even pay you money. Your particular user base may over or under index, but even if a conservative estimate is just 5%, you should address this issue. Imagine if your dev team told you they would no longer support a browser that accounted for 5-10% of your traffic? Seems crazy, I know. That is effectively what you are doing when you ignore accessibility on your site.

We have come under more scrutiny on accessibility since pivoting to an institutional sales model with Boundless. Schools are vigilant (as they should be) about keeping their courses available to everyone on campus. We agree with that goal. Our engineering team provided a great explanation of the process on the Boundless blog. Go there to read the details and the process. It’s worth it – I promise.

Based on that experience, there are a few lessons that I’ve learned through the process.

1. Start small. Don’t buy expensive screen readers out of the gate. You can use the VoiceOver technology that is integrated into Mac and iOS devices. Take a run through your site and see if it makes any sense at all. If you don’t have an Apple device or your site is not mobile friendly, you have bigger problems – address those first.

2. Don’t get caught up in the jargon. It’s confusing and hard to understand without any context. Lots of people have deep expertise in this domain, but don’t feel like you need to rival their knowledge. Originally, we paid to have the Carroll Center for the Blind do an audit. They did a comprehensive review and gave us a detailed report. They did amazing work, but frankly, it was too overwhelming to even figure out where to start. The jargon was too unfamiliar, and the list of issues too many. We were paralyzed by how much work we seemed to have to do. Instead…

3. Do what you should always do – test with real users. Define your most critical user paths and walk through the most important ones with a live user. Have the whole engineering team watch. Make it mandatory. We did not do this purposefully, but the results were great. You could watch the team’s empathy for our user grow, as they saw how frustrated she became. There was even a hint of embarrassment when the user was unable to complete even the most basic task. After the session, they were ready to knock out every major roadblock we saw. They now understood why this was important, instead of it being an abstract concept that required a lot of code to address.

Accessibility is not a certification you achieve, despite it seeming that way. It is more of a mindset you need to instill in your organization. It is a hygiene and best practice you need to always address. If you build the right habits around it, you will be better off for it in the long run. And you will have much happier users because of it!

Other good resources on this topic can be found here


Why don’t business people practice?

Sports and business are always compared. There are an endless number of analogies used every day – teams, winning and losing, star players, competitors, etc. The comparison holds, for the most part. Except for practice. Why?

Athletes at all levels know that they will need to practice their ass off to compete at the highest level. Daily images of athletes toiling away in the anonymity of the empty practice field or gym stream over the airwaves to us.

Jerry Rice, the All-Century NFL wide receiver, spent 97% of his football related time practicing. That means he only spent a paltry 3% of his football time playing in the games. That number is shocking, but not unreasonable. Think about all the time, over his career, that he put into drills, conditioning, and weight training. If you want extra color on his habits, James Clear did a great writeup on it.

I would be willing to bet that business professionals would be LUCKY to have the inverse time allocation. Based on my professional experience, people get the skills they need on the job. There are countless corporate training sessions, learning and development budgets, and other courses people can take outside of work. Learning net new skills appear to be the focus of the majority of those efforts. Such activities typically do not help people achieve mastery of a concept in the way that practice does. Your boss would be skeptical if you asked to spend 97% of your time taking courses and practicing new skills.

The daily grind for most people is a strange combination of practice and game experience. Think of the cheesy movie scene where the unexperienced backup gets called into the game and has no idea what they are doing. Hilarity ensues as the rookie flubs the first few plays, and loses the game. That is kind of what happens in business. There are a lot of euphemisms for it – ‘getting thrown in the deep end of the pool,’ ‘learning by doing,’ ‘failing fast,’ etc. In the movies, the rookie usually figures it out and comes out on top, but that is less likely to be the case in a professional setting.

Many studies (here, here, here) show the value of practice in helping people be more prepared, have more confidence, and perform at a higher level. Malcolm Gladwell made huge waves with his theory on 10,000 hours being required to achieve mastery.

This all raises a few questions for me:

  1. What is the appropriate amount of time to dedicate to learning and development (practice)?
    – More than you are doing now. It is probably reasonable to expect 10-20% of your time overall, but the more the better. If your culture is not one that promotes learning and development, you must be vigilant about finding and acting on such opportunities yourself. Without them, you will languish.
  2. Assuming you get more time to practice, how should you allocate that time to practicing and refining existing skills vs. obtaining new ones?
    – Take on a mastery mindset for this question. Until you have mastered (you’ll have to figure out how to define mastery for the skills you have) your existing skills, I would be hesitant to add on any new skills. Once you have confidence you are approaching mastery, it would be a good time to start engaging on a new skill once you have mastered the former.
  3. With limited practice time, how do you manage to get practice while playing in the game, so to speak?
    – Minimize your risk. Don’t use your best lead to do your pitch for the first time. Be thoughtful about how and where you practice, so as to minimize the commercial risk if you mess up. You can even practice outside of work to further minimize your risk, but a lot of people would not want to invest that amount of time. How bad do you want it, right?
  4. As a manager, how do you make sure that your people are setup to succeed?
    – Acknowledging this issue is a great first step. Encourage your people to invest in themselves and take trainings, first focused on mastery of current skills, then expanding to find new skills to develop. Coach them to minimize their risks when they are practicing (see #3). Be forgiving of the mistakes they may make practicing in the game, as long as they learn from it. For new employees, do a great job onboarding them and getting them up to speed with your business.
  5. Is there just a flaw in the analogy between business and sports, such that the experience of practice does not have the same impact in business as it does in athletics or other disciplines?
    – Probably. A study of the concept of 10,000 hours to mastery indicate that the impact of deliberate practice on professional outcomes is only 1%. Analogies are usually a bad way to mentally model something (use first principles instead), but it’s easy, so people do it. This is really no different – it works in some cases, but not entirely.

So what does this all mean? In business, practice can still have big benefits for yourself, your team, or your organization. It is an investment, but like any other investment, it will take time to realize a return. You can perform just fine taking the traditional approach to combining practice and the game, but taking a deliberate approach to practicing is way to consistently and sustainably outperforming your peers.

Other good reads on the topic can be found here

Sticking to new habits is always hard.

I often find myself experimenting with new tactics to increase my learning, be more productive, or save myself time (so I can focus on more ‘valuable’ things). Notice, I don’t call them habits. They are deliberately experiments. Only if they prove effective would I continue to focus on them, ultimately with the goal to make them habits.

Over the years, the lack of feedback or data on how these experiments go has frustrated me. Self-improvement experiments are foggy and unquantified. It is easy to see how people lose the initial wave of enthusiasm they have when trying something new. There is also a significant perception/reality gap that is difficult to overcome. Over time, we lose track of just how much we have completed a task – maybe confusing our intention with what we achieved.

Recently, I came across from a Tim Ferris article. This is a simple, but powerful tool that allows me to track (and thus quantify) how often I am doing what I intended to do with my experiments. It lays bare the facts and busts through my interpretation of how I am doing. For anyone interested in getting quantified feedback on how they are doing, this is a great tool. It holds you accountable and creates a fun sense of self-competition as you get amped about checking things off.

Speed Wins

Speed wins. Startup dogma. Silicon Valley platitude. Dangerous concept that is often misinterpreted.

People hear this and think of the mythological developer who just cranks things out at lightning speed. Working all night, crushing Red Bulls, typing furiously on their laptop. There are many flaws with that mythology that I won’t go into here, but why does that mythology exist in the first place? Business executives are the reason.

When people think of speed (or slowness), people don’t think about is the business exec holding countless meetings with unclear objectives or agendas to discuss and review a potential decision. They don’t think about the countless people-hours spent in discussions. The ours of analysis that result in paralysis. Hell, it’s pretty common that people don’t know who is actually going to make the decision or what that decision even looks like.

There is an order of operations that is critical to the speed equation. Business must decide THEN the things can be built. Clear decisions must be made before the engineers can build anything of consequence, but all too often, people spend countless hours coming to a decision, if ever. The ugly result is that once a decision is FINALLY made, the engineers are then put into a thankless position where they need to deliver on unreasonable timelines, because the ‘business’ said so.  This is fundamentally flawed. Product folks need to fight this fight and maintain the line of chaos.

Business executives would be wise to understand their role in this problem and how they can help solve it. So, how can they help?

  1. Set a timeline for a decision and stick to it – you will never have enough information in
  2. Be clear who will make the decision – that doesn’t mean it has to be just one person. There are many ways to come to a decision
  3. If you must call a meeting to discuss, make it a meeting that doesn’t suck – set a clear agenda, invite only people who will contribute to the ability to make the decision
  4. Make a decision and be clear in communicating what it is – you can (and should) change your mind in the future, if you are presented with new information

Over time, if you follow some of these principles, you will be amazed at the impact it has on your company’s velocity – especially your engineering team(s).

As with any problem, the first step is to confront the truth, then own the problem, and ultimately figure out how to fix it. If you are a business exec who is not happy with the velocity of your team, especially your engineering team, make sure you are not the cause of the problem.

Other useful articles on the topic can be found here, here, here, and here.

Unbundled Consumers in Education

Education is a tough market to crack. One of the big reasons that it is such a difficult market is the unbundled consumer.

Typically, a consumer does one of three things. They decide to buy something, they then buy that thing, and they then consume that thing. Many things go into each one of those steps, but they are pretty universal. A customer will take them, in whatever form, and the result will drive a business forward.

Not in education. The consumer is unbundled.

In the example of textbooks, in particular. The professor decides what is bought. Financial aid (i.e. the government) or parents then pay for the book. Finally, the student is the one who consumes the book.

This is one of the big reasons why trade books have reached majority market share, while textbooks have lagged dramatically in the transition. Tech savvy entrepreneurs have pursued lots of the digital efforts, but all have ended in a resounding thud (at least so far), in large part because they have not understood this unique characteristic of the higher ed market. They generally targeted ‘consumers,’ not making the nuanced distinction to target just the decision making part of the ‘consumer.’

Maybe this is arrogance of technologists who believe that technology will ultimately rule the day and win in all markets. I don’t disagree with that notion, but it will take a lot more time in higher ed given the inertia of the sector and the unbundling of the decision making, payment, and consumption of the product.

Create a Real MVP

I hate weasel words. So many words get bastardized and misrepresented, especially in business, but it happens in politics, science, and other fields too. They become trendy. They become buzzwords. Companies feel they need to use these words or else they look like dummies. Guess what, most of the time when you use the terms incorrectly, you look like a complete dumbass.

Some of my favorites from the software / startup world…

“Platform” – your website is not a platform. It’s a website. Or maybe it’s an app. Unless other people can independently build whatever they want on top of your software, you are NOT a platform. Stop it.

“Disruptive” – everyone thinks they are disrupting things nowadays. Really? Giving people a new filter to put over their picture of dinner is not fucking disruptive. Poor Clay Christensen. I’m sure he had the best of intentions, but the jackals hijacked his concept. Now it’s meaningless.

The one I’m going to deep dive on today is “MVP.”

Thanks to Eric Ries and Steve Blank, everyone’s talking about MVP nowadays. However, in my observations, people are using it as an excuse to put crappy shit out there. MVP doesn’t mean it’s OK to be crappy. Your product still needs to be good. Most of all, it still needs to be valuable and meet whatever goal your user is trying to achieve. Otherwise, all you have done is spent money to “test” and make someone’s day worse. They’ll never get that time back from trying your sloppy product. Don’t do that to them. There is enough anguish in the world.

A better term would have been Minimal VALUABLE Product. I think that re-frames the context in the right way. What is the simplest, most straightforward way to create value for your user? Reframing the question in that way puts it all in perspective.

The team at Spotify has nailed this. Below is from a presentation given by XX that illustrates what an MVP really is.

Image credit:

It’s simple, but powerful. If your user’s goal is to go somewhere more quickly, you should maniacally focus on that. Even if you are the next Steve Jobs and can dream up the most badass sports car to serve that need, you have to start somewhere. You’re a lunatic if you think it’s best to spend 5 years building the dream of that sports car. Then you’re in waterfall hell with no shot at actually delivering the car on time, let alone managing the risk that what you dreamt up might not be what your user in 5 years may want.

Instead focus on the goal. Get somewhere more quickly. How would you do that. You wouldn’t start by giving them a tire. They can’t do anything with a tire, even if it might be a part of the end product.  Reframing leads you to think about the most straightforward way to get your user somewhere more quickly. So you build them a simple skateboard.

BOOM. You deliver value immediately and your user is delighted. They can get somewhere faster. Then you talk to the user and ask him what’s challenging him now. Oh, you hare a hard time balancing? Why don’t we add a little steering column. More value. Build, Test, Gather Feedback, Hypothesize, Repeat.

In five years you end up with a sports car. But now you have a user who is a huge advocate because they’ve been benefitting from your awesomeness for five whole years. Isn’t that awesome? I think so.

So, take off your black turtleneck and stop building sports cars. Reframe your problem around your user’s goals. Then think really hard about how you can meet that goal in the simplest, most straightforward way.

Other great articles on this topic can be found here, here and here