When networking with developers from other companies, I often ask about their development process. Since effective software development in teams requires strong communication skills, it's interesting to hear about how other development teams are organized.
I've noticed an odd pattern though - a typical conversation goes like this.
Me: "So what kind of operating model does your team use?"
Developer: "*sigh*. Well we use kind of a modified Agile process at the moment. We used to do more of a waterfall approach but we're moving away from that. Thankfully, we're evolving into a pure Agile process!"
Me: "Oh, ok! So your team used to use more of a waterfall approach? And now you're moving towards more of an iterative development process?"
Developer: "That's right! We'll have daily standups and two-week sprints, which start with a big planning meeting and end with demos and a retrospective."
Me: "Oh, so you mean Scrum?"
Developer: "Yeah, that's right! I think.. They're the same right?"
There are two things that bother me here - the first is that Agile has become synonymous with Scrum even though they're completely different things. The second is that for some reason developers now feel like they have to follow a Scrum approach, or that it's the best one. What's the deal with that?
First, let's briefly differentiate between what Agile and Scrum are.
The Clear Distinction Between Agile and Scrum That the World Has Forgotten
Here's what Agile development actually is, directly from the Agile Manifesto.
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
There are also twelve principles that underpin these four concepts. These principles focus on continuous face-to-face communication, development, and improvement. Similarly, they're all fairly reasonable pieces of advice for any modern software team.
Unlike most mistaken interpretations, this is what Agile is - a set of concepts for development teams to adhere to. Note that there isn't any notion of "how" to adhere to these principles, though.
Agile is more of a philosophy than a specific way to organize software development work
This is where an implementation of Agile principles like Scrum comes in. Scrum is defined by a set of roles and responsibilities that teams adhere to in order to deliver products and services. A Product Owner, or PO, curates a product backlog which consists of items to be worked on. The development team pulls these items into timeboxed amounts of time called "sprints". A Scrum Master meets daily with the team to discuss work being done and priorities. There are also planning sessions and retrospectives.
Compared to the Agile philosophy, Scrum is clearly focused on the "how" part of the equation. Because of this distinction, there's actually no such thing as a "pure Agile" development process because Agile is more of a philosophy.
Why You Should Customize a Development Process to Meet Your Team's Needs
Although the Scrum process has become synonymous with the Agile philosophy, it's not a one-size-fits-all solution. Scrum is a fairly prescriptive framework consisting of daily standups, sprints filled with user stories from the product backlog, capacity through story points, etc.
And I have to give credit where it's due - not only has the process become synonymous with Agile development, but the marketing forces behind it have successfully pushed the idea that there's this binary world consisting of only waterfall and Agile development. Waterfall is positioned as the ancient model that's no longer relevant and Agile is presented as the only alternative.
But to say that this specific system is the best way for every development team to organize their work is ridiculous to say the least. Think of all the different team makeups, organizations, problem domains, personality types, and other factors that could impact how following a development model plays out.
This is where other operating models come in. Ideally, a team would adapt any principle that helps them to deliver their products and services effectively, regardless of what philosophy or model it came from.
Therefore, it's worth exploring what other development philosophies and frameworks are out there to find out what benefits can be gained from each.
An Agile-like Alternative to Scrum
First, let's start with a development process that's not radically different from Scrum - Kanban.
Kanban is similar to Scrum in that it's based on principles that are similar to Agile. It was originally invented as a scheduling system for the Toyota Production System, but has since been adapted for software development as well.
In Kanban, the focus is on work in progress, or WIP. A Kanban board is used to track WIP, which consists of a series of columns that range from the inception of a task all the way to code deployment. A team puts tasks, represented as cards, on the board in the first column and moves them across the board as they're worked on.
Each column represents a phase of the Kanban process, and the team is limited to working on a certain number of tasks/cards in each phase.
Each column has a WIP limit, which sets a maximum number of cards that can be in a column at once. This prevents the team from too much multitasking or overcommitting to work. When a column is filled up with the maximum number of cards, the team is incentivised to help "unblock" the column by working together on the tasks that are stuck there.
Unlike Scrum, there is no notion of a timebox for a set of tasks like a sprint. This means that under Kanban, you don't estimate how long it will take certain tasks like you do for user stories in Scrum. Planning and grooming sessions take place as needed instead of having fixed sprint planning meetings, retrospectives, and other Scrum rituals.
Learning from an Operating Model for Designers
Unlike Kanban, design thinking is a broader approach that encompasses both deciding what work is worth doing and how to do it. Another difference is that design thinking describes a process in which various phases can be happening at the same time in a non-linear fashion (instead of work going through a clearly defined pipeline like a Kanban board).
With design thinking, any (or even all) of the above phases can be going on at once.
A design thinking approach begins with identifying a common problem that a certain population (i.e. your users) has. Research is done to better understand the problem, its causes, and possible solutions.
With the available research findings (remember this process is non-linear), ideas for possible solutions are refined with further analysis until they become actionable. To help form these solutions, patterns between the users in the studied population and their problems are identified.
Ideas that are specific enough to be implemented are prototyped and tested on the population, or a subset of it. Attention is given not only to the functionality of the prototype but also for the overall user experience and the emotions it evokes. To further improve the solution being tested, prototyping continues to happen in an iterative fashion until a final solution is decided upon.
What excites me about design thinking is its human-centered approach to solving problems. The prescribed workflow for identifying and solving problems is reinforced by focusing on designing solutions that create a great experience for end users.
A Waterfall Principle to Steal
Let's circle back around to the waterfall model, which has been advertised as Agile's mortal enemy. The waterfall model is drastically different from an Agile approach in that it is non-iterative. Instead of delivering work in small pieces, the waterfall process organizes work into irregular releases that are split into discrete phases.
In the first phase, detailed specs are defined by product teams in a silo, which are eventually rolled down to the development team to act on within a fixed timeframe. Teams operate in a more silo-like fashion and development can't start until all specs and design have finished.
Each phase can't overlap with another. This means that any phase that's not on schedule has a ripple effect on the remaining phases. For projects in a time crunch, the development team may not have time to question any specs or design details. This can result in a rushed delivery and a very unhappy QA team.
As a developer in the waterfall model, you're stuck from doing anything in the implementation phase until the requirements and design phases have completed.
Because of the potential ripple effect, development and QA teams have the potential to suffer the most with this approach. If the initial phases aren't completed in time and the requirements don't have enough technical input, then the development team has to work with poor requirements on little time.
In retrospect, this all seems pretty terrible. I do think that there is one benefit to waterfall though - lots of time can be given for the overall architecture and design of a solution. As someone who's currently rearchitecting the front-end environment that my team works on, designing long-term solutions can't always be done in a sprint-like manner.
Creating Your Own Development Process
As you can see, there are many workflow models out there that can be adapted, even if just in part, to suit the unique needs of your team. Since there are pros and cons to each approach, I'd recommend picking and choosing which aspects of each approach are the most beneficial.
When considering how to customize your development process, think beyond the prescribed recommendations of a particular workflow model. Think instead of the specific strengths and needs of your development team. In this way, you could even pick a particular model to stick to (like Kanban) and then sharpen it to suit your specific environment.
As a starting point, consider your unique team in these three contexts:
1) The preferences and skillsets of your team
2) The needs of the stakeholders your team writes code for
3) The future preferences and skillsets of your team
First, think about the makeup of your development team. Does it skew towards newer developers and could benefit from more structure and process? Or does it mostly consist of veterans who believe that too much overhead slows them down? How does the team prefer to work and how much process do they feel is necessary?
Think about your overall team vibe. Mostly newbies? A group of experts? Mostly introverted or extraverted? These and other human-focused factors can impact which development process will work best.
The preferences of your team should be balanced delicately with the needs of your stakeholders to deliver to the business. Is there one unified direction that the business is moving, and so it's easy to streamline those objectives into work for your team to deliver? Or are there competing objectives and changing requirements often?
Consideration should be given as well to where your team sees itself in the future. Maybe newer developers on your team are independent and ramping up quickly, and will eventually grow tired of process rituals like daily standup meetings. Creating a development process that's flexible, or at least an environment where developers are open to change, will allow you to scale effectively in the future.
Why Soft Skills Strike Once Again
There's no technical answer to solve for when it comes to creating a development process for your team. Instead of just charting out workflow models and diagrams, think about how each individual on your team will feel when working with a specific model. In this way, you'll think about each developer from a human perspective, as opposed to just inputs into a workflow diagram.
Developers aren't robots - so design a development process that considers human factors.
Will developers feel encouraged to do their work and continue to improve over time? Or will they feel that they're being stifled by too much process? These are some of the questions you'll have to answer and adapt your workflow model for.
Designing an effective development process is yet another example of where soft skills are invaluable to software development. Whether you're the manager of a software team or a developer who has input into your development process, communication skills and knowing how individuals work together are vital to having the insight to make effective recommendations.
My recommendation to managers of software teams is to allow your developers to get heavily involved in designing and improving their development process. Their insight is crucial since they're literally working within the model.
With happy developers comes a better product - the happier your developers are, the more productive they will be. This uptick in productivity will improve the quality and volume of the work they produce over time. With this in mind, remember to always consider how you can customize and adapt your development process over time to better suit your unique environment.