Friday, July 15, 2011

New Article: Repositories post 2010: embracing heterogeneity in AWE, the Academic Working Environment

After beefing it up a little, Peter Sefton and I had our Open Repositories 2010 paper published to the Journal of Digital Information (JoDI). Check it out at http://journals.tdl.org/jodi/article/view/1766/2165. I now need to start getting our OR 2011 paper ready for submission!

Abstract
The organizers of the 5th International Conference on Open Repositories list nine polar dichotomies that represent “The Grand Integration Challenge” for the repository community/movement. In this paper we take up the challenge. We do so in the context of a our work to build infrastructure for the academy in general, with the goal to develop a modular 'Academic Working Environment' (AWE) which encompasses both teaching and learning on one hand and research on the other. Repositories and the ecosystem of services and workflows that surround them play a key role in this emerging system.

Friday, June 10, 2011

Tuning your project's GPS

[T]here are known knowns; there are things we know we know.
We also know there are known unknowns; that is to say we know there are some things we do not know.
But there are also unknown unknowns – the ones we don't know we don't know.
- Donald Rumsfeld

I'll dare to be very simplistic and state that most projects can be abstracted into 3 main stages – determination of a goal, advancement towards that goal, and completion of the goal. There's lots to debate in that tiny framework: the time-frame, the notion of “complete”, how pure the goal remains through the process, etc. but let's run with this for a bit.

Most projects start with the determination of a goal. This may be directed towards solving a problem (“People are copying music and we want to stop it”) or maybe to create/design something new (“What does the next form of online communication look like?”). Assuming it is agreed that this goal is worth pursuing, an effort is undertaken to reach that goal. In some cases the goal is not really achievable – your project is an ongoing effort to get as close to the goal as possible – but you have a direction that you're heading in. At the end of the project or at a useful point in time (say, the release of the next version) you look back and reflect on how well that goal was being worked towards. You may then continue your efforts, refactor the goal or just dump the project.

Newell and Simon (1972) described that middle stage (advancement towards the goal) as a space through which problem-solvers must traverse to achieve their goal. It is in this problem space that we often see the trouble begin.

Consider a project that you've been on recently – did you experience staff changes, political pressure, changing technologies, ideological differences, technical hitches or just anything that made the traversal go off in a different angle to what you'd expected? If you didn't then you probably ran the project in your own shed, with the door locked. If you did then the map of your traversal features a few detours, renegotiations and stop signs. Understanding (or at least generally comprehending) the space through which your project is traversing is the difference between watching your project fall from the sky like a flying piano and getting somewhere near your goal.

In their 2003 paper “The new dynamics of strategy: Sense-making in a complex and complicated world”, Kurtz & Snowden state that “we challenge the universality of three basic assumptions prevalent in organizational decision support and strategy: assumptions of order, of rational choice, and of intent”. Having thrown down (or taken up) this gauntlet, they present their Cynefin sense-making framework. This was modified slightly in an HBR piece in 2007 and makes for a useful reflection point when you just can't see the forest for the trees.

Cynefin describes four domains: Known (Simple), Knowable (Complicated), Complex and Chaotic. I find these to be useful reference points on projects as they beckon me to review the project environment and explore why things are going the way they are. I also like the fact that Cynefin isn't the same old 2x2 matrix that every second analyst seems to barrow out whenever they want to describe an optimal outcome. As Kurtz & Snowden indicate, there is no optimal state in Cynefin – you can't make everything stable (simple) and nor should you want to.

In the Known domain we see standards, well established procedures and even best practice. If we feed in input X, we get output Y and we always get output Y. In terms of technology projects, this domain invites ERP and off the shelf solutions. You probably use more traditional, structured approaches to project management, based on the SDLC.

The Knowable domain is less structured than the Known but, with the help of experts, you can find a pertinent pathway. We need to engage with the right people in the organisation to understand how and why things are. We can acquire systems that can be customised to achieve our goals and the project can be reasonably structured but we must be aware that eliciting expert knowledge is rarely a straight-forward brain dump.

Projects in the complex domain are probably my favourite. There aren't any really solid rules and you need to search for themes, commonalities and patterns as you seed ideas and check the response. In this domain there's probably not a lot of single, off the shelf titles that will meet the goal requirements. Instead you call on a mix of existing software, development, data exchange and training to work towards the goal. This, to me, is the domain in which agile practices fit well. Quick iterations, frequent demonstrations and releases, and close client contact allow the team to see how effectively they are traversing the problem space.

Chaos can be a difficult domain in which to run a project. Chaos can take form when you've suddenly dropped out of one domain due to an unplanned "happening". Maybe it's cutting edge work, a huge upheaval in the organisation, or it's a death march project taken over by a sociopath manager that has their own dream to fulfill. In operational systems, chaos occurs if your system suddenly fails (hacked, rushed/forced to production, solar flare). At this point you have to move quickly and definitively to fix the problem. Once fixed, you may be in a good position to explain (again) to senior management why you've been lobbying for that high availability setup.

To be honest I lied a bit – there's a fifth domain, disorder. You're most likely to have experienced this domain if you're a high-school teacher trying to teach VB6 to students that found a case of Red Bull in the fridge at little lunch. Being extremely agile here is the only way to weather the storm.

These domains aren't set on some dogmatic lore and you may even notice the your project spans across more than one domain. Take for example a payroll system. It's most likely in the Known/Knowable domain in terms of software but the organisational context may be Complex/Chaotic. Maybe Product X was selected but the accounting team used Product Y and look set to engage in passive/aggressive mode. Maybe you're facing an organisation with 6 payroll systems or maybe you got the budget for the software but none for the customisation.

It is important to bend your mind a bit and see if the domain really is what it appears. Perhaps what you're seeing fits the Known domain but it's really out of date and people are just clinging on to old ways – maybe it needs some disorder thrown at it. What's critical is that you get a sense of how decisions and understandings are reached within those domains. Armed with this you'll at least be able to tailor your navigational instruments as you motor towards your goal.

As someone who often works on projects that seek to introduce several new concepts to stakeholders I am often suprised that it's a struggle to convince the project office that agile methodologies are more effective than their highly structured project management framework. Everyone in the room knows that the timelines and feature-set will be difficult to set out up-front. Everyone in the room knows that we're doing more than development work - we're bringing about cultural change. But not everyone in the room likes to admit that things will get complex.

References

Kurtz, C.F. & Snowden, D.J., 2003. The new dynamics of strategy: sense-making in a complex and complicated world. Engineering Management Review, IEEE, 31(4), p.110.

Newell, A. & Simon, H.A., 1972. Human problem solving, Prentice-Hall.

Snowden, David J. & Boone, M.E., 2007. A Leader’s Framework for Decision Making. (cover story). Harvard Business Review, 85(11), p.68-76.

Wednesday, June 1, 2011

GTD® as my personal product backlog

No time to discuss this as a committee - Han Solo

I forget things - I admit it. I also look at a mass of work and struggle to know what I should do next. Part of the problem is that I have a wide range of interests and often work across a number of projects. Another issue is that I can get bogged down in the procedural if I'm not careful. My goal over the past year or so has been to organise myself so that I can better see to what needs to be seen to and give myself time to get above the forest.

I have kept lists for quite some time - sometimes on paper, sometimes using software. What I didn't really do though, was see these lists as an ongoing effort in knowing my priorities. In some ways, this xkcd comic boils down exactly what I was doing. Lists can be a prison if they're just a huge blob of stuff. This really hit home when I looked through the issue list for software that had been developed by a team I worked with. This issue list had hundreds of items, some were defects, others were features. Each week this list just rolled over and got larger. It was impossible to work out what needed to be seen to now and what was just some blue-sky thought. In the end, the development team appeared to just ignore the list and deal with issues they were being called about. My lists treated me a little differently - they made me feel guilty that I wasn't finishing everything.

So, with the idea that I could do better at this, I picked up David Allen's book Getting Things Done. David talks about many of the issues I was facing and presented a process that I find rather natural:
  1. Collect all of my stuff - emails, articles, meeting notes etc
  2. Process this stuff - work out if I need to do something and, if it takes less than 2 minutes I do it, otherwise I Organise it (next step)
  3. Organise tasks in terms of priority, project etc
  4. Review my tasks on a weekly basis to ensure priorities match my current context
  5. Work through the tasks as a series of "next actionable items"

What really hit me was the similarities with Scrum. In essence, I was drawing in my various inputs and building a personal product backlog. Each task is described much like a user story ("Book car in for service") and it's important that the task is described in a useful way ("Call John" is not as useful as "Call John about the new server order"). Each day I check my calendar for fixed tasks and then plan which actionable tasks I can achieve, based on time and priority - rather similar to a sprint backlog. Every week I groom my personal product backlog to ensure it matches my current reality.

Whilst David Allen doesn't use technology beyond pen and paper, I decided to look for software to help me organise myself. To be frank, the idea of using non-virtual folders and paper made me shudder. After a brief search I eventually chose Toodledo.  There's a fair number of titles on the market but Toodledo had plugins for the iPad® and Firefox® and I've found it flexible yet easy to keep using.

When I had an iPad I used Notability to collect things like meeting notes for processing at my normal time. The loss of the iPad (I left the job and had to hand it back) saw me go to system cards and I found that these work quite well. I would take a new card to a meeting, jot down any notes and then put the card in my in-tray for processing as any other collected item. What the card offers is a discrete input and avoids the notepad issue whereby you just end up with pages and pages of notes/tasks that never get actioned. The other thing I've been able to leave behind is the desk piled with papers that never get read and this makes my cubicle that little bit nicer.

It's not been an overnight thing and, at really busy times, I've had to focus and keep my rituals going but this has meant that I don't suddenly lose track of what needs to be done. I even get more time to think about the bigger picture.

The legal stuff:
  • GTD® and Getting Things Done® are registered trademarks of the David Allen Company.
  • iPad® is a registered trademark of Apple Inc
  • Firefox® is a registered trademark of the Mozilla Foundation 

Friday, April 1, 2011

Scrum at ADFI

For quite a while I've been meaning to post an overview of my work to implement Scrum in the development team in which I work at the University of Southern Queensland. This has taken shape over many months and, as with any real process, it is always being reviewed and developed to meet team needs. If you aren't really acquainted with Scrum I would encourage you to visit http://www.scrum.org/ and check out their Scrum guide.

Why Scrum?

For quite some time the ADFI software development team had asserted that it was Agile in its approach. However, this was a very loose notion and the need for improved structure was recognised when we considered our problems in areas such as project scope and code stability and releases.

The type of software development I'm interested in is design-based. No, not design as in design processes like UML, but in the creation of new solutions that improves a targetted context. We often work in new areas such as research data management systems and the main thing I have noticed when you create these new systems is that you embark on a journey that doesn't easily lend itself to easily defined time-frames and user requirements. This is where waterfall methods really fall over.

I like Scrum as it provides an open and honest approach to project management. It doesn't tell you how to code, instead it focuses on what a project is delivering and how it communicates. I won't go into the various comparisons I undertook across approaches such as XP but I can say that a fair bit of time was spent looking for a best-fit method.

What does it look like?

To begin with, the introduction of any new methodology is an exercise in culture change.If the change is to be sustained it's important that those in the team are willing to try the new approach, see its value and start to internalise the process. This last bit is the hardest part.

I started gently by reorganising our meeting schedule. Our developers had been drawn into a long weekly meeting that was largely administrative and, when they demonstrated new development work, the conversation was dragged into organisational issues such as possible project sponsors and committee procedures. This was incurring a large cost in terms of resources. I am a strong believer that developers are most effective when given time to focus and, more broadly, people are more useful in meetings that relate to their work. So Step 1 was to break the meeting into two different meetings - an admin one (usually with no developers) and an iteration meeting for demoing the work being done and planning the next iteration.

I then brought in the daily scrum so as to track our work on a daily basis and I can be made aware of any issues slowing us down. We don't have fines for being late - that's not helpful and can be a real demotivater. In my teaching career I really had problems with teachers that gave out lollies to motivate students and yelled at students for infractions. If people see a value in something (or are at the very least neutral to it) their intrinsic motivation should guide them to attending. In a negative scenario it's important to individually discuss the issue with the team member and try to work out what's going on before you wave the "fine tin" at them.

So we now had fortnightly iteration (sprint) demos, sprint reflections and sprint planning and daily scrums.

As a team we'd been using the Trac system for quite a while. Tickets that had been opened in an iteration but not finished just carried over into the next iteration and, very quickly, the list of tickets was soul destroying. To tame this beast we went through (groomed) our tickets and chucked out stuff that had been done, broke up the "needs" vs "dreams", and ensured that the remaining tickets had appropriate metadata. I then added custom fields so different projects could grab tickets and allocate them to their sprints.

We then started to call tickets User Stories as they're really meant to track feature requests and be written so users could look at the list of things being done and understand them. However, we found that some stories were really developer stories and created another Story class to cover things that needed to be done that the user is unlikely to ever request.

The result of this Trac work can be seen in pages like https://fascinator.usq.edu.au/trac/wiki/Projects/ReDBox- we have a vision statement for the project, key info and document links on the project page. Under the development planning link you can see the current sprint burndown and agreed that a defect burndown would be really handy in seeing the defects that need to be fixed and when we plan to get to them. From the development planning page you can access the product backlog and the various sprints. Picking a recent sprint I can see the burndown list, a sprint goal and the full sprint backlog (this helps with the sprint demo). We also have room for Sprint notes but, honestly, we're getting better at commenting the stories so a lot of the information goes there or is expanded upon in a wiki page.

Issues

One of the first things people shout out (they really do) when you describe the Scrum method is "so you want us to change how we do things just for your team?". It's one of the many ways you can see how dogmatic people can be about project management. Many of us have seen organisations cling to project management frameworks that fail time after time but are kept in place as they provide for "accountability".

Realistically I find that Scrum makes us even more accountable than in many other methods. On a daily basis the team looks each other in the eye and lists the work they're doing. In every sprint meeting we demonstrate our efforts to the product owner and our peers. We then reflect on how well we're going. Surely this is far more accountable than feeding project reports into monthly project steering meetings in which only the only attending team member is the project manager.

The point about meeting the needs and structures of others is still important though. This is another area where I believe Scrum is strong. I believe that Scrum can dovetail into a variety of project environments and, whilst not being "pure" Scrum, it still provides tangible benefits. In a current project we don't really have a perfect Scrum environment (a remote stakeholder and a project environment that isn't structured in that direct product owner <-> team interaction). This is where we adapt. We still have daily scrums, sprint planning, review and reflection but the team is suggesting priorities to the product owner rather than the product owner grooming and setting the user stories. The project group, however, is a trusting one and these suggestions are well placed and accepted before the sprint begins.

I also think our demos are still overly technical and we need to be more user-centric in our presentations but we're getting there. Our releases are also not as often as they maybe could be but over time this process can be refined. This sort of ongoing development really highlights to me how much more effective stable teams can become rather than teams that are constantly dissolved at project completion (unless you have an organisation-wide agile model). As always, you're making a big investment in your team and it's probably got the best pay-off when viewed as a long term investment.

As for Trac, it isn't a great multi-project environment but it's the one we had and, given more scope, I would start to explore better options.

Where to now?

As Scrum settles in I would like to start looking at drawing on my teaching background and examine how a variety of thinking skills can help development teams but that's for another day.

Thursday, March 24, 2011

Reboot

Reboot

Well, it’s been a while since this blog and I ran into each other but rest assured, I haven’t been hibernating. As usual I’ve been involved in a wide variety of stuff:
  • Building the ReDBox/Mint system for recording the existence of research data
  • Developing an Creative Arts Research Repository
  • Building the ADFI development team’s Scrum model and support systems
  • Investigating the noSQL and Convention over Configuration landscapes
  • Trying to round up my reading into the eResearch environment and actually start writing


I’m aiming to get the Prag-o-Matic cranked up again with some posts really soon. I have done some writing elsewhere, however:
  • On the subject of identifiers: As various teams start to build research metadata stores, it’s important to look back at the work done and lessons learnt in the Institutional Repository world. In this post I’ll discuss the issue of identifying “things” so that all repositories can have a shared understanding of data. It’s something that wasn’t well resolved in the IR community and threatens to reappear in our research metadata stores.
  • Some conference presentations as well - I really should get these up on the web