4 ms·

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy writ

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.

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
humanrebar 10y ago
Describing drawbacks and problems is value added. Theoretical physicists regularly know about problems for decades before solutions are found. Precisely describing the problem can get the intelligent diaspora organized around finding improvements to the situation.
- stevesun21 10y ago
  Did you just compare a project management methodology with theoretical physics? Sounds to me like you try to compare apple with orange. Sorry, I don't follow you.
  - humanrebar 10y ago
    I came up with an example of where problem descriptions were useful. A more relevant example would be The Mythical Man-Month. In many ways, agile and scrum are iterations on solving that problem: project-based knowledge work is hard to estimate and challenging to scale in certain ways.
  - rimantas 10y ago
    He did just compare problem solving with problem solving. Sweeping problems under the carpet does not get them solved.
- davnicwil 10y ago
  Yes, thank you. The attitude of 'you may not describe a problem without already having prepared specific, actionable solutions to it' is limiting and only really appropriate in situations where time comes at a very high premium generally, i.e. meetings and such, or the value of actually solving the problem is too low wrt time spent coming up with solutions. In almost every other situation, writing articles on the internet included, simply describing perceived problems so that you and others may consider solutions to them immediately or at a later time is extremely valuable, and is a necessary (but insufficient) condition of progress being made.
SyneRyder 10y ago
He makes suggestions at the end, in the section "Ideas for Alternatives", after the sentence "The default answer to any substantial criticism is "What is your alternative?"" In summary, he suggests eliminating the review, planning and stand-up meetings (replacing them with asynchronous & as-required meetings), increasing the frequency of retrospectives, and spending time analyzing the backlog to see what the underlying causes are and tackling those.
UK-AL 10y ago
Honestly, if you can get away with it Kanban + NoEstimates + Continual Releases. Scrum becomes useful when you are required to plan(or attempt to) schedules for certain features far in advance.

After I read this complain-based article, my only question for this author is what's your fix/suggestion? Otherwise, I don't get what the point of this guy write this article.

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

humanrebar 10y ago

Describing drawbacks and problems is value added. Theoretical physicists regularly know about problems for decades before solutions are found. Precisely describing the problem can get the intelligent diaspora organized around finding improvements to the situation.

stevesun21 10y ago
Did you just compare a project management methodology with theoretical physics? Sounds to me like you try to compare apple with orange. Sorry, I don't follow you.
- humanrebar 10y ago
  I came up with an example of where problem descriptions were useful. A more relevant example would be The Mythical Man-Month. In many ways, agile and scrum are iterations on solving that problem: project-based knowledge work is hard to estimate and challenging to scale in certain ways.
- rimantas 10y ago
  He did just compare problem solving with problem solving. Sweeping problems under the carpet does not get them solved.
davnicwil 10y ago
Yes, thank you. The attitude of 'you may not describe a problem without already having prepared specific, actionable solutions to it' is limiting and only really appropriate in situations where time comes at a very high premium generally, i.e. meetings and such, or the value of actually solving the problem is too low wrt time spent coming up with solutions. In almost every other situation, writing articles on the internet included, simply describing perceived problems so that you and others may consider solutions to them immediately or at a later time is extremely valuable, and is a necessary (but insufficient) condition of progress being made.

SyneRyder 10y ago

He makes suggestions at the end, in the section "Ideas for Alternatives", after the sentence "The default answer to any substantial criticism is "What is your alternative?"" In summary, he suggests eliminating the review, planning and stand-up meetings (replacing them with asynchronous & as-required meetings), increasing the frequency of retrospectives, and spending time analyzing the backlog to see what the underlying causes are and tackling those.

UK-AL 10y ago

Honestly, if you can get away with it Kanban + NoEstimates + Continual Releases. Scrum becomes useful when you are required to plan(or attempt to) schedules for certain features far in advance.