[bdcravens]

I've found value in adopting bits and pieces. We have a small team (2 developers, sometimes more) and we're balancing bug fixes/customer needs/putting out fires/new development. Some guidance about where we're going and what we're walking on keeps us from focusing on the wrong things, but at the same time, when there's 2 developers you have to minimize overhead. I use a backlog and "sprints" (just a range of dates really). I assign points to have a bit of a clue (since I have to be able to answer what's on my plate and give some guidance as to when things may be completed). Nothing is sacrosanct: bugs get points the same as new development, since to the business it's all revenue blockers. A sprint is never carved in stone; any thing can be put in at any time, and priorities can be shifted, as they necessarily must. I don't do planning poker, standups, or retros ... daily communication via Slack is sufficient. We have no made up jobs like "scrum master". To me it's just a framework, in the same way that TDD or MVC are. You adopt pieces that help you get shit done, and ignore the pieces that get in the way of getting shit done.