Like said above, scrum is pretty straight forward. You write your requirements out, figure out the work required for each, break them into sprints of set time frames, and work to get all that you planned done. At the end is a product that should, in theory, have all of that work done which can be showed to the product owner/customer
Where I work we have....mixed adherence to various scrum principles. While we tried to get all the teams to do the exact same process, things started to fall apart depending on the project that it was being applied to. Our projects department, which builds off the shelf (ish) software, tends to get bogged down in contracts that require huge re-writes and almost no staffing. These teams have cut out a lot of the process (sprint retrospectives, reviews, and a few other things) to streamline our work to get things done so we can get paid.
The teams that work on a contract basis tend to follow most of the methodology and it works well for them. The key there is that the product has well defined requirements, a generous timeline, cost plus billing, and customers that also adhere to most of the same processes. Although I would run if someone ever comes to you and asks about using SAFe.
We use TFS and Visual Studio for pretty much everything, although Trello is used for some boards if the people are ambitious enough to duplicate the work.
I like some parts of scrum, detest others. Constant updates with team members keeps us aware of what is happening, and having a well written backlog of items to work on keeps the focus of the product and serves as documentation about what the thing should do. Almost every review and retrospective I have been in has been a waste of my life, but that could be due to a number of factors, including my hatred for meetings of any sort.
Feel free to message me if you want to talk about anything.
|