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:


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:

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

Kill your email

Communication is the lifeblood of a business. Without it, there is confusion, misalignment, wasted effort, missed opportunities, poor performance, and failure. Email revolutionized communications. Email reduced the time to communicate AND increased information density at the same time. The ROI on those simultaneous improvements to communication was incomparable. Rapid adoption ensued and everyone became glued to their email.

As with most technologies, and the innovations that disrupt them, email reached (a long time ago) a mature state. We are now entering a post-email age. New forms of communication are emerging that push the boundaries to an even more efficient frontier.

Email suffers from some significant shortcomings that are no longer justified in the face of new solutions. There are now solutions, from Trello to Slack to Basecamp, that better optimize both variables of the ROI.

What does this mean for you?

Try to move all your communications off of email. That might sound crazy, but just try it. Especially if you are a PM.

Encourage face to face interactions when there is a need for synchronous information exchanges. Face to face will always will be the best form of communication. Use new tools when there is a need for asynchronous information exchanges.

We are currently experimenting with some new processes where email is not allowed. The early results are positive. Stakeholders are more active participants. They are providing better information, faster. They have more clarity of thought.

But, why is that?

My hypothesis is that email has become a crutch. Response time often comes at the expense of a thoughtful response. By changing the medium, it forces people to take a bit more time and organize their thoughts. The end result is that the communication is more information rich and actionable. The information is more dense, but the amount of time it took to communicate (using the new tools) is equal to that of email. Thus, the ROI is better on that new form of communication, when compared to email.

Plus, no longer being a slave to your inbox is amazing. At first, you are anxious because you don’t have a ton of email – but then you realize – that’s the point. You and your team will be more productive. Stakeholders are better equipped with the info they need. And you can finally start doing all that work that has piled up because you had been spending so much time responding to emails!

What do you think? Give it a shot and let me know how it goes.

Product Owner Skills

We are now about five months into our transition to Scrum. Embarking on the experience as a Product Owner has been awesome. I recently came across a useful graphic that outlines the skills (and there are many) that make a good product owner.

Credit to

This is a good summary. I would add Authority to the chart (but that messes up the layout of the poster, so I’m sure the creator had to make some hard decisions).  Authority is a more nuanced form of leadership, in my opinion, but it is important to call it out on its own. Authority comes from your domain expertise, and the way you carry yourself with the dev team and the rest of the organization. You earn this, you don’t just ‘have it.’ It’s a hard thing to master, but it is instrumental to your success as a PO.