Article summary
Publication of the Agile Manifesto in 2001 turned the software development world on its head. Waterfall, with its months of comprehensive planning followed by months of heads-down development, was out; Agile was in.
The Agile Manifesto lays out its values and the principles behind them, but it avoids defining a process. And this is good. After all, the Agile Manifesto’s first value emphasizes “individuals and interactions over processes and tools.”
Agile Frameworks
Businesses need to plan, though, so various Agile frameworks (i.e. processes) have been created: Scrum, Kanban, XP, etc. Although these all provide value, I’ve experienced problems with each of them.
Scrum
Scrum provides a business with timelines. It can also feel like a cascade of feature waterfalls, rather than a big project waterfall; a day of not-as-comprehensive planning followed by a week or two of heads-down development, repeated.
Kanban
Kanban can be extremely efficient, but software development does not behave the same as manufacturing (Kanban’s original industry). The variability of time needed to develop software features makes it difficult, if not impossible, to manage the flow of work and smooth it out.
Extreme programming
Extreme programming (XP) perhaps comes closest to pure Agile. It has an almost fanatical adherence to the values and principles laid out, and it iterates very rapidly. My most productive time developing software involved doing XP by pair programming and switching pairs every day. However, the changing requirements and updated designs still felt like they fell outside the development cycle.
Cross-Functional Development Team
A recent discussion with a coworker led me to envision a cross-functional development team in which the product owner, designer, and developer pair together. After all, one principle of the Agile Manifesto is that “business people and developers must work together daily throughout the project.”
Developer pair
Developers pairing would be akin to pair programming in XP.
Product owner and designer pair
In my experience, product owners and designers already work closely. This pairing setup would see them work the entire day together to design for the customer’s requirements. It would give the product owner visibility into the designer’s thought process and also resolve potential misconceptions about what the customer wants.
Product owner and developer pair
Pairing the product owner with the developer grants the developer immediate clarity into customer requirements. In return, the product owner sees exactly how the code operates and notes any edge cases that need to be handled. As they pair, the product owner may also be alerted to mistaken assumptions the developer may have made regarding the user or the domain and correct the code architecture before a large refactor is needed.
Designer and developer pair
There is often a lot of back and forth between designers and developers, and pairing them could reduce that overhead. Design is often guided by technical feasibility, so having instant access to the developer could be helpful. Likewise, the developer has the design intent available, so UI designs can be shaped on the fly.
Caveats
While I think such a setup has merit, there are definitely valid concerns, as well. The product owners and designers shouldn’t need to learn to code, but that requires any developer they might pair with to be willing and able to explain technical concerns in terms of the product domain.
There are also valid concerns about efficiency; non-developers pairing with developers on code sounds like a potential waste of time. However, I think there’s a lot of value in product owners and designers thinking in terms of implementation and edge cases. There is also a lot of value in developers thinking in terms of intent.
Inter-disciplinary work is at the forefront of new ideas, and having product owners and designers as part of the pairing rotation seems like an interesting way to generate those ideas.
Although I’ve never experienced a team like this, I would love to be part of one and learn more about what works and what doesn’t. Have you ever worked on an inter-disciplinary team?