This post is a continuation of my series on adopting healthy practices that enable an organization to make the agile transformation. You can read the first three parts of this series here:
Although I’m trying to emphasize in these posts that companies well staffed for agile software projects don’t require any exact rules to follow about how people are organized, in practice there are some key skills that make it easier and some of these work best when they are not the same person.
First of all, you absolutely must have at least one resource I’ll refer to as the Customer Champion. This person does not have to know how to build software, can have a horrible eye for usability and aesthetics, and have no concept whatsoever for technology. In fact, it can be easier to work with them the less they try to aid in the design of the software itself. The Customer Champion is the person who understands (hopefully) what problems the customer has and of those, which impact them the most as far as time wasted, wasted money, wasted efficiency, or perhaps missed opportunities. Note that the Customer Champion does not have to know how to solve these problems! Sure they may have some ideas, and those ideas may be very helpful in coming up with the eventual solution, but their value is in communicating in the language of the business what the current processes are in the domain that the software is trying to solve and what areas for improvement exist.
Secondly, and this is important both at a product company who is trying to lead a market with their product as well as an organization that is trying to be the best in its line of work (for which software is only an internal part of the business’ value offering overall) we need someone who is a Competition Analyst. This can be the same person as the Customer Champion, but in many cases, the person asked to do both jobs is really only good at one of these skills and fails horribly at the other. If this is the case at your organization, I’d recommend making time for this resource to invest in training to get the knowledge needed to do both jobs effectively or hiring a second resource who can do it. Also do this before you start your project – it sounds ridiculous to say it but there, I have. You can solve a current set of customer problems with software but be ignorant of the competition and fail spectacularly. You can also position yourself against the market leader but fail to enable the minimal functionality needed for the customer to do their work and suffer the same fate. The Competition Analyst must find and evaluate upcoming and existing companies that either do or have the opportunity to start doing work that interferes with the success of the company, and aid in coming up with solutions to the problems identified by the Customer Champion to position the company as the market leader.
I’m not going to dive into all the approaches and processes the above two roles can use to be effective, that’s an entire topic in and of itself. The important thing is that during the design and implementation of each feature on an agile software project, the organization must be driven by the reality of the customer’s problems as well as the strategy that will produce results keeping the company at the forefront of offering value to its users. Again, this doesn’t matter if the project is for a consulting engagement for which the client’s users are the “market” or the customers of a product company. I’ve also found that while in a startup environment a brilliant person who knows a problem domain from experience and is also a great software designer can do the jobs of these roles and the ones I’m about to describe, in any other organization that wishes to respond with agility to shifts in customer need and market competition it’s much more effective with the business and development represented by at least two separate people.
Inevitably, we also will not produce working software of much value without a skilled Development Lead. This resource can have a title like Solution Architect, Project Lead, Technical Lead, or Lead Developer but if this person is truly fulfilling this role, they must have several skills. First, this person needs to be able to talk in the language of the business resources. The Development Lead will be the primary person with responsibility for the overall technical solution, and so to design an appropriate implementation, it’s critical that they are able to talk to business resources in their words and avoiding “programmer lingo” as much as possible. The Development Lead also needs to understand domain modeling as described by Eric Evans in his book, Domain Driven Design. Now I’m not saying they need to use the exact patterns in his book, but they need to understand how to go about modeling software that represents objects in the context of the domain, using the language of business users, and following industry practices that take more research and dedication than watching videos on how to use their development tools of choice. This book happens to be, in my opinion, one of the most effective pieces of current literature in conveying how to go about this – though it will lead to research in other topics (Martin Fowler, etc.) and by no means negate the need to still tediously research technologies and tools. The Development Lead does not need to be the resource most skilled at math or writing algorithms, but they do need to be able to select technologies to use and be versed enough in their use that they can lead developers in translating the models of the domain into real working software. If they are also the best programmer on the team this is a bonus from a resource cost standpoint, but will require a delicate balance to produce both solid designs and working code since their efficiency in both disciplines is effectively halved.
If the software will have a user interface of any sort, it’s important also that your organization or project structure has access to a resource who is a Usability Expert. I’ve found that many companies leave the design of the user interface up to a business person, and this is often a mistake. First of all, user interface patterns and control/widget availability is changing all the time, and business resources often don’t have time in their schedule to be keeping up on all of the latest trends. There’s no denying that an effective user interface that is also modern reflects confidence in software. I also find that business resources sometimes design the user interface out of fear that the developers will leave something out. In reality, if business resources are doing their job effectively at conveying the domain and its problems to the developer, there are no grounds for this paranoia. Secondly, designing an effective user interface usually requires looking at all the features of the software as a whole, and then “zooming in” to specific features to identify patterns for common navigation, controls, and other capabilities and this is a skill more natural to a Software Architect type of resource than a business user. Though a business resource may understand the “big picture” of the business better than a development one, software inherently only models a subset of this big picture of the overall domain, and this subset is where the patterns and opportunities for consistency need to be focused. The person who does this job could be the Development Lead, a graphic designer with usability experience, or a software developer – whoever is most skilled at designing user interfaces (and not just pretty pictures – usable pretty pictures). While it is possible to have each developer on a team design the user interface for each feature assigned to them (I’ll discuss this more when we get to posts about UI design) to enforce consistency and enable the highest effectiveness it still makes sense to have one resource that will have input on setting the standards for and reviewing all user interface mockups.
On any project of a non-trivial size, it’s essential to have a dedicated Quality Assurance (QA) Lead. Even on projects where every developer is great at writing unit tests, and the quality of the code appears to be high, the benefits of a resource that is responsible for championing the overall quality of deliverables and providing a “second set of eyes” is another recipe needed for sustainable delivery of successful projects. This person should, just like the Development Lead, be very effective at talking in the language of the business resources. A resource that can use software to create automated specific case, integration, performance, and user acceptance tests is helpful as well, but even more important is the ability to validate that the software satisfies agreed upon functionality and to identify paths through the software that are not being adequately tested already by developers.
When the number of business and development resources on a project reach a certain scale, it becomes useful to have a Schedule Facilitator. This resource might have a title like Project Manager, Software Development Manager, or SCRUM master – or it’s duties may be fulfilled by the Development Lead. On a small to medium-size project (don’t ask me for a number), if agile processes are working, the development and business resources should be communicating and executing autonomously and some of the benefits introduced by a Schedule Facilitator will already be in place. However at a certain scale, the need to coordinate the management of the backlog, availability of resources, and deal with the pressure to meet milestone deliverable dates requires time that may detract from a solid design if these duties are dually burdened by an existing critical development resource. The Schedule Facilitator should understand the agile processes agreed upon at the organization, and be an advocate for both business resources and development resources equally to enable transparency and fairness in the organization. When this resource begins to favor (or shield) one discipline of the organization from another, it leads to miscommunication, bad feelings, and ultimately unsustainably low morale. It is critical that this resource respect the value of business and development resources equally, and do whatever they can to get the right people in the room to continue making progress on projects. It’s also important for them to yield business and technical feature negotiation to those best equipped to make the decisions. Remember, the goal of this resource is to facilitate, not “design” or “manage”.
One thing you may be thinking after reading this post is how it’s “not the agile I’ve read about”. You may have been led to believe an agile project starts with a napkin, continues with code, adds some tests, and iterates with refactoring. Though I will get to all of these very useful practices, in reality the “off the shelf” agile community-driven practices we use to arrive at implementable code still exist within the larger framework of the business and its need to sustain delivery of value. A healthy organization is one that has an environment in which the problems that are solved with software are being driven by those with the problems, and developers are not the right people to identify those. Conversely, a healthy organization needs skilled development resources who are free to use their skills to enable modern solutions to the problems without a design being dictated to them by business resources. It’s this explicit boundary, and a need to continually reinforce the roles and their importance in this mutually beneficial relationship, that enables organizations to continually, predictably, and smoothly deliver value over several releases of projects. If you are going to invest the time and money to build something, it’s important to lay a solid foundation not just for the software’s technical architecture, but for the dynamics of the people who will go about making it happen.