4 ms·

We now use Kanban on our team, after using Scrum for a couple years. Pointing is a process to discover unexpected hurdles or uncover hidden knowledge from cowo

We now use Kanban on our team, after using Scrum for a couple years. Pointing is a process to discover unexpected hurdles or uncover hidden knowledge from coworkers, and as a guideline. By not having sprints, you just focus on your current ticket, and not artificial deadlines or points. Tickets will be done when they are done, and managers don't have expectations of completeness that as disconnected from reality. We've added priority swim lanes to our process. We have a prioritization meeting with PMs every week to assign priority to tickets, order items in the high and medium priority lanes, and review blocked items to see if anything can be nudged back to a working column. The process is clear, the expectations are fluid, the work gets done in the time it needs to get done.

eli 10y ago
I'm considering a similar approach with my team. Any specific resources or books or tips you found especially helpful?
- jesalg 10y ago
  We use a similar approach in my company and the key here is to borrow the parts that work for your organization from Scrum and blend them with a much simpler Kanban approach. Don't follow a methodology blindly just because someone wrote a book about it. Keep evaluating & tweaking the process until you think it's at a point where it's working well for your organization.
lmm 10y ago
There's certainly a lot to like about that approach. But my experience is that it makes it very easy to end up with tickets that end up taking months (because there's no longer a natural point at which to stop and take stock), and/or accepting tickets that don't really have clearly defined acceptance criteria, which risks working on something that won't actually turn out to be useful. I don't like the artificial 2-week cadence of Scrum but I think I might still prefer it to not having one at all.
- a-priori 10y ago
  When I worked on a team like this, the rule was that when you came free and are looking for work, before you started any new stories you looked at the work in progress to see if you can help out to expedite any of it. The idea is that it's everyone's responsibility to try to minimize the work in progress (Lean). We also had the general expectation that one story should generally take no more than about two weeks. Before starting a story, if you think going in that it will be too big, then you try to limit the scope or defer parts of it into new stories until you're confident it can be done in two weeks. Once a week we tracked how long stories were in the "In progress" column, and once it'd been up there for three or four weeks, people started asking how they can help wrap it up. I think the longest I remember a story being in progress was about 6-7 weeks, and that was real uncomfortable for us. Typical times were 1-3 weeks. So we had a weekly cadence for demos, and product owners liked that they would see steady, regular progress rather than being inundated with sudden large dumps at sprint boundaries.
  - frandroid 10y ago
    Two weeks! Any story that takes more than 2 days is generally broken down into smaller stories. A two-week project is more like a small epic...
    - a-priori 10y ago
      Lots of teams have different expectations about how granular a user story should be, and some of this has to do with the project. How fast can you design, develop, test and deploy a meaningful amount of new content? One explanation for the longer time is that we had a process where for each user story we'd write a short, informal design document and send it to the team and stakeholders for review. For non-trivial stories we'd then meet to discuss them and come to a consensus about how to implement it. This probably added about a day or two to a story's duration, but it meant that we had a solid system at all time. It also often served a similar purpose to a retrospective, or produce topics for a retrospective, because these meetings would surface any technical debt and other impediments to progress. It also served as knowledge transfer and helped the team converge on design principles and expectations. So these meetings had a cost, but we felt it was essential for practicing agile design. We didn't find this made us slow to react. On the contrary, because this kept our technical debt low, and our software well designed and well understood by the whole team, it meant we could pivot on a dime. I think there's a real risk in going too fast. Maximum speed should not be the goal of a software development process, and I don't think any business really wants that. The two primary goals should be: 1) to make predictable, steady progress over long periods of time, and 2) the ability to change priorities as quickly as possible as new information emerges. If you have to sacrifice some speed to get there, it may be worthwhile.

eli 10y ago

I'm considering a similar approach with my team. Any specific resources or books or tips you found especially helpful?

jesalg 10y ago
We use a similar approach in my company and the key here is to borrow the parts that work for your organization from Scrum and blend them with a much simpler Kanban approach. Don't follow a methodology blindly just because someone wrote a book about it. Keep evaluating & tweaking the process until you think it's at a point where it's working well for your organization.

lmm 10y ago

There's certainly a lot to like about that approach. But my experience is that it makes it very easy to end up with tickets that end up taking months (because there's no longer a natural point at which to stop and take stock), and/or accepting tickets that don't really have clearly defined acceptance criteria, which risks working on something that won't actually turn out to be useful. I don't like the artificial 2-week cadence of Scrum but I think I might still prefer it to not having one at all.

a-priori 10y ago
When I worked on a team like this, the rule was that when you came free and are looking for work, before you started any new stories you looked at the work in progress to see if you can help out to expedite any of it. The idea is that it's everyone's responsibility to try to minimize the work in progress (Lean). We also had the general expectation that one story should generally take no more than about two weeks. Before starting a story, if you think going in that it will be too big, then you try to limit the scope or defer parts of it into new stories until you're confident it can be done in two weeks. Once a week we tracked how long stories were in the "In progress" column, and once it'd been up there for three or four weeks, people started asking how they can help wrap it up. I think the longest I remember a story being in progress was about 6-7 weeks, and that was real uncomfortable for us. Typical times were 1-3 weeks. So we had a weekly cadence for demos, and product owners liked that they would see steady, regular progress rather than being inundated with sudden large dumps at sprint boundaries.
- frandroid 10y ago
  Two weeks! Any story that takes more than 2 days is generally broken down into smaller stories. A two-week project is more like a small epic...
  - a-priori 10y ago
    Lots of teams have different expectations about how granular a user story should be, and some of this has to do with the project. How fast can you design, develop, test and deploy a meaningful amount of new content? One explanation for the longer time is that we had a process where for each user story we'd write a short, informal design document and send it to the team and stakeholders for review. For non-trivial stories we'd then meet to discuss them and come to a consensus about how to implement it. This probably added about a day or two to a story's duration, but it meant that we had a solid system at all time. It also often served a similar purpose to a retrospective, or produce topics for a retrospective, because these meetings would surface any technical debt and other impediments to progress. It also served as knowledge transfer and helped the team converge on design principles and expectations. So these meetings had a cost, but we felt it was essential for practicing agile design. We didn't find this made us slow to react. On the contrary, because this kept our technical debt low, and our software well designed and well understood by the whole team, it meant we could pivot on a dime. I think there's a real risk in going too fast. Maximum speed should not be the goal of a software development process, and I don't think any business really wants that. The two primary goals should be: 1) to make predictable, steady progress over long periods of time, and 2) the ability to change priorities as quickly as possible as new information emerges. If you have to sacrifice some speed to get there, it may be worthwhile.