Agile PM Tools: Team Of One

When I’m not managing and coordinating digital projects at doejo during normal business hours, I’m working in some capacity on my hand-made leather goods project, Black Dog Bags. This is something that I do when I have spare time because I enjoy planning, designing, and making leather projects. Most of my projects have been for friends and family, however as I gear up to open an Etsy shop, I need to build up inventory. Working through individual leather projects, I find myself applying Agile Project Management principals that I use during business projects to my personal projects.

I recently downloaded the latest copy of the Scrum Body of Knowledge to brush up on my knowledge of Agile and see if I was really practicing the Scrum framework for development with projects. Well, it turns out that I was, but not the the fullest extent possible. Because Scrum doesn’t have a “project manager” role on the team, my professional role translates into a mashup of a Scrum Master and Product Owner, depending on the project and client. Agile and Scrum practices have a huge emphasis on flexibility within reason, rather than themes of traditional project management: strict project processes and front-loaded planning. Working in a digital agency capacity, I find myself jugging a delicate balance of needing flexibility for change in my projects as we work through business, design, UX, and technology discovery, but also having the need to adhere to a defined list of deliverables that ultimately determine the definition of completion for a project.

For my personal projects, I have a bit more leeway in how a project is managed and completed, as I make up the entire “team” and only have one customer per project to satisfy. For each project, I will still use a planning and discovery phase to flesh out the details and what’s needed for project. Just like the web-based projects I work on, I will use sketches and paper prototypes to determine design and sizing before moving on to a “build” or in this case, cut and sew phase. When I first started out, I found myself skimping on this phase of my projects, but I quickly found that it’s much easier and less costly to cut and measure paper rather than leather. I often make many iterations of my paper prototypes before finalizing a design to ensure that along every step of the way my project is still on track to meet the functional end result.

During the execution phase of my leather projects, I still have some tolerance for change or adaptability. If I find that the my original plan isn’t working out, I am still able to experiment with things like the type of stitch or closure hardware. The further along the project progresses, the less tolerance that there is for change which is why for leather-working purposes I am upfront with my customers about design requirements for things like the color of leather/stitch or the final size of the project. While finishing a project, I will also perform my quality checks and “stress tests”. I always keep in mind the final purpose of the item that I’m building and will check throughout the project that it is still aligned with that purpose by physically testing it out with whatever objects it will hold. like credit cards, passports, laptop, etc. I’ve found that handoff for leather projects is a little lighter touch than a business software application and there isn’t nearly as much ongoing maintenance. Once the project is “done”, there is still some room for modification, however in most cases it would be easier to start with a new project.

With outlined project process for my personal leather crafts, I am also often working on multiple projects at the same time. As I do with my work projects, I still maintain an ongoing “to-do” list, however I don’t require robust project management and track software for just myself. I’ve found that a mini-scrum board outlined in Google docs does the trick for me. It gives me the agility to prioritize and change the things I’m working on as needed. I typically won’t go through a formal documentation of a “feature change” within one of my projects, but I will track if there is a change in purpose or there is something significant that needs to be added on. While I still follow a traditional project management framework for the baseline of my projects, I keep Agile tools in my back pocket. Having the ability to be flexible and accept change, within reason, is an extremely useful skill in any circumstance and allows a project to remain relevant and ultimately have a useful end result.

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.