I was having lunch today with a new client that is interested in implementing scrum in their organization. They are a very large company where a single project can have five or more departments involved as stakeholders. They are not interested in turning on a switch and being 100% agile overnight. For a company such as this, they need to be more prudent in bringing scrum online. In addition, the move to scrum should be transparent to everyone outside of IT and software development. Thankfully the planets are in alignment for us and they have the perfect opportunity to use scrum: a project that needs to be completed, and a staff and higher-ups wanting to use scrum.
Often times we look at a project as an all or nothing proposition. We do this with many other things including improving development practices and business processes. Introducing scrum does not have to be done in one large, sweeping move. I recommend against doing that. It is those instances where scrum is introduced too quickly, on too large of a scale, or in areas where scrum is not useful, that cause projects to fail and everyone blames scrum. That is akin to blaming a framework for scalability issues where the framework isn’t to blame, but rather the implementation.
If you have a project or a small set of tasks where you can apply scrum use that as the test bed. You can even start using it without telling anyone. “Geez, how is Jim able to crank out so much stuff in such a short amount of time? I love seeing new stuff every couple of weeks.” Scrum. It’s great stuff; however, it is a paradigm shift for many. Don’t dive in too quickly lest you end up in shallow waters and bonk your head. Use it on a project, achieve a great success, and use that as proof that it can work. Then build on it.
Other Posts That Might Interest You
