If it hasn't happened already, at some point
you may be approached with the idea of being involved in an "agile"
project, like a Scrum. In theory, this is a good thing. A properly executed
agile project can vastly increase your chances of having a successful
compliance related project. However, there is a real dark side to this.
If you ( or anybody on your agile team ) don't understand what you are
getting into, you can really sabotage the project.
I'd like to share with you some of the issues Champions and other management
related stakeholders ( i.e. Program Managers ) have had with these types
of projects, and tips on how to keep you from sabotaging your project.
But first of all, let's define an agile project ...
I'm not going to spend a lot of time on the structure and merits
of different agile projects. That's for another time and place. But
just to give you a high-level in case you're new to this, and agile
project is characterized by two things: 1) It's iterative, meaning
a iteration timebox is fixed ( usually 2 - 4 weeks ), and at the end
of every iteration some tangible value is produced by the project
team; 2) Teams are coached, not managed, and the project team members
self-organize their own activities to meet the project's deliverables.
They are highly collaborative, and extremely resilient to change,
which is what makes agile teams very attractive in an environment
where the requirements are constantly changing.
You may not think this applies in a compliance project ( regulations
are regulations, right? ), but it actually does. As your project progresses,
you will invariably find out more about your data and / or processes
than you originally thought. Having the ability to change course as
new information presents itself is extremely valuable.
Unless you are trying to construct your own in-house methodology
( be extremely careful with this approach ), you will probably be
running a Scrum. All other popular agile methodologies apply mainly
to software development. Scrum is extremely simple to learn; there
are very few concepts and rules to digest, especially for the Champion.
The ScrumMaster ( the coach or project manager equivalent ) is the
only one who really needs to spend some time learning the methodology
well.
On a Scrum, you will have a 30 day timebox, or a "sprint".
As Champion, you will meet with the team once a month, so they can
give you a demo on what they've delivered. This is also about the
time you will define the scope for the next sprint. These two events
are usually handled in either one full day, or two half days back
to back.
Okay, now that you have some background, let's save you from yourself
with some critical tips.
Critical Tip #1: Organize the Right Team, Choose Attitude
Over Aptitude
It is very important to have team members with either successful
experience running Scrums ( preferred ), or very open minds. Everyone
on the team must be completely committed to the methodology, or at
least remain open minded. One bad apple will spoil the whole lot,
so be very selective here. Although you need skilled people, attitude
is much more important. You want people that are flexible and open
minded.
Your team must include members from all facets of the problem, including
internal auditors, process analysts, subject matter experts ( i.e.
finance professionals ), and techies ( if a data system is involved
). They must all be full-time
dedicated to the project until it's over.
Since your ScrumMaster is the most important person on the team,
choose them carefully. Either choose somebody that's already coached
a Scrum, or somebody you know will keep an open mind and
dedicate themselves to learning the methodology. This won't take a
long, but an investment in time is required. He or she will need to
coach the team through problem solving and organizational issues,
so somebody with the necessary people skills is absolutely vital.
Critical Tip #2: You Are a Chicken, So Act Like One
In Scrum, there's the story of the pig and the chicken. They get
together to open a restaurant, with the plan to serve ham and eggs.
The chicken is involved, but the pig is committed!
The story here serves a very important purpose in role definition.
The ScrumMaster and the rest of the project team are the pigs. As
pigs, they're the only ones that can make decisions on how the project
team gets its deliverables done. As the sprint rolls on, chickens
( like you ) are merely observers. Do not interfere with what's
going on. Trust your ScrumMaster and your project team to
deliver.
That doesn't mean you disengage until the sprint is over. In fact
it's very important that you stay informed. Your ScrumMaster will
probably have a daily meeting of about 15 minutes. You need to attend
every single one, but your job is to listen. Don't
say a word, except maybe "Thank You" or "Good Work"
at the end of the daily meeting.
Critical Tip #3: Understand That Scope Will Change, Sometimes
Radically
In project management terms, we're locking down time and cost, and
solving for scope. Scope will change every month, sometimes radically.
This is a byproduct of discovery.
This is okay. In fact, it's healthy. I would be extremely concerned
if throughout my entire set of sprints, my scope never changed. It
means something's wrong, and the project is not free to explore its
own discovery.
This can be extremely challenging for Champions and / or program
managers to cope with, when trying to "report up", or for
that matter explain to anybody that's not "in the loop".
If you can, try to be as evasive as possible about future deliverables.
It's okay to talk about the current sprint's deliverables, because
they are locked in, but do not communicate anything about what will
happen after that. You will seem flaky and out of control to those
that don't understand the process. Instead, focus on the immediate
and the past. If the team is doing it's job, you will have tangible
results to demonstrate within a month. These successes are more important
than trying to figure out what things will look like in 6 months.
Critical Tip #4: Help Your ScrumMaster Protect The Team From
Outsiders
Protect your team at all costs. It is important that they stay 100%
focused and dedicated to the effort. The minute individuals start
time-slicing in the project, the synergy of the team will be lost,
and your project will go south.
Also, protect your team from outside influence of any kind. Remember
the chicken and the pig story? All the chickens need to leave the
pigs alone to work. Furthermore, without the right background, it
will look "funny" to outsiders, and they will draw the wrong
conclusions about what's going on. From the outside, the team will
look chaotic and out of control. The instinct will be to come in and
"manage" what's going on. This is not necessary, and will
damage your team's efforts. If your team feels pressure from an outside
manager ( i.e. your boss, or one of your peers ) to do things differently,
they will probably cave. No one wants to get fired over this.
Critical Tip #5 : Respect the Scrum Rules, Especially the
Scope-Lock For A Sprint
Once a sprint is started, the scope is locked for the next 30 days.
There's nothing you can (or I guess "should" ) do about
it. There's one Ace card the ScrumMaster can play in the middle of
a sprint to halt it if things are going haywire-- but that's the ScrumMaster's
call, not yours.
My first exposure to an agile methodology was Extreme Programming
( XP ). In XP, a typical timebox is 10 business days ( 2 weeks ),
not 30 days like Scrum. You would think that my key user could keep
his pants on for 2 weeks while we developed a block of scope, but
he was constantly pressing us for scope changes within an iteration.
I was amazed then, and I'm still amazed at how impatient stakeholders
get when they realize a new requirement. The proper thing to do here,
even if you discover a requirement on day 2 of the sprint, is to put
it in the backlog ( the living record of scope ), and wait until the
next sprint's kickoff. If it's still important in 29 days, you can
make it the top priority of the next sprint.
Critical Tip #6 : Worry About Results, Not Methods
This is my final and most important tip of the article. When agile
methodologies execute, they look very different. You won't get the
real impact of this until you see it in action.
You might observe some real strange things. You might see your project
team organized in pairs, where you always see two people on one computer,
working on the same thing. Or you might observe what seems like chaos,
with everybody talking at once, and running around like there's no
direction. Or you might see what you consider a gross under use of
technology, with people using sticky notes and index cards to gather
requirements, or whiteboards to keep their designs.
Leave it alone. Your team needs to organize itself, and this is how
it manifests.
Just leave it alone.
Instead, focus on results. Your team should be producing tangible
functionality at the end of every timebox -- no questions asked. Don't
take answers like, "We're almost there", or "We have
finished a lot of foundation work, and now we're ready to roll".
At the end of 30 days ( in the case of a Scrum ), they need to be
absolutely, production-quality, done with something.
The acid test here is, "If I stop the project now, am I functionally
better off today than I was 30 days ago". "Yes" is
the only correct answer here.
So, if the answer is "No" then you have a real problem
with your team, and I would take that up immediately with the ScrumMaster.
He should know better than that.
However, if the answer is "Yes", leave them alone.
That's the point anyway, right? You tell them what you need done,
and they do it. Who cares how they do it?
One more time just for good measure. Leave them alone.
Using agile methods on a compliance project is an extremely effective
way to get the job done where other efforts have failed, especially
in an environment where requirements are changing on a regular basis.
To prevent sabotaging your team, it's as simple as understanding and
following the rules of the game.
If you've got a compliance situation that you can't seem to resolve,
give agile a try, and make sure to keep these tips in mind. They will
save you and your project team a lot of grief, and lock in your increased
chance of success.
