Background
With many organizations adopting some form of Lean development it becomes necessary that the team is aware of the changes required to move from one methodology to another. Here are some of the most common mistakes a team does while trying to adopt Agile methodology.
My experiences so far
In my opinion the most important thing that is needed for adopting Agile is the change in mentality at all levels right from a junior programmer / developer, tech lead, team lead, architect, project lead, manager and also the top management. Unless everybody realises the change in roles in a scrum team it becomes difficult to manage Agile teams. The 3 scrum roles of a Product Owner, Scrum Master and Team are very well documented.
In order to get the optimal output from the team there has to be a right mix of all the ingredients. Team size is most important. Assuming that the team follows pair programming there should be around 6-8 people in a team. More than 8 developers means more than 4 pairs which can cause communication problems. Less than 4 people will mean that there are less than 2 pairs. This can increase the technical debt.
Problems start arising if the team is not trained properly before starting the Agile development. People don’t realise common things which are the foundations of Agile development like self-organization, communication over processes, faster feedback etc.
I have seen on many occasions that in an Agile team estimates are given by one or two people rather than the whole team. This results in a situations where team members are forced to stretch beyond the regular working hours in order to complete the work.
Teams don’t take into account the velocity while planning for the next sprint. Scrum masters fail to take into account the capacity which results in over commitment. The team is not able to achieve its goal.
Team members are not aware of the complete list of tasks planned for the iteration as they do not discuss the tasks during iteration planning meeting. As a result the priorities are not clear and team ends up with wrong tasks completed at the end of the iteration.
Another common mistake I have seen is that people tend to go back to waterfall model the moment there is some impediment. The common example of this is people start working on individual tasks rather than pairing. This increases the technical debt within the team and the overhead is too much if this continues for too long as the knowledge is residing in silos.
Whenever there are stories added to the sprint in between after the sprint has started Scrum Master does not take enough measures to de-scope or reschedule some other story of the same magnitude which increases the workload of the team.
Developers often work on parallel tasks increasing the risk of having more than one item in half complete state at the end of the iteration. This can happen due to the definition of DONE not properly agreed between the product owner and the team.
Team members are not aware of how to use different set of matrices like velocity, sprint burndown chart etc. The factors which are responsible for measuring these matrices like the estimated efforts and the actual hours remaining to complete the tasks are not updated regularly. This results in inaccurate facts and figures.
An active involvement of the product owner is also very important for the success of the team. If the product owner can’t attend everyday standup meetings with the team at least he should be available for the Sprint Review, Retrospective and the Planning meetings. An early feedback from the product owner at the end of the iteration helps the team to deliver the right set of features. Inability to demonstrate the features developed during the sprint due to any reason increases the maintenance cost and can lead to major reworks at a later point.
Agile is all about improving with each sprint / iteration. People forget to take concrete actions on the issues discussed during the retrospective meetings. Without positive actions being taken there will not be a shippable product at the end of the sprint.
Conclusion
I always keep saying that Agile is change in mindset and also attitude to the way we develop software. Unless everyone involved is trained properly and understand the concepts and artefacts related to Agile methodology the success of the team is not guaranteed. If people follow Agile properly in most cases we can have a highly energized workplaces and a high performing teams. Unfortunately in most cases that is not the case and teams just struggle to deliver on time.
ReplyDeleteThe SBOK guide of scrumstudy.com will actually show how Scrum can be a very useful tool to keep organized and create better goals for your team. If all goes well, your team will gain a lot more focus and work more efficiently by using Agile Project Management in your Projects.
The SBOK guide of scrumstudy.com will actually show how Scrum can be a very useful tool to keep organized and create better goals for your team. If all goes well, your team will gain a lot more focus and work more efficiently by using Agile Project Management in your Projects.
ReplyDeleteI would say that a PMP Certification is highly respected within both IT & non-IT communities where strong project management skills are required. If you plan on a long term career as a project manager, then yes, even with your level of experience, I would suggest getting your PMP. You can prepare yourself for the exam in one of the PMP trainingproviders like PMstudy. You can do minimal prep-work to get 40 PMI® Contact Hours and apply to PMI for PMP Exam before the class begins.
ReplyDelete