Scrum does not work for me, any other option?
Scrum does not work for me, any other option?
In the organization I currently work, we are not only having big projects to be done. We also have tons of Business As Usual (BAU) requests to deal with, enhancements, error fixing, ‘super important’ changes, etc.
In my opinion, Scrum will not work in above activities.
Read more at: http://www.ru-rocker.com/2017/03/18/kanban-as-another-option/
#agile #it #informationtechnology #projectmanager #projectmanagement #kanban #scrum #scrummaster #atlassian #rurocker
Thanks for sharing! Kanban can be very useful and I have my own Kanban board to keep myself organized on my personal tasks. I've personally found it to be an extremely effective tracking mechanism. You could even combine the two, and use Kanban to track work within a sprint.
Coming from a traditional project management background, Kanban is easier to adapt to because it doesn't require a process change; just a workload change. Scrum is hard because it's an entirely different process. That process has value but comes with a lot of overhead. Not every organization or client is willing to put things on hold and pay that overhead up front.
Most importantly, I'd say your work and team structures should dictate the best agile methods for your team. Scrum works best when you have a fixed team and variable work within a central objective. If you have lots of random unplanned work, or constantly changing teams, Scrum is going to become difficult to implement effectively, and other methods start to stand out.
However, it sounds like your main concerns are that tasks require quick turn around, and that your client/product owner is being indecisive and ineffective at prioritizing tasks. Both of these could be handled within Scrum, with the proper training and process adjustments. I'd be curious to know if a 1-week or 2-week sprint would work much better for your BAU tasks.
Hi jason,
Yes, I agree. Proper training and proper adjustments will definitely needed for Scrum.
As per BAU, mostly the changes will take only 1 or 2 weeks, so if we treat them as scrum, only take 1 sprint.
So I think that will be too much to be prepared if we treat those as scrum.
Unless we group some related changes and fixing together and put those in the product backlog.
IMHO
If you choose to go with it, Kanban still requires prioritization and enforces Work In Progress (WIP) limits. It is a great way to inspect and adapt current processes, visualize and prioritize work to be completed, and expose the impact that "business as usual" has.
Releasing a Done (complete, tested, quality) Increments is the way of Scrum. Basing a Sprint length off of business expectations is likely to result in heartache for all. If the organization isn't willing and ready to support adoption of the Scrum framework, then it might be best to table those thoughts for the future.
Hi Alan
Yes, whatever the way of Agile we're taking, Organization's willingness to adapt Agile is still very important.