Comprehensive software reviews to make better IT decisions
“Doing Agile” Is Only Part of the Software Delivery Pie
“Being Agile” enables the delivery of the right value at the right time. When most people talk about this, they think about the core technical skills required in the action of delivering software. This is only part of the Agile software delivery pie.
SFIA does very well in articulating the skills, competencies, and attributes across different disciplines (which include information technology, digital transformation, and software engineering).
Specifically, these skills fall into one of four categories:
- Engineering Skills. These are the skills and competencies required for building brand-new valuable software.
- Technician Skills. These represent the skills and competencies required for maintaining and operating the software delivered to stakeholders.
- Framework/Process Skills. These represent the specific knowledge required to support engineering or technician skills, for example, Scrum, SAFe, and Kanban.
- Tools Skills. Represents software that helps you deliver software. Some examples include Azure DevOps and Jira.
These represent the hard skills needed to do Agile. While these are important, they are not the whole story. To effectively deliver software, we believe in the importance of being Agile over simply doing Agile.
While doing Agile is important, it does not enable the effective delivery of value to stakeholders. Doing Agile represents the hard skills required to put working software into production using an agile method. Unfortunately, working software alone doesn’t create value. To effectively deliver, we believe in the importance of being Agile over simply doing Agile.
Enterprise Agile coach Matt Hosking says, "Ultimately though, the 'essence' of agility and from where people actually get the real benefits are in the soft skills - the 'being agile', rather than 'doing agile'."
At Info-Tech, we are aligned with the distinction between the different classes of skills and directly tying them to being vs. doing Agile. However, we have a different view of what it means to be Agile.
Doing Agile is all about going through the motions and carrying out the actions required to deliver. For example, user story writing, doing standups, ceremonies, and retrospectives are all important skills required to do Agile.
However, to be Agile, you need a change in thinking and behavior, which we call Agile skills. These Agile skills come from traits and values I previously discussed in Agile Skills Don’t Revolve Around Ceremonies and Procedures: They’re About Traits and Values. For example, embracing the unknown, collaboration, analytical thinking, ability to learn, embracing risk, and willingness to innovate.
Everybody who aspires to be an Agile organization needs to understand and embrace the appropriate Agile skills that work in your context. This is in addition to the engineering, framework, technician, and tools skills that are articulated by SFIA.
Want to Know More?
Learn more about what it takes to being Agile instead of simply doing Agile.
Traditional accounting practices are tailor made for waterfall project management. Organizations that have transitioned to the use of standing product teams using Agile and DevOps need to transform their accounting practices as well or they will leave valuable capital expenditure dollars on the table.
IBM is changing the terms of its ubiquitous Passport Advantage agreement to remove entitled discounts on over 5,000 on-premises software products, resulting in an immediate price increase for IBM Software & Support (S&S) across its vast customer landscape.
So you’ve gone Agile. You do daily scrums, retrospectives, and all the “right” Agile ceremonies. But still your organization isn’t quite convinced. It is now critical to balance the drivers and goals of both Agile and traditional thinking in order to achieve organizational success.
Do you feel like your Agile teams are treading water – going through the motions but never going anywhere? It’s a risk, and practices such as daily standups, retrospectives, and demonstrations need to be used wisely or you risk losing discipline to meeting fatigue.
Stakeholders expect the speed and responsiveness of product delivery does not come at the expense of quality. QA tools offer retailers the ability to continuously ensure both business and technical quality standards are upheld, but these tools should not be viewed as a silver bullet.
When trying to implement Agile as a defined process, Scrum turned BAs or other roles into order takers with the title “product owner.” This undermines the entire value proposition of product management.
No matter how good your product roadmap and backlog are, they are only as good as your audience’s ability to understand your vision and priority.
The scrum master is like the conductor of an orchestra, ensuring that every piece fits together at the right time to create something greater than the sum of the parts. You don’t have to know how to play each instrument, but you do have to understand what each part contributes to the overall masterpiece.
Tools are important to product teams, but only when they support solid people and processes.