General information

Librarians in the Wild: Information Architecture

  As I explained in my previous post, the Librarians in the Wild series will highlight non-library fields that are a good match for librarians looking to expand their career horizons. Given LITA’s technology focus, I thought it would be appropriate to focus this first post on Information Architecture.   What is it? At its core, the field of Information Architecture is concerned with helping people (users) find what they’re looking for, typically in an online or application environment. Sound familiar? According to the Information Architecture Institute (IAI): A good IA helps people to understand their surroundings and find what they’re looking for – in the real world as well as online. Practicing information architecture involves facilitating the people and organizations we work with to consider their structures and language thoughtfully. Information Architecture is not focused on building systems; it is concerned with fulfilling user needs. Yes, technical know-how is useful, and usually the…

General information

Librarians in the Wild: Selling Librarian Skills Outside of Libraries

  When I decided to pursue the MLIS seven years ago, it wasn’t so that I could tap into a vast supply of readily available Librarian positions. I did it because I was drawn to the profession and intrigued about how technology was changing it. My first job search as a degree-toting Librarian was a lucky one: I happened to find a place who needed someone with a strong foundation in project management and web development as well as an interest in librarianship, and that is as good a description of my professional self as you will find. That’s how I ended up at Avery Library. Then life happened. As the project I was working on was ending, my wife and I decided to leave New York and return to San Diego. I’m not going to go into our reasons for moving, because they’re not relevant here; suffice it to say, my professional goals took a backseat to other considerations….

General information

Providing Access through GIS Data at Avery Library

Technological advances can have a variety of effects on access to information. New technologies can change the breadth, depth, and sheer amount of information we can readily consume. They can also fundamentally change the way in which we organize and access that information. One example is the way in which the use geolocation coordinates (also knows as GIS data) as an access tool has changed in the last decade or so. While I was working at the Avery Library of Architectural and Fine Arts I was part of a concerted effort to explore the possibilities that GIS data offers for providing access to and context for collections. This is a brief look at three different projects that highlight different ways in which the same basic data can be used to change the way in which a library user interacts with a collection.   The New York Real Estate Brochures (NYRE) Collection The NYRE project is a look…

General information

Agile Development: Building an Agile Culture

Over the last few months I have described various components of Agile development. This time around I want to talk about building an Agile culture. Agile is more than just a codified process; it is a development approach, a philosophy, one that stresses flexibility and communication. In order for a development team to successfully implement Agile the organization must embrace and practice the appropriate culture. In this post will to briefly discuss several tips that will help develop Agile development. The Right People It all starts here: as with pretty much any undertaking, you need the right people in place, which is not necessarily the same as saying the best people. Agile development necessitates a specific set of skills that are not intrinsically related to coding mastery: flexibility, teamwork, and ability to take responsibility for a project’s ultimate success are all extremely important. Once the team is formed, management should work to bring team members closer together and create the right environment for…

General information

Agile Development: Sprint Retrospective

In my last two posts I’ve discussed how to carry out sprint review and sprint planning meetings. This month we’ll look at the final component of the sprint boundary process, the sprint retrospective, which is where the team analyzes its inner workings. Objective The sprint retrospective is an opportunity for the development team to review their performance over the previous sprint, identify strengths and weaknesses, and modify processes to increase productivity and well-being. Timing The retrospective should take place near the end of the iteration. It usually follows the sprint review, and can be held immediately following, but some sort of boundary should be established (take a short break, change the room, etc.) to make it clear that these are two very different meetings with very different purposes. The length of the meeting will change from sprint to sprint; budget as much time as you think you will need to fully explore team performance. If there isn’t much of substance…

Original Content

Agile Development: Sprint Planning Meeting

In my last post, I talked about the sprint review meeting; this month we look into planning a sprint. As I said last time, this meeting should be separate from the review, both to differentiate the two and to avoid meeting fatigue. Objective Sprint planning takes into account the overall project plan and the results of the previous sprint (as presented in the sprint review) and sets out a plan for the next week discrete development time period. Timing The timing of the sprint planning meeting is the subject of much discussion, and different teams adopt different conventions based on what they feel is the best fit for their particular process. Personally, I prefer to hold the planning meeting on the same day as the review. While this puts pressure on the Product Owner to quickly adjust planning materials based on the outcome of the review, it has several important advantages: The knowledge acquired…

Original Content

Agile Development: Sprint Review

At the boundary between sprints, there are three different tasks that an Agile team should perform: Review and demo the work completed in the finished sprint (Sprint Review) Plan the next iteration (Sprint Planning) Evaluate the team’s performance during the sprint and look for improvements (Sprint Retrospective) While it may be tempting to package that entire list into one long meeting, these should really be separate sessions. Each one requires a different focus and a unique cast of characters; plus, meetings can only last so long before efficiency plummets. Over the next set of posts I will be discussing each of these tasks separately, in the order in which I listed them. Even though planning happens first in any particular sprint, I prefer to look at the transition between sprints as a single process. So, we’ll start with Sprint Review. Objective As we’ve discussed previously, one of the core values of Agile is to prioritize working…

Original Content

Agile Development: The Daily Standup

The cornerstone of Agile development is the sharing of information. An Agile team that does  not communicate well is destined to fail: the focus on efficiency and short,  independent development cycles means development moves at a rapid pace, and there is much slack in the timeline to account for communication hiccups. Therefore, the each member of the team needs to be aware of what everyone else is working on, as well as any impacts and dependencies between her assigned tasks and those of her coworkers. With sprints lasting two or three weeks each, it’s imperative that team members be proactive about sharing the status of their work. While this can (and should) happen as informal conversations between team members, Agile provides a tool to encourage frequent communication: the daily standup. What it Is The daily standup is a meeting where team members discuss their own immediate goals and challenges. It is typically held at the…

Original Content

Agile Development: Tracking Progress

In my last post, I discussed effort estimation and scheduling, which leads into the beginning of actual development. But first, you need to decide how you’re going to track progress. Here are some commonly used methods: The Big Board In keeping with Agile philosophy, you should choose the simplest tool that gives you the functionality you need. If your team does all of its development work in the same physical space, you could get by with post-it notes on a big white board. There’s a lot to be said for a tangible object: it communicates the independent nature of each task or story in a way that software may not. It provides the team with a ready-made meeting point: if you want to see how the project is going, you have to go stand in front of the big board. A board can also help to keep projects lean and simple, because there’s only so much available…

General information

Agile Development: Estimation and Scheduling

In my last post, I discussed the creation of Agile user stories. This time I’m going to talk about what to do with them once you have them. There are two big steps that need to be completed in order to move from user story creation to development: effort estimation and prioritization. Each poses its own problems. Estimating Effort Because Agile development relies on flexibility and adaptation, creating a bottom-up effort estimation analysis is both difficult and impractical. You don’t want to spend valuable time analyzing a piece of functionality up front only to have the implementation details change because of something that happens earlier in the development process, be it a change in another story, customer feedback, etc. Instead, it’s better to rely on your development team’s expertise and come up with top-down estimates that are accurate enough to get the development process started. This may at times make you feel uncomfortable,…