All posts tagged: methodology

When an organisation or team decides to adopt Agile methodology for their projects, not “staying agile” can potentially lead to problems. Although Agile itself is very broadly defined in the general principles of the Agile Manifesto, and there are many different ways to implement these principles, “staying agile when using agile” is important and straying too far from the underlying principles can potentially lead to pitfalls.

So, how can we keep Agile development agile and avoid common pitfalls when adopting Agile project management techniques?

One of the important things to know about Agile methods is that if they are limited to one development team churning out code, the outcome won’t be truly Agile. It takes a whole organisation to truly be agile, with agile methods supported by management and other staff within your organisation – not just one team without any support for agile in the organisation.

There are several other key success strategies for organisations when adopting Agile methods, such as looking beyond the application “construction” stage and considering the life-cycle context of the application. If organisations only change the way they construct software, without downstream or upstream business changes, this is unlikely to lead to the most effective outcomes with Agile.

It’s important to not be “Agile zombies”, with the inaccurate assumption that just attending a class or seminar about Agile methods and implementing some of the points learned leads to “being agile”. Every organisation is different and is constantly evolving. Continuous learning and improvement is at the core of Agile, and Agile isn’t a strictly defined “one size fits all” recipe.

The methodology itself isn’t a prescribed process or set of practices; it’s a philosophy that can be supported by practices, and no two agile approaches are exactly the same. No one single methodology exists that meets the needs of everyone.

It’s also important for organisations to decide if and where agile adoption is most beneficial for their business, to plan carefully for adoption, and to not adopt “Agile just because it’s Agile”. Organisations should ask questions such as why they want to be agile, what benefits it will provide, and how agility will be achieved and measured. Organisations should ask what cultural or other barriers exist to their adoption of Agile techniques and how they can be overcome.

Without a plan that clearly shapes the initiative, addresses and resolves constraints to agility (for example, removing waterfall process checkpoints or getting support from other required entities), it is more difficult to shape the Agile initiative, staff it, fund it, manage blockers and maintain support from executives.

It’s valuable to ensure that the entire organisation is included in Agile project management – including areas of the organisation that may be overlooked such as marketing or accounting staff. It’s faster and less painless, of course, just to launch an Agile initiative with one team, but this is not most effective.

A single team may gain some benefit from agile, but to be most successful you need to look at the whole process around solution delivery and the numerous people involved. Agile, ideally, should be a change in culture for the entire organisation.

It’s important to find supporters for Agile adoption not only among developers and IT teams, but across all parts of the business unit. In particular it is desirable to try and get somebody from senior management directly involved in Agile adoption, with as much support as you can find from executive management.

Effective agile adoption requires executive sponsorship at the highest level, because these are the people who control resources and can move them as needed to deliver results most efficiently.

Successful adoption of Agile means a shift in the way business views technology, and for most effective results we should recognise that developers don’t like change and many people like working in their own world. As with any cultural shift like this, coaching can be valuable.

Business users will need to learn to work differently with development teams as well. That’s why a coach – either a professional or a designated employee with strong communication and motivation skills – can be an effective part of a new agile team, to help everyone learn to work together most effectively.

Training is also important for success with Agile. Some organisations tend to skimp on training, but Agile is one area where it can be particularly valuable. Managers may only send a few key people to training, in the hopes that they can train the rest of the organisation to implement the new approach for free.

This is unlikely to yield the best results, since Agile is a game-changing initiative, and everyone across the organisation needs to understand it for best results. Continuous improvement is a key principle of Agile development, including continuous development of the team and their skills.

Once again we enjoy illustrating that Agile methodologies 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.

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.

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

When designing hardware to integrate with an Internet-of-Things solution, or an entire solution – it can be easy for the design team to focus on the software, server and control system due to the ease of prototyping and the availability of experienced people. It’s a common philosophy that once the software is “sorted out” – the hardware can be easily designed to work with the system. Thus it can be tempting for organisations who move towards IoT solutions to focus on the software more than the hardware as it may seem at the outset to be more complex and more difficult part of the system.

However hardware design cannot be overlooked or resources in that field minimised. There is much more to consider than just what “the hardware will do” – the consideration of which type of IoT system to work with needs to be executed – and in conjunction with that the choice of which hardware design path to take.

After deciding on which IoT platform to design your hardware for, the choice of hardware design path is crucial to the success of your IoT implementation. Even if you’re developing for internal use, or offering hardware or turnkey systems to customers – the choice of hardware design can play a part in the long-term success or failure of the system.

When we say the “choice of hardware design” it is not the actual type of device (however that can also play a part in success or failure) or design tools used to create something – it is the choice between one of hardware design paths. That is, will you choose proprietary hardware interface designs from an existing supplier; create your own hardware and protect the intellectual property with copyright and possible patent protection; or open-source your design to some degree to allow input and contribution from internal and external customers? There are pros and cons to each method, so let’s examine them in some more detail.

Existing design – This is the easiest option for your design team, as the hardware interface to the required IoT system has been designed, tested and ready for integration into your hardware. To resell your own devices based on an external system can require licence or royalty payments to the system provider, however this will often be returned “in kind” with marketing support, referrals and leads from the system provider. However you’re at the mercy of the success or failure of the host system – which could leave you with outdated and useless hardware that can be at least difficulty to modify or at worst a total write-off.

Internal, protected design – With this option you have access to the required interface design from the IoT system provider that allows you to create your own hardware instead of buying or licensing technology from the provider. It gives you total control over the hardware design – including possible modularity between the IoT interface hardware and the product itself, in case of system failure (as mentioned previously). Furthermore you have complete control of the design, maintain all IP, and can market your designs as an exclusive product that’s compatible with the system. However all design, support and revisions will happen in-house.

Open-source – After a few minutes searching on the Internet it may seem that almost everyone is open-sourcing their designs to allow all and sundry to review, modify, critique and sometimes re-manufacture their products. This method is preferable if you are offering paid access to the server-side infrastructure or you are happy to allow others to create devices that compete with your own hardware to quickly allow customer take-up of your IoT system. Furthermore you can build a community around users of your system, which can reduce the support load and generate good-will. However taking this path in essence abandons revenue from hardware sales and any intellectual property your team have created. Finally, larger customers may see this product as insecure (even if it offers encrypted data transmission) due the openness of the designs.

Here at the LX Group we can discuss and understand your requirements and goals – then help you navigate the various hardware and other options available to help solve your problems. We can create or tailor just about anything from a wireless temperature sensor to a complete Internet-enabled system for you. For more information or a confidential discussion about your ideas and how we can help bring them to life – click here to contact us, or telephone 1800 810 124.

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