The Agile plan for this portfolio site

The plan

(As of my time at Computershare, I've now had experience working in Agile, and found this to be a good fit for me.)

I'll admit it. I haven't had formal agile experience. Yet, because of my strong project management training (in Civil Engineering study + practice), and innate organisational ability, I'm a natural at it.

While most projects I've done have been more or less building websites, rather than ever-expanding SaaS products, I've been able to follow an Agile/Lean methodology for this portfolio.

One of the great things about an Agile method is that you can better manage timeframes by building the core functions first, and then having the option to defer 'nice-to-have' features later.

Of course, getting early feedback is a very nice thing too. As we learned in Civil Engineering, the later the changes, the more expensive they are.

Curve showing costs proportionally increasing over time as the project builds, and where agile methods find problems (early) as opposed to traditional methods (late)
Agile (in green) finds problems much faster than traditional methods (in red), and is therefore cheaper and faster

1st iteration: The minimum viable product

I wanted a new portfolio up that displayed my latest projects. This would be to communicate to prospective employees my work.

So, minimally, I had to have a writeup on these projects.

I needed to learn Bootstrap better, so decided to use that framework instead of WordPress, Joomla or another CMS.

I mapped out some basic content needs for the first iteration, such as a brief description of skills, and the main UX/UI piece: Red Cup Cafe. I would leave colour schemes and design to a later iteration.

To do this, I've used which is installable on Windows/Mac and does all the Node.js npm goodness for you, in terms of preprocessing for SASS, Pug (Jade), and managing live browser updates when you save, and FTP.

I whacked a Beta badge on it, and uploaded it.

First version complete!

2nd iteration: Content, content, content

I had thought to do design work at this stage ("I really need to WOW hiring managers!"), but I needed more core content first:

  • The Naturally Wild IA process
  • My work experience history

I'm not yet finished this stage

3rd iteration: Design

Grey is not great, so I am planning to work on the design in this stage.

But it's clearly less important because my design skills can be clearly seen on the sites that I've shown already.

4th iteration: Animation

I'd like to test and grow my CSS/JS animation skills, and build on the theming of the design work.

This is really about growing my skills, and has to be built after the core design strategy and theme has been mapped.


I've been reading 'User Story Mapping: discover the whole story, build the right product' by Jeff Patton (O'Reilly books).

I think overall his insights and the process is solid.

I'm wondering though, whether the innovation here was:

  • A new visual style of project management, i.e. sticky note style instead of lists?
  • New names for the same things, i.e. stories for functions; story maps for gantt charts, iterations/sprints for looping milestones/sections?
  • A new focus on users rather than functions, i.e. flipping the task list to across the page and highlighting the user stories?
  • Or that simply he was the first to collate all of these things (i.e. they don't really seem that different to other project management techniques)?

Regardless of Patton's contribution (much or little), the process has these advantages and disadvantages:

  • It makes project management sexy again, and planning like this makes better products
  • More people are visual learners than word-based learners, so the message can get across better
  • Managing visually is easier than with text, and naturally involves more people, especially if done physically on a big wall
  • The naming is probably from the wider Agile movement, and isn't immediately intuitive, but easy to pick up (story map? Okay, gantt chart is pretty bad too)
  • The focus on user stories is demonstrably better than focussing on abstract functions, but there's no reason we couldn't move back the terminology from 'epics' to 'milestones', and 'user stories' to 'functions' - provided we add the structural elements of 'who' and 'why'. That seems to me to be more meaningful than fancy names that have to be relearned.

As Patton says, the main goal is shared learning, not getting the technique correct. I'd say, well done! Visual communication pretty much always beats text-based communication for learning, so visualising project management like this is wonderful.

However, the core disadvantage of this method is the inefficiency compared to writing it out. Visual methods are always a bit slower. But this is mitigated somewhat by software such as and sticky note style interfaces which have the building blocks ready for you to efficiently map.

Book cover - User Story Mapping (O'Reilly) by Jeff Patton