scrum Archives

Although the Scrum agile methodology was originally formalised for software development projects, as with other agile frameworks it can be applied well to any complex, innovative project that a team works on.

Scrum is a way for teams to work together to develop a product where product development occurs in small pieces, with each piece building upon previously created pieces. Building products one small piece at a time encourages creativity and enables teams to respond to feedback and change, to build exactly what is needed using a most efficient manner.

Furthermore it’s a simple framework for effective team collaboration on complex projects that provide a small set of rules that create just enough structure for teams to be able to focus their innovation on solving what might otherwise be an insurmountable challenge.

So let’s have a look at how scrum methodology can be applied, and its potential benefits and challenges, when applied to embedded systems and hardware projects. Building complex products for customers is an inherently difficult task, even more so for projects that have a hardware component, and Scrum provides structure to allow teams to deal with that difficulty.

However, the fundamental Scrum process is quite simple and at its core it is governed by a few core roles on the project team. Product owners determine what needs to be built during a “sprint” interval of 1 to 4 weeks and the development team does the technical work to design and build what is needed during this interval, followed by demonstration of what they have built.

Based on this demonstration, the product owner determines what to build next. The Scrum master ensures this process happens as smoothly as possible and continually helps to improve the process.

A key principle of Scrum that differentiates it from traditional project management philosophies is its recognition that during a project the customers can change their minds about what they need or want, and that unpredictable challenges cannot be easily addressed in a traditional predictive or planned manner.

As such, scrum methodology adopts an empirical approach, accepting that the project cannot be perfectly understood or defined in advance and instead the team focuses on maximising its ability to deliver small iterations of progress quickly and to respond to changing or emerging requirements as the project proceeds.

As the team proceeds through the “backlog” of tasks during a scrum project, it is accepted that changes can and will happen – the team may learn about new market opportunities to take advantage of, competitor threats that may arise, or customer feedback may change the way the product is supposed to work.

When it comes to hardware projects, the time constraints involved in fabrication of printed circuit boards, the ordering of components, hardware assembly or other external manufacturing dependencies and the commitment to a particular hardware prototype design once it has been sent for manufacturing can potentially make it much more difficult to respond to new or changing customer specifications or requirements within the fixed timeframe of a given sprint.

If these kinds of factors in ordering or manufacturing hardware devices exceed the time allocated for a sprint, these manufacturing issues can present a unique challenge when trying to apply agile methods to hardware development.

The “sprint” is the basic unit of development effort in a Scrum project, a period of typically 1 to 4 weeks in which development occurs on a set of “backlog” items that the team has committed to, restricted to a specific time duration which is fixed in advance for each sprint.

Over the course of a sprint the project team has a physical, co-located, “stand-up” meeting every day to communicate between the team and assess its work, while the scrum master keeps the team focused on its goal along the way.

For hardware projects, increasingly popular and accessible tools and technologies such as small-scale CNC milling, 3D printing, and laser cutting are becoming more important for rapid prototyping and agile hardware development, allowing components such as custom plastics or simple PCBs to be rapidly prototyped, demonstrated to the product owner and evaluated within a sprint.

A prototype iteration of a hardware system doesn’t have to physically involve hardware. Simulation and visualisation tools, such as SPICE for electronic engineering, 3D rendering of mechanical components and PCB component dimensions, and thermal modelling for predicting heat transport with a device enclosure, for example, can all play an important role in assuring the quality, interoperability, industrial design, electrical and thermal performance and the “look and feel” of all the components that come together into a new product even before a prototype is actually physically constructed.

These tools and techniques can also be valuable to demonstrate hardware design and engineering progress relatively quickly, within the finite timeframe of a sprint, if the manufacturing of physical prototype hardware will take longer.

Once again this shows that agile can be used effectively with embedded (and other) hardware development if all members of the team embrace the methodology. And that includes the engineering team here at the LX Group – who can bring your ideas to life.

Getting started is easy – join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.

There are many different agile development methods and process frameworks, with Extreme Programming, Scrum, Kanban, and Dynamic Systems Development Method being some of the best known. Although there are many different agile process frameworks and methods, most are fundamentally similar in that they promote teamwork, collaboration and process adaptability throughout the whole life cycle of a development project.

The various agile methodologies share much of the same underlying philosophy as well as many of the same characteristics and practices. From an implementation standpoint, however, each has its own combination of practices and terminology. Most agile methods break tasks into small increments with minimal planning, without directly involving long-term planning.

At the end of teach iteration in the agile process, a working product is demonstrated to stakeholders. This minimises overall risk and allows the project to adapt to changes quickly. Iterations might not add enough functionality to warrant a market release, but the goal is to have an available release (with minimal bugs) at the end of each iteration.

Multiple iterations might be required to release a product or new features. No matter what development disciplines are required, each agile team contains a customer representative, for example the “Product Owner” in the Scrum method. This person is appointed by stakeholders to act on their behalf and makes a commitment to be available for developers to answer mid-iteration questions.

At the end of each iteration, stakeholders and the customer representative review the project’s progress and re-evaluate project priorities with a view to optimising the project’s return on investment and ensuring alignment with customer needs and business goals.

Extreme Programming, which has emerged as one of the most popular but sometimes controversial agile methodologies, is a disciplined approach to delivering high-quality software quickly and continuously. It promotes high customer involvement, rapid feedback loops, continuous testing, continuous planning, and close teamwork to deliver working software at very frequent intervals, typically every one to three weeks.

The original model of Extreme Programming (XP) is based on four simple values of simplicity, communication, feedback and courage, backed up by various supporting practices such as pair programming, test-driven development, continuous integration and collective code ownership.

In an XP project, the customer or customer advocate works very closely with the development team to define and prioritise granular units of functionality referred to as “user stories”. The development team estimates, plans, and delivers the highest priority user stories in the form of working, tested software on an iteration-by-iteration basis.

Scrum is another popular agile project management framework; a lightweight framework with broad applicability for managing and controlling iterative and incremental projects of all kinds. Scrum has achieved increasing popularity in the agile software development community due to its simplicity, proven productivity, and ability to act as a wrapper for various engineering practices promoted by other agile methodologies.

Using the Scrum methodology, the product owner works closely with the team to identify and prioritise system functionality in form of a “product backlog”. The product backlog consists of features, bug fixes, non-functional requirements and anything else that needs to be done in order to successfully deliver a working software system.

With priorities driven by the product owner – cross-functional teams estimate and sign-up to deliver “potentially shippable increments” of software during successive “sprints” typically lasting 30 days. Once the product backlog for any given sprint is committed, no additional functionality can be added to the sprint except by the development team.

Kanban is another agile method used by organisations to manage the creation of products with an emphasis on continual delivery while not overburdening the development team. Like Scrum, Kanban is a process designed to help teams work together more effectively.

It is based on the three basic principles of visualisation of the work to be done on a given day using large noticeboards, walls or “information radiators”, since seeing all the items in the context of each other can be very informative, limiting of the amount of work in progress at any given time, which helps to balance the flow-based approach so that teams don’t start too much work or commit too much work at once, and the enhancement of efficient workflow, where the next highest-priority task from the backlog is underway quickly once a previous task is completed.

The Dynamic Systems Delivery Method, or DSDM, is another important agile method, which grew out of the need to provide an industry standard project delivery framework for what used to be referred to as Rapid Application Development or RAD.

While RAD was very popular in the early 1990s, the RAD approach to software delivery evolved in a fairly unstructured manner. As a result, the DSDM Consortium was created and convened with the goal of devising and promoting a common industry framework for rapid software delivery, and since then the DSDM methodology has evolved and matured to provide a comprehensive foundation for planning, managing, executing, and scaling agile process and iterative software development projects.

DSDM specifically calls out “fitness for business purpose” as the primary criteria for delivery and acceptance of a system, focussing on the useful 80% of the system that can be deployed in 20% of the time. Requirements are baselined at a high level early in the project. Rework is built into the process, and all development changes must be reversible. Requirements are planned and delivered in short, fixed-length time-boxes, also referred to as iterations, and requirements for DSDM projects are prioritised into “must have”, “should have”, “could have” and “won’t have” categories.

All critical work must be completed in a DSDM project, but it is also important that not every requirement in a project or time-box is considered critical. Within each time-box, less critical items are included so that, if necessary, they can be removed to keep from impacting higher priority requirements on the schedule. The DSDM project framework is independent of, and can be implemented in conjunction with, other iterative agile methodologies such as Extreme Programming.

Agile hardware development may seem complex, or quite foreign – however the methods used can decrease the period of time from idea to final product launch – with the right partners. Here at the LX Group we can partner with you – finding synergy with your ideas and our experience to create final products that exceed your expectations.

To get started, join us for an obligation-free and confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

LX is an award-winning electronics design company based in Sydney, Australia. LX services include full turnkey design, electronics, hardware, software and firmware design. LX specialises in embedded systems and wireless technologies design.

Published by LX Pty Ltd for itself and the LX Group of companies, including LX Design House, LX Solutions and LX Consulting, LX Innovations.