Table of contents
It's hard to imagine that it's been already six weeks! For this week, it has been more methodical, systematic even. It's a good feeling when you have a routine set out in your day where you know you have a few hours allocated to formal meetings or catchups and perhaps a one-to-one screen share for troubleshooting. Then, you have a couple of hours blocked out for progressing on issues, a 'power hour, or two!' where you get stuff done. Whether this means planning, research, prototyping or actually coding, it all counts to the final goal. This week was certainly that, and I hope as I become more fluid with my programming and coordination skills, I can enjoy more frictionless work days as opposed to those weeks which can feel very stop-start.
Summary
Relatively short this week, that's a good sign of less pain points and bottlenecks!
Drupal Webforms
It was nice to progress on two tickets concurrently as the end product was similar: create contact forms to collect user data for a general enquiry and another for an event. This required learning and trialing the Drupal Webforms Module which fortunately for me, is well documented. I have been working to implement email handling and form fields display. I did not have experience from self-learning on handling data- I always shied away from it as I tried to focus on front-end and at the time, as HTML, CSS and JS made sense to me. These tickets require more review steps with a senior developer because we are handling sensitive data. Good thing we are working on two-week sprints!
Content Building
I also had the opportunity to actually construct professional pages as the content editing team were stretched this week. We were given a google docs markup as a specification, then told to reference the existing page and make changes to a new page as per the doc. It was a good first attempt at taking instructions, making a judgement call where the instruction was open to opinion and creating the web content. I used the layout builder module to place blocks (created by other developers) appropriately with the text, then place the media assets where needed. The aim was to turn around the markup as quickly as possible so any final tweaks could be made asap. As such, we were making draft pages straight onto the production site. Overall, I hope to do more stuff like this- with a helpful walk-through with our more experienced dev, the process was relatively painless and straightforward. It was nice to see the end-product rather than just build the features and functionalities for others to use.
Apprenticeship Training
The formal apprenticeship training has been going swimmingly. We were fortunate to receive a run-down on Drupal Views, which is the CMS's way of sorting and filtering data: tags created from posts, form data, blog articles, to name a few. It was made apparent the power that Views can provide to the developer and eventually to the content creator and reader.
In terms of theory, we touched on SDLC and Agile Principles in more depth. The frameworks we discussed were Waterfall, KanBan and Scrum. It was an opinion of mine that we as an organisation, were employing KanBan method as we indeed are using a visualisation board to track the status of our tickets or issues. The instructor delved deeper into this and established that you can have Scrum Boards which have more columns to subdivide out the process and stages that a ticket will go through, appropriate to our workflow.
I think we are actually using a Scrum Board, as traditionally, the KanBan board has three columns: Backlog or To-Do, In progress or Build, then a Deploy or Done column. This is too general for what goes on with our work, and we need separate columns to illustrate these steps in the workflow. For example, contrary to KanBan and Lean Methodology, we have a 'blocked' column where we cannot progress the job for whatever reason e.g. waiting on info from other colleagues. It is important to identify this as early as possible so that our team can collaborate to find the solution to get this issue moving again. There's nothing shameful about this column, and it is a reflection of the work: we are often tasked with running with a feature without all the requirements and come up with a proof of concept for example. We are problem solvers, and facilitators, so as a team we will try to come up with a solution but the organisation is accepting that this will inevitably take time. To add, we also have a testing column and review column which will reduce the 'lead time' but we appreciate the sacrifice in time is outweighed by the gain in a higher quality and more secure feature.
Another difference between our setup and KanBan, is that typically KanBan would have specific workers for specific tasks along a production line. Supposedly, this is the work environment where this agile framework thrives. For software development, you could have developers dedicated to creating code and pushing features, then a separate workforce for testing, and perhaps another team for documentation and gathering feedback. This is great if you have the labour resources to spare. This is not the case for our team, where every member is responsible for pushing code, carrying out their own testing as appropriate. There is an understanding that the explanation of the feature should also be the responsibility of the originator, through informative MRs and supplementary Notion documentation for example. In my opinion and for my training, this is a better process as you get exposed to more stages in the workflow and ultimately learn more. The flip side is there will be inefficiencies as junior staff find their footing and will make more mistakes. Getting through the backlog will be slower as there are no go-to staff for quality control or only senior staff have the experience to check code and provide feedback, drawing them away from their own tickets or managing tasks.
Ultimately, the takeaway message was to use the agile methods and tools that suit your team, throw away the techniques that are counter-productive. I'm glad to say that we do just that!