We are happy to have he opportunity to interview Ellen Grove, who helps teams do better work by coaching them to create the circumstances in which they can work most productively. Her Agile coaching practice with agilepartnership.com is founded in over 15 years’ experience leading software development and implementation teams in global enterprise, a passion for exploratory software testing and user-centered design, and a background in community organization. Ellen presents frequently at Agile conferences, most recently: San Francisco Agile 2012,Agile Day NYC 2012, Agile Tour Montreal & Ottawa 2012, Play4Agile2013 (Germany) and Agile Games 2013 (Boston). She is the Scaling Agile Adoption theme chair for Agile India 2014.
How did you begin in agile coaching/consulting?
I got my start as an agile coach while I worked for a large
telecom company. My background is as a software tester, though I've done a
little bit of everything except coding along the way. My team had begun
as a startup, which had been acquired by the large company but maintained the
startup mentality of doing it all ourselves and trying to get things done with
a minimum of process. The company decided that they needed to introduce a
standardized process for software development across the entire company; my
team looked at the proposed process and realized we'd need to double the size
of the team and the length of our release cycles just to handle the process
overhead, which was obviously not acceptable.
We decided that we would need to counter-propose an approach
that would demonstrate some discipline in the process yet give us the
flexibility we needed to do things very quickly. Until then, we'd been
playing with some Agile ideas informally, but hadn't really made an effort to
work intentionally in an Agile way.
This is when we got serious about Agile. After arranging
for myself, my boss and his boss to attend Scrum training, I helped to
organize and deliver Agile training for all the teams involved on the project:
there were three teams involved, spread over 3 countries and a 10-hour time
difference, as well as an external vendor who was supplying a vital component.
We were working in 1 week iterations (integrating the work of 4 teams)
and learning a lot as we went along. I was playing many roles - leading the
testing function, acting as Scrum Master for one team, and serving as an
internal Agile coach to the larger project team. I was also involved with
the company's process team establishing an Agile alternative to the big
universal process they were trying to introduce. It was crazy, but quite a lot
of fun while it lasted.
When that role ended, my next gig was as a project lead on a
non-Agile global network transformation project, very complicated and complex
and risk. What I learned from that experience was that I really only
wanted to work on Agile projects, since Agile approaches offer some of the
simplest ways to manage risk and complexity.
In a small company with less then 200 people following Agile, do
you think a project managers role is as important and would be beneficial. Why?
Interestingly, in the large telecom situation there was never
much attention paid to project managers, even though we had one on our team all
along (even when we were still operating as a startup). The PM was the
person who updated Gantt charts, counted things and went to boring meetings
that none of the rest of us were interested in. It was quite a surprise
for me to start consulting in other organizations where the Project Manager was
effectively the leader of the project.
I think that many of the functions of project management are
critical, but on a smaller team/project the important elements of the function
can be built into the team's work and there's often no need for a designated
project manager. Where I've seen real value in a PM role is in larger
organizations where the PM acts as an interface (and shield!) between the
development team and other functions in the company, allowing the Scrum Master
(if the team is using Scrum) to focus on supporting the team's day-to-day
activities and leaving the team to coordinate its work internally. It's
often very hard for people who are accustomed to a traditional PM role to make
that jump and let the team have space for self-organization.
Tell us a little more about what you do as a LEGO Serious Play
facilitator.
I love doing LEGO Serious Play -
I wish I could spend all my time running LSP workshops! LEGO Serious Play
is like play therapy for business. It's a very simple, structured process
that enables people to have really important conversations about how they're
working as team or to share ideas about the work they're doing in a way that is
designed to help them get to the heart of the conversation very quickly.
How an LSP session works : the facilitator asks a question, the
participants build a model to answer the question in a very short period of
time, and then each person at the table shares their story about the model with
the others. This process is repeated a few times to build up a shared
understanding of the subject at hand that incorporates the viewpoints of
everyone taking part. A longer workshop may involve fitting the individual
models together in an integrated landscape to really create a shared view of
what the aims of the group are.
It's simple, but incredibly powerful. Because people are
using their hands as well as their brains, unexpected ideas emerge.
Time-boxing the builds forces a focus on the most important ideas.
And seeing the ideas take shape on the table results in a different kind
of understanding about how the pieces fit together. I use LSP for
everything from team building sessions at the start of a project, to strategic
visioning and planning, to retrospectives.
I've written a bit on my blog about how
LEGO Serious Play works. I tend to overuse the word "magic" to
describe the results of LSP, but every single time I run a session I'm blown
away by what ends up on the table. People are often very skeptical before
they've used LSP to do work because it seems silly and not serious, but once
they've taken part in an LSP session they realize how incredibly powerful it is
as a tool for helping people to express what's in their heads and their hearts.
When working with organizations how you do come up with a
strategy?
My Agile coaching strategy is fairly simple: 1) Help the
organization figure out what they're really trying to accomplish, and then 2)
help them find ways to get there. This sounds easy but usually is not,
especially in larger organizations where there is often ambiguity and conflict
in what the real goals actually are. With small teams/companies, there's
usually a clear set of desired outcomes driving the team ('Make customers happy
so that we make money and stay in business'). With larger organizations,
especially in the public sector, it's often much more complicated to understand
what the actual goals and desired outcomes are. "Get the project
done" is a fairly meaningless goal unless you understand what the real
value to be delivered through the project is and who you're delivering to, but
large public sector projects often fail to communicate either of those things
to the people who are doing the implementation work - the message conveyed to
the team is usually "Here's the requirements, just get it done!".
It's very hard to transition to an Agile way of working in those kinds of
organizations.
What are the 3 things you would suggest to all Agile project
managers?
Focus on the value being delivered through the work, not the
meeting the expectations of the plan. Inexperienced PMs sometimes lose sight of
this and confuse "successful delivery of project artifacts" with "a
successful project". It doesn't matter if you deliver on
time and on budget if the end result doesn't please the people it's meant
for.
Trust your team to do the right things (and tailor your behavior
accordingly). People tend to live up to what's expected of them, and if you
want to encourage responsibility and accountability in your colleagues, you
need to treat them as responsible, accountable individuals with good intentions
and good judgment. Most people want to do great work - and if they don't,
taking a command-and-control approach to managing their work won't result in
happiness for anyone. If they do want to do great work, a controlling approach
is just going to get in their way.
Make it safe for the team to fail. If you don't want the bigger
effort to be a failure, you need to help create a culture (at least within the
team) where it's OK for people to make mistakes and to ask for help when they
need it. I've seen too many big problems that were caused by smaller
problems being ignored or hidden because team members weren't comfortable being
open when things went wrong. I'm a big fan of the "Failure Bow",
because it's so much better in the long run to handle failures well instead of
blaming-and-shaming so that we can learn from mistakes.
Thank you Ellen.
(Pic Courtesy: Ellen Grove)
