2

The department I am working in is Data Support Dept.

The nature of work, is providing reports to other departments, and do some data integration.

I am thinking of using Agile in the dept. but I don't know how is that going to be implemented.

The projects here are support, so we do not have list of features need to be delivered and no timeline as well. once we finish user get the updated report directly

on top of that each request has its own owner. in other words we could have 10 product owners at the same time.

How can I implement Agile in such environment?

1
  • Hi asmgx, welcome to PM.SE! I believe the community can help you much further if you explain what's currently failing and why you think agile could help you with. Agile is a means to an end and shouldn't be considered the end in itself. Otherwise, you're likely to fail (or end up with a half baked implementation that will cause more frustration than benefit). Commented Jul 21, 2019 at 19:59

2 Answers 2

2

At the core of Agile you find a set of values and principles. Agile is more of a mindset than a way to implement software development. Agile is also an umbrella term for more practices that share the same values and principles.

I see you tagged your question "scrum". You don't necessarily need to go with Scrum if you want to be more agile. For support teams that work based on received requests from multiple "product owners", Kanban might be a better choice. I suggest you give it a look. It might be closer than how you currently do things, and it's a starting point.

Take into account also that you don't necessarily need to pick one method and stick with it forever. You might later move to Scrum is the nature of your work changes. For example, a lot of teams start with Scrum and develop a product, then switch to Kanban for maintenance and support just because it matches better the nature of the work. You could start with Kanban then slowly evolve toward something else. There is also Scrumban which combines features from both.

One work of caution though. Try having one "product owner" for the work you are doing. I have it in quotes because it isn't necessarily someone that does a product owner job (since you get work from many directions), but someone who decides on priorities. When you have 10 product owners at the same time, inevitably each considers their requests to be top priority. If your team can't work at all reports at the same time, someone needs to prioritize across the board and everyone be in agreement with why the work is done on some reports now and others later.

1

Agile is an approach, so can be adopted by all kinds of teams. To do this you need to favour responding to change, customer collaboration, interaction and the other values of agile.

Adopting the Scrum framework is a bit more involved, but is readily achievable within a data support team.

You can think of the reports the team generates as the product. The reports have value and so can be prioritised.

It would make sense to have a single Product Owner who is the judge of report value and who will own and maintain your product backlog. The people who make the requests act as the stakeholders rather than multiple Product Owners.

The advantage of this approach is that the Product Owner becomes a single voice of requirements in to the team. Their job is to listen carefully to the stakeholders (report owners) and to distil their requests down in to a series of user stories.

An example of a user story on your product backlog might be something like:

As a sales director I want to see the monthly sales figures broken down by district so that I can see which areas need help

This requirement is translated in to an update of the sales report.

Once you have several such user stories representing the requests from report owners then you have your product backlog.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.