The Agile process and methodology is used in a handful of industries, but most commonly seen in the world of software development. Agile development is focused on the idea of iterative development and building evolving solutions through collaboration between the developers and clients.
By implementing an Agile process, there is room for frequent inspection and adaptation throughout a project. Rather than building the entire piece of software before sending out for review, the Agile system allows for two or three week sprints.
During these sprints, the developers work on the next big milestone of the project, then gather internally and with the client to review progress. This allows for easier, faster adjustments and ensures all parties are still in agreement with the direction and priority of the project.
For over 10 years, Kevin Wentzel has been a leader and champion of the Agile Methodology and we sat down with him to get his insights and advice.
How did you get started in the agile world?
I worked at a company that pitched a shift to the Extreme Programming (XP) model, including pair programming, story point estimating, the whole nine yards.
Has agile changed a lot over the years? What are the biggest differences you see today compared to when you first started out?
The core of agile has stayed the same – spending effort in the most valuable places and getting user feedback as early and often as possible to make sure you nail the bullseye with the final result.
What’s the one thing people usually get wrong or misunderstand about Agile?
The biggest challenge is ensuring people are comfortable with a moving target. What experienced programming teams understand is that what you think is the bullseye at the beginning is almost never where the bullseye ends up.
So without that moving target, you’d end up with lots of changes that need to be made after release or a failed product. There’s a phrase that we like to borrow that describes defining that bullseye and having no movement at the beginning is when you’re at the “maximum point of ignorance.” There are always lessons learned through the course of the development process that can drive even higher value.
What challenges have you faced with implementing true Agile practices?
It depends on how you define “true agile.” There are so many different variations and flavors now as organizations have figured out how to implement agile principles for themselves. For us, our clients need to have an idea of overall cost at the beginning and we need to manage to that. Very frequently we must go deeper in the design/planning up front than would be used in “true agile” operation.
We use that time to uncover unknowns and risk points so that we can comfortably estimate the whole project using a time allocation model similar to budgeting the different parts of building a house. It is then our team’s job to work with the client to manage the product to those allocations.
What advice would you have for other organizations?
Be real with yourselves in terms of what your strengths and weaknesses are and what you want to get out of the agile process. For most organizations, targeting “true agile” will only result in frustrated management and development teams. Use one of our core values and figure out how to Simplify the process to make it manageable and repeatable.
Are there some qualifiers to see if a company is eligible or qualifies for Agile?
Companies that operate under strict, fixed cost, fixed scope rules will struggle to be successful with agile. Agile requires a trust in the process that some organizations just can’t take the risk on. If nothing else, integrating in some agile principles can work. For example, iteratively delivering a project that has been fixed-scoped to get feedback earlier. You’d rather catch a scope change early in the project than after the release.
Who would qualify for Kanban, Agile, or Scrum? Why would they be eligible for one but not the other?
Strengths/weaknesses of the organization, comfort level with a full agile process, desire for simplicity can all drive the choice. Kanban is a great simple way to improve how projects are managed without going full agile. Technically Scrum is just a type of Agile, so it’d be a decision of whether Scrum was the right way to specifically implement Agile for the organization. So – organizations first need to decide whether agile is right for them, then which type of Agile is best for them (Scrum being a very popular one).
What tools have you found most useful for working in an agile way?
Most project management tools these days have good support for running agile. For us, we needed a product that we could configure and customize to be our “daily work tool” for our development teams. We are willing to pay a little more for a tool that allows that because it is so core to our success as a business, but others may want to just use a free tool because it can deliver what they need. We do like using a tool that integrates with or offers a source control product so that you can tie source code to the stories that have been completed.
Where do you see things evolving and changing for agile in the next five, ten years?
I think you will see some organizations implement and figure out how to execute what I would call hyper-agile where sprints can be measured in days instead of weeks and priorities shift on an hourly basis. This will primarily happen in organizations that have lots of small stories.
As low-code development platforms become more prevalent, that will shorten development cycles. Some organizations will struggle with the pace of change, but others will excel and be able to make huge business impacts by taking advantage of it.
What advice do you have for aspiring Scrum masters and those new to agile?
Don’t be too hard on yourself. You’ll read articles about some really mature organizations and experienced scrum masters, but they all had to start somewhere. See if you can find one and ask how they got started and what lessons they learned.
