In
our team we have accomplished some things I find essential for the scrum
process to work effectively. Maybe somebody finds something interesting or
inspirational. All comments are very welcome...
1) Agile principles
It
is very hard to progress in something if you don't believe in it. In our team
every member understands and appreciates the principles of Agile and tries to
apply these in everyday work. For example our newly recruited quality engineers
says: "I can just comment that it felt a very natural process for me
starting from day 1 even though I didn't have any previous experience with it.
It just kind of made sense after the first sprint already." Of course we
need to adapt some of these principles to our work specifics, but more often it
requires for us to adapt ourselves to agile.
2) Customer value driven
One
of the most important agile principles. The whole point of software development
is to offer value to the user. This point has to be constantly acknowledged by
everyone and the process should be built around this principle. To increase
this we started releasing after every sprint which resulted in some interesting
changes.
a- Tolerance
for the bugs reduced and changed our development to more quality oriented. We
write tests first, automate everything what we can, and do testing as often as
possible. After each sprint we have high quality production ready product.
b- Sense
of ownership and actually making a difference increased. Instead of waiting
more than a month for the release, we see that we create something, and people
start using it pretty soon (being actual users or people in the organization).
So the chain "we create -> people use", became a lot more visible
and prominent in everyday work.
c-
Ability to deal with small and big things at the same time. We don't have to
wait weeks to get a small bugfix live and we don't have to release half-tested
or not complete product when we need to get something out of the door quickly.
The
downside of this can be that it creates a lot of routine and there is less
anticipation for "The release", but I think the benefits outweigh the
cost.
3) Scrum process
With
scrum it goes even deeper. It is very important for each team member to
understand the scrum process and coming down from that, understand the meaning
and value of each part of that process. It's hard to make the full use of the
tools if you don't know what is their purpose, let alone not knowing the
meaning of the whole process. In my mind probably the biggest responsibility
for the scrummaster is to promote this meaning and these values in team. In
addition in our team we try to keep our knowledge of the process updated
(everyone has attended or re-attended scrum training recently) and also
constantly share and discuss ideas and experiences between members.
4) Cross-functional
Since
grooming is one of the backbones of the scrum process, we find it very
important for each team member to understand to some extent every aspect of the
work we do. Since skills and the nature of different tasks vary a lot, we use
pair-programming as much as possible. The goal is that every member of the team
has at least basic skills for every aspect of the work we do, and we are pretty
close to that. For example every member of our team is able to run and write
automated functional tests.
5) Product Manager
One
of the roles of the product manager is to be a diplomat between higher business
and development. Translate one's visions and needs to other and vice-versa.
This means he needs to understand both parties and more importantly trust and
listen to them, where he lacks the understanding. Since engineers are from my
experience often more prone to agile than business people, this is maybe one of
the key points for all this to succeed. Points 1-3 should be covered by direct
management also, otherwise it renders the whole effort useless. It feels to us
that our PM has understanding how our process works and is taking an extra
effort to adjust his work to the way we work, to get the most out of us, while
not compromising his own goals. Our PEM is also not forcing anything, he is
questioning the things we do and enabling us, not forcing.
6) Avoiding "Product
arrogance"
We
think about our product, how to make it better, faster, robust, etc. but we
often forget our users, although users are buying our product. There is one
technique to put users first: change the way how we write our user
stories (PBIs). Our typical PBI starts with the common format "As a {role}
I want to {do something} because of {benefit}". The problem is that then
every developer thinks about that {role} as himself. But there are usually no
users skilled like you are (or minority is). The cure for that problem is to
use Personas for writing user stories. Give your Personas names and some
characteristics and background, like age, how they spend their time, how they
use your product. When you have Personas then you can write PBI in simple
English, e.g. "Jane and Andrew share photos to compare their
children". Everybody understands such sentence, which includes concrete
actors, performing specific actions and there is a result which is
testable.
--
When
talking with people about these topics I often hear "show me proof, show
me numbers". This post is not meant for convincing anybody, but rather
express our feelings about our team and our processes. For me as a scrum
master, the most important metric is the feeling in the team. Do we feel that
things just progress and the feeling in overall is good? And the answer is (to
put aside estonian way of expressing ourselves - "I guess not too
bad" :D ), while constantly seeking for ways to improve, we are happy with
the way things are going.
