Agile For Non-Techies
Probably the number one question we get asked in the Agile context, is “isn’t Agile a methodology for software development, only?” After all, the Agile Manifesto itself was born from a need to simplify and find commonality in the software development life cycle. But, why? Why wouldn’t any and every service, project or product benefit from the same principles espoused in the Agile framework? What project or team would not benefit from a collaborative, empowered approach to controlled development and implementation? But, it’s not just because of Agile’s origination in software, by any means. It’s also because of words like “development.” So, let’s break this down for the non-techie folks, and at a minimum, for the non-software developers, among us.
(1) What is Agile
Oversimplified, “Agile” development is iterative. While everyone knows the “big picture” or “end goal,” steps are broken down into tiny parts, or “sprints,” and “features” (called, “user stories”) get broken down and prioritized into shorter cycles, called “iterations.” The user story/functionality may or may not make it into the final product. That is the very nature of Agile development. Instead of making life-or-death-level decisions, every step of the way, continuous communication, and shorter cycles allow teams to improve on the design, well before the full product is delivered.
Compare this, for example, to an HRIS system. In the “old days,” sometime after testing, the system is in production, and various business users immediately complain about various functions not working to their liking. There was no alignment on priorities, or even who the customer is/was. Some of the costly implementation costs are wasted as features need to be redone.
(2) Who can benefit from being Agile?
Anyone who can see the benefit from a collaborative, customer-centric approach to delivering, can easily benefit from incorporating Agile principles. However, many of us, through the decades, have been taught to do work for “work’s sake,” and give very little thought to our internal and external direct and ultimate customers. I’ve certainly been in the room with people who just frankly don’t care. Believe it or not, many do a perfectly acceptable job – solely because of an inner drive toward a job well done. But, unless you make a shift to a customer-focused culture – with alignment at all levels, including performance metrics and reward systems, then this won’t work.
(3) How would you take a non-technology department through this exercise?
Let’s continue in the HR world, and pick a non-technology project to illustrate. Let’s say that, as a result of an enterprise-wide Agile transformation, your company now needs to change the way you measure performance on annual reviews. Perhaps, your managers were using a volume-based measurement system. What if some development groups’ performance were measured based on completion of a larger project, or if their performance scores were reduced by the number of “bugs” that were reported.
HR would have a project on its hands — it would have to completely revamp the annual performance review. Most likely, someone on the team, charged with this revamp, would begin by creating a to-do list of sorts. S/he would identify the steps needed to move that project ahead towards its end goal. If s/he started by breaking up the big tasks like “rewrite each department’s annual review forms” into smaller, manageable to-do items, it will then be possible to prioritize and assign tasks to team members. The first incremental steps of progress that result can be tracked, measured and shared with fellow team members, representing the first “iteration” of this otherwise massive project.
The open nature of an Agile project management approach requires more flexibility than simply giving someone a task. However, that’s why an Agile tracking tool that allows team members to comment on tasks and to invite input from additional team members, done in real-time, is essential. Do your (here, internal) customers regularly escalate their requests, because they think they’re not being heard or not given priority? Adopting a smaller iteration, transparent, and “here, we delivered step one” approach will quell this complaint, once and for all!
Let’s face it, serving internal direct customers, can be thankless and exhausting. Never satisfied, HR customers often work against the program, and complain about its benefits or features, before they’ve even tested any of it out. Because an essential element of Agile projects is collaboration among team members on an ongoing basis, not just in the early brainstorming phases of a project, the input of different experts working together towards a common goal causes a successful project and a satisfied customer. By allowing team members to comment in real-time, Agile-inspired workflows encourage creativity and help a project evolve positively.
Try it. Let us know how you did!
