Bringing Agile to the Non-Tech Employee
There are 5 principles making up the core idea behind Agile. By adopting these principles, even non-IT employees will confidently buy into the change in culture.
Join the DZone community and get the full member experience.Join For Free
Even though Agile (and other methodologies like Kanban and Scrum that fall under the Agile umbrella) were developed for the IT industry, other departments have found success implementing the core ideas. It does require some tweaking and getting non-IT staff to buy into the process, but Agile is no longer only the tech department's sole property. First, we will look at the core concepts of an Agile methodology and how to get non-tech employees to adopt the methodology.
Agile’s Working Definition
When a team leader embarks on researching how to implement Agile, they’ll come across several opinion pieces proclaiming that very few understand Agile. These are enough to put even the most even-keeled off when looking to incorporate a non-tech team within the Agile bubble. However, when one looks at Agile’s core concepts, it's easy to see why others think the future is bright.
To those who are looking to adopt Agile across departments, a number of benefits will be seen. Agile places importance on independence, trust, and personal responsibility. Rather than a mandated change from upper management, Agile transformation can, and should, happen organically so as to alter the culture of the workplace for the better. In workplaces, the traditional view was to view management responsible for all success and failures, with Agile the drive for responsible individuals allows teams to shoulder the responsibility for what they do. This means that all share in the success of a project and have a greater drive to help ensure success.
Steps on How to Adopt Agile
In essence, there are five principles that make up the core idea behind Agile. By adopting these principles and transforming them to the needs of a specific project, even non-IT employees will have sufficient reason to buy into the change in culture. These five principles may initially sound like they were lifted from an IT project management textbook but as you will see, they are flexible enough to be used across disciplines and departments. No matter the project, whether fine-tinkering with cloud communications policies or improving customer service principles, the five principles below can be adopted universally.
1. Working Software
Straight off the bat we come to a principle that already seems IT-centric. However, this principal is more focused on what is to be delivered to the customer — or put differently, what is being worked on to bring value to the customer. This can be anything from a cost-benefit analysis, to a new business process. It is important that this is defined from the onset as a catalyst to get the team moving in the right direction.
2. The Customer
Another principle to define early on is who the customer is, or the individual or group who will benefit from the “working software” as defined above. For software developers, this is often easier to determine, as they would be the end users. For other projects, it is vital that whoever owns the product once completed is determined, whether external stakeholders or upper management. This is done to rein in complexities so that the working product remains clearly defined throughout the development cycle.
3. What Does Done Mean?
This may seem silly to some. The project is done when it is completed, obviously, some will scoff. However, as the team works on separate parts that will be brought together to form the whole and then may be delivered to a third-party for quality assurance, everyone working on the project needs to know at what point is the deliverable considered done and ready for quality assurance. Perhaps the project does not only have to be delivered to a third party but also requires to be implemented successfully in the future. This will alter the “done” state of the project and needs to be considered and clearly defined.
4. Business Value
This is often the hardest principle to define regarding a non-IT project as what is completed is often a prototype or a theory — but determining the business value of the project needs to be done. This can be done by preparing a cost benefit right at the start of the project, then determining if the benefits are achieved at specified intervals during development.
5. The Unexpected
One of Agile’s greatest assets is its flexibility in dealing with challenges that will inevitably crop up. This is because one of the guiding principles is to expect the unexpected. Once an issue arises, solutions need to be found as the plans that have been made are not treated as being carved in stone. This attitude of being prepared for whatever may come up, be it a change in customer or shorter iterations, allows for flexibility in dealing with changes.
The five principles above can be used to set the agenda for the entire project. Once the agenda is set, then comes the adoption of more nuanced Agile principles like Scrum. However, once the agenda is set, the adoption of other principles can happen organically and as the project dictates, which is where an Agile culture shines.
Opinions expressed by DZone contributors are their own.