Modern Agile: Better people = better company on the long-term

<p>This blogpost is the second one in a series of four blogposts delving into the discussion about what is Modern Agile, how it relates to regular agile and how companies can start adapting to it. You can check the first one here. It brings to light ideas of <a href="https://www.vinta.com.br/blog/2017/modern-agile-1-iterate-learn/">How to always learn about your software process</a> as well as a better explanation of where Modern Agile comes from, how it came to be and what it means.</p><p>Now, we are going to talk about another principle of Modern Agile:</p><h1 id="make-people-awesome">Make people awesome</h1><p>Here at Vinta we firmly believe that, as a services company, we are only as good as the people who work here. And when you mean it, not just say it, you focus most of your efforts into growing the people you have around you. We think more companies should do it; we believe it should be the norm. <a href="https://www.economist.com/news/americas/21727941-many-workers-are-left-human-scrapheap-solving-latin-americas-skills-crisis">This article from the economist</a> is only one evidence that the lack of investment in the continuous learning of your collaborators can generate a long-term problem. Also, researches like this one <a href="https://rework.withgoogle.com/guides/understanding-team-effectiveness/steps/identify-dynamics-of-effective-teams/">from Google</a> or <a href="https://hbr.org/2018/02/people-want-3-things-from-work-but-most-companies-are-built-around-only-one">this from Facebook</a> clearly state that caring (with actual company measures) about people’s needs is not only nice but that it pays off in business returns. And not just the huge companies are moving in this direction; many smaller ones are already reaping the benefits of measures seen only as expenses on past times. We at Vinta, for instance, invest a lot in a variety of ways. Our partners from <a href="http://www.luminary-labs.com">Luminary Labs</a> do that too and also <a href="https://www.luminary-labs.com/introducing-the-human-company-playbook/">started a movement</a> who pushes for other companies to improve healthcare bonuses, severance packages, and several other bonuses. These are only two examples. There are plenty more out there. And once you start making your people awesome, it’s way easier for your people to make your clients awesome. It’s a win-win scenario. This blogpost will talk about how people are usually thinking about making employees awesome the wrong way, then move on to some considerations on how to do it right, finishing with how this all fits in an agile software development process.</p><h1 id="3-myths-around-roi-with-employees">3 Myths around ROI with employees</h1><p>The first myth we should debunk is that: <strong>Investing money in your employees is only an expense</strong>. As The Economist’s piece shows, many company owners, directors, and managers believe that they don’t have the obligation of growing or investing in their employees. This belief is seen as something that will lower their profits, be too expensive or too time-consuming for the employees, with a return that is very hard to measure.</p><p><br>This view of the world, as debatable as it can be, still governs more companies than you might think, and it made actual business sense in the past. There were a lot of workers, and the demand for work was huge but was restricted to some companies. Another point is, if a couple of huge companies produced almost everything, it was effortless to differentiate, and quality was not that big of a concern. But things have changed. Competition comes from many different directions; markets are re-defined by new technologies and clients can contact you from anywhere, everywhere and will be very mad if you answer them poorly. In this modern times, quality is paramount, be it in the product/service being consumed, be it in how you answer to your client, or even how do you handle problems around the whole process. If you don’t invest in your people, it’s tough to reach quality in all of these levels (be it because they lack motivation or the actual skill to deliver more quality).</p><p>Another myth is that your better returns come when all of your employees spend all 8hrs (or more) of their work-day producing output for your client. There is a lot of research that contradicts that, especially regarding the software development businesses. Aside from all the scientific research done in the field of productivity, in <a href="https://basecamp.com/books/rework">Rework</a> Jason Fried and David Hansen state in a very clear way the problem with that: If you are always producing, you are never optimizing/automating your work. You grow and improve in your work when you start working smarter, not working more. In other words: someone who spends all his time cutting down trees has no time to sharpen his ax.<br>Even so, the solution is not to force people to work and optimize 24/7, as it also can be counter-productive. Especially for programmers. Working longer hours makes it harder to solve a problem, shortens your concentration span (<a href="https://codewithoutrules.com/2016/08/18/productive-programmer/">amongst other problems</a>).</p><p>The third widespread myth is the belief that my business would work best if I only hire fully-prepared experts and spend no time in training and developing people. These people would only need to be pointed to the job, and it’d be done, with process improvements suggestions to boot. Although this sounds appealing, it’s an almost impossible scenario for nearly every company and mostly due to circumstances out of their control. As Chris Andersen, former editor in chief of Wired magazine, once said, “The reality is that most of the world’s smartest people don’t have the right credentials. They don’t speak the right language. They didn’t grow up in the right country. They didn’t go to the right university. They don’t know about you, and you don’t know about them. They’re not available, and they already have a job.” Not only him, but lots of people have already stressed that one of the most challenging things in hiring is timing. This doesn’t mean that it’s useless to invest in hiring campaigns, market your company for prospective employees or even bothering to open a spot at all, it only means that a significant factor isn’t influenced by any of these activities and, sometimes, they’ll bear little fruition. In this case, makes way more sense to train people. You get a lot of variables under control and even get to hire people that are fully committed to learning your way of work in order to grow professionally.<br>In order to circumvent all these myths, companies need a change in mentality, that leads to a change in practices in how to deal with employees. Here at Vinta we are continually working for that, and we’ve learned a few things, but some of them might only work for developers, others might not work in bigger companies, and so forth. But we hope at least they inspire other companies to try and create their own best practices on how to make collaborators awesome.</p><h1 id="4-steps-to-employees-awesomeness">4 steps to employees awesomeness</h1><p>The foundation for every improvement in a company to make your own people awesome is to <strong>listen to them</strong>. People know, or at least have an intuitive feeling, of how they could improve their work-life. The tough part is how to make that happen in your company, since the feedbacks can range from purely operational ones (“I wish I could work facing the window”), going through management ones (“I want to do less of X and more of Y in my work-days”) all the way to more strategic issues (“why do we even get projects with clients like this? Shouldn’t we be focusing on Z market?”). <strong>The point here is not to fix everything, as that’s impossible, but rather, solve what you can, clarify what you can’t address right away and acknowledge what is inherent to the business and won’t be changed anytime soon</strong>. This last one is a little tricky, mostly because it’s hard to refute when it comes from someone in a more senior role. It’s crucial for more senior people to keep an open mind about inputs, even strategic ones, usually there are very fewer things inherent to the business than expected.</p><p><a href="https://hbr.org/2018/02/people-want-3-things-from-work-but-most-companies-are-built-around-only-one">Aside from the positive effect it can have on the company’s employees</a> there is also <a href="https://www.mckinsey.com/business-functions/strategy-and-corporate-finance/our-insights/how-companies-make-good-decisions-mckinsey-global-survey-results">a research from Mckinsey that points out that decisions have better-than-expected returns when aligned with a transparent process of hearing and evaluating options</a>. Here at Vinta we have different ways to accommodate this wide range of feedbacks, always giving clear feedback for every suggestion:</p><p><strong>Operational:</strong> Every team has autonomy to change operational processes (like meetings, ceremonies, roles, tools, etc.) whenever they think it’s necessary for their own project. This can come from their own research or inputs given by other teams in our weekly. We also have one-on-one mentoring with the partners and managers to help in a more personal way when necessary. But the teams are encouraged to share learnings and best practices to help everyone be productive.</p><p><strong>Management:</strong> <a href="https://github.com/vintasoftware/playbook">Our Playbook</a> already specifies a lot of the things the managers need to pay attention to/are responsible for. If a manager is failing to do any of those, or either, there are suggestions to be made on the way of doing so, the suggestion can be made either in weekly, for a more broad discussion, or simply by opening an issue/PR on the playbook (where it’ll be discussed in a more asynchronous way).</p><p><strong>Strategic:</strong> We do that in our weekly meetings. We are 21 people now, and every project uses the weekly to tell their problem and listen to what the partners or other projects have to say about that particular issue. Also, the partners mentor the collaborators in one-to-one meetings, and that makes it easier to catch more strategic problems. We also help everyone setting goals for bi-monthly deliveries where a path of business/strategic career can be chosen by anyone (this is worth a blogpost all by itself, for no detouring processes we’ll write about that later).</p><h1 id="how-that-reflects-on-clients-who-also-want-to-be-awesome-">How that reflects on clients (who also want to be awesome!)</h1><p>Making your employees awesome is only part of the job. The end goal is also to make the customer awesome. People engage in products for a reason: the value that they see in the product/service. Yet, this is usually regarded as something static or with little change. That’s one of the things that puts companies out of businesses: <strong>the inability to perceive the change in how their value is perceived</strong>.</p><figure class="kg-card kg-image-card"><img src="https://vinta-cms.s3.amazonaws.com/media/filer_public/1c/60/1c60e9bf-9de2-46fa-93c5-15bdb7a85e2a/not_technology.jpg" class="kg-image" alt="alt text"></figure><p>Although this is not usually a single big decision, rather smaller decisions made over-time and opportunities that the company didn’t capitalize. This can generally relate to how decisions are made within the company, <a href="https://online.csp.edu/blog/business/decision-making-process">according to this research by Concordia University Saint Paul</a>, the first steps every organization goes through on the decision making process is: ‘identification’, ‘information gathering’ and ‘identifying alternatives’. These can all be collected from the customers (actually they don’t work that well when collected otherwise). The way to do it and integrate it with your production process varies, and there is no surefire way of doing it. Although introducing UX elements in your processes can almost surely help. We’ve already written about <a href="https://www.vinta.com.br/blog/2018/vinta-design-process/">how we think it could be done for a software development process</a>. But we are still constantly evolving and upgrading our process. We’ll discuss what’s being done on that front in the next (and last) session of this blogpost.</p><h1 id="but-what-has-agile-to-do-with-all-of-this">But what has Agile to do with all of this?</h1><p>First of all, there’s one thing we need to put out of the way, and that was thoroughly described and debated in the first blogpost of this series: Agile is a set of principles for self-managed teams to work better, It was never about the practices. So anything described here should not be taken as a silver bullet, but rather one of the many ways to implement the agile principles. More than a recipe to be followed: an example to spark the imagination.</p><p>The first thing to consider is that <strong>if iteration is key, user-proximity is a requirement</strong>. Even if you are solving your own problem, <a href="https://www.linkedin.com/pulse/genesis-startup-ideas-solve-your-own-problem-sunwoo-yang/">as a lot of successful entrepreneurs have done</a>, you should not be fooled to believe yours is the only option. To avoid this, there must be a way to collect feedback on the use of your product/service and this feedback should be as integrated with development process as possible. Either a specific meeting after each sprint or having a role on the team to collect data and implement features related to gathering knowledge can work. Even people from outside of the team can sync with the team once every few sprints to realign customer’s personas and assumptions (although this can be suboptimal due to increased noise). The takeaway here is that something needs to be done. Primarily because the exact answer to how much effort should be dedicated and what kind of feedback needs to be collected depends on the organization (some feedback-collection methods can be found <a href="https://www.cdc.gov/std/Program/pupestd/Selecting%20Data%20Collection%20Methods.pdf">here</a>). Without forgetting to never stray from actual data, that despite the disadvantage of needing interpretation, is still one of the most precise ways to see what’s happening.</p><p>One last thing to also consider is: <strong>Proximity is meant to improve development flow</strong>. Fewer re-implementations, higher acceptance ratings after sprints and positive feedback after an improvement or added feature are only some of the benefits for the team morale of keeping the team close to the customer. This, in order, boosts the team to work better every day and strive for more customer proximity. Taking it’is done properly (if this feedbacks from the customers pop-up and interrupts the developers every 5 minutes, this will hardly help). A good tip to remember here is that the feedback needs to improve the development process, not overtake it. People need concentration time to hit flow and keep hitting deadlines. That’s why it’s best to organize the feedback in a way it can be interpreted and nurture future development. Only then can we create flow for the developers and start this cycle of feedback and improvements that can make the team, the client and the business awesome!</p><hr><h3 id="keep-following-us-to-know-more-">Keep following us to know more!</h3><p>We publish a monthly newsletter where we talk about coming events, interesting topics that might have sprung on twitter or interesting blogposts we came across. If you like our content and want to receive drops of it, you can enroll <a href="http://bit.ly/subscribe-vinta">here</a>!</p>

Modern Agile: Better people = better company on the long-term

Join the Tech Forward newsletter

Related articles

Unit testing React Components with Jest

Autonomy: keeping engagement during crisis

Modern Agile: Embracing Rapid Experimentation and Learning in Software Development