0

I'm currently managing a new software development project for my company, and we're considering implementing Agile methodology. I've read a lot about its benefits, but I'm looking for practical advice from those who have experience with Agile in a real-world setting.

Here are a few details about our project:

Project Scope: Development of a web-based application for customer relationship management (CRM). Team Size: 10 developers, 2 testers, 1 project manager, and 1 product owner. Timeline: 6 months for initial release, with plans for continuous updates. Current Methodology: We have been using a traditional Waterfall approach. I have a few specific questions:

What are the key steps to successfully transition from Waterfall to Agile? How do you handle resistance to change within the team? What tools or software do you recommend for managing Agile projects? How often should we conduct sprint reviews and retrospectives? Any tips on ensuring effective communication and collaboration within a distributed team? Any insights, experiences, or resources you could share would be greatly appreciated. Thank you in advance for your help!

Improve this question
2
  • There are far too many questions here. At least one of the questions - software and tool recommendations - is explicitly off-topic here, as well.
    – Thomas Owens ♦
    Commented Jul 2 at 11:44
  • Agile is not a methodology. It's a set of values, principles, and practices. It's a different mindset. If you approach things like a methodology, you will just go through the motions, you won't see the benefits you hope for, there will be a lot of frustration instead, and then conclude that Agile is crap. It's not. Unless you do it badly. I recommend you ask specific, focused questions that won't get your posts closed if you truly want to apply Agile to your project.
    – Bogdan
    Commented Jul 2 at 19:46

1 Answer 1

Reset to default
1

Start where you are. Start simple. Start small.

Is that enough of an answer? :-) You seem to know what you want to build; the product owner will be the one keeping checks on that (but make sure ownership is not his or hers alone). Split the product down and find important key features that would make or break it. If you can, make them as small as you can; there are plenty of (story) splitting resources online. Pick one. Pick a timebox, preferably as short as you can, so the feedback loop is smaller, faster. Do the work, review the outcome, review the proces (how did it go), adjust and start again.

As soon as possible get something out there to end-users, even during development and not just at the end of the timebox(es) They will have vital feedback.

As for managing things, try to look at what you're using already. Again, simple works, even an online whiteboard. Your proces review should discover if it's enough or not. Same for communication: are you already on Slack or Teams or ... Start where you are, review, adjust.

Look at the team you have and assess if one or two would benefit from a scrummaster or similar training. They would typically be very curious people and the ones that are good gauges for how things are going and full of 'what if we ...' ideas.

As you proceed make sure to keep all aspects open for discussion: the deadline of 6 months, the scope, the team setup, the tooling, the timeboxes, ...

Hope this helps.

Improve this answer

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