It should be of no surprise
That I, a creative, isn’t particurly fond of rules and structure. I find it much easier to just improvise and free-associate my way through most tasks, if allowed. However, that isn’t the best way to approach things, especially when there are tight timelines and stakeholders to deal with.
If there is one thing I am learning to embrace in my journey to code, it is the power of frameworks. This week, as part of my Perpetual Education course work, we practiced working agile.
Admittedly we did a modified version, where each sprint was divided across two days. but the pressure felt real, and I certainly treated it as a real-world project.
The project was to create a website for a web design agency. Read on to see how we leveraged the agile framework to get stuff done.
What is Agile ?
Agile is a type of framework that allows teams (especially remote ones) to organize their time and efforts to deliver project milestones in a clear timeline and with their sanity intact. Used in project management (especially) for websites and software, instead of hedging your bets on a big launch, you work as a team in small sprints.
The coolest part is that you iterate at each step, keeping what works (meets the goal!) and leaving what doesn’t. It’s inherent to the Agile framework.
According to Atlassian
Requirements, plans, and results are evaluated continuously so teams have a natural mechanism for responding to change quickly
Day 1: map
Since this was my first group project, I really wanted to make a good first impression with my team. Day 1 is about mapping and luckily for me, our team leader, Derek, created a document in Google docs to help get us started.
I made a copy of that file, and started typing away. The first thing I wrote was a catchy acronym (MAID) of the members of our team, along with the team roles.
I then worked my way down the doc to try and address all the topics (see the sidebar). I definitely got stuck at some points, but the major wins for that day were content-strategy, project overview, and learning to work backwards from the goal. I felt like I ended the day strong.
Day 2: sketch
I used Skitch to create the sections of the website. Keeping the goal of a web deign landing page in mind, I drew a couple rectangles to represent the different sections. This was super easy, considering how little content there really was. The harder part was writing the LFPS.
Thankfully, Agile has a solution to one of my favorite activities: brainstorming. They call it crazy 8’s, and it is awesome. It is essentially brainstorming with timeboxing. In our case, we had a minute or so to draw 8 drawings of the main page. Here’s what I came up with.
I also wrote 8 different LFPS’s too, that I am particularly proud of! Here’s what I came up with.
The most important thing I learned is that I can convey intention with my sketches, and how to let go of my ego and work fast and loose. As someone used to writing and speaking to convey my ideas, it felt good that my teammates were able to understand my ideas just from simple low-fidelity sketches!
Day 3: decide
I found day three to be the most difficult day so far. It really challenged my neurodiverse brain, particularly the executive planning areas. I felt overwhelmed by the choices and ideas, so I made sure to check back in with the team google docs.
At this point, I thought the best tool to problem map and storyboard would be whimsical. This is a graphic design/protyping tool that teams can use to illustrate their ideas in real time.
The MAID team hopped on a slack call and Derek showed us how to use whimsical problem map.
The goal of problem mapping is to find “pain points”. These are areas where users encounter problems, i.e a piece of UX that doesn’t act as expected. Even though Derek walked us through it, I struggled to do it on my own! I felt a bit depressed to be honest, but then I realized I am learning! This is just a skill I need to practice, and the first time is never easy.
Day 4: prototype
Day 4 was all about implementing our ideas with code. Finally, something I am comfortable with! I took all the hard work we did in google docs and made a couple style tiles.
With the colors and fonts all picked out, I opened up a CodePen and started coding away!
Day 5: test (validate)
Day 5 was all about validating the concept or as I like to call it, user testing. Thankfully, my team mate Anna Lena wrote up very thoughtful questions, and even took the initiative to reach out to local businesses.
I made a list of people I could user test the website with. We are actually still at this step, as we are working out some internal technical details. To be continued
Agile thoughts
Overall, I felt pretty good about working Agile. I certainly learned alot myself, particularly my strenghts and weaknesses. My favorite part was problem solving as a group with my amazing team. It gave me a preview of our performance when bigger projects start rolling in!