The research to find the minimum set of Agile practice that you can use in any project type came as a necessity for me. In the past I tried several methodologies pretty much by the book, but the reality of the projects made most of them not to fit perfectly.
Most of the encountered issues were caused by contract types, dependencies with other project teams, remote teams or customers commitment for the project deliverables.
Because of these issues, I started to find out what’s the sweet spot of Agile project management practice that I can use in any project type, regardless of technology and regardless of the customer knowledge about project management.
Here’s the list of Agile practices that I’ve come up with:
Nowadays, I guess this meeting type is the norm for every project manager. No matter what are the project constrains, this meeting has to happen on a daily basis.
The project manager needs to be very careful to keep this meeting as short as possible: 15 minutes in average. One good reason for this would be the costs of such a meeting. If you keep 10 members in a one hour meeting, then you spent in total 10 hours from the project total time. This is valuable time that can be used elsewhere. Complex issues must be discussed in private.
Agile boards are the best ways of having a visual representation of your sprint currently in progress.
You can have it on a whiteboard or on JIRA, in case of remote teams. The type of the Agile Board doesn’t really matter too much. It’s up to the project manager to choose what’s the most conformable to use (e.g. Scrum vs. Kanban).
Retrospective and Iteration Planning Meetings.
I’ve combined this together because it seems natural for me to discuss first the good and the bad from the previous iteration and then to use that to plan the next one.
I recommend not to have this meeting on Fridays because I noticed the team usually thinks more on Weekend sprint rather than the project sprint.
During this meeting, you can as well do the backlog prioritization.
Even though the customer may not be proactive in requesting information about the current status of the project, that doesn’t mean you shouldn’t do development in sprints.
As long as you constantly deliver value with every sprint to the customer, you should have no reason not to do this.
Organize efforts into Features, Themes, Epics and User Stories.
I believe this is good to adopt for the sake of having the right Agile vocabulary for your team. However, this is sometimes not possible because of internal policies.
As an example on how to organize the efforts, let’s split the shopping cart functionality of an e-commerce project:
- Feature: Shopping Cart
- Theme: Step 1 – Add Products to Shopping Cart
- Epic: Promotions Integration.
- User Story: Implement promotion for getting free shipping after x amount ordered.
Continuous Integration Environments
For me, continuous delivery is the essence of Agile development. A continuous integration environment provides some of the following benefits:
- Faster detection of development related issues.
- Possibility to enable automation testing on the staging environment.
- Have a better distinction between software builds and software releases.
This is the list of Agile elements that I found so far to work seamlessly in my environment. Of course, this list will be under constant assessment over time for what’s good or bad and what can be added or removed.
Please let me know in the comments section what’s your list of agile management elements that helps you deliver faster.