Blog

After accepting the Agile methodology through managing a project and experiencing its benefits, I wanted to take the opportunity to share some of the challenges I've faced and lessons I've learned along the way.

 

First and foremost, managing a project without fully validating the initial list of user stories can cause a domino effect of hurdles to jump over later on. Even though the product backlog is a living document and user stories are added/modified all the time, there is a fair amount of work that must be done in preparation for that first sprint. For example, there will be work needed to procure any needed hardware, software, and setting up environments. There will also be some work required to understand the technical framework and the developers will need to have access to get started.  If this isn’t figured out in the beginning, the team can end up moving in circles trying to resolve these issues; which, in turn, can impact the progress of sprint planning, not to mention can waste time and money for both the customer and your project team.

 

Second, the product owner must, and I mean must be 100% committed to the project. Anything less is a recipe for disaster. You don’t want to end up working in a vacuum with no response, feedback, or attention. The project manager must make every effort to engage with a person from the client side for the constant feedback, however, the client must also be committed to doing the work required. This involves much more than simply attending sprint meetings. The product owner's responsibilities include the following:

 

·       Must be the primary decision maker;

 

·       Help the development team with any roadblocks;

 

·       Prioritize the backlog; and

 

·       Approve the development work completed for the sprint (to list a few).

 

One must remember that by the time of the sprint review, the product owner has already seen the functionality for each of the user stories and has agreed that they’re complete. It’s not only important for someone to be dedicated as the product owner, but it has to be someone that truly understands the project’s end goal in order to be able to tie the work being done into the overall vision. Most customers think this is extremely time-consuming, but they must make it a priority in order to ensure the project is running smoothly and efficiently.

 

Lastly, the daily scrum meeting is not used as a problem solving or issue resolution meeting. I can’t emphasize this enough. During the daily scrum, each team member answers the following three questions:

 

1.     What did you do yesterday?

 

2.     What will you do today?

 

3.     Are there any items preventing you from doing your work?

 

And that’s about it.  Any issues raised during the meeting must be taken offline and usually dealt with by the relevant subgroup immediately after the meeting.  Only those required to solve the issues should join that meeting. Also, try to avoid changing the time of the daily scrum meeting, unless its an emergency, in order to maintain a consistent routine with your project team. It would be beneficial to set these expectations with the team before the scrum call begins.  Keep in mind that the goal of the daily scrum is establishing the context of the day’s work and gaining an understanding of how far the team is progressing towards the sprint goal. It is not intended as a status report. It is the responsibility of the Scrum Master to ensure the daily scrum meeting is kept short (usually 15 minutes) and the discussions are kept to a minimum.

 

Agile can be tricky, especially if the team isn’t used to working in such a way. There will be bumps along the road especially during the first few projects and within these projects, with the first few sprints. It’s a constant learning process, hence why you must hold a retrospective meeting that allows the team to discuss what didn’t work and what worked best. You want to continuously evolve and improve. I now know how I can prepare the team and avoid these challenges in the future.