As a software architect, one of the challenges I have in writing this blog is finding creative ways to connect my experience and expertise to topics that will be useful to an audience outside of software development. I often find myself thinking about how some of the ways in which software teams approach problems can be applied to other types of projects or to life in general.
Agile Development Lends to Agile Design
A while back, I wrote a blog about how agile software development techniques can be applied to family life based on TED talk I had listed to about the idea and this got me to thinking, if agile can be applied to something as abstract as family management then it might also be pretty useful for intranet design and management. Today I will discuss implementing an agile design strategy on your intranet.
A few weeks ago, our marketing assistant, Karleen Murphy, wrote an excellent article about the benefits of incremental intranet design. In the article, Karleen has some great and specific ideas on how intranet design can be done in small steps rather than as a huge project that involves overhauling the entire application. This is exactly the type of design advocated by an agile methodology so my intent here is to discuss the theory and the process involved in an agile approach rather than the specifics about how you can make incremental changes to your intranet.
If you haven’t yet read Karleen’s blog, Incremental Intranet Design, I would strongly recommend doing so either right away or immediately after reading this one as the hands on ideas it provides are extremely useful.
The Agile Manifesto
Agile software development is built around the idea that software projects are something of a moving target and are therefore difficult to plan in advance due to constantly changing requirements that affect the overall design of the system. In many respects intranets are very similar in nature.
Intranets are often large systems where the information they need to provide changes regularity making it difficult to design something in advance that is robust enough to handle future changes in such a way that a major overhaul is not necessary.
The agile methodology provides a way to deal with such projects and is rooted in a simple manifesto that contains 4 Elementary Axioms:
- Individuals & Interactions Over Processes & Tools
- Working Software Over Comprehensive Documentation
- Customer Collaboration Over Contract Negotiation
- Responding to Change Over Following a Plan
Agile Design: Small Changes, Big Impact
The notion of agile design focuses on the idea of incremental change: Start by building a small intranet that accomplishes one requirement very well. Start small, get lots of feedback from relevant stakeholders, ensure that the design is intuitive and easy to use and finally accept that changes can and will occur. This could be something like an employee directory that contains everyone in the company and has all organizational relationships captured within it. Once the first piece is in place, add to it iteratively, one piece at a time, making sure to get feedback and make the necessary adjustments before moving on.
Let’s look at each of these axioms, one at a time, and examine how they apply to intranet design and management rather than software development:
“Individuals & Interactions Over Processes & Tools”
This can be a big problem in software as there are a lot of cool tools out there for developers to work with and developers tend to love working with new exciting technology over talking to one another or to project stakeholders. The message here is to talk to the people who will be using the intranet. Don’t assume that as an Intranet Manager you know what they want or need or that if you build it they will come. If you make sure you are creating content and workflow that solves real problems for people in the organization then you will have an intranet that is used regularly and that will have a positive ROI for the business.
“Working Software Over Comprehensive Documentation”
It’s possible to spend all kinds of time writing documentation and of course some documentation is absolutely useful. However, most users will not spend much time reading documentation and a better approach is to create intuitive, well organized content that is self-explanatory and straight forward to navigate and consume. An intranet designed with this in mind will need little documentation and will have much more uptake among its targeted user base because they are able to jump right in and start using it without needing to read a bunch of complicated documentation.
“Customer Collaboration Over Contract Negotiation”
This one is written to apply to software consultants but it is easy to apply to intranet design. The point here is to involve the client at every step during the development of a product rather than negotiating all the requirements at the beginning and then going away and building the application. Involve your employees in the creation of your site content as much as possible. For example, if you need to build an interactive form for the finance department involve them in the process and show them working prototypes as you do so. Doing this will allow to you receive immediate feedback and allow you to build exactly what is needed and will prevent you from having to add in missed requirements after the form is complete or remove unnecessary additional items.
“Responding to Change Over Following a Plan”
At first read this one may sound like bad advice because it sounds like it is advocating having no plan for software design but that’s not really the case. Instead, it is saying to expect and embrace change. If a large amount of time is invested planning the design of the intranet up front, it becomes human nature to resist any requests for change no matter how beneficial they may be. Instead, start with a small plan and get lots of feedback as you go. This way, you will be less invested in the plan and more invested in creating a design that is flexible and can meet the changing needs of the business.
An Incremental Intranet Design Approach
So now that we’ve talked a little bit about the core principles behind the agile methodology we need to figure out how to put it all to use and relate it to agile design on your intranet. In my experience, the big key here is iteration.
Start by talking to stakeholders, figure out their needs and from that come up with a list of requirements. Next, plan what needs to be done, but only for a small, cohesive piece of the requirement list and then implement that plan from end-to-end. This process should not take very long, two or three weeks at most and shorter is generally better if possible. Make sure that whatever it is that you choose to do can be demonstrated to stakeholders when complete so that they may provide immediate feedback.
Once a small piece of the intranet is complete and feedback has been provided, make any necessary changes and move on to the next piece and repeating the process. Building the intranet incrementally, in this fashion, will result in software makes sense to its users and involving those users during its design will provide them with a vested interest in using it.
Agile Design = Incremental Improvements & Evolution
The primary goal of agile development is to create a process that enables the rapid delivery of content and features to stakeholders so that they may provide feedback crucial to the design. A close cooperation between intranet designers, content managers and the business that will make use of it is critical in ensuring the process works successfully. If changes can be made before too much effort is invested on an incorrect path of design, much of the pain of a traditional design process can be avoided.
An agile process also saves time by ensuring that time is not spent building content that is of little use to the business, effectively maximizing the work not done.
