15 January 2014
TMS actually matches quite closely. Is this real, or just matching what we should do?
Cost share also good.
Chris: Team told to "aim" for %, and mark it according to nominal commitment. He did not push hard on this, and feels that generally people are pretty honest about meeting their commitment. He thinks it was good enough, but not as accurate as it could be.
Richard: Used % commitment as guideline. Probably spent more time on grant than reported. PLS: why? R: fuzzy line between grant and deployments, where to report.
CONCLUSION: hard to account for time when multiple sources of funds for related projects.
Can we do better? Assume it will often be an issue.
CH: sometimes, might want more accurate data.
AK: Federal money has tighter requirements for reporting.
RM: If trying to develop metrics, better data would be helpful.
CH: Is JIRA accurate?
CH: IMLS was more stringent. MaryLynne wanted more support and info to sign off on data for effort. But did not take different aproach to TMS.
PLS: Is our data good enough to build metrics and do projections?
CH - would not want to do tighter reporting in both JIRA and TMS. Not sure if JIRA really represents work. Data not really good enough. PLS: Could we develop hard metrics for CSpace deployments? Hard.
CH: For Bot Garden and Cinefiles, tried to be more diligent about reporting effort to have better baseline. Now trying to leverage that to build better estimates for BAM art collection. Could be better, but hard to know when worth the effort.
RM: Are the tools and tech right, and could we learn how to streamline dev processes to get faster.
PLS: How do we analyze pain points?
RM: we don't - it is all in Ray's and Other's heads.
CH: But work on customization for Cinefiles, aside from a few new features that were expensive, most of the work went pretty well, and he is working efficiently. PLS: Would JIRA components help to group types of work for reporting? Maybe.
ACTION: reconsider how we use components in JIRA with an eye to more effective effort reporting and analysis.
Reporting and analysis from TMS:
Patrick tells people to be accurate to reality - useful for tracking.
Chris has folks periodically track time really closely, but not every week. Eye opening.
Patrick cannot get % distribution from TMS. AMy downloads to Excel to produce this.
CH: better data to our PIs would be good, and would be better for the relationship.
ACTION:DAG: we should do periodic updates to them.
PLS: How much would a PM in the dept help us, save us time, make us more productive.
DAG: WHen talk about CSpace, there are 4-5 areas of activity that we could consider. Distinguishing among these is important. If we had a PM, we would need to explain this, and they might help us to work out the boundaries, but we would have to have some clarity before we brought in a PM. We also need service managers.
Have to be careful not to have one person have too many roles. May need to have roles in multiple people to get good discussion.
PLS: COuld we justify a full FTE as PM? How we do determine the amount of need, and the benefit of having a PM?
DAG: Distinguish projects from services. Also have a lot of relationship management. Rephrasing PLS question to be what are all the management needs?
PLS: We have tried to do it ourselves, and does not work as well as it could.
PLS: How big a problem was it to not have a PM?
CH: Losing Penelope was a problem.
DAG: Early on, we spent a lot of time wrangling the project and would have been very hard for a PM to come into.
PLS: A PM might have saved a lot of time during that period.
CH: Need good governance to back PM decisions, set priorities.
RM: concern than work with Lyrasis is more churn, and we might lose time trying to be nice.
ACTION revisit discussion on PM support for our group.
CH: Not seeing value of scale yet. Pure linear, rather than benefits of scale. Hope to reduce costs, but not seeing it yet.
CONCLUSION: Need to figure this out.
ACTION: Work on how to shift from linear cost to less than linear.
RM: to chris: Would PM help to streamline new deployment planning and coord.
CH: Maybe, if right person. Reqts gathering, etc. Depends on person: Strict process person, not as much. If also customer facing, yes.
RM: backpedalled a bit, since we had more teams, etc. Testing is less rigorous. Docs always weak (relative to ideal). Relative to successful OSS, also weak. PLS: relative to docker, nuxeo, etc. Not bad relative to those.
PLS: big failing to not track documentation across teams.
RM: App layer is crappy code with mediocre docs. Fluid is better code with no docs.
RM: decrease in core dev. Tracking in JIRA for project work has fallen of. Testing not as rigorous as used to be.
PLS: did not do enough testing at scale under large load (people and lots of data).
RM: could still do more on this. Testing still takes too much time and people. Should automate much more.
RM Have done little or no refactoring. Will make it more costly to fix bugs, add new code, new features.
CH: Thinks we spent lots of time on this, and this cost us with customers who thinks we spent too much time on this and got no new features.
PLS: maybe need to be clearer why doing work that fixes bugs or real problems for others.
CH - may tease apart project and deployments. Leverage John Lowe's writeup of BotGarden.
PLS: Be clearer about Positive practices to talk about, as well as things to improve. Pull in whole team (at least for part, perhaps after initial analysis). Probably take more time.
DAG: be clearer about time period and scope. Give people time for a plus-delta that is more open and free form. Consider timing - he feels like current budget work is a distraction from good retrospective analysis.
RM: need to be careful about repeating what happened early on CSpace, with too much niceness and politeness, and descending into chaos or inefficiency.
PLS: What prios, etc.
DAG: Ensure we are clear and forthright about our priorities. WOrry less about CSpace as a project. Thinks we can do that more since we can rely on governance group for project.
PLS: Dependency on strong effective governance group that manages sustainability, etc.
DAG: Not that we disregard good of org, but that we push harder on our own needs.
PLS: Priority must be to get good strong proj director that we can work with. Need to work on requirements for position. Need to get gov board in soon.
ACTION: Develop and communicate our requirements and expectations for proj director. Ensure Lyrasis has this input.
DAG: Need to be clear on what we need and want from them.
RM: Can think of several things we need to have happen: As tech lead, wants to see commitment to ongoing, active development. Not just bug fixing, perf tuning, supporting SaaS. Someone should engage the community, develop list of needed functionality, seek funding, move this forward. Don't just limit ourselves to what current grant funds.
CH: Ensure project does not stall out during this transition. How to ensure code and community are active during transition.
DAG: Can we get the list of things we actually want? [Yes - CH has this]
All: limitation of the grant resources, and need to push on this.
DAG: better to bring a list, than to just say we want to keep working on it.
PLS: get SMK engaged as well. Also, ask Megan what she thinks, what her direction is.
ACTION: Talk to Megan.
RM: Need to focus on deployments outside UCB.
DAG: revisiting retrospective: order of deployments was right politically, but was a tremendous challenge.
PLS: Need to do more simpler deployments in first year.
CH: Not clear this is realistic. Thinks people have very high expectations.
CH thinks getting contributions in is important.
PLS: clearly, need to have all those in, and need profiles, so more museums can just go with something existing.
RM How much influence do we really have.
PLS: Need to engage with them about how governance works on project.
ACTION - above engagement.
DAG: Need to have our priorities straight, have clear list of what we think should happen, when, and how. May have to propose changes to original plan.
ACTION: Get our list clear, be able to make clear proposal for work going forward.
CH - Need two lists: General priorities for development and activity. AND new functionality to be developed.
PLS: If we build it, to whom do we deliver it? Committee, Lyrasis, ?
DAG: will need to wear UCB hat, and then sometimes wear community hat to ensure it all works.
PLS to RM: think about what dev lead role and his tech lead role at UCB mean, relate to one another, will work together, etc. What authority must we cede to them to effectively delegate work?
ACTION: RM to develop model of his role and their dev role, and relationship.
CH: ACTION: Need to set up regular periodic reviews of progress w.r.t. Lyrasis. Monthly for next 6 months, then quarterly. PLS to talk to Julie. DAG, CH, RM, PLS.
On to CSpace financials... - Patrick gave up note-taking.
ACTION: David Greenbaum we should do periodic updates with better data to our PIs; would be good, and would be better for the relationship.
ACTION: Talk to Megan about her stance on additional development, grants, etc.
ACTION: Richard Millet to develop model of his role and their dev role, and relationship.
ACTION: Patrick Schmitz Need to set up regular periodic reviews of progress w.r.t. Lyrasis. Monthly for next 6 months, then quarterly. PLS to talk to Julie. DAG, CH, RM, PLS.