Here at EngLancer, we often talk about adapting the practices of the web and software industries to engineering design and project delivery. After all, the EngLancer platform itself is derivative of the successful outsourcing platforms seen within these sectors.
Our CTO, Phil, is also, of course, a full-stack developer. Because of this, I am often picking his brains on the merits of the various project management and delivery methodologies he has employed during the array of projects he has been involved in building and bringing to market.
I do this, much to his annoyance I’m sure, because I always see value in comparing how different industries and people try to solve the same problems. I find it often highlights opportunities and efficiencies that would have otherwise been missed or not considered in our daily race to ‘get things done’.
The ‘Scrum’ or ‘Sprint’ framework for managing product development particularly stood out for me during our discussions, and we went on to use the methodology as part of our development of the EngLancer platform. This post considers its major features, benefits, also whether it could be effectively rolled out within engineering design and project delivery.
‘Scrum’ is an iterative and incremental agile project management methodology. Essentially the approach challenges the more traditional “sequential” project delivery, with task completion enabled through the execution of numerous ‘sprints’. A ‘sprint’ is a time constrained period of work or effort, with two weeks the most common period over which tasks are planned and executed. The specific time period is flexible however, as it is dependant on the nature of the work being delivered. It must though, be defined as part of the initial (mandatory) planning meeting, with this meetings also acting as the start point for each sprint.
The planning meeting is a crucial part of the process. It is used to discuss, define and document each of the discrete tasks or “sprint backlog” that are necessary so that the team can go on to successfully deliver the developed product, component or otherwise required deliverables. For each task a time estimate is also given, with this data then allowing the team to develop the ’burndown’ for the sprint. That is, a chart or graph illustrating the remaining tasks to be completed, along with the anticipated period of time for completion.
From the ones I have seen, a ‘burndown chart’ provides a very useful visual reference for the team’s progress on the current block of work/’sprint’. This is because the initial time estimates provided are used to plot the expected (sometimes the ideal) ‘burn’ or progression towards the required deliverables. In other words, they give a performance metric, so that as each task is completed the team is able to assess how effectively the task was delivered relative to the corresponding initial estimate. It additionally, therefore, provides an effective feedback loop so that the performance of the team can be measured both in terms of how efficiently the task has been completed and the effectiveness of the collective in correctly assessing what time and resources are necessary before that task can be marked off as ‘done’.
As part of the scrum methodology, daily (or more regular) sprint meetings also provide the design team with the opportunity to input live information into the sprint backlog. What this does, is it lets common blockages, bottlenecks and inefficiencies in the supply chain or product development process to then be captured recorded and improved, both during the current sprint and for the next iteration. What really attracted me to the process as an engineer, is that the process and associated procedures provides the team with useful data. That is to say, it gives the team a means by which we can measure, manage and improve the design process as its ongoing.
The other aspect of the scrum methodology that appealed to me, as someone who founded and ran as small scale engineering business, is that Scrum emphasises the need for a working ‘product’ or a completed aspect at the end of the Sprint. That is to say, a task that can be considered to be done. This to me means a fee earning piece of tangible work, that can subsequently be issued to the client and invoiced against.
This is where I see potential overlap between the methodology and the EngLancer platform.
What our site allows engineering teams to do is to define a series of discreet design, drawing or modelling tasks along with an associated time constraint. There is nothing within the Sprint methodology that requires all members of the the team to be within the same company, building or even country. The entire methodology is focussed on the effective definition, delivery and feedback associated with design or other work tasks. Further ‘freelancer’ feedback relating to cost, delivery time, further information required or any other potential ‘blocker’ would add further useful data when preparing the sprint backlog.
EngLancer in no way restricts communication between outsourcing and delivering body once the price for a piece of work has been agreed. It is this communication that is key to the success of the scrum methodology. Further our planned feedback and rating mechanisms will add further useful data for inclusion within the daily sprint meetings, as well as the longer (again mandatory) post sprint review.
The key principle of “scrum”, which did initially make me question its compatibility for engineering design, is that a client can alter the scope of work as part of the process and that there is an acceptance that the problem cannot be fully understood or scoped at the outset. Because of this, the success of the entire process is consequentially reliant on the ability of the design team to deliver quickly and respond to emerging criteria.
In some ways, this is contradictory to what we preach at EngLancer.
We see correctly scoping each task as a key part of ensuring the quality of any outsourced work. That is, defining the required design codes, loads, key deliverables etc are key to making sure you get exactly what you want, for the agreed price.
However, on reflection what I came to realise was, that while the engineering process as a whole actually should be responsive and flexible in this way, so as to meet (and even exceed) the needs of the client, it doesn’t mean that each design, calculation or modelling task that informs the process can’t be effectively defined, scoped and packaged in a way that can be outsourced.
Essentially, this process of discretising design tasks is what scrum is all about. It highlights the effectiveness of breaking large design and development projects down into deliverable and manageable chunks. By doing this you are reducing and managing the risk (and therefore the costs) associated with the design process. That is, its better to have five people doing five different tasks that will inform of the correct solution, than all five people working on one methodology that turns out to be wrong further down the line. Again, we see EngLancer as the best tool to manage the scoping, review and payment of the discrete tasks outlined.
I know of a few engineering firms that have looked at and trialled the Scrum approach in a few limited situations, with varying results. I would be very keen though, to speak to anyone who has direct experience of the scrum methodology being used on a regular and successful basis as part of the engineering design process. If this is you, we would love to hear from you.
Come help us reengineer the way we engineer.