Hello

I'm new to this group so I thought I'd introduce myself and share my
perspective. I recently joined Pluron, the maker of Acunote, as a
member of the company's executive team. If you are not familiar with
Acunote, it's a SaaS project management tool for Scrum teams. As part
of my initiation into Pluron, I am reading as much as I can about
Scrum, which admittedly reveals that I'm still on the steep part of
the learning curve, even though this is not my first encounter with
Scrum.

Honestly, I was skeptical about and somewhat annoyed by Scrum before I
read Agile Software Development with Scrum by Ken Schwaber and Mike
Beedle. I have been an executive, investor and board member in
companies where development teams employed Scrum, so I know Scrum is a
popular methodology that can produce commercially successful products.
However, prior to reading this book, my understanding of Scrum
principles, practices and purpose was hazy, at best. My prior
experiences with Scrum, as a non-programmer, had taught me that Scrum
is a shield, deployed by development teams to insulate themselves from
interaction with management, and a way to force management to interact
with developers on their terms. While I still believe that this
"shield" is an aspect of Scrum, I now understand why it is in the best
interests of development organizations to shield themselves from
management... because all to often, management doesn't understand how
software is created!

Typical non-programmers, myself included, assume software development
is a defined process like building construction and we need to be
educated so we can understand that software development is an
iterative process of innovation. As Schwaber and Beedle carefully
explain in their book, software development is not a defined process
because software product requirements change rapidly, so it is best to
view software "as a new product every time it is written or composed".
As such, software development should be managed by a process that
anticipates continuous change. For me, this was the most important
revelation of the book, though I also learned plenty about the details
of the Scrum process. I highly recommend that all non-programmers who
come in contact with Scrum read Agile Software Development with Scrum
by Ken Schwaber and Mike Beedle. It will better prepare them to
collaborate with Scrum teams and respect the inherent boundaries of
the Scrum process.

If you are a developer in a Scrum team, give this book to your
non-programmer counterparts and ask them to read it. This book will
give your management and customers a better appreciation for the
complexities of software development and help them to value Scrum as a
strategy for risk management and productivity enhancement. Share Scrum
with non-programmers so that they can support it, rather than view it
as a shield. If they don't read the book... then, shields up!

Though not covered in great detail within the scope of the book, I am
interested to learn more about the role of management in Scrum. Other
than removing impediments, staying out of the way, and funding the
work of Scrum teams, how can management contribute meaningfully to
Scrum? Are there other Scrum books or resources tuned to the
particular perspectives of management and customers? I'm especially
interested to hear ideas from other non-programmers based on their
experiences with Scrum. Of course, feedback from programmers is very
much welcome, as well.

Cheers.

Mark

COO
Acunote - Online Scrum Software
http://www.acunote.com