Why are some teams successful while others are less than stellar? Can teams use processes to do their work? How can managers help teams to become better? And do we need incentives to improve the quality of software? These are some of the topics that Simon Brown’s talked about at the GOTO Amsterdam conference earlier this year in Sustainable competence - the people vs process and technology.
InfoQ did an interview with Simon Brown, in which he talks about sustainable competence for continuous improvement, balancing people and processes, and software quality and architecture.
InfoQ: Simon, can you introduce yourself to the InfoQ readers?
Simon: I often describe myself as a software developer that understands architecture, or a software architect that writes code. Like many people, I started my career as a software developer and gradually evolved into taking on the software architecture role on projects. Where possible, I still get involved in the day to day development work.
Five years ago, I moved back to Jersey in the Channel Islands. Jersey doesn't necessarily have a reputation for software development so it may seem an odd choice but I was born there and it's a fantastic place to live, especially if you have children. Prior to that, I spent twelve years working for IT consulting companies in London and, although much of my work was focussed on the finance industry within the city, I’ve worked in a broad range of vertical industries. From a technology perspective most of these were Java projects; ranging from rich-desktop applications and websites through to distributed messaging and service-oriented architectures.
Much of my work over the past couple of years has been helping software teams understand software architecture, technical leadership and the balance with agility. I'm writing a book called "Software Architecture for Developers" (via Leanpub.com) and I work with teams across Europe, teaching them about software architecture and how to adopt a "just enough" approach to up front design. In essence, this is about introducing technical leadership, which is often forgotten in the race for agility.
InfoQ: You talked about that not all teams are created equal. Can you explain what you mean with that?
Simon: Although we would all like to work on the super-experienced, self-organising teams described by agile evangelists, in my experience this doesn’t happen that often. In the real world, you rarely have a choice of the people that you work with. Some are great and some, well, not so much! Different people are motivated in different ways too. Some people work as software developers because they enjoy the creative challenge of delivering something using technology. Other people work in IT because it pays well. With such a wide range of people in the IT industry, not all teams are created equal.
InfoQ: In your talk you showed that teams use processes to do their work. What are these processes? And how do processes help teams to do their work, and improve their way of working?
Simon: Software teams often use a number of processes to do their work, varying from high-level processes to shape the way that software projects are run through to lower-level processes that help you take requirements through to code and through to tests. If you look back in time, before Agile hit the mainstream, many software teams used to be driven by and follow explicit processes. Obvious examples include waterfall and the Rational Unified Process (RUP). As an industry, we’ve now moved away from following explicit processes and the “agile mindset” tells us that it’s okay to adapt the way that we work in order to improve. You could say that blindly following a process has gone out of fashion. And while this is generally a good thing, I often find that software teams don’t understand where to start because of it. A well-defined process provides a starting point and can be useful if you don’t know where to start. Although it doesn’t get much attention, DSDM Atern is a process framework for running agile projects. Although some people in the agile community say that this is an oxymoron, I personally think that Atern is a nice starting point for teams who are new to agile. The key here is that it is a *starting point* and should be adapted as the team gains experience.
InfoQ: Plan driven methods give much attention to processes, while agile prefers people over processes. What are ways to balance people and processes, combining the strengths of them?
Simon: For me, it’s all about putting some structure and discipline in place because we don’t want a “free for all”. A team of experienced people usually have the experience to naturally do the right thing. That’s why they’re experienced! A team that has a mix of abilities, like those you mostly find in the real world, often need some guidance. I would advise such teams to keep their processes light and ensure that everybody understands what those processes are. Processes can be restrictive, but sometimes people need some guidance and boundaries to work within. The trick is understanding the people that you are working with, adapting the level of process as needed.
InfoQ: Outsourcing expects that you as a customer collaborate with your suppliers, and assure that you get what you need from them. Sounds easy, but many organizations struggle with this. Why?
Simon: Let’s imagine that you’re an organisation with a very limited internal IT capability and you need to build a new software system to deliver some benefits for your business. One option is to organically build and grow your own internal IT capability, by hiring people or using contractors. This is possibly the better long-term option but, as somebody that doesn’t know much about IT, this sounds complicated. The other option is to outsource the work to an IT supplier and pay them to take care of everything for you. In order to reap the benefits of the relationship, you need to work as partners. While this sounds straightforward, contractual agreements and your inexperience with IT will get in the way.
Most of the customer-supplier contracts that I’ve seen, and still see, are of the form, “we’ll pay you X for delivering Y by date Z”; fixing the price, scope and time. Think about the last time you decided to hire somebody to fit a kitchen, refurbish a bathroom or build an extension. You have a rough idea of what you want and you have a budget. But what happens when you change your mind about the type of tiles or size of windows that you want? If you have a fixed price contract, you might find that “collaboration” starts to breakdown as you eat into the supplier’s profit margin and the job starts to take longer than anticipated.
The key to effective collaboration is to ensure that people don’t think of the customer-supplier arrangement as “us and them”. Everybody needs to have the mindset that it’s a single team, with shared goals. In my experience, simply having the customer and supplier in close proximity and working together in the same office is often enough to ensure that projects start out on the right footing.
InfoQ You discussed the incentive for quality. First, do we really need an incentive for that? Why is this important?
Simon: This comes back to how not all software teams are created equally. If a supplier is fitting a kitchen for you, it’s often obvious when they’re cutting corners or using substandard materials. A visual inspection is usually all that’s needed because very little is hidden away from you. In the software world this isn’t the case. Sure, your supplier might deliver you a very polished website and therefore, from an external point of view, that website looks good. But what about the internal quality - the stuff that you can’t see “under the hood”? To put this another way, how do you know that the software has been designed “well” and that the code is “good”? Software with a poor internal quality tends to be hard to change, enhance, maintain, operate and support. Although these problems may not manifest themselves immediately, you’ll certainly pay the price later. If you don’t know anything about software development, which is often a major reason that organisations outsource, how are you supposed to make a judgement call on whether the software being delivered is of a high quality?
Of course, you could put some quality metrics in the contractual agreement (e.g. unit test coverage, cyclomatic complexity, etc) but these aren’t a guarantee of quality and I’ve seen teams game some of the metrics. The ideal situation is to trust that your supplier will do the right thing. If the supplier has a poor team and is motivated by profit rather than craftsmanship, you may find yourself getting a raw deal. And because you’re not technical and will never look behind the scenes at the code, you may never find out. Having reviewed some outsourced software projects in the past, I’ve definitely seen some that haven’t been built by what I would call “professional developers”! Having somebody on the customer team who is able to objectively review the deliverables will help, otherwise I would recommend that they hire a trusted advisor who can do this on their behalf. Again, objectivity is key.
InfoQ: What do good teams do to deliver software with sufficient quality? In your opinion, what works, and what not?
Simon: Writing software is relatively easy. Writing good software, less so. It’s all about discipline and attention to detail. Good teams pay conscious attention to the quality of the software they are delivering and they understand the importance of building well structured software with clean, readable code. Such teams will also have adopted practices like automated testing and continuous integration. Although these technical practices are considered “mainstream”, I still meet teams that have yet to embrace them. Even the use of source code control isn’t guaranteed! Ironically, it’s the better teams out there that are usually looking to continuously improve. Such teams typically have a culture that encourages learning, sharing experiences and continuously improving. They also have passion for what they do.
InfoQ: You talked about the software architecture in teams. What is this role, and how can it be fulfilled?
Simon: The easiest way to think about the software architecture role is that it’s about technical leadership on software teams. People have traditionally considered software architects to be people that dictate solutions to development teams, who then have the undesirable task of making that solution a reality on their own. My view is that the software architecture role can be undertaken by one or many people on the team, and it’s about technical leadership through collaboration and coaching. In a nutshell, the role includes understanding what shapes the solution, designing the solution, making sure that the solution is going to work, evolving the solution as needed and taking responsibility for the technical quality. This is an oversimplification of the role, which can and should include coding, but it captures the main elements.
InfoQ: What can managers do to have teams where professionals can develop themselves, grow and increase their skills and value?
Simon: I’ve been very lucky during my career, as most of the organisations I’ve worked at had a very structured technical career path. For example, in order to progress to the next salary grade or role, you needed to prove that you had demonstrated a number of competencies. More often than not, these competencies were based upon technical *and* soft skills (e.g. consulting and leadership). In addition to this, the organisations invested heavily in actually helping people progress through that career path, with the appropriate technical and soft-skills training. Mentors were assigned to everybody too, helping to ensure that people’s careers were never forgotten about.
In essence, most of these same organisations had an excellent culture where learning and helping others to learn was rewarded. From a practical point of view, this included creating an environment where people wouldn’t feel afraid to ask for help and ensuring a sense of community through events such as “special interest groups” where people could gather to share their experiences. In my view, it all points to the culture of the organisation. Organisational culture is hugely important.
About the Interviewee
Simon Brown lives in Jersey (the largest of the Channel Islands) and works as an independent consultant, specialising in software architecture, technical leadership and the balance with agility. Simon is an award-winning speaker and regularly speaks at international software development conferences, as well as providing consulting/training to software teams across Europe. He is the founder of Coding the Architecture (a website about pragmatic, hands-on software architecture) and the author of Software Architecture for Developers (an e-book that is being published incrementally through Leanpub). He still codes too. Simon can be found on Twitter at @simonbrown.
