Reason 1: Revolutionary Change
For many companies, Agile methods like Scrum and Extreme Programming (XP) can appear to be huge change to the current process. Businesses that I’ve encountered that do not use a named methodology typically have a process that looks like this:
- An arbitrary release date is set
- Someone (usually management of some level) determines what is going to go into the release
- Preliminary requirements are written
- The team is handed the requirements and told the release date
- Development begins
- Meetings are scheduled, the number of which depends on how the level of detail in the requirements, and how well the team understands them
- The release date comes and goes; managers get pissed; teams get yelled at; a death march may begin
- Finally the release is completed
- Bug fixing begins
And then the process starts over.
Sound familiar? If it does, then implementing just about any formal method will be pretty revolutionary.
However we can lessen the impact of that change by taking it one step at a time. Who says you need to be fully Agile by Monday?
Reason 2: Changing Job Titles
In Scrum there are three major roles – ScrumMaster, Product Owner, and the Scrum Team.
So where do I as a System Architect or Project Manager or Senior Developer or [INSERT JOB TITLE HERE] fit into this naming scheme? How are my current responsibilities affected? Do I have more or less?
These three roles are not job titles – they are project roles. Yes some companies do have them as job titles, and some are fortunate enough to be able to be a full-time ScrumMaster or Product Owner. However many aren’t. And what if you have more than one business analyst? Does only one of these folks get to be the Product Owner?
If you don’t already have these roles as job titles, keep them as roles. And be sure you understand the additional duties you may take on by being a ScrumMaster or Product Owner.
Reason 3: Developers Run Amuck
This is one of my favorites. The meaning of self-organizing and self-managing teams has got to be the most misunderstood terminology in the Agile dictionary.
Neither of these terms means that project management all of a sudden goes out the door and teams do whatever they want whenever they want. Scrum and XP are both frameworks, meaning there is a structure within which you work. And within that framework teams determine the best course of action to complete the work.
The difference here is that my team is not being micromanaged on a daily basis.
And what happens? The team, sometimes with assistance, becomes more productive, and as a manager I can help them to stay productive by removing impediments standing in their way.
Get More Agile
If you liked this post, please consider subscribing to my newsletter to get more Agile resources and subscriber-only webinar announcements. You can unsubscribe at any time if you find I’m a bit to snarky for your taste. What can I say, I’m belligerent.
Other Posts That Might Interest You
