Really meaningful reports

[nig3d]

Hi Guys,

After 1 year we use VersionOne and after the big effort I made as ex
senior programmer to understand how to communicate with stakeholders,
I start to wonder, if the VersionOne reports are really meaningful.
Under the team point of view, the only meaningful value is the story
point, in order to be able to have a metric to estimate the velocity
of team production.
The problems start when I need to report our progresses and plan to
the stakeholders. I tried to show the Vone reports in several ways to
the stakeholders, but I found out that there isn't really any report
that can be suitable for these purposes.
This is a real problem, because I'm forced to use excel to create home-
made charts that doesn't look professional at all.
The only thing I can use to communicate with the stakeholders is the
parking lot, that is a good way to show the current development
snapshot. The only problem is that it's very unhandy, since I don't
have any way to show the the complete hierarchy features, so that I'm
forced to copy and paste images or show the feature group tree, with
the progress bars, that can't be exported in excel as percentual by
now.
The real problem, imo, is that while VersionOne is very customizable
(you almost couldn't recognize vone using our configuration), there is
no way to customize the reports, unless I would use (maybe?) the SDK
to code custom charts.
For example I don't have a proper tool to communicate the features
that will be delivered over the time, to show the planning and the
release date in a simple way.
It could be interesting, imo, if the reports could be made also
according the custom values, even if this won't solve my problem at
once.
Unluckily, when the "old" fashion managers here tell me that a Gantt
would be better to show the features to be delivered over the time, I
can't find a real way (yet) to show them that they are wrong in a
convincing way.
Will you help me to find a solution on this?

[V. Lee Henson CST]

Hello There,

I am sorry to hear that you feel like you are not getting the value
from the VersionOne reports that you might expect. 2 things stuck out
to me as a red flag:

1) "you almost couldn't recognize vone using our configuration" = You
may have customized the application so much that the input into the
fields that generate the reports within VersionOne have no meaning and
are generating Garbage out reports.

2) Managers/Stakeholders are looking for very specific information
from "old fashion" type reports. One of the keys to successful agile
adoption is setting the correct expectations with your stakeholders up
front regarding visibility, reports, etc.

I am never one to point out negatives without having a proposed
solution. When organizations REALLY "jazz up" VersionOne to make it
their own, I find myself encouraging them to use the API and or SDK to
generate custom reports that could be fleshed out into really pretty
Crystal Reports. I must first point out as a VersionOne product expert
that 90% of the time I find myself walking into organizations and
helping them simplify to both make their lives easier and their
reports more meaningful. As part of the VersionOne Services team, I
would love to learn more about what organization you are with and
figure out a way that we could be in more direct contact to match your
expectations to the tool's capabilities.

More often than this I am hearing that there are too many reports and
so many ways to gather the data. The situation you describe truly is a
new problem to me. I am looking forward to your reply so I can be of
additional assistance.

Regards,

V. Lee Henson CST
http://agiledad.blogspot.com
VersionOne Product Expert
Certified Agile Enthusiast

[Kevin S.]

Somewhere in your organization Agile approaches were deemed good and
your organization decided to invest a lot of time and money into an
agile project management tool (V1). But it also seems like the shift
to agile philosophies, culture, and practices has not completely taken
hold. Until then, you will run into these problems.

You stated you are an ex-senior programmer. This puts you in a very
difficult position. If you aren't trained/practiced on the old way
(GANT waterfall) and you aren't working in a culture that believes in
the new way (ie: Scrum), then you are stuck in a struggle of two
cultures. You are going to have to stop fighting the current and
learn to swim in it (and recognize it is probably a whirlpool). This
is not a jab at your abilities, it is a comment on what you need to
overcome.

I agree with both of Lee's points and to his point of proposing a
solution... find the agile champions in your organization that started
the agile movement. Enlist their help in coaching the "old fashion
managers" you work with. Also, find the PM's that did it the "old
way" and see what they are up to now. You can either learn from how
they have adapted to agile, or learn how they are hiding the old way
of working inside an agile mask. You will have to decide initially
between learning to swim with the current and get what you need from
the tool, or become a change agent and push for the true agile
transition.

If you believe in agile yourself and want to learn how to talk to the
"old" project managers, here is a good article by Mike Cottmeyer (also
a V1 employee): http://agilesoftwaredevelopment.com/blog/mcottmeyer/how-talk-project-managers

Good luck!

[nig3d]

Thank you very much for you kind answers!
My problem is much much simpler actually :).
The stakeholders are not project manager, the stakeholders are not
producer, the stakeholders are marketing people!
They don't want and they don't care about learning what story point
means, how to read a burndown chart and so on..
they don't even read a gantt chart actrually, they usually just read
the starting and end date.
This forced me to simplify as much as possible the communication in
order to just show what is really need to know. The planned releases
dates and the current progress report.
I believe that if you carefully think about it, actually nothing else
is needed by who invest money.
Ok I really appreciate the scrum metrics to plan the project inside
the team, but my problem is not top-down, it's bottom up and I noticed
that when the communication goes from the bottom to the top actually
it gets simpler and simpler, because communication is the key and I
need to talk in such a way everybody can understand me, even without
knowing Scrum.
Under this point of view, the real useful progress report inside
VersionOne is the parking lot, but I think a couple of other reports
can help me a lot, since the parking lot is useful to communicate
about the current progresses, but not about the planned releases.
If you want to know more about what I'm talking about, and if you are
interested about it, I can explain you what I'd like to have.
If you instead want to share your experiences with me, it would be
very appreciated :)
thanks again!

[Kevin S.]

Aah... marketing.

Hmmm....

In some organization (strongly technical ones), marketing is part of
the team and will understand the process.

In the rest, I find it is best to just be a translator and build the
"project plan for dummies" into a powerpoint slide or two and be
done. When you dumb it down that far, it is probably quicker to just
build it and talk to them than force V1 into that model.

At a prior company, we had a standardized chart built in excel. After
going agile, we just pulled the dates from V1 instead of Project and
built the same charts. There have been projects where I create my own
version of this so that it looks similar every update meeting I
present in.

Good luck with that one!

[nig3d]

Thank you,

it's more or less what I do actually :D
Still the parking lot is "marketing people readable" and I think Vone
could be do something more on the future group side.

Actually all the feature group system is "marketing people readable"
but the reports related to the feature groups are few and not so
complete.

For example it would be great to see a feature group plan according
the projects plan (or iteration plan, but better the project plan for
marketing people). For my purposes, the plan should be made according
the feature groups of the stories inside the iterations inside the
project and not plan directly the feature groups according the project
where they are created, because usually I create feature group always
in root project of the project hierarchy.

The feature group roadmap looks similar, but story points estimation
is not something the marketing people can understand :).