If I’d have to choose a single contribution of mine with the most impact to Zemanta, pushing for more whiteboards would be it. When I’ve joined Zemanta three years ago, we had just one small whiteboard, while now we have 14! I got to see the power of whiteboards for the first time at Nil, more than 10 years ago. At that time I was working on Nil’s remote labs project together with Milan and Miha, and we shared a room with a big whiteboard. We’ve done all the designing and planning on this whiteboard, and it was also our best documentation tool. I didn’t understand it then, but this was my first project done the extreme programming way.
In the last couple of posts I’ve tried to analyze why quite many programmers reject agile even though the agile manifesto should be a program of emancipation for programmers written by programmers out of decades of experience of programmers. In my experience it is not that programmers renounce any of the proclamation of the agile manifesto; it is only that they dislike some of the changes that happen when an organization tries to become more agile.
Agile is not an unbreakable monolith, but a set of values, principles, and practices put together into a coherent framework. Not all of these building blocks cause discomfort to programmers. The daily meetings and demos have been performed by good programmers already in the heydays of waterfall. Empowered teams of emancipated programmers led in a democratic fashion has always been the most efficient way of organizing knowledge workers. And letting the process be implemented by those who practice it, either through retrospectives or in any other way, is the most effective way how to introduce meaningful change in any organization, not just in software companies or startups. Finally, having a product development process in place that makes sure the company builds the right product is much more important for the success of the company than building the product right.
Only after we introduce iterations (XP or scrum) or work in progress limits (kanban) the pressure starts to build in the team and things start to explode. I think that it makes a lot of sense to well prepare the team and the organization by introducing practices described in the previous paragraph first, before putting a lid on the pressure cooker that is your team by introducing iterations or kanban limits.
The last issue I will cover in this mini-series on the unattended side-effects of agile is probably the most controversial. In my opinion lean and agile by themselves do not promote high-quality software engineering, but on the contrary, they are suppressing the excellence.
These days they say in Silicon Valley: “If you’re not embarrassed of the first version of your product, you’ve shipped too late” I very much agree that from the business and product management standpoint it makes a lot of sense to put products to the hands of end users as soon as possible so that customer feedback can be garnered immediately. But from the angle of an engineer this position is really hard to swallow. Engineers are proud people who define themselves through results of their work. Forcing engineers to constantly do make-shift work with no time for doing things properly is a recipe for miserable engineers.
I believe the business and product managers must understand that engineers are special people that must be treated with respect. I’ll provide tomorrow some remedies how to enable fast product discovery while still keeping excellence in engineering.
Engineers adore solving problems that nobody has and we love solving problems with technology, even if non-technological solution would be much more efficient. Occasionally this approach produces things that gain mass appeal and then we like to pat each other on our engineering’s backs that we are so smart and the users so stupid. You hear even very bright and open-minded engineers uttering non-senses such as that “if Henry Ford had asked people what they wanted, they would have said faster horses”, though history teaches us that Karl Benz patented automobile in 1885, while Model T was introduced more than 20 years later when the concept of a automobile was already validated by the users.
The best remedy how to bring engineers from their ivory towers is to get them in contact with the real users of their products. But if you’ll force your programmers to participate at user interviews their feeling of superiority will only increase while watching users’ ignorance. Much better approach is to show to the engineers only the parts of the interviews where their product was obviously failing and the parts where the users used the product in an innovative way unanticipated by the programmer. Showing the engineers such unexpected episodes shatters their feeling of omniscience and superiority and make them interested in actually listening to the users, which is the first step towards building the products that people would actually buy and use.
As I’ve explained yesterday, forcing agile on an introvert programmer is never a good idea. If pushed too hard the silo that the introvert programmer has built around him over the years will explode violently with devastating effects for both, the introvert and the agile transformation. So instead of adapting the introvert to agile, I’d recommend adapting the agile to the introvert (isn’t being agile about being adaptable in the first place?).
What I’ve learned in my career from discussions with several introvert programmers is that they are not happy in their silo and they want to get out of it also themselves. But without some guidance and a bit of push from managers they will get out of the existing silo only to start another one. Therefore, introvert’s intrinsic motivation for change should be used to change introvert’s way of work and not his object of work.
In my experience the two most effective ways to change introvert’s way of work are code reviews and sit together. The code reviews are almost as effective in socializing the programmers and building strong engineering culture as pair programming, but without it’s many issues with physical proximity, personality differences, and synchronization requirements. The second effective way how to gently change the introvert is to sit him together with the rest of the team and by all means prevent him from being physically separated from the others. Even if the introvert doesn’t actively participate in group activities, by sitting together with the group he will soak in the group culture and it will be easier for the group to spontaneously involve him in the group activities.
The second pronounced side effect of an engineering organization transforming itself to agile, is the extroversion of the introvert. The cornerstone of agile approaches is personal communications, or in the words of agile manifesto, individuals and interactions over processes and tools. But quite many programmers don’t feel comfortable interacting with others or just lack social skills, and they got attracted to computers exactly because it doesn’t require any personal communication.
While many agile coaches think that such introverted programmers will either have to adapt or leave, what always happens in such situations is that agile is forced to adopt to the introverts, and not vice versa. Namely, around an introvert programmer a silo always forms and this silo usually includes the critical piece of the system. In the minds of top managers, the critical piece of the system and the introvert keeping it in his silo are inseparable, which results in a sacred cow that nobody is allowed to touch.
I’ve met several such introverts in my career. What’s interesting about them is that they always seem to want to get out of their silo themselves, since they got bored doing the same things day after day and they actually miss interaction with the rest of the team. While forcing agile on the introvert always results in violent clashes, there exists several gentler approaches how to open the introverts up and bring them closer to the rest of the team. I’ll describe these approaches tomorrow.
Yesterday I described one of the more pronounced side effects of transformation to agile organization, that is, generalization of the specialist. In today’s post I’ll present two remedies that makes such transition easier and less painful for programmers.
I’ve seen it at Zemanta and I’ve seen it at several other places, too, that an organization transforms itself to agile only to find out that it’s product development process is flawed. It makes no business sense to try building the product right if what you’re building is not the right product. And if you’re team feels that it’s building the right product with real user adoption, it will be much easier for them to adapt themselves to do different things or to do things differently. Therefore, I’d really recommend to start transformation to agile with the definition of product development process and roles, and with the product roadmap and backlog in place.
The second remedy I’d recommend for easier generalization of a specialist is to start encouraging people to take more responsibility for their work already today, that is, before starting with transition to agile. So instead of having a programmer doing only coding, encourage him to take responsibility also for design, quality assurance, and operation of his code. Even a guy fresh out of college is capable of coming with design for some part of the system, if he’s only allowed to do it by his more senior colleagues. And if you put continuous deployment in place, quality assurance will no longer be someone else’s business. Similarly, if the developer is called late at night to fix his malfunctioned code in production, he will never again just throw the code over to operations people. And once you manage to stretch person’s scope of work outside of pure coding, it will be much easier to get him involved with product discovery or customer support, too.