It is very natural that any organization that while transforming into Agile OR after the fact may have some regular challenges. Specially the people who are practicing and running show like “Scrum Masters”, “Agile Project Managers”. The purpose of this page is to put down all those challenges and write a workaround so that new or budding agile practitioners can read and apply the same at their work. A word of caution that as it is the solution may not work but think of it more from a framework OR a template and you can further customize. Nothing works like staying close to the Agile principles or values – so any of your action or solution shall remain in and around values and principles:
Here you go –
1. Daily stand-up calls going over 15 mins
This is a common challenge that pretty much every scrum master goes thru in a newly formed teams. If the team consist of software developers, testers, analysts, managers etc., then one of dealing with this is to note that you’ve been assigned a scrum master for the development team to start with and then run agile shop for the larger team. So going by this thought the SM during the daily stand-up ceremony call for the developers to start and then if the time is left then the other support functions or shared functions like analysts and other groups can chime in.
2. Too many people in stand-up calls
One way is to check with people who wouldn’t contribute anything to the ceremony itself and respectfully requesting them to stay out of the meeting so that we can keep a concise group. For e.g. functional managers, shared functions, shared resources who are only project specific may not be able to contribute on a daily basis, so it is best for the project to keep such of people out of the ceremony. Pl note that the SM has to reach out proactively to these people and explain to them both the ceremony importance and their perspective about the ceremony. Since all stakeholders are important for the agile to function normally.
3. Team sizes are too big to handle scrum process
One of the fundamental requirement is to have a team size of not more than 8-10 people per team. During the Agile transformation process the coach, SM or any other agile practitioners must convince the divisional head or the agile sponsor to agree to keep the team sizes low.
If the damage is already done, then over a period of time the efforts should be on to explain the factors around agile functioning to the agile sponsor or divisional head to divide larger teams to smaller ones.
4. Team members not cooperative enough to practice scrum process
One of the reasons why some people are somewhat against going Agile is because of their experience. The trait of people who have spent some good time in the organization and have become institutionalized with the years way of doing things or developing code or basically anything that relates to previous development methodologies. Coaching, Mentoring, One on one talks, Socializing and sometimes may be candid talks etc., may help resolve the issue. Over a period of time this becomes better, only if the Agile practitioners are putting their best effort to prove a few things to these people that Agile actually works OR you as a Agile practitioner can actually deliver something for the team. You will need to spend time understanding what are those things that the team really wants OR people have actually told you which are hampering their progress. Even if you resolve 1 or 2 issues out of those then you will see the change that they will actually start respecting you OR what you are trying to help them get over the agile change management bridge.
5. Team doesn’t believe in story points
The concept of story points itself is very new to the project management and specially when discussing the time or schedule of the effort. So its very important for Agile practitioners to very gently explain the concept and the method of using it for measuring velocity. Earlier we used to say “team has spent 160” hours this week, in Agile we say “team is doing 35 points worth of work sprint after sprint”. So you are comparing the same item called “work” from a new angle or view point. Why – because the challenge of hours as always been that we either bloat or do not provide near accurate number when putting that down in any formal document of Project Management. Hence, negative expectations or not meeting deadlines of the business owners results in overall dissatisfaction.
On another note, we are NOT completely removing the concept of hours even in Agile methodology. To say that we know that people are not paid by no of story points that they deliver. Also Story points is not an individual’s measure of work but overall development teams measure.
6. Retrospectives are not productive
One of the unique challenges that requires lot of courage and motivation to facilitate and execute. The challenges around not having a productive retrospective derives from situations that doesn’t help the team to be agile or be productive each day, each sprint. There are 3 dimensions to this issue. a) people b) not having enough or full conducive environment for agile c) not having enough continuous delivery and/or integration model
People issue can be solved by reaching out, real communication and mentoring.
Conducive environment for agile – must be a management issue. It is important that management understands the fact that setting mission, clear out objectives and directives and get away from the execution way for the team
Continuous integration/delivery model – again one of the issue that management can resolve. One of the core agile values or reasons why Agile exists is because continuous delivery of smaller chunks of software components for business users, getting feedback and redoing or deploying those approved ones.
Fix the above 3 and your retrospectives shall be very productive
7. Functional Managers still boss around
This is an issue that will be there to haunt the agile world for some time to come. Note that Agile immediately fits into a newly formed team. However agile transformation is a big challenge in larger organizations where are a TON of people involved in getting the product delivered or having one piece of functionality built. Many of the organizations like these have divided teams into various functions of work and have been doing that for many years. Each of these functional departments have functional heads, their deputes so on. Typically, Agile requires more power to the team that executes the work. Giving away that power from functional managers is a huge change management issue.
The solution could arrive from the mapping of roles from previous hierarchy to new roles of Agile organization. Agile practitioners must work with the management OR the Agile sponsor to align these roles and fit them into Product Managers or Product Owner OR some other value add positions that helps the teams who execute the work. Some organizations have started to address this issue, but many are still in realization mode.
8. Continuous Integration not there yet
The core of Agile delivery model is Continuous Integration. Lets try to understand what is CI. CI is a process of having the work done, integrate with several technical components of the enterprise software solution, running automated test scripts, getting the test results of pass/fail and communicating those results back to the team. For the team who think that their CI process is not there yet, means that of these workflow pieces is not aligned yet. For that that not or mis aligned piece must be retrospectively discussed, brought to the attention of the support teams who responsibility is to provide this CI piece to the team and agree on a timeline to provide it. So that’s the process side of it.
There is a element of tools that are put into use for this workflow. The support team has to spend and focus on using the right tools that are efficient and monies worth spent to augment to the CI flow or process
9. Teams not collocated
This is a common issue found in many organizations. Specially with the world is becoming flat and more teams are located in different geographical areas, this issue is not going away anytime soon.
Instead – lets just under there are 3 issue:
a) Virtual teams having some over lap ~ 2-3 hours
- Daily stand ups should not become an issue since the ceremony can be scheduled during the common hour
- Other sprint ceremonies can become a little tricky to schedule since duration required is min 2-4 hours of planning, review, demos etc.,
b) Virtual teams having more over lap ~ 4-6 hours
- Absolutely no issues in hosting the daily stand-up or for that matter any other scrum ceremonies since there is a good overlap time of more than few hours
- Working together can become an issue so lets not try to fix something that is not fixable
c) Virtual teams with absolutely no over lap
- Any ceremony or meeting scheduling can become an issue
- Unless and until both the locations put a point of contact from each region to handle the communication and coordination of efforts
- Other ceremonies like review, demo, retrospectives can become a hurdle. So it is upto the teams on either regions to come up with a schedule that has some overlap. Specially when this occurs once every 2 weeks, so it should not become a big hurdle
Try fitting your issues into one of these buckets and then try to come up with a strategy to address the issue of communication, working together, meetings together etc.,
10. Swarming of tasks
This is one of the important items that the team needs to address as part of the teams agreement. During the sprint if any team member is either done with the self assigned tasks or stories, there is no harm in either helping others or taking over some of the tasks/stories from other team members. There will be occurrences where a team member may need a push or little help from other experienced/tenured/experienced/subject matter expert in the team to finish a task or a story during the sprint. Team members should understand it is OK and should help each other to handover tasks/stories and the appropriate knowledge that is required to complete the work.
The agile practitioners should protect the team from sending out a incorrect signal externally.