Good morning Calgary. Day 2 of Access 2014. Continue reading “Access 2014: Day 2 Morning Notes”
Lead by Rosalyn Metz, Becky Yoose
Not agile, because with a single person team, it’s difficult to do SCRUM, so only agile-ish.
What are we working on?
Being with ‘what are we working on?” Have a meeting
This goes into helping to figure out the scope of the project.
5 why’s: basically, ask why 5 times. Everyone write down their answers. e.g. Want to redesign the website, but turns out because they don’t know what services are provided.
List of goals that you want to achieve, but what if you don’t know what your goals are?
Goal setting using SMART goals. Gives you a structure to work off of, and helps with project monitoring.
- S: Specific – should answer who/what/when/where
- M: Measurable
- A: Attainable – realistic given current resources
- R: Relevant – goes back to scoping, making sure addressing issues
- T: Time-bound – marking milestones & progress
Also helps you narrow down your scope, and leads into project charter.
Goal vs. Task: More general, what needs to get done vs. implementation details
- Design and develop an interactivity module from other code by the end of September. – will want to break down, more of a project objective
- Initiate development of code with team [add time].
- Testing API to see if meet requirements [add time/who].
- Have [person] teach one workshop with at least 20 registrants this summer at [this office].
Who are you dragging into this project?
- project executive sponsor – whether the project happens
- project sponsor – person who makes decision resources, people, budget, etc.
- project manager – person responsible for moving the project forward, beholden to executive and sponsor, also note person who comes up with idea is not always the manager
- team members – people doing actual work
Do this on your own or with someone trusted. Don’t do this with the stakeholders in the room.
You want to understand their place in the project, reason they’re there, the support they will provide.
If some people don’t need to be always be there, keep them up to date e.g. status report meetings. Take up little time, and do their influence. Be the protector for your team if need be.
Not everyone is going to be happy.
Make sure they’re in conversations up front, to see why it needs to happen. Will already have had the ‘why are we doing it this way’ conversations. See also Dealing with defensiveness in high conflict people.
If have unknown stakeholders, you might want to delay project until have all the necessary resources are in place.
Project One Pager
This is your project charter. It covers
- objective – conscise high level thing you want to achieve
- outcomes – your SMART goals, inumerate things need to be achieved to reach the objective
- out of scope – include things people will likely ask for
- team – who and role (not necessarily stakeholders) e.g. developer, handling metadata, user testing
- schedule – high level milestones, but might leave out and add after approval
Your work then needs to be broken down. Need to break into the small tasks. e.g. Goal of teaching cohort -> registration, marketing, book space, etc.
Want to team to come up with tasks, but can help them.
One person might be responsible, but that person can decide how it gets done. Give people a couple of days and come back.
It’s okay where what you’re doing is preparing for the next project.
The majority of the time should be spent planning rather than the work.
It’s to create the schedule and understand the cost. Frequently realize it’s not worth it.
The only way to estimate time is to do time tracking. Might try Harvest.
Time tracking can be a real eye opener.
Tend to vastly underestimate or overestimate, so best to use buffers.
Choose a realistic buffer. Applying the percentage to the entire project. Usually start with 10-15%: T / (1 – B%)
Use Fibonacci numbers (1, 3, 5, 8 – never higher) to assign numbers, see SCRUM in 10 easy steps article. e.g. Do 16 points of work every week.
Difficulty seems to be not getting developers to track time, but staff people outside of IT to track time. Approach by making workflows more efficient, more realistic. You can play the dumb person and ask how long it takes.
Can ask your vendors whether they have a project plan.
- estimating time ( in hours)
- benefits (as a percentage of income)
cost = P1(hour * salary/hour) + P2(hours * salary/hour) + …
Important to keep track of meetings when tracking your time.
Use a spreadsheet to calculate cost of total, plus number of hours per week for each team member (and the cost). For example, if can only commit more than 20%, should not be spending 40 hours in a week on the project.
What do you track? It depends on who is funding the project.
If grant funded, depends on what is required based on the grant. Sometimes grants don’t cover certain things, or institution needs matching funding.
Internally, contact your supervisor, their supervisor, or contact person in another department.
The key is to keep it transparent.
Budget (spreadsheet) only one piece of reporting.
Have a communication plan (see example).
Team standing meetings meant to be very short. All people involved in that portion of the project say 3 things:
- what did you do after the last meeting?
- what are you planning before the next meeting?
- issues preventing from work getting done
Informal, but technical = daily grind.
Status reports in comparison, regular, more formal, but regular
Reporting is absolutely necessary and needs to be clear, consistent, concise. Stakeholders feel like they’re involved in the project even if they’re not really.
Handling Issues that Arise
A lot of people fall back to issue tracking system, is not a project management strategy.
Need to work out workflows around tickets. Are you going to use it for communication, time tracker? Customize system for that use which statuses, attachments, granularity, etc. Internal vs. external notes.
Who is responsible for which types of issues. Have primary and secondary contact.
Also, what is timely matter? Depending on during or outside of business hours.
May need to convince users to submit the information the new way. Talk to them about it not ending up in a black hole. Make sure have confirmation that issue has been added.
Need to also make sure the tickets are in scope. Go back to project charter if need to reference something.
- support consortial digital repository
- open source
- different user permissions
- email features
- good adoption
- time tracking in 15 minutes increments
- will make Gantt charts for you
- lessons learned: don’t overload users with the emails from the issue tracker
- previously used Trello
- paid service, web based
- can have pre-made teams, templates
- can import whole teams or templates e.g. checklists
- calendars can be exported and show on public page
- integrates well with google docs
- text features to throw notes together
- has API
- good for managing resources as well
- basically a big whiteboard/sticky note system
- but very basic
- track issue and for code, plugged into webserver
- one repository for each project
- one meta project to track all projects, including non-code projects
- can be difficult to search or filter issues
- everything in one place
- has email notification
- can’t assign due dates or track time
- can assign issues to larger milestones which can have due dates but have had mixed success
- great customization
- can take a lot of time to customize
- but will do whatever you want it to do
Different tools work at different organizations. Tools are only as good as the people that are using it. Need to be consistent about using it.
Do whatever you can to make it easier e.g. single sign-on.
When is it done? Met the outcome and objectives.
However, it doesn’t mean you can wash your hands of it.
Learn from your experiences. Take those lessons learned and apply into future projects.
Might be a presentation or report, template, etc.
Why did it go wrong? Some things that are external you cannot control, but internal things you can change.
Once you finish the project, you have a product.
While the project is done, you need to continue to maintain it.
Product owner = product manager. Lifecycle function dealing with planning, marketing, maintenance throughout the entire life of the product.
Product manager is the heart, mind and voice of the user. Not your own voice.
Have to make the hard product trade off decisions. e.g. which features to include.
Provide a second opinion on how things work. Create a trust relationship with the development team so you can ask questions.
The most important thing is communcation.
Dale Askey, Mark Jordan, Catherine Steeves, & MJ Suhonos
What is a culture of innovation? Continue reading “Access 2013: Culture Clash: IT Experimentation, Innovation, and Failure in Libraries”
I don’t think I really realized how important ergonomics are until these past couple of weeks. Unfortunately, the setup at work is less than ideal, and my neck and shoulders have been in a lot of pain this week. Continue reading “Office Ergonomics”
For more than half a year now, I’ve been trying to get an issue tracker fully implemented for our IT team within the library. I admit that I’m still working on it. Getting the system up and running was easy enough, but trying to work it into people’s workflow isn’t so easy.
Choosing the Issue Tracker
There are a lot of issue trackers out there, but we are a small team and I wanted the issue tracker running easily and quickly. It’s not something I wanted to spend a lot of time getting up and running, because we had a lot of other projects happening.
Other requirements included:
- support multiple projects
- non-members being able to report issues
- support email issue management (either built-in or plugin)
- low to no cost
- support CAS or LDAP login (either built-in or plugin)
- documentation area and/or wiki
- code repository integration
- open source
I asked around a little bit, and these were the recommendations I got:
- Asana: 2
- FogBugz: 1 Against: 1
- Footprints: – Against: 1
- Github: 2
- JIRA: – Against: 2
- Pivotal Tracker: – Against: 1
- Redmine: 5
- Request Tracker: 1 Against: 1
- SupportPress (for WordPress): 1
- Trac: 3 Against: 1
Trac and Redmine seemed to be the two forerunners. My problem with Trac was that it didn’t have clear project organization, and no one could confirm that the email issue management plugin worked.
Installation & Setup
Our system administrator took a couple of (not full) days to get it installed and going, and following the instructions were apparently fairly easy. Then it took me maybe half a day to set up all the projects and users with the settings I wanted. The e-mail creation also worked well out of the box. We just had to make sure we had the right settings for what we wanted.
Staff Issue Creation & Management
In order to make it so that staff can file issues without ever having to see Redmine, I created a form in our Intranet (webform module in Drupal). The form had most of the standard fields:
- Name: automatically filled in with username
- E-mail: also automatically filled in
- Related to: options which were essentially the project names
- Need: options equivalent to tracker e.g. Support, Bug Fix, etc.
- Priority: options equivalent to priority
- Summary: email subject line, which then turns into issue name
- Description: issue details
Once it’s submitted, a copy is sent to our team’s email. Through a cron job (every 5 minutes or so), the email is picked up, and filed.
If the user already exists in the system, Redmine will use the email from the user account to match it to the user, they will automatically become the ‘reporter’ of the issue, and get a copy.
If the user does not exist in the system, Redmine will say that ‘Anonymous’ reported it. This will always happen the first time someone reports an issue as I did not add everyone on staff to the system. So, the first time this happens, I then add the user to the system, and add them as a watcher to the issue.
The one issue I ran into was that I forgot you have to set both the email plugin and each project to accept issues from anonymous users. Simple carelessness really.
Getting Staff to Change their Workflow
I think the hardest part with implementing any issue tracker is getting staff to use it. Within the team, it hasn’t been too difficult. We have a small team and the developers in particular have no problems using it. The only problem I sometimes have is making sure they close issues when they’re done with them.
But even within the team, sometimes it can be difficult to get people to report issues using Redmine. While our manager wanted us to start using it just for the website, it has worked well enough, so we’re strategizing how to get the rest of the staff using it now.
We’ve concluded that it kind of needs to be an all or nothing. So we’ve decided that all non-urgent issues should be done through the intranet form regardless of the project, and that should people email us, we’re going to be emailing them back to submit it through the form.
For any urgent issues and for immediate support, they can still call us. After all, trying to walk someone through editing something on our website or intranet is much easier by phone anyway.
Before we start enforcing it, we’ll be introducing this workflow to staff through various committee meetings in part to gather feedback.
So… we’ll see how it goes.
by Matt Thompson (absent), so actually Gunner
Processes & Tools
The process and tools, and how things are done should be open. Etherpad – like a google doc. Collaborative, and in Mozilla, tied to conference calls.
Give guidelines, not direction.
Some are a little open, but to be truly open, everything is open not just the nice looking bits. For example, the Firefox mailing list is open. The discussion on Chrome “kicking their butts” was a public discussion.
Need to pro-actively report out, especially for offline conversations.
If you’re going to work in the open, it’s about the community. Have to ready to share: ownership, control, everything.
How to contribute from day one. Make a wishlist (e.g. documentation, testing – never done). Ask for things to be added to the wishlist.
Have core community values.
Having a Narrative
Naming the contributors, and having an ongoing story.
Give other voices a channel. Invite others into the narrative. e.g. put someone else’s story into your blog.
Still have to have governance though. Study other successful projects, e.g. wikipedia. Key is a benevolent dictatorship with radical openness.
Risk aversion and fear is failure before even beginning.
Study the licenses and pro-actively license your content. e.g. GPL, Mozilla
Leading with questions to ask one-on-one why they
E-mail and IRC suck.
Best practice is to move to audio/video if the e-mail and IRC is not working.
Setting frame for discussion. Turn it from “Do you want a vitamin?” to “Do you want the orange or purple vitamin?” Another example would be to share only benefits of two choices.
Use open paradigm. For example, Twitter uses volunteers to localize, so even though it doesn’t use an open platform, it uses an open model.
But propriety, locked down systems are in the process of dying. There are companies that are open software corporations e.g. Firefox, Redhat. What really makes you special is customization, service, etc.
Start internally. It doesn’t need to be open externally. It can open within the organization first.
Learn from Others
Study the successful open companies and organizations.
Model for success, status quo and failure as a win, because you have learned what not to do again.
Think ahead and think aloud.
While I admit that I have not gone to many library conferences, I thought I would reflect on attending my recent outing to Seattle.
Funding & Limitations
Fairly obvious, but it was important for me to know how many conferences I might be able to attend in a year. If hired as a permanent position, most librarians get a set budget for attending conferences and other events, but on contract, it’s a per-event approval process (as it tends to be at most institutions).
Based on what I heard from others, I think it is key to know what kind of policy administration usually has. I’ve heard from some that non-permanent full-time librarians get absolutely no funding, and even permanent full-time librarians sometimes have to wait 1-2 years before getting funding.
There is, of course, the choice of funding a trip yourself on your own time, but these costs can be prohibitive for new graduates or those with lesser financial means.
Choosing the Right Conferences
On a bit of a side note, I think it is also up to the individual to pick and choose what’s right for them. There are so many conferences being held all the time, it can be very difficult to choose. Being able to only choose 1-2 conferences in a year, I decided against the larger, more general conferences (such as CLA, ALA, or the provincial ones) because I felt that many of the sessions were just not relevant to my interests and position. Instead, I decided to focus on technology related conferences, namely Access and Code4Lib.
Other more local events, which only involves work time, with little or no fees and travel costs can help to supplement or be alternatives to larger events as well, especially regional versions of larger events. Once again though, depending on the policies of the organization, this might involve an individual paying their own way and using vacation time to attend.
How Can We Help?
One of the discussions I got involved with while in Seattle was, how can we help new graduates/librarians (and librarians in more restrictive positions perhaps) attend conferences?
While many conferences offer discounts on registration fees or free attendance for volunteers, registration fees are not usually that high (at least not at library conferences). Even airline tickets are fairly low cost when flying within the US (though admittedly to/from/within Canada can be quite expensive). What makes a trip prohibitive then is usually the hotel, which generally costs at least $100/night.
Then, what can be done to help with these costs?
- Scholarships: many have student scholarships, which is great, but maybe they can be opened up or a couple can be made for those in need (who are not necessarily students) – it was the only reason I could attend Code4Lib this year
- Roomshare/Rideshare: while we had this at Code4Lib, I’m not sure how well it was advertised (but then I got in late in the game). Maybe if it was advertised on the main webpage or somewhere in the registration process, a list of people willing to share can be generated.
- Hostel Room: Similarly, facilitate a way for a group to get a hostel room together (while they might still be strangers, personally, I would not mind so much with fellow conference attendees as opposed to complete, possibly unfriendly strangers).
- Ask Locals to Offer a Couch/Floor/etc.: I admit that this would be probably difficult for large conferences, but if locals could offer a place to sleep to those in need, I think it would be a great way to encourage new folks to attend. (Organizers can consider writing a simple guideline, such as only if a person doesn’t have any funding sources to attend.)
I’d love to hear other ideas, which might be passed on to conference organizers, especially for Code4Lib 2013.
by Bethany Nowviskie, University of Virginia
She began by expressing that it is great to have a speaker from the inside the community and lots of thanks to the invitation to talk. Then continued to talk a bit about her background and where she is coming from, including Blacklight and Hydra. She is now in the library world, where she was introduced to many issues such as open access, class issues.
Frequently, lazy consensus gets formalized, such as in committees. When a decision needs to be made, a proposal is put forward. Some might agree, but the default answer is yes. If there are objections, then you go back, but usually just some adjustments. In order to object, people need to take the time to think and take the effort.
Some might think that there are fortunes for the bold. However, with this social contract where we already agree that if you don’t say yes or no, “we’re not waiting on you,” inertia can work with you or against you.
Your team should work in lazy consensus. Use it to do what you know is right. How do you know what’s right? Make sure you’re one of the good guys. Act and speak up when you need to.
- skunkworks / R&D operations – trust them to have a plan
- developer-driven 20% time
- rabble-rouse… in disguise – organize smartly to fit in
- knowing your enemies (trends, not people) – extract personalities, because usually fighting bad trends, not people
- finding your friends (people, not just trends) – check data preservation, open access, digital humanities people
Your (Ethical) Obligations
- always share information freely – it will fail otherwise
- never shut out the public services and user experience
- practice what you’d teach – think mentoring a promising novice
- if you screw up, confess
- try not to screw up in the first place
If you have a bad technical plan, the library administration might not notice whether you implement it to the letter. They probably care more about the spirit than the letter of it. However, do genuinely try to explain to all levels of the organization.
Never do it alone. The word consensus is in there for a reason. You need enough people who agree on the direction to take that can be implemented reasonably and sustainably.
Keep talking to people.
If you produce, administration will have your back, but then you need to deliver a product that will make everyone look good, even the dead weights.
The library is not involved enough in larger issues at the university, national, or government level. One common example is the research that is produced, peer-reviewed, and then sold back to the university at exorbitant prices.
It’s up to you to make contact with the leadership level of the organization. If you have a problem, put it on the agenda. Make the first move.
There should a bias toward action. Stagnation is a far, far greater danger than taking measured risks.
Drive it like you stole it.
Q & A Comments
Does this reflect reality? Sometimes it is the person. – Act like it is the trend, even if it is the person. This will work better in some areas than others, but it is flexible.
Some believe that they are righteous and do not care about consensus. – Power to the people. Get enough of the staff to implement a directive.
How to deal with it going wrong? – Hard to do sometimes in formalized way, and need to do collectively.
EDIT: Bethany has now posted her version of the keynote talk on her blog.