intranet – Web Services

Wiki Meetings

Posted on December 10, 2009December 10, 2009 by Steve Daniels

Early on in the New Year the old Intranet here at Edge Hill will be abolished. All of its content will be available directly through GO. The platform we’re hosting this content under is called Confluence and it’s a wiki.

To the majority of people this won’t mean much right now but we’re hoping in the future it will. You’ll be able to manage your own content on GO for dissemination to colleagues you work with on a daily basis and those you work with across the university.

This new way of managing things will hopefully reduce the amount of out of date information that is out there. You shouldn’t be emailing around Word documents within the university. Because the moment you send that document it’s out of date, your recipient just doesn’t know it yet!

Lets take Meeting Agenda’s as an example. The below video describes why you shouldn’t be emailing meeting agendas and why you should start using a wiki:

The Faculty of Health is already doing stuff like this, posting meeting dates in their calendar, having agendas online, with misc documents for the meeting available on each meetings dedicated pages. You department can too!

Another brilliant use of the wiki is to keep track of action points:

These excellent videos are courtesy of Stewart Mader’s 21days you can find a lot more videos there and other extremely useful wiki related resources.

What’s Up Docs?

Posted on November 19, 2009 by Mike Nolan

There are big changes coming to the staff intranet! The staff intranet, also known as “docs”, is the default homepage for staff on campus and has served us well for the last… actually I don’t know how many years! But it’s becoming increasingly apparent that the systems – both process and technical – are not able to scale with the growth of the University and with the increasing reliance on the web as a publishing point.

Along side the staff intranet, for the last three years we have had GO, our portal system available to both staff and students offering single sign on access to a range of web-based services from Edge Hill. While it’s been possible to access the intranet via GO, it’s never been well integrated but our changes will move to a single platform.

For about a year we’ve been slowly growing our use of Confluence, an enterprise wiki system which will manage most of the content available through GO. To date the Faculty of Health has been the largest user as part of their extranet project but over the next few months we will be implementing the migration of the contents of the staff intranet into Confluence.

We’ll be using this opportunity to give sites a good winter clean and give access to departments to enable them to easily create and update pages and link to files, all through a web interface. The wiki offers a number of other benefits such as searching across pages and documents, and – of course – integrates with many other services available through GO.

GO and the staff intranet are very different beasts and so we’ll be making further developments to aid the transition. Some of these might be temporary such as a new default homepage for people who haven’t yet taken advantage of the personalisation available through GO. Other changes will apply to everyone including students.

I’m pretty excited by the changes that are coming and we’ll be introducing some possibly as soon as early December so stay tuned to find out more!

Burning down the house

Posted on November 6, 2009November 8, 2009 by Mike Nolan

This week Web Services started a new way of running some of the projects we undertake. It’s still early days (five of them!) but I thought it might be useful to explain what we’re doing so that we can reference it in future.

The system we’ve adopted is called Scrum – the name comes from the game of rugby – and is a commonly used agile development technique.

As with any project management system there’s a whole load of terminology and scrum is no exception. We’ve got pigs and chickens, scrum masters, product owners, sprints, backlogs and daily standups! I’m not going to explain everything now but here’s a few of the things we’ve done this week. I’m sure we’re doing some things “wrong”, but that doesn’t bother me too much.

The first project we’ve introduced this technique to is the migration of the staff intranet into GO. We’ve set ourselves an ambitious timescale to get it moved across by the end of the year and it has a good balance of development, design, content creation and training meaning everyone in the team is involved. Again, there will be more information about the intranet to GO migration coming out soon!

I was advised by Alison Wildish Kerwin (formerly of this parish) that the roles of product owner and scrum master should be distinct so Steve, whose work for the Faculty of Health involves a lot of development work on GO, agreed to take on the latter role.

The process started off at the end of last week when Steve and I – now undertaking the role of product owner – met to draw up the product backlog. This is the list of things that need to be done on the project. We already had lots of things to do to GO and added in a bunch of jobs related to the migration. We tried to make sure each job was well defined so that anyone undertaking the task could get going straight away.

Fast forward to Monday morning, 10am and our first team scrum meeting. After I’d explained what I understood it to be about we took a break to play poker.

Before I get into trouble, we weren’t sat round a table with a stack of chips playing Texas hold’em, we were playing Planning Poker. This is a way for the team to collectively decide how difficult each task is. In our case we’re using story points instead of time as a measure of complexity as everyone has different skills so what takes me a few hours might be done by someone else in a matter of minutes, but the complexity doesn’t change.

Aside: I’ve seen some really nice planning poker cards from Moo and other companies but I’m cheap and don’t want to pay $$$ for them so I made a set with a marker pen and some of the hundreds of old business cards that are in my drawer!

In Planning Poker, each task is read out and players each choose a card. If there is a consensus, the ticket is allocated that point score, otherwise the highest and lowest players are given the opportunity to argue their case. The process is repeated until there is agreement before moving on to the next ticket.

Once this was finished I quickly sorted through the tickets and gave each a priority from one to five before passing the product backlog back to the team to select tasks. Some tasks were selected by individuals, others by pairs to undertake during the first sprint. I didn’t try to influence this process too much but if a job was selected, it had to be completed by the end of the week.

Nine tasks totally 65 story points were selected to form the Sprint #1 backlog and the project was now underway.

Sprints are short, iterative cycles in the project development where each final output should be a “finished” product. I consider finished not necessarily to be something we’d release to the public but at least something that we’d show to stakeholders and clients. In most scrum teams, sprints are 30 days long but I think this is probably too long for many web development projects where there are fewer hard software engineering problems.

So we have adopted one week sprints. This may turn out to be too short but for now it’s giving us the opportunity to see how the cycles work in a shorter time.

Each day at exactly 11am we have our “daily standup”. So far there hasn’t been much standing up going on but I can let that slide. Each person in the team has the opportunity to say:

What they did yesterday
What they’re doing today
Any problems preventing them from achieving their goal

These meetings last at most 15 minutes (and so far much shorter) but are really useful to give everyone an awareness of how the project is progressing. As tasks are completed they are closed in our ticket tracking system and we can update our burndown chart. This is a graph showing how many story points are outstanding each day and means we can see at a glance how work is progressing.

Today after the daily scrum meeting we took the remaining items from the product backlog (with a few additions) and started the next cycle, first playing planning poker, then choosing tickets to undertake next week. For next week we’ve introduced one task from another project – Topics/125 – and we’ll be using scrum for more work over the next couple of months while we assess its long term effectiveness.

So that’s all for our first week of scrum! I need to thank Alison and Andy Male from the University of Bath Web Services. They’ve been very patient in answering all my questions about how they use scrum over the last few weeks (and months!).