4 ms·

Deconstruct Scrum and perhaps something like RUP/DAD (Scrum doesn't tackle the whole lifecycle) into components and understand what the purpose of each componen

by blub 10y ago

Deconstruct Scrum and perhaps something like RUP/DAD (Scrum doesn't tackle the whole lifecycle) into components and understand what the purpose of each component is. Start from Kanban and add stuff until you get a process that matches the critieria of the organisation. This requires a lot of skill though, so many teams are stuck with one-size-fits-all tools like Scrum, especially now that it's become a management buzzword. And it does a not too bad job at delivering somehing of passable quality not too late. :)

stevesun21 10y ago
I have been two different org, one use scrum and one use kanban, working in the team apply kanban was feel like a sunny afternoon in a park - you lose the awareness of time, and just want to lay back and work on few things for long time, but suddenly your manager told you there is a timeline, no one knows until your CEO keep ask (yep, a startup).
- blub 10y ago
  A Kanban board should be customized by the team to help them achieve their goals. e.g: if timelines are important, a due date should probably be added to the tasks/post-its. Assuming some tasks are more urgent than others, the todo column should be sorted, or tasks could be assigned priorieties. Adding a limit to the done column which triggers an event like a retrospective/celebration can help avoid the feeling of an endless grind.
dkersten 10y ago
Instead of inventing my own system, I would go with the (rather new) GROWS Method[1], which is designed to be adapted to suit your needs (but only after a certain level of experience is gained). GROWS splits its components into stages, through which your team progresses as they become experienced with the various practices. The stages are: Stage 1 is very simple and easy and about getting your team setup on good practices (eg source control). At this stage, you should be following it rigidly. Stage 2 is about making sure the right people are working on the right things at the right time. A rigid but simple agile-development system. Stage 3 is about applying judgement and critical thinking to stage 2, adding release planning, retrospectives and other plan-and-feedback practices Stage 4 is the stage where your team is experienced enough to tune and alter the practices so that they work best for your unique situation Stage 5 is when you're ready to replicate your teams practices for other teams or environments. I like it because it acknowledges that no one-size-fits-all system can be perfect for everyone and provides a framework that allows itself to be changed, but does so around a "skills model" to prevent premature change. "This requires a lot of skill though" Exactly. Which, in my experience, most teams do not have. All too often have I been in a team practicing some form of agile, but they don't like X and would prefer Y and so they change the framework to suit their needs and then it fails and they blame the framework, saying it doesn't work, when in reality what happened is they changed and broke it, because they are not (yet!) experienced enough in that framework to actually tweak it to their needs. GROWS is designed with this in mind. [1] growsmethod.com

by blub 10y ago

stevesun21 10y ago

I have been two different org, one use scrum and one use kanban, working in the team apply kanban was feel like a sunny afternoon in a park - you lose the awareness of time, and just want to lay back and work on few things for long time, but suddenly your manager told you there is a timeline, no one knows until your CEO keep ask (yep, a startup).

blub 10y ago
A Kanban board should be customized by the team to help them achieve their goals. e.g: if timelines are important, a due date should probably be added to the tasks/post-its. Assuming some tasks are more urgent than others, the todo column should be sorted, or tasks could be assigned priorieties. Adding a limit to the done column which triggers an event like a retrospective/celebration can help avoid the feeling of an endless grind.

dkersten 10y ago

Instead of inventing my own system, I would go with the (rather new) GROWS Method[1], which is designed to be adapted to suit your needs (but only after a certain level of experience is gained). GROWS splits its components into stages, through which your team progresses as they become experienced with the various practices. The stages are: Stage 1 is very simple and easy and about getting your team setup on good practices (eg source control). At this stage, you should be following it rigidly. Stage 2 is about making sure the right people are working on the right things at the right time. A rigid but simple agile-development system. Stage 3 is about applying judgement and critical thinking to stage 2, adding release planning, retrospectives and other plan-and-feedback practices Stage 4 is the stage where your team is experienced enough to tune and alter the practices so that they work best for your unique situation Stage 5 is when you're ready to replicate your teams practices for other teams or environments. I like it because it acknowledges that no one-size-fits-all system can be perfect for everyone and provides a framework that allows itself to be changed, but does so around a "skills model" to prevent premature change. "This requires a lot of skill though" Exactly. Which, in my experience, most teams do not have. All too often have I been in a team practicing some form of agile, but they don't like X and would prefer Y and so they change the framework to suit their needs and then it fails and they blame the framework, saying it doesn't work, when in reality what happened is they changed and broke it, because they are not (yet!) experienced enough in that framework to actually tweak it to their needs. GROWS is designed with this in mind. [1] growsmethod.com