Scrum - Strengths & Challenges

Scrum is a project management framework that is mostly used for software development. It builds upon continuous iteration of predefined processes - planning, development, feedback.

If you search for it, you will get thousands of writings on scrum. I would like to share about what are the pros (strengths) and cons (challenges), and how to deal with the challenges.

Strengths
1. Has built-in communication process - the planning and daily stand-up meetings. This forces and ensures the team is aware of everything that is happening. Continuous communication is key to a project's success.

2. Shippable deliverable. This is really a good one. Most of the time the customer are not really clear of what is needed. But along the way when everyone sees a working product, they can tell if that's what they want or not. This is similar to prototyping. But prototyping can be just on paper or screen design and may not be good enough for customer to see what he/she will eventually get. Thus ship-able products is really a working prototype that customers can use and validate.

3. Scrum expects team members to have multiple skills - design, coding, testing, writing user stories etc. The skills acquired will make a scrum team member to be able to contribute actively in future projects and any kind of discussion. It will also improve their communication skills.

4. Lean product backlog and sprint backlog management. Forced ranking and delaying the detailing of a requirement still we reach it are the 2 methods that I find very useful and believe makes scrum a lean project management framework.

5. Clearly defined user story format :-).

Challenges
1. Meetings are time-boxed. Its good to ensure we are focused. However, there may be more things to discuss and clarify especially during the start of the project or start of a sprint. Limiting time may result in some important discussion & agreements is missed. "After meeting" discussions or unofficial meetings between a few members may result in some members not aware of some of the things.

Possible solution:- I suggest, we use bigger time box in the beginning. Or better still don't time box the first daily meeting. But strive to eventually bring it down to the recommended 15 minutes along the way.

2. It assumes most or all impediments can be resolved in 1 day. What if there are impediments that can't be resolved during that sprint ? It may result in the task or backlog not done. The scrum will be busy but what happens to the developer who took up the task? He/she may end up being "free" as in scrum there is no planning/prioritization during sprint. It assumes all the agreed tasks can be completed during the sprint whether it is a 2 weeks sprint or 1 month sprint.

Possible solution:- I would suggest to have a "stretch goal". That means identifying a few additional items in the sprint backlog. They should be classified as "non-committal". The team should only look at them if for whatever reason they are not able to work on the other committed items. This creates a much more agile situation.

3. In scrum, the Product Owner is the key decision maker with regards to requirements (product backlog) and its prioritization. In scrum, the Product Owner is the ONLY key decision maker on requirements and prioritization. He/She is expected to provide instant answers during sprint planning. But in real scenarios, the Product Owner may just be representing the "requirements team" who is talking to their own customers. Unless the Product Owner has full and complete knowledge of all the requirements, which is a rare case, he/she will not be able to provide accurate and instant answers to the team members. This situation will cause some delays in the team's progress.

Possible solution:- During backlog refinement meeting and sprint planning, Product Owner should be allowed to bring along a few other members. However, their roles should be limited to providing clarification. The Product Owner should still be the decision maker on prioritization. In this way, we can clarify matters faster. After a few sprints, the Product Owner (and the team) will have much better understanding and should be able to clarify and make decisions without the involvement of other members. Of course, in both cases, the Product Owner should continuously engage his/her requirements team to be on top of the requirements and so that he/she should be able provide clarity on the backlogs.

4. Some organizations are very operational in nature. They do not have dedicated project teams working on software development projects. Since operational support is always the number one priority for most organizations, it is going to be very difficult to assign a few members to be spending full time on a software development project as demanded in scrum. Sometimes there is no one who can support a system better than the team member. Sometimes his/her partner may be out on vacation or unplanned/emergency leave.

Possible solution: Having shorter sprint cycles (such as 2 weeks) may actually help. The person can be away for 1 sprint and join back the team in the next sprint after having the issue addressed or his/hear partner back to work. Having shorter sprints can also help in a situation whereby rotation of duties is practiced. However, changing of team members will increase the time for them to familiarize themselves with each other and take longer time to reach the performing stage (based on Tuckman Model).

5. Effort estimation depends on each team members skill set, experience and familiarity with the system. Different estimates may be given due to lack of skill set rather than lack of understanding. Junior team member may be feel uncomfortable providing estimates.  Different estimates may also arise if the developers have different approach in mind. Sometimes both approach may have its own pros and cons.

Possible solutions: During estimation, team members should describe not only why they estimate so but also explain briefly how they would develop the solution for the user story. This will help the team to understand why is the estimation being made so.