If you are a leader, non-technical manager, product owner, marketing manager, C-level executive, etc., I recommend you start with ‘The Scrum Guide.’ It’s a short read, so don’t delay. Then, share this with your technical team. Getting this knowledge will allow you to support them and encourage them to move in this direction. Make it clear this is the direction you want to go in (because some Engineering teams can be stubborn about ‘a new thing.’) Also, review ‘Introducing An Agile Process to an Organization’ and follow some of the ideas.
What’s in it for you? How about seeing “your product” improve every two weeks? No, you might not ship it to clients every two weeks, but YOU (and your stakeholders) will see progress, quickly, regularly. How’s that for accountability and measuring ROI?
If you are a Software Engineer, Developer, Project Team Member (or an Engineering Manager, Team Manager) you must immediately become familiar with Scrum. It will change your life (and your teammate’s lives) – believe me! Start with ‘The Scrum Guide.’ It’s not very long and it’s easy to understand. Then, perhaps try ‘How To Implement Scrum in 10 Easy Steps.’
Then, JUST DO IT. Sure, you might need some buy-in from the business, but I’ve seen where Engineering teams can start moving in the direction of Scrum on their own initiative. The point is: saying “we’ll do this one day” won’t change anything. You have to start one-day, so “one-day” might as well be today!
If you hire outside resources or outsource your project development, start with ‘The Scrum Guide’ but then ask your partner company about their Agile process and what role you will be playing. You should likely be the Product Owner, but if you are also contributing team members, they too need to participate in the Agile ceremonies and processes. In some cases, you also might want to provide the Scrum Master as well (even better if that person is in your PMO.)
One important consideration is that as Product Owner, you retain a critical role but it is one that comes with great responsibility considering your ongoing attention will be needed. Whereas in a waterfall project, you might work hard initially to create requirements then hand them off to a team, in an Agile project, you’ll be participating on an ongoing basis. The work might even be a little more considering you are factoring in changes and unknown factors, but it is spread throughout the life of the project as opposed to front-loaded. However, the potential for success is also much higher (and easily makes up for the extra work) since you will be able to make adjustments very quickly when compared to a classic project.
