In the IT industry, buzzwords flood the market every day from analyst firms, vendors, consultants, and countless self-proclaimed “gurus.” In recent years, terms like big data, cloud computing, and social media have taken center stage. Within software development circles, “being agile” has become just as big a buzzword as the others. Today, I want to dispel the hype around agile and share an actual application of the Agile Methodology so you can see how it can drive real value for your business. Agile is not a new concept. In fact, the term began to gain traction with the publication of the Agile Manifesto in 2001. Learn how agile development prevents leaders from investing in failing strategies. Before we dive into the practical application of Agile, let’s talk about it from a theoretical perspective. When teams are agile, they:
- Meet early and often to ensure teams and disciplines are collaborating
- Deploy processes and applications as soon as possible and are open to feedback
- Constantly refactor completed work and review their priorities to ensure they are delivering the most critical business value first
- Have open and honest lines of communication
- Typically work in Sprints*
So, while it can be difficult at times to sort through the consulting jargon and distinguish passing fads from lasting trends, it is important to review your internal processes as a company. By constantly reviewing, reflecting, and agreeing upon, “What will help us most the fastest?” business can drive real value from top to bottom.
*Note: Sprints are predefined time periods during which the team will commit to delivering an agreed upon result. As the team becomes comfortable working together, they will begin measuring the velocity of their sprints to see if the team is improving (i.e. the process is getting smoother and the teams are collaborating more openly).
“Ok, Mike. This all seems well and good but give us a real-world example of how this works.”
I am glad you asked…
At a recent client, we were developing a Project Management Application. The original idea for the software we were going to build was a mobile-enabled reporting device. Project Managers would walk around the facility, review and check off items on a standardized checklist on the tablet, and ensure they were in compliance with all local and federal requirements.
While that certainly sounds useful, once we began reviewing the business requirements of the system, it became obvious that document management and the free exchange of non-paper based information would drive significantly more value for the business. In a typical waterfall methodology, there is a high probability the project would have gone full steam ahead with the mobile reporting device. However, because we were agile, we quickly shifted focus and began developing a document management and collaboration portal.
But agile teams do not stop there…
The key business users were so pleased with the new toolset, they immediately became engaged in our work. They began reviewing their processes and questioning, “Why are we doing this? What could we be doing better?” This is the actual application of agile and how teams become more effective. So what came next—you would think the mobile reporting device, right?
In a typical waterfall methodology, there is a high probability the project would have gone full steam ahead with the mobile reporting device. However, because we were agile, we quickly shifted focus and began developing a document management and collaboration portal.
Wrong. The Project Manager’s Regional Managers got together and determined that the PMs were creating too many errors and wasting time rekeying information. So our Agile project shifted course again. This is a common way agile software projects are depicted. Optimally, they reflect the Pareto Principle, or the 80:20 rule. Our 7 Principles of Agile Enterprises slideshow explains this further.
The reason we ship the software earlier than completion is to receive feedback from the end-users. By getting a working version in their hands, they are able to provide clarity around ambiguous requirements, and suggest new higher-value requirements to the team.
The result? Even happier business users, more buy-in from the business stakeholders, and the cycle repeated itself. When the business users saw the tangible results and that the IT department was actually listening to them, they became even more involved.
As a result, the good vibes in the company really started flowing!
The company was more profitable because they reduced the time in getting questions answered by over a day. In addition, processes were improved, margins expanded, and the business streamlined their reporting which positioned them solidly for future growth.
So, while it can be difficult at times to sort through the consulting jargon and distinguish passing fads from lasting trends, it is important to review your internal processes as a company. By constantly reviewing, reflecting, and agreeing upon, “What will help us most the fastest?” business can drive real value from top to bottom.
If you want to hear even more about agile teams, checkout this Webinar co-hosted by Mendix and Jeff Sutherland. Good luck and Happy Scrumming!
This blog was originally posted on mendix.com October 1st, 2013.
About Kinetech: Kinetech is a targeted software, strategy, and technology services company with industry expertise in the energy, construction, and financial service sectors. Kinetech empowers our clients by transforming their business potential into dynamic performance.
