11–20 of 20 posts
I love the UI. Clean, focused, and specifically tailored to scrum. I think sprints enforced by the interface is critical to keep management on track. The companies I worked at which used Asana, Trello, or free-form task lists were a mess. It was maddening not having a single schedule.
Earlier quoted context omitted.
The page is too light on details. What is different about this vs the hundreds of alternatives out there? Why would I switch from a different product? How do I know if I'm your target buyer?
Just put the page together this week. Will be adding more detail to it. The idea is to get away from the kanban board look and to help you track your sprint flow. Capture standup notes, sprint planning notes, manage backlog more effectively. I just wanted to see if there was interest. Looks like there is. That's awesome. I'll spend some time this week adding more details to the page.
Can you say why? Kanban is literally the only thing I like about capital-A Agile. I doubt either of will convince the other to change our minds. But in the interest of helping you refine what you’re building and how you communicate it, articulating what you don’t want is valuable too.
Why does so much effort go into tracking and managing programmers? Does the customer care? Does it actually improve quality or delivery? Is it really any better than just letting people work?
It is more a power play by the "Management" rather than satisfying any actual need. While some amount of management and issue/time tracking is necessary the intense focus on the same by Agile/Scrum is useless and counter-productive.
Earlier quoted context omitted.
Just put the page together this week. Will be adding more detail to it. The idea is to get away from the kanban board look and to help you track your sprint flow. Capture standup notes, sprint planning notes, manage backlog more effectively. I just wanted to see if there was interest. Looks like there is. That's awesome. I'll spend some time this week adding more details to the page.
> The idea is to get away from the kanban board look and to help you track your sprint flow. Can you say why? Kanban is literally the only thing I like about capital-A Agile. I doubt either of will convince the other to change our minds. But in the interest of helping you refine what you’re building and how you communicate it, articulating what you don’t want is valuable too.
I've been doing project management for a over a decade now and from my experience, and interviewing people, reading, I realized that people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more done.
So that's the primary idea behind it.
Why does so much effort go into tracking and managing programmers? Does the customer care? Does it actually improve quality or delivery? Is it really any better than just letting people work?
To be fair, they do not care about any specific individual developer. And I don't bother tracking individual dev performance. I track the overall delivery cadence.
Where I do care about individual developers is knowing how much they stay on-task. My teams vary from someone who will always do exactly what is outlined in the ticket, to people who second-guess and redesign the work (sometimes for the better, sometimes not), to people who go off the rails and design grand future visions that we then need to scale back to reality.
All of those people have value, but I need to manage their working style to the short-term business needs when planning upcoming work - sometimes I can let them fly free, sometimes I just need someone to put a freaking button on the screen and ship it.
So yes, it matters... micro-managing is pointless, but high level tracking helps set the correct pace of delivery.
Earlier quoted context omitted.
> The idea is to get away from the kanban board look and to help you track your sprint flow. Can you say why? Kanban is literally the only thing I like about capital-A Agile. I doubt either of will convince the other to change our minds. But in the interest of helping you refine what you’re building and how you communicate it, articulating what you don’t want is valuable too.
Originally Kanban was designed to visually track inventory. It is useful in that context because you could easily spot the items that need refilling. I've been doing project management for a over a decade now and from my experience, and interviewing people, reading, I realized that people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more…
You’re saying Kanban was designed to track inventory. I think that’s true but not completely accurate. It was designed to track work and inventory together.
> people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more done.
I’m so confused! This is exactly what Kanban is supposed to be. It’s not supposed to be anything more than that, or less.
Where did the bad PM Jira you?
Earlier quoted context omitted.
Originally Kanban was designed to visually track inventory. It is useful in that context because you could easily spot the items that need refilling. I've been doing project management for a over a decade now and from my experience, and interviewing people, reading, I realized that people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more…
Thanks for the response. I’m more confused than when I started. You’re saying Kanban was designed to track inventory. I think that’s true but not completely accurate. It was designed to track work and inventory together. > people work best in lists. Top to bottom, most important tasks at the top, least important at the bottom. It helps us focus and get more done. I’m so confused! This is exactly what Kanban is suppos…
As a process for tracking work, it is lacking for a number of reasons. There is too much information on the board at any one time. It is too open, meaning, you can create as many columns as you need, which leads to unnecessary complexity.
Finally, the Kanban system works well for moving physical items (completed items) from one station to next. It is not used for changing states of items. We use it to change state on incomplete tasks (i.e from Blocked to Todo to Inprogress), which not what Kanban is for.