Thanks for checking out my blog. I’ve broken up my DPM: Summit talk into 3 distinct posts.
For the ‘Price per Point’ contracts stuff check out Part 1 here
This is Part 2 about automation
As Digital PMs, we are living in an amazing time. Truly. Facts and statistics about the rapid increase in technological sophistication have become so ubiquitous that we are almost numb to them.
It really is worth taking a breath every once in awhile. To stop and look up from bidding on second-hand goods via your smart-phone in your wi-fi connected city; to take a break from watching instantly streamed TV or personal broadcast from around the world…just so you can say ‘Wow’.
I’m not someone who believes in the technological singularity, but I do believe that within this era each subsequent generation will see greater and greater technological-based changes that will rip apart the fabric of our society and stitch it back together in ways we could not ever have anticipated.
As a Digital PM one of my fundamental remits relates to stability, standardisation and building upon tried and tested formulas e.g. you get a brief, you get an estimate, you work out who will do what, you build a digital product, you get paid – simple.
Except it never seems to go quite like that. Stability and standardisation are still extremely relevant goals for any PM – but how can stability be an end point when we are living in an inherently disruptive time. That doesn’t mean we should in any way abandon these tenets – every PM knows that most teams (except the really odd ones) doing better work when they are within a stable environment with clear goals and a process that everyone knows and follows. However, it isn’t as if there is a fixed point where you can ever say ‘Great. We’ve finally nailed the process down. Everyone do this for the next ten years’.
In the background to all of this is the fact that we have to keep on rapidly updating our process and environment to try to keep pace with the changes in tech. Yes – you can broadly follow the same project management methodologies for building a mobile app, a Drupal site, infrastructure software and a one-page blog, but the major and minor differences in developing each one clearly demands a more nuanced approach as to how you tailor your methodology.
It’s one of the main challenges with Agile and the culture of continuous improvement. Inherently the ‘rules’ are simple, the principles are clear, but there’s a huge amount of space within each framework to define exactly how you work that for newcomers it can be overwhelming when you find yourself in scenarios that don’t look like anything from the training manual.
Likewise for more experienced practitioners and high performing teams, you can find yourself over a long period of time refining and amending your process from retrospective to retrospective to the point that you end up with a workflow systems and methodologies so unique to your situation to make you question – ‘is this right?’ And sometimes you won’t be able to work out the answer until the dust has settled and there is something to benchmark against.
I believe as DPMs we should be engaging in a continual tearing down and building up of our process. Not on a day to day level, but project by project, year by year. To deviate away from standards on a daily basis causes nothing but chaos and confusion, but to stick rigidly to established standards on a long-term basis without exploring bold alternatives or new ideas (in a sensible and controlled manner) leads to a knowledge loss and bureaucracy culture that can be terminal for any tech-based company.
For a recent project, I was lucky enough to have the freedom to tear up some of our established processes and do some controlled experiments in regards to workflow etc. Myself and the lead dev came up with a simple workflow that integrated super-sweetly with our JIRA issue tracking:
- Whenever a developer would create a branch to start writing code, we configured Jira to automatically move a ticket into in progress.
- Whenever they developer had finished writing code, they would submit a PR and it would automatically move the ticket into in Review:
- The minute something was ready to review. The system would send out automatic notifications to the client, designer, tester and anyone that needed to see it along with a link showing them where they could view the code.
- This meant we got everyone testing the new feature at once. Before this our process was that a designer would look it over and request small tweaks from the developer; then it would get some cross browser testing and more fixes would be requested…. Finally, after several rounds of amends the client would see it… and say ‘no’ and the whole process would have to start again.
- Finally, the Code was merged into master, it would automatically move the ticket to done and any hours remaining would automatically be zeroed.
We also built our own checkbox system so anyone could see the status of where a story was in review. Meaning that even myself or a client could safely push code live.
This workflow, though not ideal for every project, really.shortened the feedback loop and meant we were getting really rapid responses from the client as to whether they were happy with each step.
It also got me thinking more about automation and how it could enable us to do less work.
Doing less work isn’t a bad thing even if it sounds like you are being lazy. The first step for me in ‘doing less work’ is to really understand what it is that you do in your job on a day to day basis:
We use Harvest at White October and I have to keep detailed timesheets of all I do. We just use this data for billing, but it occurred to me that with a bit of tweaking this data could actually offer some really rich insights into how we do our jobs.
So I began keeping rigorous timesheets and in addition to recording what the task was and how long it took, I would add a really brief notes as to whether I felt positive, negative or neutral about the task I had done and whether it was by necessity a manual task that only I could really do, whether it was something that with a little bit of effort could be delegated or whether it was something that could be automated.
After about 6 weeks, I took all this extra data that I had added to my timesheets and did some analysis of them (Clearly the results are all subjective and aren’t scientific in any way, but they were really interesting to me.)
Firstly, it turns out that I really like my Job.Turning up for work is by far and large a positive experience for me. Most of the stuff I liked tended to be around creative conversations, team problem solving and anywhere where I really thought I was personally adding value.
The neutral ‘meh’ stuff was more around planning, report writing, admin etc. and negative stuff included difficult interaction and having my time wasted.
Well what I found, is that there was some positive stuff that I didn’t actually need to be doing, but I probably enjoyed. There was a load of neutral stuff that I really could delegate to someone else and there were also numerous negative tasks that could probably be automated
So I spent some time trying to automate the stuff I had identified:
- Automated reminders and custom notifications for recurring events (IFTT is really good)
- Automated time-sheet entries based on my Google Calendar
- Automated file manager using ‘automator’ and other tools
- Giving clients access to the budget tracker for ‘automatic’ budget updates
- Auto-generated analytics reports and site performance data sent out from Google Analytics and other tools
- Automatic meeting scheduling and booking using Meekan
Other stuff I still want to try but haven’t managed to get going yet:
- Automatic invoicing/billing
- Dashboards that automatically give a project update and status report
- Automatic project set-up
There are 100s of these hacks around, but for me it’s about having identified first where you’re spending your time and then look for the solution – not just adding in automated systems because you can
All of these ideas stem from taking and established process and just having a pause before using it on the next project and thinking Why are we doing this? Should we be doing this? Could we do something better?