“The biggest variant when developing software is people. And a Project Manager is the one tasked with making sure they reach their best productivity. More than money, time or the scope of the project, it’s about soft skills.”
— Chuz Magaña, Project Manager at Scio
Agile thinking is a must-have in this ever changing world. It means being able to think and respond quickly when change happens around us, whether it be technology evolving or someone else’s idea taking off unexpectedly.
As such, software development has never been an easy task to do. It requires planning, testing and many more practices like sprints or pair programming, depending on how you want your project done, and coordinating everything can be a daunting task.
That’s why the approach of Agile can be very helpful in understanding what needs to be done when faced by certain situations during development, because each brings out different complexities which dictate how they should be dealt with. In this framework, everyone is involved (from a developer through the customer), with confidence about where his/her responsibility lies throughout all the steps taken, mediated by a Development Manager.
What is the Role of an Agile Software Development Manager?
“Well, what does a Project Manager do? In simple terms, my job is to help a team to reach their goals during each step of development, but what I really do is manage people, because they dictate the progress of a project. And that can be from personal issues that one has to take into account, to making sure we have enough resources and a solution to solve any problem. In other words, it is making sure the collaboration we need to achieve our goals happens”, says Chuz Magaña, Senior Project Manager at Scio, with more than 15 years of experience in the field.
What he refers to is that, if the goal of a team is to improve the process and deliver results on time, then a Project Manager can help by empowering employees with responsibilities, encouraging them to work together as professionals who will commit themselves fully towards meeting those goals — even if it means taking risks or making difficult decisions along the way.
After all, Agile software development is all about being flexible. Each technique used in this process has a clear and defined role, but it’s important to know how your individual job fits into the bigger picture — and that of other team members too!
When you’re an agile software development manager, it’s important to define what everyone’s responsibilities are. You should help each team member excel in their specific role while making sure that everything goes according to standards using the Agile principles; overall, the manager ensures that the team delivers excellent results.
Here are some of the most important duties of an agile software development manager:
1. Project Planning and Management
As a manager, your job is to make sure that the scope of projects are defined efficiently with an achievable delivery schedule. You also need to keep up-to-date on everything, including leading and organizing progress reports for employees, as well preparing them when needed so they can be effective.
Also, part of the role of a manager is to project plans and make necessary changes if required.
Managers who understand the importance of agile in the project should be able tackle any challenge with more success, so make sure you live and breathe this process as well!
2. Team Management
If you are the agile software development manager, you have a duty to manage your team properly, and that includes assisting them when necessary so they can do their best work process-wise, guiding and mentoring them properly, especially as they undergo a stressful environment.
With a critical timeline, it is important to ensure the completion of projects on time. You can do this by respecting your team members and not micromanaging them; as well making sure that you give clear instructions for any given task or project so they know exactly what needs done without overstepping boundaries in either direction!
3. Risk Management
Risk management plans ensure that the project stays on track and prevents conflicts between team members, budget issues, or questions about the goals of development.
In order for a risk development plan to be effective, it must have clear communication among all parties involved, in order identify potential risks before they become insurmountable problems down the line; this includes identifying any conflict situations now so you can develop an appropriate response strategy if needed.
4. Process Management
Structure your workflow with a well-defined process. Make sure you identify and follow the best practices in agile software development to maximize productivity for yourself as well as other people collaborating on the project.
Keep the workload balanced so that no member falls behind. In an agile environment, the communication between the team and the product owner is crucial in terms of meeting deadlines.
5. Team Building
One way to make sure that you’re empowering your team members is by giving them freedom while still holding each individual accountable for their work. You should manage tasks at an achievable pace without sacrificing quality, which will lead everyone along nicely.
To be a successful agile software development manager, you need to have strong coaching and feedback skills. You should also build relationships with your team members, by giving them one-on-one meetings where they can share their thoughts about the project or codebase, without feeling uncomfortable doing so.
At the same time, you need to ensure rapport between the members so that they can work better as a team. A successful manager encourages the team members to bring ideas to the table.
Our relationship to work is evolving, and a new model of flexibility seems to be the next step in our industry. However, the challenges that bring, as well as the human side of the story, need to be at the forefront.
By Scio Team
Untangling how deeply our life changed during the Covid-19 pandemic will take a long time, and while we are still dealing with much of its aftermath, the process of planning the future doesn’t stop, even if we aren’t quite sure of what’s next for the industry.
Because, undoubtedly, one of the deepest impacts was in the way we worked; our entire model of collaboration was based around in-person contact, to such a degree that a world without face-to-face interactions was unimaginable. After all, what happens when a member of an organization doesn’t have true contact with other people?
Every industry since 2020 has had to grapple with that question daily, to the point that the idea of “work” may look completely different from now on. And even if we understood, from a technical standpoint, that working remotely all the time is 100% possible, the human side of it had a cost.
“The pandemic didn’t erase the need for human connection, and I think some kind of rebound is due to happen”, says Luis Aburto, CEO, and Co-Founder of Scio, about the future of work in the software industry. “We experimented with the freedom of a full-time remote position, but when every interaction is digitally mediated, you inevitably feel something is missing.”
And this missing element is going to shape a lot of the future of the industry, as the biggest challenge of collaborating remotely, be it from home or another country, will be managing remotely the cohesion between the members of a team, an issue that looms over every workplace strategy rising from the pandemic.
The best of both worlds
A solution, however, might be here: the “hybrid” model of working, a mix of in-person presence and home office work that seems to strike the balance between the needs of the job and the preference of an individual.
“Although right now full remote work is the preferred model for many people in the tech industry, I believe that things are going to shift soon, as more of us start feeling the weight of the isolation that it builds up. After all, work can be more than just the means to make a living, it can also allow you to be part of something together, a community”, continues Luis Aburto. “The real challenge of transitioning to an effective hybrid model will be to promote and maintain this feeling of community and belonging.”
After all, the effect of prolonged isolation in the workplace has been well documented since the pandemic began in 2020. Although remote work did a lot to keep us safe, it wasn’t a shift without downsides: the lack of structure, the blurred lines between the personal and professional life, and the stressful fluctuations in productivity (be it underperforming due to distractions, or overperforming due to a lack of feedback) showed us that in-person collaboration was full of hidden benefits that only became clear when taken from us.
“Being physically at the same place creates opportunities to develop your skills, get ideas about where to push your career path, and discover what you like professionally. And even in casual encounters, where personal rapport can develop, you inevitably feel part of a group because people always need deeper human connections”, continues Luis. “At home, even if you go to a Starbucks, you don’t have any links with your coworkers, which is isolating.”
With this in mind, and adding all the benefits that remote work has for a business, like reduced operational costs, improved retention rate, and a bigger talent pool to draw from, the compromise of hybrid work seems to be the best solution. But what are the challenges it brings?
The challenge of hybrid models
The numbers provided by the Future of Work survey, as reported by Forbes paint a serious picture. Even if a hybrid model of work becomes the new normal, many issues need to be solved to implement it successfully. For example, according to the article, “the vast majority of businesses lack a detailed hybrid work strategy: 72% lack a detailed strategy and 76% don’t have the right key performance indicators (KPIs) to support hybrid working models.”
This is to say, that the leadership and management of any organization looking to implement this model need a clear strategy to build a culture remotely, be it through technology or the implementation of special measures. Helena Matamoros, Human Capital Manager at Scio, points out the strategy we have been implementing during the pandemic to keep our culture intact, making sure every new collaborator feels at home from day 1.
“We start with a Welcome Kit to make them feel part of Scio, and then we ensure they have everything they need to do their jobs comfortably. Beyond that, when our hybrid work model starts (for now, we are still 100% remote), we want to ensure that every leisure activity we do, like our Game Nights, can accommodate both face-to-face and remote collaborators.”
These activities have two purposes: one, allow new collaborators the opportunity to meet their coworkers and teammates, integrating them more easily at Scio, and two, give them the chance to play, share, and generally mingle about outside of a project, which is also why we encourage our Project Leader to organize their own activities, forming a better relationship in the team.
These are some of the measures we have implemented successfully at Scio, even if the real test of hybrid work is about to begin. However, as we already have a home office policy before the pandemic (when many of our collaborators could choose a day of the week to work away from the office), and we have employed talent from all over LATAM, we know that this challenge is not insurmountable.
Keeping the human connection going will be key. Even if we no longer want to be beholden to an office 40 hours a week or more without any flexibility, our relationship with work is changing, and as a society, it’s good we are experimenting with different ways to get things done. And it seems likely that the lion’s share of people in our industry will prefer the option to work from home for two or three days, and go to the office the rest of the week to not leave behind this source of connection.
“A lot of people tie professional relationships with negative feelings, thanks to overly-demanding leaderships that only know how to push, so we try to create a positive environment at Scio, aiming for the kind of positive experiences that enrich everyone equally, making everyone feel appreciated, heard and with the chance to grow”, states Luis Aburto, emphasizing that a good environment will be critical.
“Otherwise, the most valuable people are bound to find somewhere else to satisfy their professional and human needs, and if your organization doesn’t encourage different approaches, be it connection, flexibility, or culture to call their own, these people are bound to find a better opportunity elsewhere, and then you, as a business, is going to be left behind in obscurity.”
The Key Takeaways
The future of work is a hybrid model where people are able to work remotely. This trend is only going to become more permanent as time goes on, so companies would be wise to accept it and even implement it themselves. However, there are many challenges that come with this new way of working, the biggest one being culture. How can you make sure your organizational cohesion doesn’t suffer? That’s still an unanswered question, but it’s one that we should all start thinking about. What do you think of the hybrid work model? Let us know in the comments!
There are a lot of opinions about the best possible way of measuring productivity, but that can bring us to another question entirely: why measure it at all? In this second part of our interview with Adolfo Cruz, we dig into the reasons why measuring productivity is important for any organization.
By Scio Team
If you are adding value for a client during a product’s development, creating something they can use to attract more users or increase their profits, you may say the time invested in the process was productive, but how do you measure that? Can it be done?
Productivity can be witnessed, it happens right in front of you when a team is making progress, but translating that into data is not an easy task; it takes a lot of time and effort to get right, and it might take focus away from the resulting product, ironically affecting your productivity.
It’s similar to that quantum physics phenomenon where you could change the outcome of something by observing it; all the effort invested in getting exact numbers to measure productivity could make you neglect stuff that has value for the product developed, so you need to be very careful in how you implement measurements to not interfere.
So this begs a very important question: why measure productivity at all? You can see people in the software industry questioning that, going as far as suggesting it’s unnecessary, but we disagree. At Scio, we want to know if our engineers are offering real value to our clients, which is very important to us even if sometimes we use subjective, case-by-case measures to do so.
Measurements impact the way products are being developed
Reaching a standard that applies to everyone is complicated, and if you add the fact that some people may be working on different projects and products at the same time, with different challenges and rhythms, you get variables that complicate things further, so we guide ourselves by the idea of “We are productive if we add value to a business”. It’s a given that achieving working software is delivering promises, so it’s more about how a client feels about the products you are making.
The problem is trying to approach this with objectivity, but doling out numbers can have unintentional consequences; developers can over-focus on raising their numbers because the important metric seems to be proving your value with high stats, so it ceases to be a team and instead is just a collection of people making their figures go up. Metrics can bring improvements, but you also need to consider their context to make them helpful, which is why it’s difficult to find a universal solution to measure productivity in software development.
When we are in charge of managing a project, productivity is more focused on avoiding red flags instead of checking who is less productive in any given team, measuring it to avoid deviating too much from our goals; it’s easy to fall from a cliff if you aren’t careful with that. We are not interested in using metrics to know if everyone is achieving some arbitrary standard, but rather steering a ship, looking at the productivity of the team as a whole.
To this end, it’s useful to register the progress of every project and map them out to find general trends rather than trying to get exact figures. Robert D. Austin, the author of the book Measuring and Managing Performance in Organizations, said that unless you can measure 100% of something, there’s no point to measure anything at all, but in most cases, you don’t need to have every single data point, just an educated guess about where the project is heading, helped with some metrics that give a clear perspective.
This can be seen in the sprints. With information about how many story points (the metric used to estimate the difficulty of implementing a given improvement) are completed, how many issues surface, how many are solved, and comparing it with past efforts, the red flags are obvious. If the team completed between 5 and 10 story points in a sprint, but only 1 or 2 the next one, you need to dig into the process; you might find some challenges nobody saw coming and had to be solved to move forward, and you didn’t need more than knowing past productivity to compare.
And often, if you are using Agile Methodologies, the team is the one that realizes when someone is struggling or is free to help and correct the issues themselves. A good team can manage itself, keeping productivity up without needing someone to check their progress daily. This also results in the quality of the product being directly embedded into the productivity of the process, as the team should already know at this point what needs to be measured to plan with the amount of flexibility necessary to succeed.
We help your team deliver more value to the business.
In software development, we could measure how many Final Users are aware of a specific feature, how many support tickets are being sent, how many things are misunderstood, or which things are not working as intended, converting it into data to know if there are issues during development, but you still need to take some subjective measurements, like conversations with the clients to know how they feel about the product, to give context to this information.
That’s the impact we want to have on our clients, and more often than not, they start seeing the benefits of these processes. They take the time to plan their sprints, properly assess the project, and address issues, especially with not very experienced clients, whom we show what a good software development cycle looks like.
After all, developing software is closer to creating art than manufacturing an object, so the question of productivity is similar. Just like writing a novel, it’s hard to estimate exactly how long each step is going to take because human beings are bad at estimating time and effort in the long run.
We take the time to understand your business and create custom software that helps you grow.
As we know how quickly things can change in a short amount of time, Scio typically plans short-term goals (between 1 – 3 months) and mid-term goals (between 6 – 12 months) at most when we work with our clients during the evolution of the product, in order to ensure it has enough room to grow naturally, focusing on the steps we need to reach a desirable outcome, and even then it’s a challenge to keep every detail under control. There have been occasions where we have to overhaul plans to finish a project in the timeframe we set, and in those situations, the final product is different from how we first envisioned it because of the natural evolution that a project goes through.
So planning way too into the future is highly risky, shorter steps with a clear idea of every milestone is a method that has shown us the best results to develop a product, which is one of the principles of the Scrum methodology; working with iterations that have defined starting and ending points, and progress is registered at every step.
And even then you can get slightly different results every time. Sometimes a team is very well attuned and can build things faster than a team mostly composed of new developers, or engineers who had never worked together before, so obviously they took a little longer, which is why Scio evolved to focus more on the value we are delivering to our clients, involving them more in the process, deciding together which features were more valuable, and the priorities to establish.
After all, always having the option to say “Okay, let’s stop for a bit, reorganize, plan better retrospectives, and find areas of improvement” depends on knowing your process back and forth, and that’s why measuring productivity is important.
Measuring productivity is hard, but it’s not impossible. It takes some general metrics and subjective questions dictated by human behavior that are never objective. That’s where Scio comes in – we design teams that fit with the culture and practices of our clients, ensuring that no matter what, we always have the necessary perspective to achieve a successful engagement. If you want help measuring your engineering team’s productivity or just need someone to bounce ideas off of, send us a message. We love talking about this stuff!
Whether you are coding software or managing a company that creates software, the name of the game is optimization: there’s always a better way to do things, a wrinkle to iron out, a bump to flatten quickly. However, even if we somehow reach a perfect process, it will probably not last long. Technology is always moving forward.
Then why is it often difficult to adjust your development practices to ensure you always obtain a better outcome? Why is it so hard to leave behind “tried and true” methods of development to try new ideas to better the efficiency of any process?
It’s not surprising to find out that the root of a lot of these issues lay within human psychology, specifically a phenomenon that can help us understand how we conceive our practices, and the sooner we can work towards mastering how it works, the better our outcomes will become: cognitive inertia.
The human side of change.
“Cognitive inertia” is a term gaining popularity in software development, and with a good reason: it aptly describes why it might be so hard to change approaches to development, even in the face of an evident need of trying something else:
“Changing management is an age-old problem; migrating to a new process with new technologies can represent a big change. The management teams are met with cognitive inertia and a long list of reasons why new methods and technologies will not work. So, instead, they work harder, and the harder they work, the farther behind they get”, points out Barry Hutt, CRO at Viviota Software, in his post “Cognitive Inertia a great challenge to innovation.”
It’s a paradoxical outcome, but to begin to understand this issue, we should define clearly what “cognitive inertia” is. Cognitive inertia is not “belief perseverance”, or the phenomenon of maintaining the same belief even when presented with new information. Instead, cognitive inertia is the inability to change how a person processes information, which is a much more complicated framework that involves motivation, emotion, and developmental factors.
Its consequences can be seen easily in software development when we think of practices like testing or brainstorming, which makes the old adage “work smarter, not harder” a difficult one to implement, especially as a project or an organization grows in complexity.
“Cognitive inertia evolved because the brain optimizes energy efficiency. If you keep the same behavior and don’t question it, your brain conserves space and can make faster, simpler decisions. On a social level, maintaining consistent behavior preserves social cohesion by maintaining social roles and responses”, explains the blog “Cognitive Inertia: The Status Quo Bias” by Joseph Adebisi.
However, it’s obvious why in a field like software development this can bring problems in the long run. After all, even if roles in a development team are clearly defined, the multitude of solutions that need to be reached at every step of the process (from the ultimate goal of the client to fixing the smallest of bugs) benefit from the creativity that surges from having multiple approaches.
The key to collaboration
The approach of Scio to this issue, both internally and in the work, we do with our clients, is knowing that a “solution” is more than having the seemingly right answer for everything; it is developing a process that lets you question and rework the methods you used to arrive at to fine-tune the outcome.
“When you build walls, it’s easy to keep piling bricks on, one after another, in every house you build. That might work for a while, but if now you are looking to build something with a different purpose, like a cathedral or a hospital, will that approach still be the best?” comments Luis Aburto, CEO, and Co-Founder of Scio. “What happens when you partner with someone that comes and says ‘hey, maybe this bricklaying will not support the multiple stories we need for a hospital, so what if we try this instead?’”
A culture of constant sharing through collaboration, then, might be a way to avoid the pitfalls of cognitive inertia. After all, cognitive inertia, as real inertia does, keeps the same trajectory if nothing initiates a change, so the more different perspectives you have, the stronger the final product may be.
“Human beings love to help. Doing it productively and seeing people overcome obstacles it’s a very rewarding experience, and at a company like Scio, where collaboration is a key part of us, you also get the benefit of cross-pollinating different parts of your organization”, says Yamila Solari, Co-Founder and Coaching Leader at Scio. “If you create a culture of mutual help and support, where one person talks to another and so on, your culture is always enriching itself.”
This makes coaching one of the best tools Scio has to keep our organization moving forward, making sure that knowledge gets shared around between collaborators to strengthen the outcomes of every person and every team. This circles back to our earlier article about outputs and outcomes in software development, where we try to understand the purpose and goals of any project we collaborate with before deciding on the approach that will work best for that specific job. Sometimes laying bricks in the usual way will be enough, but that doesn’t mean that developers shouldn’t have an open mind to try new things if they hit a snag during development.
Cognitive inertia in the day-to-day
However, one should not assume that the issue of cognitive inertia only affects an organization at the macro level, or that it is always a bad thing; it’s part of our daily work whether we notice it or not. For example: if you are focused on a task, and an interruption comes (be it a software update, an Internet outage, an unforeseen meeting, or even a coworker just stopping by to ask something), how difficult is it for you to resume your rhythm at full speed?
Martin Cracauer, CTO of the software development firm Third Law, holds the opinion that the way our brain absorbs information and uses it in the short term is a form of cognitive inertia, and keeping information properly compartmentalized is a way to ensure a task, or a whole project, doesn’t get derailed:
“A lunch break absorbing lots of information that has nothing to do with your work task is relaxing because it does not compete with the work task memory. But a work meeting that touches actual work stuff competes for the same cognitive machinery. […] Your Company makes its money on the programming tasks that are completed today, so you just traded away the brain state needed for Today’s Task in favor of some imaginary later benefit.”
What this means is that some form of cognitive inertia (the one that puts a developer “in the zone” when writing code) can be used to the advantage of the development cycle if we structure the project with clear goals and purposes that need minimal interruptions, and let the developer to fully focus in the day to day progress.
The Agile methodologies, when well implemented, help with this as it lets organizations like Scio maintain a high level of cohesion in the development cycle that doesn’t give enough space for distractions. A well-managed team knows its goals, the potential pitfalls, and biases that can surge in development, and has the support to focus on the tasks that actually get things done, letting the outcome dictate everything else the product might need.
Cognitive inertia, then, is not inherently a good or bad thing in software development; a well-balanced organization can manage, and even use it to its advantage. After all, the software is not about working harder, it’s about implementing the smartest approach and letting the results speak for themselves.
The Key Takeaways:
Cognitive inertia is not stubbornness, it’s the way some people get used to processing information in their day today.
Changing this inertia can be difficult, but is not an insurmountable problem, and it’s a critical need for software development.
Collaboration and tools like coaching can be effective in mitigating the effects of cognitive inertia, feeding constant new information to avoid settling on a single approach.
However, cognitive inertia is not all bad; it helps a developer to focus as long as interruptions and problems derived from sudden changes of course are avoided.
It all comes down to good management. Being aware of bias and cognitive traps, constantly encouraging new knowledge between collaborators, coaching and a good implementation of Agile methodologies can result in a healthy development environment that guarantees a good outcome.
How to measure productivity effectively? Adolfo Cruz, Scio’s very own Project Management Office director, offers insights into a question many in the business have in their minds all the time.
By Adolfo Cruz.
Building an exact image of productivity is a question with no definitive answer yet. Defining what “productivity” means for someone starting a business for the first time is a complex process. From everything I’ve learned these 14 years at Scio, each person needs to discover what works for them, considering the specific context in which they are trying to succeed.
The thing is, when trying to measure productivity in something as fluid as software development, every seemingly useful metric comes from a different perspective (be it from the client, the developer, or the managers), so if you want to establish a baseline, I would recommend defining priorities first, taking into account your business needs.
How do we measure productivity in Scio?
Early in Scio’s history, around 2008 or so, we tried to implement Agile Methodologies along with some number crunching, like the hours put on a project or the number of bugs, to know exactly how productive our teams were. However, the number of variables involved, like realizing that a specific team had better outcomes because they had certain chemistry between them, made it difficult to translate the results into measures that could be implemented in any project.
So we moved away from that, instead of looking at the results from the client’s perspective, thus defining our productivity as the value our developers are adding to a product during development. Our measures became more focused on people than metrics because helping a client to build a product, adding value at every step, and therefore growing their business, was our main priority.
To this end, building a perfectly calibrated development team that proposes new things, learning and evolving together was the best approach for Scio. A lot of the time it’s not even necessary to keep a register of everything happening during development because the team itself realizes when something’s not right and works out any issue; a team of developers capable of self-management is always a good sign.
If you achieve such a team, you don’t need to measure specific metrics for each collaborator, instead, you evaluate the team as a whole, looking for relevant information that can help them grow, so you should think of questions that help you get the information you need.
For example number, many User Stories were completed in a given time?
Was there any serious bug in the development of the product?
How many bugs surfaced?
What priority did these bugs have?
How did the team respond to them?
How long did it take?
However, these questions need to be constructed with the project’s context in mind; although there are a lot of metrics you can use to generate specific “productivity” numbers (like the Personal Software Process popular in the 90s that tried to define productivity through the number of lines of code written), if they don’t reflect reality, then the team will not know how to use this information, as many of the challenges they face can be subjective.
So avoid trying to arrive at exact numbers, and instead, I recommend you to look at the trends emerging from one project to another. A trend interpreted correctly should give you a “big picture” of both performance and productivity, showing places where your attention or some improvement is needed.
First, look for a certain range of information in a development cycle; If the team completed between 5 and 10 stories in a sprint, but only 1 or 2 the next one, there’s probably a red flag somewhere in need of attention. Then dig a little into it, and maybe you’ll find some unforeseen challenges the team needed to prioritize to keep making progress. And finally, make a note out of it, so you can improve the circumstances around an issue so it doesn’t reappear later; that’s how an understanding of productivity begins to emerge.
Most of the trends we watch at Scio are about how our developers contribute to our client’s goals, and we developed some tools to measure that. For example, we use the Team Self-Assessment, a guideline for collaborators to reflect on their work, that we adopted and modified according to what our experiences and specific contexts dictate.
In our TSA, there’s a section where we inquire about bugs surfacing during development, asking how they are preventing issues during development, if they are doing Pair Testing practices, if they are showing their additions to someone else before moving on, and generally if they are focusing on things that matter.
When a team reviews these questions, they realize their areas of improvement, and we work together to avoid falling into them again in future projects, because what you want to do is push your teams into adopting excellence as a natural part of their processes, encouraging them to add their experiences and expertise to the final product.
The subjectivity of a productive team
Productivity is not always a purely technical approach; sometimes you need to look at the business side of things, involving the stakeholders and product owners in the creation of the product to reconcile a multitude of perspectives, converting them into priorities to define the best course of action.
Just remember that you need to experiment in software development, build an iteration of the product to validate its potential, and look for features that can be improved to maximize its success. Your development team will probably need to go back and rework a lot of stuff, updating their methods to create a more efficient version of the product, so your definition of productivity here has to account for it; if stuff is being redone, at least quality should always be improving.
So, to recap, a good measure of productivity is established by defining your business priorities and then choosing the metrics that best reflect the context in which the product will be built. A productive development process gives enough flexibility to iterate and experiment without neglecting business needs, and having your client’s goal as the focus of your team is a great starting point.
Just remember that if you aren’t adapting what you learn into your specific context, capturing the information your team needs, then productivity might suffer. Software is mostly a creative enterprise, so some subjectivity will always be needed to properly define what makes a successful project, fine-tuning every cycle to achieve the value you want for a specific product. With an approach like that, you can be sure your organization will always be improving.
How to measure productivity? That’s a question that many in the business, from CEOs to coders to engineers to managers, have in their minds all the time, and Adolfo Cruz, Scio’s very own Project Management Office director discusses metrics, measures, and meanings of productivity.
At the end of the 90s, a methodology called “Personal Software Process”, or PSP, was designed to help developers measure their productivity. You had to take a course, there was a lot of documentation to follow through, and you had to use a timer to measure your progress, stopping it every time you needed a cup of coffee or to go to the bathroom.
The idea was to see how much you accomplished in a day, but in fact, this methodology was entangled too closely with the number of lines you wrote, meaning that you were more productive the more you coded, which is not necessarily true.
But if this is not productivity, what is it?
I define “productivity” as finishing a task in a reasonable time. The word “finishing” here is key because productivity is not starting a lot of things, but seeing a project to completion, right until you get a product. However, how do you define exactly when something is “finished” in software development? What criteria do you have to fulfill to say something is done? If we were building something physical, let’s say a boat, first, you need to build a hull, and this phase ends when it fulfills certain requirements.
And although not all boats are the same (building a freighter or a yacht would look very different), in essence, you have the same process, blueprints, and requirements to do it. Software development doesn’t work that way.
Developing software involves a lot of things. You may see it conceptualized as a “factory”, or a development team working like a well-oiled machine, where you input requirements and get a product at the other end. But in truth, there’s an artisanal quality to developing software; everyone has their approach and style, and progress changes according to the team you are with.
This results in a lively debate where no one agrees on the best way to measure productivity. If you ask a room full of developers how many lines of code they write to see if they are productive, you can get a very heated discussion, because how are you measuring that?
The best code is concise and everyone checking it can understand it, so I don’t know how you can see someone writing 10,000 lines of code and conclude he is more productive than someone achieving the same in 500. Maybe it made more sense at a time with no frameworks to build things faster, when everything was a bit more rudimentary and you coded every single piece of the product, but today you have to write very few things from scratch, with a whole range of tools that let you produce, let’s say, the shell of a website in a minute without coding anything directly.
So imagine if a company starts giving productivity bonuses based on lines of code produced per project. They would end up with developers gaming the system to get the bonus or at least trying to not look worse than their peers by writing less, resulting in bloated, inefficient products because the incentive wasn’t centered on creating something useful.
You have to be very careful when linking rewards to metrics, or else you’ll generate a perverse environment where everybody is just racing to inflate numbers.
The Scio way
I’ve been with Scio for 14 years, and since then, perspectives have changed. With the arrival of Agile Methodologies, we moved on from counting lines of code to seeing how that code comes together, achieving working software whose process of development is not focused on numbers, but on how the product is going to be used.
To give you an idea of this evolution, not long ago the requirements of a project were written from the point of view of the system, so every requirement started with the phrase “The system shall…”: the system shall do X thing, the system shall do Y thing, the system shall do Z thing, etc.
So you ended up with a massive document repeating “The system shall…” for every little thing. Then the Agile Movement centered on the user, with requirements stating “The Administrator can…” or “The Manager can…” because we understood that software is not about a system that “shall” do things, but what people in different roles “can” achieve with the product, resulting in productivity built around how much value we give to the final user, not how much code our devs write.
Coming back to Scio, we see it from the perspective of the stakeholders and clients we are building a product for, and our productivity is measured on the information we get from them, knowing how our teams are doing, how much value they are adding to a project, and what their perception of the whole process is. It’s a more people-oriented approach, far from the days of counting lines of code, and more interested in understanding how a developer is contributing to the goals of our clients.
To that end, we developed some internal tools, like the Team Self-Assessment, based on our prior experiences, consisting of questionnaires about the things we consider important for a team to focus on. For example, there’s an entire section about quality, how they are preventing issues during development, if they are doing Pair Testing practices, or if they are doing code reviews to make sure the code is maintainable and scalable…
Are they giving issues the proper attention? Are they documenting them? The team members have to ask themselves if they are focusing on the right issues, and if they aren’t, it’s something we have to improve. That’s how we try to motivate our teams to share their experiences, practices, and insights into our client’s projects.
It is said that only 35% of software development projects succeed, and I think it has to do with the planning stage of a product. Let’s say I want to complete the A, B, and C steps of a project in six months, based on previous experiences in similar projects. But it ended up taking 8 months instead of 6 because something needed to change, does that 2-month delay mean the project is going wrong?
It happens a lot with start-ups trying to create something completely new. In the course of development, it’s common to see something, a feature or function of the product that changes the client’s perspective, that taps into some potential we haven’t seen before, so the plan has to get reworked to harness that and bring its full potential. In six months, priorities can change.
But if we measure the productivity of the process very rigidly, and then that very same process brings out the value in unexpected places that, nonetheless, force you to rework entire parts of the project, it’s easy to see it as a failure.
The Project Management Institute uses these rigid measures a lot, asking for a specific basis, beginning, and end of every phase of a project, and if you don’t deliver them exactly as planned, then you get a mark against you. In an actual software development environment, that doesn’t happen, because the dynamics of a development cycle can change fast.
Software development works by evolution
The measures you have to use are subjective more often than not. Some industries require strictness, especially when manufacturing something, but in the world of software, and start-ups in specific, I don’t think it’s necessary to be like this to create a successful product.
This is why we back away a little from the technical aspects of a project and focus instead on the business side of things, having conversations with stakeholders and product owners to get them involved, reconciling all these points of view about what the business needs, and how development is.
We take a look at the features planned, check how many people ask for them, how critical they are for the business model to work, and decide how to proceed from there, adding real value by focusing on building those pieces first. Technical aspects are solved later, as you first see what the business needs, and then the technical team starts sketching solutions for the challenge.
Productivity is a question with no definitive answer yet.
Considering all this, forming an exact image of productivity is a question with no definitive answer yet. Every individual has to decide what works, but only in the specific context in which that person is acting, so no one has come up with a universal method to measure productivity in software development, as even the perspective from which you measure can change; seeing it from a client’s perspective is a world apart from a developer’s.
As you discover better routes during development that weren’t foreseen during the planning stage, or maybe because the technical aspect ended up being unfeasible for one reason or another, or the infrastructure cost is too high for your purposes, or any other number of reasons, a lot of what you may define at the beginning of the project will change.
You adapt, which is very different from building furniture or producing food, where it is clear what you are trying to accomplish over and over. But in software, where there’s no single solution for the same problem, it’s difficult to reach a consensus on what you need to do in detail.
However, you want to measure productivity, metrics evolve, and whatever method you use to decide how productive your team or your company is, I think the Agile Methodologies got it right, where it doesn’t matter the number of lines, or the documentation you have, or how pretty your database is, what matters to the client and the final user is having software that works.
