Googling “Post Agile” brings up the following as “Searches Related to Post Agile”
Design Thinking is a collaborative process where those who innovate meet a user demand with what is technically feasible, using a viable business strategy. It′s a human−centered approach to problem solving that helps people and organizations become more innovative and more creative. (Explore Creative Confidence by Tom & David Kelley)
A good article on combining Agile and Design Thinking comes from Tom Roach, Design Lead at IBM. Check it out: How to combine Design Thinking and Agile in practice
Agile and Design Thinking are not mutually exclusive. To compete in today’s market place, engineering leadership must embrace both. And what is more, a good measure of systems thinking needs to be applied as well (read the entertaining The critical role of systems thinking in software development to understand why).
By now there is substantial experience across teams of software development, and a pragmatic approach of adopting the agile process seems natural. Adoption means not to blindly follow some agile guru’s prescriptions, but evaluate what would work in your specific environment and specific projects.
The types of projects where you can use close to a pure agile process are at least of two types (there might be more). One is when you need to deliver a POC that has technology exploration with an MVP end goal. Another is when you have an established deployment framework (referencing the SaaS model), and you are providing incremental functionality taking advantage of what already exists, and hence don’t have to worry about the design and architecture and quality attributes).
If the project is one of delivering a major platform or a framework that will form the underpinning of customer facing capabilities, a lot of design thinking and systems thinking must be expended at the start of the project. The “design thinking” is critical and might consist of a few prototypes which may have to be thrown away; systems thinking would warrant intense interaction with the chief architect to make sure the quality attributes are addressed, and a good measure of project planning to design the sprints in a meaningful way to achieve milestones that might only be seen by the internal stakeholder.
Unless you are creating a very simple web based application, you are bound to have a number of projects of varying types. If this is the case, it is best to evaluate each project to determine how agile should be adopted. The difficulty in implementing agile in a geographically distributed team is also a motivating factor in not blindly following the agile manifesto.
Current software development teams are using agile in one form or another. Embracing agile along with design thinking and systems thinking is bound to delight the stakeholders.