It depends. The common answer. But the truth is that particularly in this situation it really depends on the team maturity level, environment, and industry. However, the most usual challenges that I’ve faced were the followings:
- Team rhythm adaptation to the new methodology while it still needs to keep the product development rolling out.
- Lack of procedures.
- Lack of structured planning and organized meetings.
- Difficulties on timing/effort estimation when doing the spring planning (= low level of experience/maturity inside the team).
The solution & answer for most of all these issues are Time and Routines.
Implementing proper procedures (e.g. daily stand up meetings every day at same time, no excuses) makes the team getting into routines and healthy habits. This consequently increases the team rhythm. And, motivation, because the results will be visible for all.
Most of the times this solves the topics 1 and 2.
For the points 3 and 4, I would recommend to start simple with the basics and then keep increasing your level of details, meetings, and Agile best practices once at the time. For instance, from a team that is not used to Agile, I would suggest to simply start by implementing:
- A. Daily stand up meetings > this will help everyone have a big picture what is being developed and what the blockers
- B. Sprint review & retrospective meeting (at the end of the sprint) > by defining a sprint time box duration (only to help you know when it starts and finish), in the end of the spring you can put your team inside a room and discuss the feelings of the past sprint in order for all of you have a sense of accomplishment and discuss what to continue (the positive things the team is already doing), what to stop (the wrong things/mistakes) and what to start (to be improved/wish list).
There are multiple methodologies that can be applied on these sprint retrospective meetings.
Having implemented this two simple steps (A and B), you need to implement another healthy habit and very important one:
- C. Sprint planning > these meetings are very important since they will define what the team will do (and must accomplish) during the sprint. A clear goal (or 1 or 2 most important task of the sprint) must be defined in order for the team have a clear notion of what needs to be accomplished. To have a productive meeting, the stories for each task requires to be clear and detailed (for this topics there are a lot of methodologies, my particular preferred one is JTBD).
After you have A, B and C in place congratulations, your team is doing Agile!
Go one level deeper
Now that you have the basics in place, your team is already doing the basics of Agile development, you can push a little forward and motivate yourself and your team mates to optimise your development process and implement a few other little things that will help (again, it always depends on each team) to optimize your team. Here are a few ideas where you can work on:
- Grooming sessions
- Measure team velocity
- Time box your sessions (in particular the daily stand ups)
- Team role playing
Despite all different opinions and interesting discussions around the difference between Agile and SCRUM or what’s the best methodology, in my opinion, the most important thing to save from here is that you should apply and test as many methodologies as you can.
Then see what suits better in your environment and team. And if you wish make an all-in-one cocktail with your favourite pieces from multiple methodologies.
At the end, everything is possible but you should test and see what works best because we are talking about People, so there is no one size fits all solution.
Did you agree? What other challenges did you face implementing Agile within your teams? And how have you surpassed those challenges?
Share your experience and insights. I’m looking forward reading it.