Post-Agile: A Design Thinking Approach to Software Development
Regardless of how trained and focused your people are, when the projects you work on vary in complexity and time finding a single project management solution that works for all is impossible. This is the truth I have discovered after my first three months at Artefact, where the range of development projects varies widely – from an 18 month fully integrated design and development like PIRCH Advisor to a quick four-week iteration on our commenting platform Civic IQ.
Yet Agile project management, or the iterative and incremental method of managing design and development has become so pervasive, that people and companies throw the terms around like they’re the panacea for all productivity issues. Not only that, they expect you to blindly embrace and follow the methodology regardless of the project at hand. And if you dare to divert from the postulates of the Agile zealots, you will be judged. And it won’t be good.
But we at Artefact use design thinking as the approach to solving problems. Design thinking is centered around truly understanding client needs and opening yourself up to try as many things as possible before coming up with the preferred solution. This is the approach we are taking with development as well –analyze, experiment, and remain flexible to use the approach that best suits the nature of the problem, the needs of the client and the capabilities of your team. As a result, every design and development project we undertake falls on a different spot along the agile/waterfall spectrum. There is no silver bullet, or universally applicable method. Because problems will be problems, people will be people, and deadlines will be deadlines.
Waterfall – And why it’s not completely evil
Those of us in the software field have been trained over the last several years that Waterfall, or the methodical one directional approach to development, is pure evil and will doom the project from the beginning. No arguments there – I once worked on a project that had a 9-month deadline but took more than 6 months to get the final specifications. That left just enough time to build something nobody really liked with hastily made decisions to drop key features. Yet, there are certain pieces of Waterfall development that are beneficial, so let’s not be too hasty to ignore all of it.
Everyone by now knows the cons of Waterfall:
- Massive specs bear little resemblance to what is actually needed: No matter how good the product person and the architect are, you cannot conceive of every eventuality. And even if you do, it will take so long to get to market your users won’t want it anymore.
- It takes a long time: Design and development cannot begin until the product manager has thought through every single scenario and use case, once they’re done, design makes everything perfect, and then, finally, development can begin. The longer something takes the greater the chance of estimates being wildly wrong and functionality obsolete before it even hits the market.
- Teams operate in silos: By its very definition, the interactions between disciplines such as the designers and developers are restricted. As a result, things get designed that won’t work, developers make decisions others don’t like and everyone has a ‘throw it over the wall’ mentality for dealing with issues.
- What does not kill you, makes you hate each other: Every Waterfall project of any sort of scope always ends with software engineers working long hours, being blamed for features not making it to the end and generally despising the product folks. And after the engineers, the QA teams get really squashed. They test rushed code in a severely limited time frame and then take the blame when bugs get to production. Fun.
All part and parcel of Waterfall development and all things we need to avoid during any project. But should we throw the baby out with the bathwater? Let’s see what we can keep:
- Plenty of time for research: It’s always good to know your users, to drill down to exactly what the key principles are and to make sure that early designs are going down the right path.
- Plenty of time for design: Having plenty of time to really nail down the overall design is very important. There will be iterations and improvements later in the project but having a cohesive design language at the onset will help with decisions down the line
- Plenty of time for architecture: Coming up with a sensible, scalable architecture on the fly is challenging, by putting in the effort at the beginning to create a system that can adapt to changing needs as the project progresses you’ve got a solid foundation with room to grow.
Agile – And why it’s not perfect
The Agile movement has been great for getting companies and products out of slow, ponderous life cycles that have often resulted in outdated products. While the transition to Agile has had many benefits, confusion, poor transitions, zealots and over-priced Agile consultants have only replaced Waterfall’s issues with different ones, often making things worse than they were.
Undoubtedly, Agile has been praised for faster time to market, better adaptability to the changing needs of the user and a better-aligned collaboration between different teams and disciplines. But despite what the Agile zealots will tell you, not everything is coming up roses. Without the proper guidelines, Agile can lead to
- Architecture and code can be a mess: It happens, you start off in one direction, need to change but keep some of the old code around because it’s quicker. Now, keep doing that on a large code base and pretty soon you’re going to end up with spaghetti.
- Hard to produce perfection: When everything is an iteration it can be hard to really nail either the architecture or the design. In many cases, that’s not a big deal but as a design firm that prides itself on creating perfection, nearly perfect isn’t good enough.
- Zealots: You know them. They’re the ones that live and breathe Agile and if you do something that’s not in whatever Agile book they’ve memorized, you will hear about it. It’s even worse when the zealots are misguided. I have heard statements like “we can’t add that to the sprint, we have to wait until sprint planning before we can change scope.” This is not only contrary to the very nature of Agile, it’s dangerous to the company. If you’ve got a showstopper you better make sure the team is set up to react to it before it is too late.
- Paired programming: This one’s contentious as not every developer likes being teamed and supervised in real time. While paired programming can help, if you’re transitioning to Agile and didn’t hire for paired programming then a lot of your developers might have a real problem with being forced to pair just because some Agile zealot told them to.
Big A vs little a
Here at Artefact, we practice being agile, with a little a. The difference between big A and little a agile is pretty straight forward. Being ‘big A’ Agile means that you do everything the Agile manifesto tells you to do – when you spend that much time worrying about being Agile and following all of the rules you’re not actually being that agile. When you’re being ‘little a’ agile you’re adapting to ever changing teams, needs, and projects and that’s kind of the point. For us, as a design and development consultancy, we can’t do the same thing on every project – the clients change, the needs change, and the teams change. That is what being agile is all about.
There’s a term called post-agilism being bandied about that has its own manifesto that is delightfully succinct. Here’s the core:
If it works, do it.
If it doesn’t, don’t.
Seems pretty simple but you’d be amazed by how many people keep trying to follow every single Agile principle or how many times you hear ‘it’s not Agile’s fault it didn’t work, you weren’t doing it right’. People are afraid to veer from the One True Path for a couple of reasons – they’ve got someone shouting at them telling them to do it one way or they don’t have the experience to feel comfortable experimenting. My experience has taught me that yes, sometimes it is your fault, but often, trying to force Agile into every situation will simply not work. Every team is different, every project is different and you want to make sure that you do what’s best for your situation. If test-driven development is a success, great, keep doing it, if it slows you down and doesn’t add any value (and yes, unit tests can be more of a hindrance than a help) then stop. That’s being agile, with a little “a.”
The Artefact way
One of the keys to agile is consistency – keeping the same team allows you to predict the future by using past sprints to create an average velocity. When the teams change and the projects are too short to build up a history it’s a lot harder to predict how much work you can do in each sprint and for the whole project. What we use at Artefact is a combination of individual experience, company history, and communication. We hire very smart people who know what they’re doing. What they’re also good at is knowing their own limitations. By looking at the type of project, the length, the composition of the team working on it and the client we can decide which style of project management we’re going to use. And this can, and does, change between phases of a project.
We did not learn that the easy way. In fact, a lot of these thoughts are the result of our own explorations of Waterfall and Agile. But it is the ability to learn from them and synthesize the insights that make us, and the design teams we work with, truly agile. The extent to which we choose one approach over the other often depends on the nature of the projects. Here are a few types that we have spotted along the way:
- Quick prototyping: When it’s a developer and a designer working closely together to do some rapid prototyping, they’ll either use email or Slack to communicate ideas among themselves. Nothing more is needed. Civic IQ is a perfect example of that approach.
- Heavy research and design/light development effort: We have many projects that are very heavy on research and design but only require either a proof of concept or front end code that can be applied to other areas. For these, there is definitely a large element of Waterfall style project management. Research. Design. Development. When it comes time for development a simple Trello board is setup and work is funneled Kanban-style through the developer. Using Kanban for development allows us to track progress, iterate quickly and provide feedback on the rate of completion for the client. We are currently working on a project for a large IT services provider that involved several months of research and design that culminates with one sprint’s worth of front-end development work to provide a UI framework for the client’s development team.
- Deep integration with client development team: When we’re involved in a support role for a client’s development team we generally follow their methodology. We integrate with their process, their cadence, and their tools and become a complementary team to their internal one. This requires that we maintain and constantly develop a broad set of skills to ensure we can integrate with the broadest set of teams. At the same time, our understanding of both agile and waterfall allows us to steer the collaboration depending on the product we are working on and the experience of the teams we’re working with, converting the zealots along the way.
- Large development effort: When it comes time for projects with a significant development component, the development side of things will always be done with ‘little a’ agile. There may be weeks or months of research, strategy and design before any code is written but a developer representative will be involved to help guide and provide feedback on proposed solutions. This ensures that the architecture, frameworks, and languages used will provide the best combination of flexibility, scalability, and ease of maintenance for the finished product. Once it’s time for development, regardless of what project management solution has been used so far we switch to agile development, where we bring our shared experience of shipping software to deliver frequent, meaningful updates to the client. That’s what we care about the most and that’s what drives any changes to our process.
What should I do?
Working in a design and development company, on a variety of projects, gives our team of developers a great way to keep our project management muscles agile. But what if you do not have the opportunity to do that? I would still encourage you to try things. Don’t be afraid to experiment. Keep the bits that work and change the bits that don’t. Along the way, try to utilize some design thinking strategies – especially brainstorming – open it up to everyone involved and put no boundaries on the ideas that people can suggest. Come together as a team, discuss them, and try them. Or as the post-agilist would say if it works, do it, if it doesn’t, don’t.