|
"You've Got to Have Rhythm, Setting the Tempo for Agile Development" |
|
The first
thing you notice when you walk into a shop that has really figured out agile
development is the buzz. There is energy
and tension in the air. It always feels
like something is about to happen. You
walk amongst the cubes. Some Web surfing
going on here and there. Others
feverously debating whether it's a feature or a defect (Does it matter guys,
just fix it!). And still others are
getting into the zone cranking Metallica through their headphones.
You start
to notice some subtle differences after spending a few hours with
them. There is a lot of motion and activity. People are not hiding in
their cubes. Occasionally one stands on her desk and
shouts across the floor for clarification on expected behavior.
Another, groans in frustration when he
realizes the size and complexity of his merge set.
Then there
is the "Ah ha" moment. These people
care. They really care about what they're
working on. They are not just going through
the motions. Not just collecting their
paycheck. It's infectious. You start wondering how you can help. Even though you're just a visitor, you start
to care and start fantasizing about sticking around and fighting through the
release with them. What's going on
here? Did they put something in the
water?
By day's
end, you start to see (and feel) some patterns.
There is a momentum about the place.
Somewhere in this office there's a ten ton gyroscope spun up. You can't help but feel its energy and start
to flow with it. This is how it feels in
a shop where agile is done right.
So what
drives this momentum? You poke your head
over a cube and intrude on one of the testers, exchange some niceties. Then you ask: what is it like to work here? What drives this place? What makes it so different? The tester responds. He can't let the team down. Every morning, he comes in. The builds are waiting for him. The results from the previous night's
automation test are in his inbox. The
daily team stand-up meeting is in two hours and the team is counting on him to
smoke test some new features that just came on line. He can't let them down. Interesting.
You then point out that there is plenty of time. Surely the next delivery to test is weeks away. And he laughs at you and tells you the next
delivery is less than 24 hours away. And the delivery after that is 24 hours
later. And they don't stop. They keep coming day after day.
So you
point out the obvious to him. There's no
way you can keep up with that. You'd
need five testers to every developer.
Impossible. He snickers
again. He points out the smoke test is
one of the manual tests. The build
system runs over 5000 automated tests every night. Unattended.
He describes how the automated build system retrieves the entire source
from the SCM system and rebuilds the entire application. Then it installs the application to a set of
test servers and runs automated unit, component and UI tests against the
application. Finally, when it's complete,
it sends out a notification to the team with pass / failure rate highlighting
any build or test failures. If the build
fails, it's all hands on deck the next morning, or more likely that night since
most developers seem to be nocturnal.
Nightly builds. Thousands of
tests. Amazing.
As if
that's not enough, he continues on. It's
not just for the mainline branch.
They've got this process running in parallel. There's another integration branch running some
new components being delivered by their outsourcing firm in Pune, India. Same process applies. And then, of course, there's that "custom
feature branch" running as a result of the CEO's last customer visit. He rolls his eyes.
Unattended
nightly automated builds across three branches.
I shake my head.
He notices
the stunned look on your face and tells you he had the same reaction. He hadn't experienced this before either. He mentions that the daily stand-up meeting
is in a few minutes and that you are welcome to stick around. Daily meetings. You comment that must be onerous and have a
real impact on team productivity. To the
contrary, he comments. It's where he can
stay tuned in to what's going on and raise any impediments that he can't
resolve himself.
The daily
stand-up meeting goes by quickly. Each
team member discusses their accomplishments and what's coming next. A few issues are raised. The facilitator, they call her the
ScrumMaster, notes them on the whiteboard and moves on. What's interesting, though, is the mention of
the upcoming Sprint meeting and demonstration.
You follow the ScrumMaster back to her cube. This place is bizarre.
You stand
outside her cube gazing off in the distance, again, not really wanting to
intrude. When you look down, she's
looking up at you with a pleasant smile.
She asks you: what's up? It's
embarrassing, but you ask her what a Sprint is.
Another chuckle. You're starting
to feel like you're in France. A Sprint, she explains, is a four week
increment. The team breaks up their
project into increments they call Sprints.
At the completion of each Sprint a set of new production quality
features are delivered. The product
owners and a few business types evaluate the results and make a determination as
to whether we're ready to update the production servers. She tells you that they're an agile shop and
they're doing Scrum here and comments that someone should have told you. You nod in agreement.
After a
light lunch, you spend the rest of the afternoon searching the Web for information
on just what this agile/Scrum thing is all about. A picture starts to emerge and you sketch it
out in your notebook.
feature drops, sprints every four weeks, and releases to
production slightly less frequent than sprints.
This is that momentum that you felt.
This system that they call agile and Scrum has nested levels of rhythm
and tempo. You see how each level serves
different needs. But the levels interleaves
in a way to form an efficient, vibrant software development approach not unlike
musical composition. And you now see how
real value is enabled by software configuration management with a smartly
integrated build automation system.
John
Scumniotales is Vice President of Product Management for Serena Software. Prior to Serena, he was Vice President of
Products for Pacific Edge Software, a leader in Project and Portfolio
Management. He was the first ScrumMaster
and co-created Scrum with Jeff Sutherland at Easel Corporation in the early
1990's. John has held senior technical
and management positions at Rational Software (now IBM) and several other large
and small software companies.
Trackback(0)
 |
TrackBack URI for this entry
Subscribe to this comment's feed