What do you like and what do you dislike about the fight?
I'm on a team that uses scrum for our development process. We are currently trying to update some aspects of our process to address some of the issues that we have noticed recently. In doing so, we explore what we like about the scrum as a whole and what we don't like to help us define what we value as a team in our work. We believe that if we can define what we value, then we can come up with implementations that revolve around values to help new solutions enter the team.
With that said, I'm really interested in how other people view the scrum process. What did you really like? What was frustrating and felt like too much overhead or overhead? Concrete examples of successes and failures are great, but I'm interested in a much larger view where the discussion revolves around scrum pitfalls or where scrum really shines.
Thoughts?
source to share
This is a pretty broad question! Here's my take.
I think Scrum is really good at teaching to make organizations love agile / iterative / incremental / lean software development. For a company that has used a project management and management hierarchy, the empowerment teams need to successfully adapt to their customers' needs is a massive cultural shift. Scrum makes all of this available to organizations with clearly defined roles and processes.
Basically, for me, he buys a team of programmers in the space they need in all the politics and bureaucracy of a large company in order to keep making XP.
However, with this power comes responsibility. Scrum doesn't require any XP technical solutions, but without basic practices like CI, TDD and refactoring, any scrum team will stop after a few iterations. I personally think it is completely irresponsible for this not to be explicit in the scrum rules, and that would be one of my criticisms.
My other criticism is with task cards and task scheduling. I have yet to see the team where this was really effective: there is usually a very tiring day when you try to think through everything that you will be doing throughout the iteration, then you will go and find that you really need to do something else. Measuring progress through task burning is a good way to get teams to collaborate and connect (especially if you relinquish task ownership), but ultimately it's not a reliable way to track team progress.
I pay a lot more attention to the burnout of meanings or plot points, and these days usually the team gets a daily update of the big cumulative flow chart where we sit with it. Tasks stay on the public to make lists, but they don't go to the board or be managed by anyone.
Retrospective is a key practice, of course. Mike Cohn contradicts my previous point about XP practices is that, in retrospect, teams will eventually reinvent / implement XP, and that has some value. Of course, regular introspection is the best way to make sure your team is as effective as possible.
source to share
I think in my experience the key is understanding how those in business and management prefer to implement parts of Scrum and / or Agile, or in other words, their interpretation of keywords.
I love the idea of daily parking lots where everyone says what they did yesterday, what they are going to do today, and what checkpoints they have, as this creates accountability, assuming there is respect and honor for lack of a better term. to say it.
Challenge maps and their evolution can be useful for others to see what's going on, as well as for someone to figure out if they have something nailed down. Maps do something to their channel of communication, which can be good or bad depending on how you view it.
Flashbacks and iteration planning sessions are usually useful as a way to get everyone on the same page, as well as provide feedback on the process to help improve it, no matter who sees it. Having a good leader is important here, I think, because these meetings can be less productive if the team is going on a tangent or two.
I find retrospectives very similar to the posthumous ones I had in my previous job. I find they are very useful for several things:
-
Seeing what others think is usually good or bad. Checked out the big problem? New employees arrived when it was only 2 weeks or less in the project useful or not?
-
Lets everyone speak. This can foster affiliation and teamwork, which can be beneficial for times when you want someone to burn midnight oil or work late here and there.
There is a problem with the daily stances being quick, but with some practice it becomes more natural. To some extent, the process around Scrum can reinforce good habits and bad habits, depending on how it is used.
source to share