Agile Mindset in Software
Rob Sanchez
We discussed the Agile Mindset along with the 4 important values and 12 underlying principles in the last article. Today, we’ll expand on that to look at Agility in Software Development. To do so, we’ve got to talk about something unpleasant first. Waterfall Style Traditional Project Management. This is an outdated form of managing software projects that unfortunately still exists in software companies of all sizes and industries.
In a waterfall project, all of the planning is done in the beginning. Similar to how a new home would be built, the blueprints and layouts are all prepped and planned before the ground is broken and construction begins. In this way, the project focuses on gathering all of the information and requirements up front and becomes very plan driven. With all elements of the project accounted for in the master plan, what could possibly go wrong? The plan once completed will allow cost and time estimates. As work gets started though, we inevitably run into something that was unplanned. Well then the entire plan needs to be changed to accommodate this new change, and the knowledge it brought with it which ultimately pushes out the cost and time required to complete the project.
That’s not Waterfall’s only fault. It cuts out the human element of the dev team and dictates a top down approach where it’s assumed that every single requirement is gathered accurately by one or more Project Managers. I can tell you from experience, as can many others, that this doesn’t work as planned. The developers have years of experience in their field. They should be brought into planning as early as possible to weigh into the product before development has begun. Paying devs for their work only and not their insight and advice is missing the point of knowledge work. The final point on waterfall is that value is delivered at the end in one grand finale; clients have to wait until completion to see any value. That’s enough about that, let’s get back to our main character Agile.
So how does Agile differ? In Agile, it’s the opposite; it all starts with the value to be created. Cost and time are fixed and the features are estimated. The vision drives this process. Instead of having scope creep on waterfall projects that are resistant to change, the scope can be set early and often in Agile. When run with Scrum frameworks as we’ll discuss in future articles, this scope is set in two week increments. These can be easily analyzed to address the value created and make future decisions about the team and the project.
In Agile, the planning is still important at the beginning; it’s not that there’s no planning. There’s much less though and the planning is thought of as a general guideline not something that the team will be held to. This allows room for knowledge and adaptation in the product. As the team works new discoveries and obstacles will present themselves. These are opportunities for improvements on the original plans. These unknowns were unknown at the planning stage. They have to be found in the work. In Nassim Taleb’s book “The Black Swan: The Impact of the Highly Improbable” he discusses these unknown unknowns and their prevalence. Folks quickly assume they have the full range of data in most situations especially when planning complex projects and products. But when that unexpected data point presents itself, things can go awry quickly. That’s why agility matters and adapting to new industry trends, technological changes, and general vertical knowledge throughout development is crucial. Pairing this with customer interviews and constant stakeholder feedback will create the value needed originally and then some.
The value delivered in Agile methods is also incremental. Users or clients will see value within a matter of weeks and then constantly see that value delivered as the project is completed and feedback is taken into account. This allows leadership to get instant feedback on initiatives and changes in their product. If needed, plans can change and the company can continue to maximize its dollars spent on development.
Agile in software development is much more than just a mindset though. To collaborate and achieve high-performing results, there are roles, tools, and frameworks, designed to help get work done. These are used with the agile mindset, paired together, and tailored to unique environments to optimize the value delivered. We’ll discuss the first of these tools, called Scrum, in the next Article.
For more articles on Agile see future Apt 113 posts. If you’re interested in working on Agile or Scrum teams, reach out for career or certification advice.