I've never been a huge fan of horror movies, but I have always liked Halloween, especially as a kid.
I loved dressing in a scary costume and trying to frighten my friends or other trick-or-treaters.
And I admit to getting a bit of a thrill from walking through a well-executed haunted house.
But there are aspects to every agile transformation that can send a shiver down a spine.
And those moments are not quite so thrilling.
So let's take the fear factor away from five things that might make you want to run for cover along your agile journey.
First, by naming them, and then by talking about why they aren't so scary once you understand how they work.
One scary aspect of transitioning to Agile is that there is no technical design phase.
This can be particularly frightening to architects and other senior technical people.
Just because there's no design in Agiles does not mean that design doesn't occur.
Design does occur!
Technical design on an Agile project is characterized by two attributes.
It is both emergent and intentional.
An emergant design is one that comes into existence over time.
Rather than being done all upfront in a single phase, design in an ongoing activity.
The design emerges through the creation of the product.
But design is also intentional.
This means the design does not emerge randomly.
Design is guided by the intent of the senior technical people on a project, or perhaps even by someone in a designated architect role.
If the Senior Technical People are concerned about a particular part of this system, the product owner should prioritize a product backlog item or two
in that area.
this will allow the team to explore that part some small part of that system.
Doing so will help identify the appropriate design in that area.
Allowing design to emerge guided by the intent of the team will reduce the terror of there being no design phase in Agile.
Another thing some team members might be troubled by is the myth that on agile teams, everyone must be a generalist.
This is frightening because many people have worked years or decades to acquire this specialist knowledge and skills they possess.
Plus, their compensation is tied to that deep expertise.
Additionally, most people don't enjoy all types of work equally, and we'd prefer to spend our time doing the things we excel at and enjoy.
Fortunately, the idea that everyone becomes a generalist on an agile team is completely false.
If I'm coaching a team that has the world's greatest JavaScript wizard, I am going to want that superstar doing amazing things in JavaScript,
not learning how to become a database administrator.
Yes, agile teams value members who have multiple skills, the tester who can write some JavaScript, for example.
This is because it's the easiest way to balance the skills needed on a team.
If everyone is a specialist, a time that needs one and a half testers will be forced to choose to have exactly one or two.
The problem goes completely away when some people on the team have more skills.
A great deal is made of having a cross-functional team in Agile, which means a team has all of the skills needed to produce a finished working deliverable
within the iteration.
A cross functional team requires the team as a whole to have all the skill needed.
Every team member does not need all skills.
When transitioning to agile, management is often chilled to the bone by the idea that an agile team can't plan or predict dates further ahead than the
current iteration or sprint.
Fortunately, this does not need to be the case.
Yes, agile teams give up the false comfort of overly planned projects with intricately drawn Gantt charts showing a precise completion date way in the
distant future.
But that does not mean agile teams are unable to make plans or predict future delivery dates or scope.
A huge benefit of agile is that every iteration, the team turns the crank on the entire development process.
That is, they take an idea usually expressed as nothing more than a simple user story, and they fully implement that feature.
This means that every few weeks, a team can measure its progress.
They learn how quickly they turn raw ideas into running tested features.
Contrast this with a traditional development project, perhaps one with an analysis phase, design phase a coding phase and finally a testing phase.
When that team measures its process over a period of time, they're measuring only how fast they are at doing one or perhaps two types of work.
How fast a team is it doing design?
It says nothing of how fast the team will be at coding and testing.
The key with agile planning is embracing the uncertainty, admitting that it's impossible to know all the functionality that will built before starting
the project, and then adjusting for that in a variety of possible ways.
When teams combine this realization with the ability to actually measure the amount of work done every iteration, it leads to reliable planning,
which should calm the nerves of management daunted by the prospect of having no predictability.
The prospect of transitioning a team or company to Agile is enough to scare the pants off some managers who are concerned they won't have a job after the
transition is complete.
This is understandable.
It would be dismaying to start a transition effort aimed at helping a company knowing that it may make your role superfluous.
However, I can clearly say that I have never helped a company adopt Agile and then seen that company terminate everyone with a certain job title.
Sure, a companies may decide that a specific job is no longer needed or appropriate, but the individuals with those titles still have jobs,
and in most cases I believe they end up with better, more focused jobs.
It can be true, however, that following a transition to Agile, some managers will end up with less direct control over people or decisions.
Some might find this frustrating and they may make the choice to leave the company.
And yes, there are well-publicized stories of some companies abandoning their agile initiatives or deciding to get rid of scrum masters,
product owners, or coaches.
But again, I've never seen an organization lay off an entire set of people in a role because of the transition.
So I think this fear is as misplaced as that of a zombie apocalypse.
Like many people, I really hate meetings.
In fact, it's largely why I do what I.
Most days I have no meetings at all, pure bliss.
But even I can acknowledge that some meetings are important and useful.
And that includes the four standard meetings of Scrum.
The sprint planning meeting, the daily Scum, The Sprint Review, and the Retrospective.
the thought of all these meetings, however, can send some people into a cold sweat.
Here's the problem with Sc rum meetings they have names.
When something has a name, it's easier to attack.
In my experience, many teams who adopt Scrum had more meetings before Sc rum, but the meetings didn't have names and were mostly ad hoc meetings called
to resolve specific issues.
Here's an experiment I like and that you can easily do to see if you're having significantly more meetings with Scrum.
Randomly pick a month on your calendar from before you started adopting an Agile approach.
Open that month up in your Calendar software and add up the time spent in meetings.
Then add up the average time in your Scrum meetings and see how they compare.
Based on my experience, you might well be surprised by the results.
But because these pre-agile meetings were not recurring regular meetings, they didn't have names.
And so they don't stick out in our memories the same way a meeting like Sprint Planning does.
The key for overcoming the terrorizing thought of too much time spent in meetings is keeping the meetings short.
Occasionally, I'll work with a team that I need to encourage to spend more time in a certain meeting.
But most teams spend too time each of the standard Agile meetings.
Once they find ways to shorten those meetings, the meeting should no longer frighten us out of our wits.
While it can be fun to walk through a haunted house or wear a scary costume, most of us can easily remember that it's all make-believe.
Those ghosts, ghouls, vampires, werewolves, and crazed lunatics with chainsaws are not real.
And neither are the five things I've outlined here.
And while no one can be faulted for being afraid at first, education and experience will pull the mask off the myths, leaving us reassured rather than unnerved.