Using agile methodologies for information management projects – a practice that is as useful to a midmarket company as it is to a Global 1000 organization – sounds straightforward. There is the backlog, the sprint planning, the meticulous time and progress tracking, the daily SCRUMs, the demonstration and the retrospective. There are the roles of SCRUM Master, Project Owner, Team Member and perhaps Lead Architect.
Get your ½ day “happy path” training and go off and do it with no worries, right? Actually it does not matter how many weeks of agile training everyone has. You do need to get moving with it, learn as you go and adjust to the challenges.
Here are some of the challenges faced by those who have attempted agile – perhaps you. I present these as a “heads up”, not as excuses to not move to agile. Moving to agile is one of the most productive things you can do for your information management projects. I incorporate dealing with these challenges in my training and workshops.
1. Dedicated Resources
This is the number one challenge I face. We want everyone 100% dedicated to their SCRUM team, but many want to continue sharing resources across multiple teams or, more likely, the SCRUM team AND a host of other responsibilities. Many times those other responsibilities are very synergistic with the SCRUM so those responsibilities can be absorbed into the SCRUM, as long as the SCRUM has only one SCRUM Master, etc.
Also remember that it is only expected that 62.5% – 75% of a team member’s hours will be applied to SCRUM tasks so the other tasks can perhaps fall into the other 25% – 38.5% of their time. Otherwise, we need team members who can get dedicated.
2. Dependency on Other Resources
SCRUM team members will not be the only ones executing the tasks of the sprint. Often, the core SCRUM team is dependent on others in the organization. These may be people who are not on JIRA, or the chosen project management platform.
If someone is not in the team and on the project management software, the task must be assigned (with one story point) to a real team member. And don’t just hold your breath that the task gets executed. The assignee and the SCRUM Master need to get out there are see it get done, remembering that other person may or may not be filled with the same urgency of the sprint team.
3. Organizational Roles and Responsibilities
SCRUM team members do not always nicely fall into a single department. Agile pushes some matrix thinking into an organization. While the team members may, and probably will, have other organizational bosses, for the duration of the sprint, they also, and primarily, report to the SCRUM Master.
I often hear variations of how do I project the future at a 6- or 12-month basis – the basis by which I get my budget – when every sprint is determined at its outset? The short answer to this is that you still must. Agile is a methodology. It is not the deliverable. Deliverables executive sponsors and budget granters care about usually must take months, quarters and possibly years. This is the arrangement you make with them and you have to ensure that ultimately the sprints deliver those longer-term expectations.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions.