Staff Augmentation vs. Project-Based Consultancy—Which One Wins?

Bringing in an agency to help build your software platform is a winning strategy - it saves you time, and stress and most importantly keeps you within budget. But businesses often find themselves at a crossroads when it comes to outsourcing solutions. Two popular options—Staff Augmentation and Project-Based Consultancy—offer distinct advantages and cater to different needs. Let's delve into the intricacies of each approach and explore the benefits they bring to the table.

Staff Augmentation: Unleashing Flexibility and Scaling Capabilities

Staff augmentation in software projects refers to the practice of supplementing an existing in-house development team with external, temporary personnel or skilled professionals. This external workforce, often provided by an outsourcing or staffing agency, integrates seamlessly into the client's team to contribute specific expertise, skills, or resources needed for a particular project.

Staff augmentation strategy has a lot going for it, here are some big ones:

1. Greater Control and Flexibility:

Staff Augmentation is a go-to choice for businesses requiring temporary skilled workers or dealing with short-term projects. It provides greater control over the team, allowing seamless integration with in-house operations. The flexibility to scale the team up or down ensures that resources align with project requirements.

2. Immediate Access to Skilled Resources:

One of the standout advantages of staff augmentation is the swift access to a pool of skilled professionals. This is particularly beneficial for projects with tight deadlines, enabling teams to hit the ground running without the delays associated with traditional hiring processes.

3. Cost-Effectiveness for Short-Term Needs:

Staff Augmentation can be a cost-effective solution for short-term projects. While long-term costs may accumulate, the ability to bring in expertise only when needed can be a strategic financial decision.

4. Integration with Existing Processes:

Augmented staff seamlessly follow existing tools and processes within your company. This ensures a smooth workflow and integration with established methodologies, enhancing productivity.

5. Skill Enhancement for Ongoing Plans:

Ideal for developers familiar with project goals but needing extra support, staff augmentation aids in executing ongoing plans to scale. It provides knowledge of industry best practices and can contribute to achieving long-term objectives.

Project-Based Consultancy: Precision, Expertise, and Defined Outcomes

Project-based consultancy strategy in software projects involves engaging external consultants or consulting firms to provide expert guidance, strategic planning, and hands-on implementation for specific projects within a defined scope. Unlike staff augmentation, where external resources integrate into the existing team, project-based consultancy is more focused on delivering a comprehensive solution or achieving specific project goals.

Just like staff augmentation strategy, project-based consultancy has it’s upsides, here are some:

1. Expert Guidance and Implementation:

Project-Based Consultancy shines when businesses seek expert guidance and execution for specific projects. Consultants bring in-depth knowledge and experience, offering valuable insights that can elevate the project to market standards.

2. Defined Outcomes and Timelines:

Unlike staff augmentation, project-based consulting operates on a fixed or project-based cost structure. This clarity in financials and a clearly defined scope and timeline make it easy for businesses to budget and plan effectively.

3. Strategic Roadmap and Industry Compliance:

Project-based consultants provide strategic guidance in uncharted territories, ensuring adherence to industry compliance standards. They bring a fresh perspective, introducing efficiency to development processes and paving the way for successful project delivery.

4. Specialized Skills for New Challenges:

Consultants are aptly equipped to introduce businesses to new challenges. Whether it's accessing a new consumer platform or venturing into a new field, project-based consultancy helps enterprises apply their core talents to diverse and unfamiliar scenarios.

5. High Security Standards:

Consultants are expected to adhere to stringent security standards, providing a high level of data security. Their commitment to industry best practices ensures that projects meet the necessary privacy and security requirements.

Here’s the interesting thing, it doesn’t have to be one of those options! You could actually mix them up to bring out the best of both worlds.

Strength in Combination: A Holistic Approach

These two approaches need not be mutually exclusive. At Kaz we have have done many software projects where we have had both a dedicated team of developers working with our clients as part of their core team and separate parts of the system being built at the same time for that client in project based format. This gives our clients the flexibility and cost-control at the same time getting the benefits of the dedicated team. The added benefit of such a combined approach is that a component delivered as part of a project based work can then be looked after by the dedicated resource team (augmented staff) that has the benefit of co-located with the project team. This makes solving issues, knowledge transfer, future extension fast and accurate.

Also, initiatives that start as project-based consulting may evolve into more hands-on commitments, and vice versa. The combined strength of IT staff augmentation and project-based consultancy can lead to enhanced product responsibility, end-to-end support, and ongoing intellectual property advantages.

Disagreements and debate: the crucial elements in great software projects

In the dynamic realm of software development, where agility and innovation are paramount, fostering an environment that encourages debates is not just beneficial—it's indispensable. The idea of debating within a software project may seem counterintuitive to some, as the conventional image of software development often revolves around quiet coding sessions and collaborative problem-solving. However, embracing debates in the development process can lead to a plethora of advantages, from refining ideas and uncovering hidden issues to enhancing team collaboration and achieving superior project outcomes.

Innovation through Divergent Perspectives

One of the primary reasons debates are crucial in software projects is their ability to stimulate innovation. Divergent perspectives, often emerging during heated debates, can catalyze the generation of creative solutions to complex problems. When team members bring unique experiences, insights, and approaches to the table, it opens up avenues for exploring unconventional ideas that could be game-changers. This realization has led to many software leaders actively seeking a diverse software dev team in the hope of inserting divergence in perspectives in team decisions.

Debates force individuals to articulate their thoughts, challenge assumptions, and present evidence in support of their ideas. This process of intellectual rigor helps in refining concepts and ensuring that the final solutions are well-thought-out and robust. Without debates, a team risks falling into the trap of groupthink, where conformity stifles innovation and unconventional ideas are overlooked.

Identification and Mitigation of Risks

Software projects are rife with challenges, and potential risks can lurk beneath the surface. Debates serve as a powerful mechanism for surfacing these risks and addressing them proactively. When team members engage in discussions about project requirements, design choices, or implementation strategies, they are more likely to identify potential pitfalls that might be overlooked in the absence of scrutiny.

By thoroughly debating different aspects of a project, ranging from technical decisions to project timelines, the team can anticipate and mitigate risks early in the development process. This proactive risk management is crucial for ensuring project success and preventing costly errors down the line.

Enhanced Collaboration and Team Dynamics

Debates, when conducted in a constructive manner, contribute to a positive team culture by fostering open communication and collaboration. When team members feel empowered to voice their opinions, it promotes a sense of ownership and engagement. Additionally, debates encourage active listening, as team members must understand and respond to each other's arguments.

Moreover, healthy debates provide an opportunity for team members to learn from one another. As individuals share their knowledge and experiences, it creates a collaborative learning environment where everyone can benefit from the collective wisdom of the team. This learning dynamic not only improves the skill set of individual team members but also contributes to the overall growth and development of the team as a whole. One thing important in this area is the leadership style of the team leads in the software project. If the style of leadership is not open to a multitude of ideas then the benefit of enhanced collaboration breaks down and the debates turn into points of division within the team.

Refinement of Ideas and Decision-Making

In the crucible of debate, ideas are refined, and decisions are thoroughly scrutinized. This process is essential for ensuring that the chosen path is the most effective and well-considered one. Debates force individuals to defend their proposals, encouraging a deeper understanding of the implications and trade-offs associated with different choices.

Through this rigorous examination of ideas, the team can make informed decisions that are more likely to stand up to the challenges of implementation. The act of defending one's position in a debate requires a comprehensive understanding of the subject matter, promoting a culture of informed decision-making within the team.

Continuous Improvement and Adaptability

Debates are not static events but dynamic processes that unfold as projects evolve. In the ever-changing landscape of software development, the ability to adapt and iterate is crucial. Debates contribute to a culture of continuous improvement by encouraging teams to revisit decisions, reassess strategies, and incorporate new insights and information as they emerge.

This adaptability is particularly important in agile development environments, where the ability to respond quickly to changing requirements is a key success factor. Embracing debates as a means of continuous improvement ensures that software projects remain agile, resilient, and capable of delivering value even in the face of evolving challenges.

In the fast-paced world of software development, where the only constant is change, the importance of debates cannot be overstated. By fostering innovation, identifying and mitigating risks, enhancing collaboration, refining ideas, and promoting adaptability, debates play a pivotal role in shaping the success of software projects. Teams that actively engage in constructive debates are better positioned to navigate the complexities of development, resulting in superior outcomes and a culture of continuous improvement. In the vibrant ecosystem of software projects, debates are not just discussions—they are catalysts for excellence. We have a joke at Kaz that if only two people agree in a group of many we have a decision! The little comic here says that in Bangla :)

Making remote software team meetings fun

Remote teams spread out over multiple locations around the globe and speaking multiple different languages as their first are the norm these days for most software companies. This is a great trend, as it opens up the availability of software talent to software projects and makes hiring great software developers a much easier task for companies. But as with anything else in this world, those great things come with some downsides. One of the biggest downside is the lack of interaction between team members. Without that interaction the essential element of any good software team: “gelling”, doesn’t happen. We’ve written in the past about how to make the remote team gel so it’s worth a look up if you haven’t read it. Today, we’ll drill down to one aspect of remote team interaction that needs special attention: team meetings.

Team meetings are one of the holy grails for a software project to perform well. It’s a meetup of the team to discuss the project, where they are and where they are going. It essentially setups up the direction of the team at regular intervals. Hence it’s very important to get the meeting right. However, if the meeting is too formal, then it becomes a painful waste of time, where people just sit through boring proceedings and not really discuss the issues at hand in an open way. And the only way you can make that happen is if make the team meeting a relaxed and fun event that people actually like attending. As you can imagine, remote teams pose a difficult challenge to this premise of a “fun” team meeting. We been running remote teams for the past 18 years as a software development agency that helps companies build software products so we have a few tips and tricks to solve this problem. And in today’s post I want to share them with you.

Fun introductions and catch up games

By introducing a short game over the remote call you can easily “break the ice” for new members of a team or even reinvigorate an old team that has been working away from each other too long.

A classic in this remote meeting games is called the "what do you really know" game. This is where you (as the team lead/ project manager) begin a meeting by asking the participants to share something that they know really well. This could be anything from baking to e-bikes. The idea is to leverage people's expertise and build connection and trust right at the beginning of the meeting. You then ask questions about their areas of expertise, which led to interesting conversations.

There are many other virtual games that you can run on the meetings, a quick google search with get you a whole bunch of them.

Running the meeting in the radio host mode

In this this, you make everyone turn off their video! By turning off the video, you've shifted the norm from your team, which spikes the level of fun and engagement in the group. Then you ask someone to assume they are a radio host and then ask others questions like a radio talk show. Here’s an example:

Host: “So, Max, I read on the newspaper that your feature of calculating optimal rates in the software is going really well, tell us something about what you are doing right now?”

You could spice it up a bit to create the feel of a political leader interview, here’s an example:

Host: “But many people have protested that the it doesn’t do the calculation as you promised, is that true?”

There are many variations on this theme and after some practice you’ll find that this is a unique way running the meeting which discusses serious issues in a fun and engaging way. Best of both worlds!

Show and tell

This is modelled after the show and tell things we used to do in elementary school. On the fun introductions and break the ice mode you could ask the participants to find a specific item in their house and bring it back to the meeting. This could be anything from a childhood photo to a favorite book. This is a great way to build connection and get to know each other better.

And on the serious work side, you could ask team members to show the feature they are working on, and describe it in the elementary school “show and tell” mode.

Information sharing via Ice breaker sessions

Icebreakers are warm-up activities that help make virtual meetings exciting and engaging. They require little to no preparation, and they have a lot of potential when done right. Good icebreakers help mitigate the feeling of being a bunch of strangers hanging out in a room together. They have people acknowledge each other's existence, which is just enough to get people excited. Even the few minutes invested in an icebreaker might make people laugh, make them open up to dialogue, and even help them step out of their comfort zone.

One really good ice breaker session is the highs and lows. It’s an awesome way to help people empathize with their peers. You basically ask everyone to share their successes with tasks assigned “highs” and failures “lows”. The goal is to make it easy for everyone to share where they failed without feeling bad or trying to hide such failures. This activity will encourage people to engage in meaningful dialogue with their peers, and most importantly, it enables teammates to provide their colleagues with the support where they failed and needed congratulations on their successes. As a result, this helps create a sense of empathy among team members and promotes a culture of support. Plus, this exercise encourages the exchange of valuable information between people.

So that’s it for now, our top tips for making your next team meeting fun!

Remote software team - setting up the collaboration

Remote software teams is way forward in software development. No longer are companies tied to particular locations, waiting for resources and skills to be available and delaying the entire software process. By finding the right software resource at the right time and forming a remote team to work with any onsite team completely changes the game - and companies that are realizing this are getting ahead in the game. This is just one more evolutionary step in our ever changing industry, a step that has just been accelerated by COVID but it was a step that was bound to happen at some time or other.

As with any paradigm shifts such remote software teams come with some adjustments in work practices and process. We’ve been working with hundreds of companies around the world for the past 18 years in providing software resources and hosting such remote software teams. Here are some our tips about the right setup for collaboration and workflow for such remote teams.

Setup a clearly defined work process

This may sound obvious but you’d be surprised by how many teams we’ve come across that just assumed things about the work process for collaboration of remote and onsite teams. This is understandable though, when a team works side by side many of the work processes are automatically defined and agreed upon without explicitly defining them. An example would be the timing a push of latest code into the shared repository - if the team is all together very soon a standard of when a push is appropriate and acceptable is agreed upon. A few wrong moves by a new team member quickly gets fixed by visual (and sometimes very audible!) ques from the rest of the team. But now imaging when part of the team is spread out remotely. The same mechanisms of automatic agreement doesn’t happen fast and sometime never. There is no way out on this, for teams with remote members the lead has to layout a clear set of instructions for major work processes. What the major elements are depend on the nature of the project and the team members but here are some that are obvious candidates:

Work timing - when to be available, when are good times for pinging without advance notice, when not to poke, etc.

Tools - defined set of tools for collaboration like issue tracker, IDE (specially versions of IDE)

Reporting standard - when to cry for help, when to warn about delays, what to report and what not to worry too much about, etc.

Testing rules - what should be the minimum set of tests on the developer’s side (even if unit testing frameworks are available for the CI/CD), etc.

Code repository rules - when to push, who can merge, etc.

Meeting rules - what tools to use, what are the good times for combined calls, how long the meetings should be, etc.

Create an open communications channel

With team members spread out geographically the open communications channel is essential for a healthy team dynamics. One common strategy is to have video call regularly with the video on (visual is very important forming the bond between team members). An awareness withing the onsite team about keeping the remote team members in the loop on all important decision making process is absolutely essential. Running regular video meetings is one of the best way to avoid issues caused by communication gaps and it has the added benefit of making the remote team members feeling valued. These video meets should ideally to be planned in advance and hosted at a time that works for everyone. A random last minute email to setup these calls isn’t the way to do it. Formalize at least a regular video meet by setting up a recurring invite so that everyone are reminded before each session.

Regular team calls should have the goal of keeping remote team members updated and also getting feedback. Remote teams should not find out about important decisions at the last minute. This has huge impact in lowering morale within the team members and would start creating a divide between the onsite and remote staff. If there is a new process change or some important company news a specially rededicated call aimed at all the members should be placed to keep everyone on the same page.

Use team collaboration tools as much as possible

For onsite only teams we always push for face to face informal interactions more than a very process and tool centric interaction. This is completely the reverse when the teams are spread out. In such teams you should aim to have all major collaboration purely tool driven. A good example would be work distribution on a issue tracker. For onsite only teams it’s usually great to have a quick ad hoc meeting to split a task and then asking team members to just create and assign the tasks to themselves - it moves the needle move faster and just feels less clunky, less “bureaucratic”. But doing this for remote teams is recipe for disaster. It’s best to rely on the tools, have as much as possible of the discussion on the tools (e.g. a discussion thread on the issue tracker, or slack, etc.).

It can be difficult to keep track of the progress and monitor the status of the project at every stage for remote teams. Using a great project management tool like Atlassian Jira is essential. Such a tool must have features for creating tasks and subtasks, assigning them to team members, tracking the task and setting time estimates for those tasks, etc. Such a system should also have a way for discussing details of task, a way to collaborate at the task level with a log of what is going on. Here’s a screenshot with an example of an ideal task ticket tool feature.

Top 5 challenges of building an effective software team

1. Finding the right people for your team

This is without doubt the hardest challenge. Finding skilled software professionals is hard, but find the people who work can work together is even harder. Although this is the hardest there is no way around it. The success of any software project depends on one factor - how good the team behind it is. We know this from our experience in working with 100s of software projects over the past 18 years, but research and data in this area also shows this fact. In their comprehensive study of software project failures published in Software Development Failures: Anatomy of Abandoned Projects Ewusi-Mensah, K. showed that factors related team composition and team dynamics comes up very high in absolutely every single software project that has failed in their group. Similar connection with team related factors are found in other studies too. A good summary can be found in a paper titled core factors of software project success.

Table comparing softwre project failure causes from paper: https://www.researchgate.net/publication/330290988_Core_Factors_for_Software_Projects_Success

You need to focus both on the skills of the individual resources and the fit of the resource between each other to find the right team. A mix of skills is very important, so as you are composing the team work on looking at individual potential candidates and map out their skills - both technical and soft skills. Find a balance where you have various technical skills spread out along with the soft skills. An example could be that for a web development project in .NET you should look for people with core .NET programming skills but also add people with database, javascript, UI/UX skills. And again on the soft skills front you should have some members of the team who are good communicators, some who are good mentors and some who can run a debate well.

2. Getting your software developers to communicate effectively

Once you have the right team your next big challenge is to setup a system, a workflow and a culture where commutations happen in a flexible and free form way. You want multiple channels of formal and informal discussions. You’d want formal structures like team meetings and brainstorming sessions coupled with informal channels like a talk in front of the water cooler. At Kaz a great place for informal communications is the team’s own break space - we call them ip - interaction points. Sometimes it’s a veranda with some chairs where team members take their tea/cigarette break and has a chance to discuss something that’s bugging them (sometimes its about the the project too!).

It’s vital that your team should communicate effectively. Many a great software team has produced failure by the fact that the management made it too difficult to communicate - maybe with too many formal meetings or too few.

It’s hard to suggest a winning formula that works for every team as every team is different, every project is different. And add to that mix the WFH and remote work you have an even more complex problem. Work with your team to make sure there is effective discussions happening. Check back regularly on the health of that communications.

3. Developing a process that works for everyone on the team

Once you have the #1 and #2 sorted out you are half way there. The rest is pretty standard operations setup but it’s still super important to get things right. The top thing on the operations part is setting up the workflow.

A software development workflow involves all the nitty gritty steps of getting the software requirements, specifications, planning, distribution of work and then getting that work done in phases. The catchall word for anything related to software development workflow these days seems to be “agile”. But saying “agile” is not good enough. Setting up a workflow - if it’s driven by the concepts of the agile methodology that’s great - is important. Again, the thing to remember is that every team is different, every project is different and every company is different. The “agile” that’s right for you might be different from the “agile” of a different team or company. Plan the workflow that fits with your circumstances. For example, if you working on startup’s proof of concept project and entire future of the startup depends on showing this POC fast to it’s investors so that they can get some funding to actually build the thing - having a complex process for creating and tracking tasks that has to be reviewed at multiple steps is going to be a disaster. You’d want a process that is fast, relies mostly on verbal communications and commitments and almost no red tape. The opposite would be true if you’re working on upgrading an existing ERP that a large number of customers relies on it’s day to day work and single breakdown can lead to a lot of trouble fore everyone.

4. Creating an environment where every member of the team feels valued, respected, and included

In the mode of efficiency and engineering that software projects tend to push us we forge that at the end a team is a just another group of people. They are no different than other groups of people in our daily lives - each with their own needs and desires. It’s vitally important that in the hectic pressure of the the project, the need to find great resources and in creating efficient workflows we don’t forget the fact that the team members individually and the team collectively needs to feel valued and respected.

The worst offender in this space is the high handedness management teams sometimes use to operate with development teams. They somehow feel that they need to command and control the teams - which just doesn’t work in the creative and intellectual space that software development projects work in. It’s important to we aware of this danger of detachment from reality and keep honest reviews on the company’s attitudes and processes to make sure that the team feels happy and motivated. Remember that in software a demotivated team is directly equal to a failed software - there is no mid point in this equation.

5. Balancing what's best for your company with what's best for the team

The last point is a delicate one. You might have the best resources, you might have a streamlined process with a healthy team motivation in place but you are still operating within a business. A business has priorities and typically it’s about money and short term goals. These priorities will always clash with your team’s health. Short term goals will mean over working the team, it might mean a burnt out team and it also might mean that team members pushed around various things in their project (something that developers hate). It’s not an answer to say that I don’t care about the goals of the company - as those very same goals make the ends meet and get the funds for everyone to live. And on the reverse it’s also not an answer to say that we’ll sacrifice the good of the team to make the goals of the company work. There has to be a balance somewhere. The team will have to compromise on certain things (e.g. maybe a special impossible deadline for funding) and the company will have to compromise on others. If you get the balance right you’ll have a wonderfully efficient team in place.

OK, lots of heavy stuff. Let me finish off with a stolen Dilbert :)

Why do software projects fail and how to save them

A recent post about making software project plans that work started a thread of conversation with a fellow software guy about how true it is that software projects are prone to fail and we should just accept that fact and plan around that. His point was that we should actually take a more positive attitude that software projects work out at the end and work from that positive space managing the risks. He does have a point, any work starting out with a negative thought actually leads to bad things - your thoughts are a thing as Napoleon Hill says in a book about wealth creation. And it’s a good question to ask - what is a better approach for software projects - assume failure and plan to manage it or assume success and avoid traps?

Facts & Data

Let’s look at the facts again. Research after research shows that software projects fail most of the time. A great source of software project health in general are the CHAOS reports published by the Standish Group. The CHAOS Reports have been published every year since 1994 and are great indicators of the state of the software space.  The 2015 report studied more than 50,000 projects around the world, ranging from small few man week software projects to huge thousand man year IT projects and system implementations.  The results show clearly the trend that software projects are failure prone. Take the summary pie charts in the report (shown below). The red is ominously present in all the three aspects that were judged - budget overflows, timely delivery and feature achievement. I agree that the green is also strong (note the error on the first pie though, where the colors are flipped!) but shouldn’t you the red to be much smaller on all those pies? With such large amounts of money spent and with companies betting their existence these days on their IT systems having that high percentage of red is not a good sign.

And don’t think this is a recent trend. Actually things have been getting better over the years. Software projects have always failed but the rate of failure is reducing (at least according to these guys). The stats show the success percentages are going up over the years, so that’s definitely good!

Why do they fail? And, how to save them?

This is obviously the million dollar question (I guess a billions of dollar question in this case). Every software project is different, be it with the requirements, the nature of the product, the nature of the customer and the nature and composition of the team that worked on it. So it’s impossible to generalized. But overall some common risks are seen in all software projects that can if left unmanaged lead to be one of the factors of failure. Note that I said “one of the factors” as most software projects fail not because of one single cause but a whole bunch of them, each stacked on the other. So instead of talking about generalized causes of failure, let me just claim that most software projects have the following risks that should be managed. It would not gurantee the success of the project but it would certainly make the project safer.

Bad project planning

In our experience, bad project planning is the biggest cause of software development failure. This is one area of engineering where project planning makes it or breaks it. You can have the best developers in the world, unlimited budget, time, documentation yet if you don’t plan things right, if you don’t plan things realistically you’ll just burn that team, eat up that money and time and end up with a bad software or no software. To take a recent software project that failed despite having everything ($1.7 billion budget, 1K+ strong team, etc.) is the US’ healthcare.gov platform. It was way over budget (original budgeting was $93.7 million!), severely delayed and very buggy even when delivered. Problems started as soon as it was somehow launched. Although it was known from day 1 in the planning that there will be huge demand, the huge hit caused the site to go down within the first 2 hours. While website user hit initially cited as the main cause (inexcusable as this was one of the given parameters) other problems showed up because the UI was not complete or confusing. Issues such as drop down menus not being complete and insurance companies information data not being correct or complete was a common problem. By some estimates, only 1% of people managed to successfully use the site on the first week. On October 20, 2013, President Barack Obama remarked, "There's no sugar coating: the website has been too slow, people have been getting stuck during the application process and I think it's fair to say that nobody's more frustrated by that than I am." It was all down to the poor project planning.

Work on that project plan. Read our recent post about project plans that work. And most importantly work with skilled project planners who has experience to understand the problems of a software project.

Lack of communications or excess of communications

Software is always a collaborative exercise. You need open channels of communications that are fast and reaches a resolutions quickly. The the quick resolution is also super important that is whey the excess of communication is something to worry about. You have to monitor that “analysis paralysis” doesn’t creep in just because there is a lot of communications possible.

Too many targets & unrealistic goals

Often the only things that pushes a efficient and streamlined software project towards disaster is the multiplicity of goals. A team can only do one thing at a time with a good quality. If you try to push them to do too many things even with the best of planning they will burn out over time and reach a point where it is only the team’s speed that hinders the success of the project.

Many great companies fail to understand this - they push their wonderful software teams to create great software one after another - pushing new features in, pushing new versions and upgrades in - at one point the team just breaks down. No matter how good your plans are or how good your communications channels are a burnt out team will always lead to failure.

Too large a team and too large a project!

Software project size and the team that works on them have an optimal size. Beyond that optimal size things don’t work too well. Communication becomes too noisy, mistakes start happening, people tend to lose focus and the wonder project plan starts to break down. Over and over research has shown that larger projects fail more than smaller ones. Here’s a table from that 2015 report:

If you have a large project or a large team - break it down to smaller projects with smaller teams that interact at set points to build the large project by parts. That is the only safe way of doing things - we know it from experience and data proves it over and over. I’ll finish with this quote from the report … says it all.

“... that size was the single most important factor in
the resolution of project outcome ... It is clear that the larger the project, the less valuable the return rate. In many cases larger projects never return
value to an organization. The faster the projects go into production the quicker the payback starts to accumulate. ”

— CHAOS Report 2015

Top 10 Questions you must ask your software vendor

Do you have any questions for your software vendor? You should. The standard stuff like what is the size of the vendor’s team, what are their skills, how long have they been around are usually available easily at the vendor’s website, their brochure or they are more than will to just give you that information. What is more difficult to know yet vitally important for you are the answers to the not so easy questions.

Here’s our list of top 10 questions that must be asked before any software development relationship is set up with a new vendor. There are obviously a lot more, but we feel that these 10 must be asked no matter what and the answers to these should be discussed internally with your team to see if you see a good fit, to see if you agree or accept those answers or not.

1. What are the company's values and goals?

You might think this isn’t all that important for you as a customer, or it’s just some marketing blurb that you can by pass - but you’d be wrong. A software development project isn’t like many other projects around, it’s not like a simple product you buy and then you can pretty much live on your own. A software development project means a sustained relationship for a period of time (usually pretty long - remember it’s just not the development time, but all the maintenance, updates, upgrades and fixes of a software’s typical lifetime) . So what your vendor’s values are, how they see the business, what their goals are - all these matter because you’ll need to agree with them, be comfortable with them and at the very least accept them. For example if the vendor feels that their real goal is to become a giant in 5 years, then you need to think if that fits with your goal of working with a stable and small team.

A picture from 17 years ago at our old office where we had those beautiful mosaic patterns you don’t see anymore.

Sometimes alignment of values are a very good sign that things will work out in the longer term. I remember a long time back I was showing a prospective customer our old office space that had these beautiful, intricate mosaics and I mentioned that we love these patterns and we take extra care not to destroy them somehow. She just absolutely loved it and said her company was a 3rd generation owner company that valued traditions - and we knew we had a good alignment. And indeed over time that has proven to be so true, having worked with them for a long time and launching several of their flagship products.

2. What happens when you fail to deliver something?

This is the hard question that all software vendor will try their best to avoid. But you absolutely have to ask. Things do go wrong in software (actually all the time, some studies have shown that 78% of software projects fail, a recent post of ours tries to find a way software project plans can be done to avoid failure). So asking how the vendor will manage that risk is essential. If the answer to that sounds vague or if they say the impossible - “we don’t fail” then think hard if this is a good fit, dig in deeper to see how reliable that partner is. Every software project should have a disaster recovery plan - simple. If a vendor doesn’t have one or isn’t planning one then there is something wrong with that vendor.

What you should be looking for is a realistic yet confident approach towards delivery failures. There should be a risk management plan - a risk containment and mitigation approach. They should be ready to act when a failure happens, and draw on the experience and knowledge from past projects and from the team to minimize the impact to the project.

3. What happens if a team member leaves suddenly?

Software is very much a team effort where every team member is essential. Over time a team member becomes an expert of the project and its requirements. Developers grow the essential familiarity with the codebase, the features, the decisions and the compromises that make a software project work smoothly and efficiently. So when a team member leaves it puts a huge dampening effect on the overall project and the vendor must have a good plan to first manage the team so that doesn’t happen and then manage things when it does happen.

More on this theme on question 8 below and there is a reason to separate them out and ask them a bit spaced apart. You want to revisit this topic to see if the answers fit well.

4. Can you provide case studies of customers who have been successful with your software?

5. Can I speak with a client who is using your product now to get feedback on their experience?

6. How many projects like mine has your company completed in the past year?

This is pretty standard stuff - but sometimes these case studies are not shared publicly. Maybe an NDA prevents the sharing or there are some other reason why they don’t want to put these in their marketing material. So it’s essential to ask and then review these case studies. These are projects that has worked out so you should get a feel of your own project fitting in those - see if you can imagine your project being one of the case studies in the future. Ask questions that are not answered or issues that are not clear in the case studies.

7. What's the best way to reach you during and outside normal business hours?

8. Who will be my point of contact throughout the project?

Standard questions but you’d be surprised how many customers don’t ask this. You should have a clear picture about what to expect when the project is running in terms of communications. All projects will have at least one point in its history where you are desperately looking for a quick answer to a question. It could be during an important demo that you are giving to your prospective customer, it could a bug you spotted that needs a fix right away. You need to know about the contact points and be absolutely sure before any vendor is accepted.

9. How do I know that I can trust you with my data?

Data security if everything in software and it’s important you ask this question right at the beginning. There must be a very clear procedure for data security at the vendor’s site. They must have a plan and a process that ensures that the plan works.

10. How long have your employees been with your company, and how many years of experience do they have in this industry ?

This is a revisit on the team stability question of question no 3. Vitally important question and a revisit is needed to see if the answer to this fits with the answer to the other.

Good luck with your vendor hunting!

How to make a software project plan that actually works

Making a project plan for software development is one thing, but making it work is another. You've probably seen lots of software project plans in your day. They all look the same with their pretty Gantt charts and lovely blue annotations, don't they? Yet, do you know the failure rate of these pretty Gantt charts? That number is an unbelievable 78% according to one study in 2009 (the same group found a failure of 84% in IT projects in 1994!). This humongous failure number keeps coming up in studies after studies, here’s one by another very respected group - McKinsey-Oxford study for IT projects

Given these huge failure numbers we have to accept the reality of difficulty of making a software project plan that works. Over the years we at Kaz Software have worked on numerous software projects, for hundreds of companies around the world and we know from first hand experience how difficult this is. There are hundreds of variables that you should be thinking of when making a reliable project plan - from obvious ones like requirements, business priorities, resource availability to unexpected ones like language barriers, paperwork, compliance issue, etc. On today’s post I’d like to share some of the things we have learnt about making a better project plan - not perfect, maybe perfection isn’t possible, but a better one at least!

Decide on a project timeline and set deadlines

The first step is to decide how long your project will take. One month, three months, six months? Or maybe you can't put an exact number on it because you aren't yet sure what the project entails. That's fine too - just be as accurate as you can. The point is to be realistic, to have all the information available at that point in time and make the best possible guesses based on that information. If you know the requirements will change frequently, set deadlines for each round of revisions. If you think your team members are bad at estimating their time, maybe give yourselves a longer timeframe. Set deadlines that are achievable but challenging. Don't be too optimistic or you'll end up disappointing yourself and everyone around you when things don't go as planned.

Create a list of tasks with a democratic estimation

This is where you break down the requirements into smaller areas, features and then eventually tasks. Make sure you about break large, vague tasks into smaller tasks with deadlines that are based on the time estimates. Breaking down the larger tasks into smaller tasks are relatively easy, especially if you have experienced resources in your team. Where it gets extremely hard is the time estimation of tasks. Most developers will either overestimate or underestimate time cost for a task. This is just a fact of life. Our solution has always been to use democracy to find the time cost number - effectively asking all members of the team to discuss and come up with a time estimate rather than relying on a single person (the developer who is likely to do the task). This may sound counter productive, as the task will be done by a single developer at the end of the day - but somehow the democratization of this process gives much better result.

“Realistic schedules are the key to creating good software. It forces you to do the best features first and allows you to make the right decisions about what to build. Which makes your product better, your boss happier, delights your customers, and—best of all—lets you go home at five o’clock.”

— Joel Spolsky

On this point I’d like to note another very effective way of getting time estimates - which is to look at historical success and failure rates of estimates per developer and based on that decide if the developer typically over or under estimates and then add or subtract based on that data. This idea was very effectively put into use in Joel’s FogBugz product - and he called it evidence based scheduling. You do need a platform like FogBugz to make this happen, and even then you need to have enough historical data with the same developers to make it really work.

Write down the resources needed for each task

This is where you list who's expertise is required to complete each task and what kind of equipment will be used. If the skills required for a task is not available in your team, plan for it - how you will fill up the gap, what steps you'll need to take to have that skill available at the right time. Some of those steps may be tasks themselves that you have to add to your project plan.

Set up milestones that you'll need to meet

Milestones let you know how much progress you've made and if everything is on track with your timeline. You can set up intermediate deadlines as well if you're not afraid of breaking your work into smaller chunks. If you have a long term project, it may be better to set up milestones at the beginning so that you'll know how much you can do every week or every month.

Make sure your plan is achievable by breaking it into small enough chunks so that you can achieve them one by one. Divide and conquer is the the only way to solve the complex problems in a software project. If you decide to take on something big, it can quickly become overwhelming. Try breaking your project into smaller pieces and figure out how long each one should take.

Stick with it!

Don't give up when things get tough! You're almost there! This is the most important tip of them all. If you have failures, delays, setbacks just know that that is a fact of life for all software projects. You just have to have the patience to stay with your plan, make changes as needed to adapt to the delays and move things forward. Software projects never go as planned, and one of the greatest sign of a good plan is that it has the ability to absorb the changes as they happen. And the one most important skill of a software leader is the the ability to stick with the plan.

Remember that a software project is a process, and it can be thought of as a linear progression from one phase to the next. Plan out how you will go from start to finish with milestones in between. Use your resources effectively by having the right people on the job for specific tasks, making sure you have access to special equipment or resources.

Let’s break these horrible failure stats. Good luck!

All you need to know about bug reporting

Bugs are a fact of life in software. There will always be bugs, we just need to find a streamlined way of catching them, reporting them, fixing them and deploying a new version with at least that bug fixed. In this process of catching bugs and removing them from the software the role of bug reporting is vitally important. If not done right valuable time is lost in clarifying what the bugs was about and in the worst cases important bugs are either forgotten or deprioritized. This situation makes the software less usable and eventually if this situation continues the users stop using the software - which is effectively the death of a software. So today I want to go over one of the least exciting topics in software development yet one of the most important one - reporting bugs in a way that is effective, efficient and clear.

The bug report

The best bug reports are short with a step by step "how to recreate" section and an expected results section. It’s pretty easy to remember the rule for a good bug report. Every bug should have at least the following:

1. Steps to reproduce the bug.

2. What was the result?

3. What was the expected result?

By laying out the result and the expected result the bug report is clearly showing to the developer the gap. The developer can now use #1 to recreate the bug, look at the result and check why it’s not giving the expected result.

Here’s an annotated example of a great report from a really good post about how bug reports should be done.

Apart for the basic facts above, additional data such as screen grabs and links to the product page are always good to have. Something else that also matters is the context of the bug - if there was a special situation when it happens (ideally that should be part of the steps to reproduce, but sometimes it may be hard to put that in there). If your bug is related to a specific hardware device and you should attach your device ID, it helps the developers find the bug faster and fix it sooner.

Including as much detail as possible makes finding and fixing your bug faster, remember that when reporting the bug the state of the software may be completely different from the time when the bug is being re-created and fixed. Many times a bug that was reported cannot be recreated by the developer. The reason could be that a step was missed in the bug's description or the state of the software at that particular situation needs to be in certain way for the bug to recreated. I remember a particularly nasty bug that would only happen at the QA's machine but never on my dev machine. The reason was that the QA would always run the web app by clearing his cache which would create a situation very different from my one where a certain cookie was always set. So the bug was really about not managing the cookie's absence.

Sometimes there could be many bugs that you report without realizing it. For example if the application is doing something wrong in a situation where you expect it to do something different and you thought you had reported the only bug and then discover another one after some time, chances are that your first bug was actually two separated ones and not one big one. The QA needs to think through every bug to see how it happened.

As you can see, describing a bug is not as easy as it looks and chances are that if you report a bug like this: "I opened the app and clicked 'login' but I was on the 'welcome' screen and there was no way to go back", then it will be impossible for developers to fix that. And it will end up spending everyone's time.

The process after the report

After submitting your bug report in an issue tracker, it should first be picked up based on severity of the bug. If the bug is a show stopper, a bug that stops the software from working then it should be prioritized over all other bugs and if needed current development flow will need to be changed to fix the bug so that it hits the next release. If it happens not to be a show stopper but just an inconvenience, then it gets bumped down the list and is fixed over all other bugs that are also being worked on. The issue tracker should be available to the original reporter of the bug (maybe the QA person or even the user of the software) who can easily track it down and see the status of the fix.

Another important thing with a bug report is the history of the bug. Every bug should show when it was started, what happened during it’s fixing, the exchange in information that happened to clarify the bug and finally the fix and the confirmation of the fix. So a history of the workflow per bug is a must and every software development process should use an issue tracker that supports such history. The good news is most modern day issue tracker such as Jira, Github, fogbugz, etc. support this buy default. Even the simple trello board is good for this.

How to evaluate software development company performance

Do you find that your software development company is taking too long to deliver a project? Do they lack creativity and innovation? Would you like a partner who can provide accountability and transparency in their work? If so, read on.

As a custom software development company that have worked with hundreds of clients all over the world we have come across all kinds of situations where multiple parties are involved in creating a software platform. The performance of each party is crucial for the overall pace and success of the software project. And we have advised our customers about how to monitor and assess performances of their vendors - including ourselves! In today’s post I will summarize some of the biggest tips we have for our customers to assess the performance of a software developer.

The basics

In order to evaluate the performance of a software development company, there are four criteria worth considering:

speed, price, quality & service

Here's how these factors stack up for one of our clients:

-Speed: Slow delivery times lead to lost revenue as well as frustrated customers. Our client has already seen an average 30% increase in productivity from the new vendor we partnered with them on this project.

-Price: You get what you pay for! The old adage applies here, however there is a big mitigating factor here - location. If you are using a vendor at a relatively lower cost location such as ourselves based in Bangladesh you have the opportunity to find a price that is lower without compromising on the quality.

-Quality: This is the the most important one. In the world of software the only thing that really matters is quality. And you could compromise on pretty much all the other factors but not on the quality.

-Service: How’s the requirement analysis, the communications during the build, the delivery, the promises kept and the promises broken? All of these go towards the service metric.

The performance measurement matrix

The performance measurement is not a linear operation. That is to say it is not a single number you are looking at. For example a company that is great at quality might be really poor at speed. Does that mean it’s a badly performing vendor? The only sane way of getting a full view of the performance is to create a matrix that goes over the issues at stake and measures each one of them against the four basic dimensions of performance mentioned above.

One thing to note before I jump into this: there are hundreds of “scientific” way of measuring performance of a software development vendor. This is a topic that is favourite with efficiency specialists, university computer engineering departments and large multinationals with huge investments in IT. If you really want to get to know some of the research work that is done in this space a great starting point is the highly academic yet useful book generalized towards engineering organization performance: Performance Measurement and Management for Engineers or if you prefer a google search will lead you to a pages and pages of approaches towards measurements. What you’ll soon learn is that there is no standardized foolproof way to do this. At the end you end up with a lot of hand wavy metrics. All the big names in software has said something or other about the futility of measuring performance in software projects! Here’s one I like a lot:

“So while I see the value of measuring individual performance in research settings, I think its difficult to find cases in which the effort is justified on real projects.”

— Steve McConnell

OK, now that I’ve got that out of the way, let me go over what we suggest. Our approach is pragmatic. We accept that no measurement scheme will be perfect, so all we can do is layout some basic information in a way that’s easier to visualize and let project owner do their own assessment based on that. So that leads us to the matrix I was referring to.

The columns in the matrix are the four basics - speed, price, quality & service and on the rows are the questions or issues that matter to the project or to a particular company. In this super simple method we take away the pain of running elaborate surveys, questionnaires, software line of code analysis etc. that some approaches use and use a very intuitive way of quickly getting to some feelings about the overall performance. Note that the number of rows, that is the issues, actually vary project to project, company to company. And that makes perfect sense, what matters to one project may not be an issue at all to worry about in another.

Here’s a sample matrix that we did for one of our customers recently. They had a total of 28 issues that they tracked with this, beyond the ones shows in the screenshot the rest were specific the product features, stuff like “All screens should update with animation”, etc. These made sense for this particular customer as they thought this was essential for the assessment of performance, but for many other companies such a granular level or such a narrow scope for the assessment wouldn’t make sense. That is the beauty of a simple matrix approach such as this one - it is flexible and can be adapted to the need of a specific project/customer/vendor situation.

When it comes to evaluating software development company performance, there are a number of factors that can help you determine if the vendor is working in your best interest. I’ve outlined our suggested way that seems to work very well for software projects. You can use this at regular intervals (we suggest every 6 months) to check the performance and detect signs of change. The change in scores from previous ones give you the signs of a change in performance - for the better or for the worse. Do any of these signs apply to your current vendor? If need help give us a shout at info@kaz.com.bd to learn how our team might be able to help you.

Living with bugs in released software products

Bugs are the reality of software. We hate them, we do everything we can to get rid of them but they are always there and we have to learn to live with them - that is we have to manage the bugs and fix them in a sane way. This is important. Actually trillion dollar important. in study done by the Austrian software testing firm Tricentis, software failures cost the worldwide economy over $1 trillion annually!

The same report also found that software failures have caused more than 315 years of lost time and have affected approximately 4.4 billion customers. Software failures also have a massive negative impact on the reputation of companies. The companies surveyed by Tricentis lost an average of $2.3 billion of shareholder value just on the first day after announcing a software failure. No wonder that so many companies keep quiet about bugs. Yet that is probably the biggest mistake. The trick is to learn live with the bugs as a reality and have a practical and realistic process for managing bugs in live products. Today’s post is an attempt to summarize some of the strategies we found as the best for managing bugs on live products.

Accept bugs

This may sound obvious, but you’d be surprised how many companies treat bugs as something totally unacceptable and creates all kinds of penalties and punishments when bugs start surfacing on a product. This behavior comes from not understanding the nature of software products. Yes, the goal is always to have a bug free software release, but the reality is that there will always be some. So the goal should be:

“Release with as few deadly bugs as possible”

Accepting bugs opens up the possibility of a realistic software development process with healthy bug identification and resolution strategy. So this is the first step - for the management and for the technical team leadership.

Make finding and reporting bugs easy

Real life story:

A group of security researchers were prepping for a major reveal in 2013: They planned to disclose at a D.C. cybersecurity conference how a security flaw in luxury vehicles could let bad guys break in without keys and start the cars.

But Volkswagen stopped them, winning an injunction in a British court after arguing that publishing a paper detailing the problem would "allow someone, especially a sophisticated criminal gang with the right tools, to break the security and steal a car,"

https://www.theguardian.com/technology/2013/jul/26/scientist-banned-revealing-codes-cars

After you’ve accepted that there will always be bugs the released products your next sane thing is to setup a process and workflow for identifying and resolving bugs. It’s just crazy how many software companies out there try to hide their bugs or try their best to make it difficult for people to report them. There are literally hundreds of known cases where large companies tried to stop reporting bugs in their software - just making their users suffer even more.

This line of thinking is stupidity defined. You just cannot stop people from finding bugs. What you should do is make it easy for people to find them for you. Have easy ways for reporting such bugs - such as customer support emails that can easily turn into bug reports, a bug reporting page like Facebook’s Report a Bug feature.

On your development team’s side also have the tools for keeping track of all bugs that are being reported - both by customers and your QA teams. Tools such as Jira are absolutely essential, just as important as the software development tools or issue trackers when the actual software was being developed.

Involve customers in the bug finding journey

This needs to be a management and marketing level decision - involve your customers in the bug finding process. Ask them for feedback, have formal ways of checking back for issues, reward them with freebies when they find bugs. Customers are the ideal QA of a software, they use it everyday and they use in ways that your dev team would not even think about using a software (e.g using MS Word for image editing or Power point to make web pages!).

Microsoft has a thing called bug bounty which literally inspires users to spend time to find bugs and be rewarded for such efforts. Google has it’s various reward programs for finding defects, these are all examples of far sighted companies who have not only accepted bugs in live products and made it easy to report - they are actively involving the customers in their journey to find and ultimately fix those bugs.

Have workflow for updating users about bugs

As you accept bugs as reality, your wording and communication will let your users also accept them and make them expect you to come up with fixes as soon as they are found. They also expect you to be mature about bugs found in the current system and have a place to know about such bugs and the status of those fixes. User forums are great for such things and modern ones like Zendesk or Uservoice and many others like them do a great job of updating users about bugs, getting their feedback and letting them know when things are fixed. They have also the feel of user communities and can lead to bigger and better things such as users helping each other out and users forming their own groups to teach each other.

Create a culture for celebrating finding and fixing bugs

Finally, the most important thing of all - within your company and your development team create a culture of celebrating the finding of each bug and fixing them. Some companies make the fatal mistake of making the dev team feel bad each time a bug is found - this creates the negative emotion that takes away the enthusiasm and spirit the team needs to polish off a released product over time. To a dev team the release product is their own creation - any bug would sound bad to them anyway, it defeats the purpose if the company culture is to make them feel worse. The culture should be that bugs are unfortunate yet inevitable - but once found how fast they are resolved and an updated software is released is the true sign of a great software company.

Trust me on this, after more than two decades in this bug creation, I mean software development business, this culture fix is the biggest thing that differentiates a great software company from the others.

How to manage difficult software developers?

Software developers have a reputations for being “difficult”. But from my years of working with literally hundreds of developers I know that what is considered “difficult” is just a wrong way of looking at things. You can completely change the interaction and behavior of a “difficult” developer if you just adopt a few easy changes in your thinking and action. These “software people skills” are super easy and it’s really painful to see how many project managers or team leads don’t these. I’m going to do a series of software people skill going over them one by one. These are skills that are extremely easy to learn yet effective right away.

Instead of my usual of just listing them out, I’m going to make this series more hands on. I’m going to pickup pieces of conversation that are common between a manager and the “difficult” developer to show you the scenario and show you how you can completely change that conversation. You’ll notice that the manager will always be reasonable in his requests in the scenarios I talk about since I’m not talking about irrational or abusive interactions.

OK, to my skill #1

Software people skill #1: Always criticize code in private

Scene: Mr. Dev is in front of the his computer, Mr. Manager is standing next to him staring at the computer and speaking while pointing to the code. The last build of the product had some major bugs, most of the bugs on Mr. Dev’s area. Mr. Manger wants them fixed quickly so that they can meet the deadline (and also wants to air out his anger for the bugs hoping that the anger will make Mr. Dev create less bugs next time round). Other developers are within earshot.

Mr. Manager: Hey, there are way too many bugs in your part in this build. Can you please fix them asap so that we make the deadline?

Mr. Dev: You cannot blame it on me, I had way too many tasks, I told you they were impossible to finish and you are now seeing the result. So it’s your fault not mine and I’m not cleaning up your mess.

The mistake: Code is a developer’s craft. It is his creation, almost like his child and he will always identify with it. There is no way you can criticize his code and not get him emotionally affected and be defensive. And if you criticize in front of his peers and with his creation right in front of the conversation it is the worst you can make things for her. This will get you nowhere and will only make things worse down the line.

The solution: Know the sensitivity about criticizing a developer’s code. But that doesn’t mean you should not criticize or not take any action in the hope it will be sorted somehow. You just have to do it with some care.

• Make sure you have the discussion in a private space away from the peers of the developers. Ideally your office or a meeting space with the door closed. The developer will appreciate your care about keeping it private and also feel the importance of the need to address the issue.

• If the developer’s room is itself private, you should do the conversation away from his computer. This is purely from experience and a bit weird but there is definitely a psychological effect of receiving criticism right in front of the code that is being criticized.

• You should use inclusive language like “we” “us” rather than direct “you”. This gives the developer some relief that he is not the only one involved - because in a lot of situation he feels (and he might be right) that he was not the cause for the failure. Inclusive language moves the interaction to a feeling of working together to fix the issue.

• Softening the accusation a bit may help. This is case sensitive but the fact of live in software development is that people will make mistakes, there will always be some use case not thought out, some requirements will always be vague, etc. So once again if the language feels like you understand the complicated nature of a developer’s job, his reality of dealing with all kinds of unknowns and variables of a project, he will feel more understood and be less defensive.

How to be the best software team lead

Software team leads have a difficult job. On one side they are expected to be the top developer in the team, cracking every technical challenge that comes their way with the snap of a finger yet on the other side they are expected to be the “manager” of the technical team. Now this “manager” bit is the one that is always fuzzy - it ends up meaning a lot of different things to different people and the team lead also ends up trying to fill all those roles that is expected of her. Being a manager will definitely mean she has to coordinate the activity of the software developers in her team - for example assign, distribute and redistribute tasks, help out team members with tasks, resolve conflicts, resolve technical challenges, prioritize activities and tasks. But being a manager also may require her to interface with customers, other teams within the company, attend meetings with the management teams, fill out spreadsheets for accounting … the list is really endless. With all such disparate responsibilities the question becomes what do you do to become good at becoming a software team lead. Here are my top tips from years of managing software teams and progressing through the career from a software developer.

1. Always plan first

   Obvious, isn’t it? But you’d be surprised how often the software team lead is under so much pressure that she just jumps in and tries to “winging it”. This strategy may work once in a while but it’s a recipe for disaster. ALWAYS plan, even if you feel there is no time for planning - force yourself to do it. This is a habit thing rather than a natural thing. By forcing yourself to plan things out you are ensuring that you give yourself a chance to think through things and prepare for overruns, disasters and failure. I’ve this as the first one in the list because I feel that if you don’t take anything from this list you should at least take this one. This single habit can change how good you are as a team lead. You’ll come out to be confident, your leadership will be valued and you yourself will be less stressed.

2. Mentor and delegate

   Notice how I just don’t say delegate? Delegating is really the core skill of a team lead. It is what makes her successful. But just by delegating tasks that she cannot do to others she is actually harming the project. She has to ensure that people she is delegating to has the ability to do those tasks. And for that to happen she has to mentor her team. The best software team leads are great teachers - team members come to them to learn. They start getting a reputation for turning out great professionals and developers want to join their teams. The best team leads know that without investing in her team members’s skills all her delegated tasks will fail and the everything will eventually roll up to her, increasing her tasks at the end. So mentor your team, teach them what you know and then start delegating task with the assurance that they have the ability to do those tasks. A recent HBR post does a good job at explaining this well: How to stop delegating and start teaching.

3. Communicate clearly

   Communicating clearly the exact things that need to be done is extremely important. This is where the best team leads shine. The team lead has to interpret, break down and decide what needs to be done. It is the team lead’s job to then clearly communicate those task to her team. If done well, the amount of to and fro in understanding and clarifying the tasks reduces to almost zero saving time and increasing efficiency of the team. So setup good process for communications, use tools that help and setup standards. For example, an issue management tool like Jira can make a huge difference to a team performance if used properly. Putting up stories, breaking them down to features, tasks and grouping them to milestones is investment that will more than pay itself down the line in saved time in communications and mistake free implementation.

4. Avoid micro-management

   Good team leads learn to trust their team. Trusting team members means you don’t have to micro manage. Micro management is one the biggest mistake that a team lead can make. It wastes everyone’s time and destroys morale and confidence. Team members start feeling undervalued, and worst of all they start feeling less responsible as expressions like “the boss will change this anyway” or “the lead will help me finish this code” start floating around. Your team will become more dependent on you as you micro manage and you’ll find that over time you spending more and more time doing micro management rather than useful work. Avoid at all costs.

5. Stay on top of technology

   Big one for technology leads. Software teams have an inbuilt hierarchy - a pecking order - based on technical ability. Respect within the team is handed out based on this pecking order. As a team lead you need to be on top of that pecking order and the only real way of doing that is to keep up with the technology. It’s hard, given all the pressure of managing teams and managing customers but if you don’t keep up you’ll eventually lose the respect of the team. Even just reading a few articles and discussing with the team about what they are using can help in this regard. Another tried and tested way is go setup a tech seminar system within the team where team members share their knowledge - it helps you learn things quickly and also helps the team improve their skills.

6. Take some dev tasks

   This may sound counter intuitive for large dev teams. Team leads in larger teams tend not to take any dev tasks themselves simply because they just don’t have enough time. Yet taking on some task, even very small ones are of immense value for team lead. On the surface level it shows that the team lead is “one of us” to the developers, but more importantly it gives the team lead an idea about what’s going on at low level which she may miss out completely if all she does is high level architecture or team management.

7. Learn to say “NO”

   Last but not least - learn to say no. At the end there will always be too many tasks being thrown towards a team lead. A good team lead has to prioritize tasks and figure out what tasks can be done at a later stage or not at all. Coming out and saying no is an essential skill that enables a team lead to manage this process. Say no to task that has no immediate value to the project in hand, say no to non essential tasks the management sometimes send your way a classic example is the performance review in the middle of a dev cycle. Avoiding non essential tasks will lead to a better project, better delivery and at the end a better result for the company.

   Oh this one was way longer than I planned (see always plan first :) ), OK here’s a Dilbert strip that works great with the theme. Happy team leading everyone!

How to reduce the cost of making a software?

As a custom software development company a common question we get asked is about reducing the cost of development. Software development is expensive. Even using relatively lower cost countries such as Bangladesh or Cambodia, a startup owner is likely to spend the largest portions of her funds on making the software. Yet software is only a piece of the story and usually the one of the first ones, huge costs waits for her in marketing and sales that she has to budget for. Hence cost optimization and reduction is an important strategy for the software development, and if done right can be a deciding factor for the success of the startup.

Here are some strategies we suggest to startups (and even established and large companies) to manage, optimize and reduce their software development costs:

Use an outside development company

Salary cost, particularly development salary cost takes up the largest regular cost of a company. An in house software team is invaluable, there is no question about it but when budgeting becomes tight, using an outside development team that can be dialed up and dialed down on short notice is the single best move a company can take. This gives them immense flexibility to adjust and control the cost on a regular basis and defer the risk of financial commitment of an in house dev team (which I think is essential once the software and business is established).

Source: Inc article

The graphic here shows the social sharing and marketing company Buffer’s average monthly costs. Thanks to Buffer’s open book policy this information is available for a live 7+ million dollar annual revenue company and will give a rough picture of how the costs are laid out. As expected about 69% of cost is spent on salary (for 64 employees when this data was taken).

In case of this example, the company has already produced its flagship product. The initial time when the product was being built would incur a much larger cost. For many software projects and startups this initial injection of fund can a big problem or might lead little or no funds for the marketing effort that will follow the launch of the product.

Finding good software development vendor and utilizing that vendor in an optimal way can give startups a huge edge over its competition yet keep the overall flexibility in its business operations.

Advancing the project tasks by non developers

Many software project tasks can be done in house by the founders or members of the existing team. Getting these tasks done would mean that the total effort by the software development team (in house or outside vendor) would be reduced. This leads to higher productivity for the team and obviously less cost per feature.

A great example of project tasks that can be done by a founder herself (or non developers in the team) is the creation of initial product ideas and wire frames. Sometimes founders approach dev teams just a list of ideas say in an email, this means the development or product team has to work to turn those into usable specification. This requirement analysis cycle can be quite prolonged if the founder or key stakeholder hasn’t fleshed out the ideas well and has to go through prolonged sessions involving members of the technical team or the outside vendor. The whole process can be fast forwarded and compressed if the founder can think through the ideas and use an easy to use mockup tool (our favorite is of course balsamiq ) draw out the ideas. The whole requirement process then gets cut down by as much as 80% in our experience.

Non development stakeholders and founders can also help out on many other areas of the software development process like testing, helping with documentation etc. All of these add up to create substantial reduction of costs for making the software.

Keeping the requirements stable

One of the biggest way of increasing cost of a software project is feature creep or constantly changing requirements. When a software development team has a clear specification it can plan and implement the features at a very fast pace. But as soon as those initial specifications start changing or new features start creeping in (because “business demands it”) the cost of rework and changed priorities will also pile up. Over time this single cause lead to cost increases by 100-200% if not controlled in our experience. So this is a single big area to be concerned about and control to keep the cost of software development under control.

Multi-tasking is a crime (at least in software projects!)

Fact of life: More often than not a software team will have more work than they can juggle. What can a team lead do to get things done in the most efficient way?

Coming from a logical point of view she has the following algorithm:

1. Prioritize things and get the high priority things done first (of course! We have a no brainer here).

2. Given the prioritized list of task from #1 she can get her team members to

   a) do one feature at a time

   or

   b) ask them to multi-task as in work on several features at the same time, switching between them.

The real debate is:

Is multi-tasking better than single tasking?

Multi tasking has been hailed as great solution to modern life’s challenges. Books, articles and research papers have been written showing it’s benefits for efficiency and performance. A little googling will lead you to articles such as this one aimed a entrepreneurs: Why multitasking has become the need of the hour? As you go through these you realize that it may indeed be a good thing and may solve your every day challenge of get different features of a software made (because you need to show different stakeholders different parts) in parallel.

However, in the world of software development there is a strong indication that multi-tasking is harmful. Let me quickly define multi tasking in this context - it is the act of getting the same resource (or a group of resources say a small team) to work on one part of the software and then move to another part within short intervals (hours, days but maybe not weeks). The effect of this kind of multi tasking is context switching - getting the developer(s) to load up one set of code, logic and idea in her brain and then after a while asking her to forget that and load up a completely different set. There is absolutely no question about this, context switching is bad for a software team’s performance.

Source: The Multitasking myth

In the book Quality Software Management: Systems Thinking, Gerald Weinberg writes how context switching affects performance. He showed that just like computers, humans often incur overhead when context switching between multiple parts of code or between multiple projects. He came up with a rule of thumb to calculate the overhead and showed that you lose 20% of your time by just adding one extra new context due to the overhead. And By the time you add a third project, nearly half your time is wasted in task switching.

If you think about it its quite obvious. When you are managing a software team, task switches take a long time. That’s because coding is the kind of task where you have to keep a lot of things in your head at once. The more things you remember at once, the more productive you are at coder. A programmer coding at full speed has in her head a huge amount of random yet useful bits of information that range from variable names, database tables where the variable will go, APIs that she will need to call next, the names of functions the team wrote in the library, the URL of the git directory, a stackoverflow article she read that uses a trick to solve the problem, the list goes on and on. The moment that programmer moves to a different task or worse a different project everything is lost and a complete new set has to take over - incurring that wasted time in the scheme of things.

So multi tasking makes a software team slow rather than fast. Your deliveries come later than sooner. So just like we can say with absolute certainty that cubicles are bad in a software company, we can say without a shadow of doubt that multi tasking is a crime in a software project. Here’s a good Dilbert for today…

4 Software team strategies that work

Flat hierarchy

It's important for the team to feel that they are not bogged down with management. We try to build this into the system by having very flat hierarchy in the teams. Usually a team a has a team lead and everyone reports to her. The team lead can decide pretty much everything as much as day to day operations of the team is concerned. This empowering of the teams help increase both our ingredients. Empowered teams feel more gelled because they feel their actions navigate the whole team and they feel more responsible for the whole group. Less hierarchy makes it easier for the team members to speak out and voice their concerns - increasing openness.

Small Teams

Lines of communications as the team size increases (source: Lines of COMMUNICATION)

Small group sizes are natural. If members of the team cannot know each other on a level where they consider each other friends the team’s ability to cooperate drops. The more people you have in a team the less a single team member contributes to the project - this was known as far back as 1913 when Maximilian Ringelmann discovered that the more people who pulled on a rope, the less effort each individual contributed. 

Smaller teams lead to more social cohesion, that leads to more individual responsibility and more productive work done per capita.

There is another strong reason for smaller teams: less time spent on communication. There’s a formula for this, the number of ways conversations can flow between person to person is:

n(n – 1) / 2
where n = the number of people in a team

So this builds up very fast as n becomes larger and larger. The graphic here shows this - things get messy quite fast. And the messier it is the more noise there is to get information across the team and thus more time spent in getting things done.

What’s the ideal team size?

It depends of course on the nature of the project. Jeff Bezos has the famous Two Pizza rule that goes - “If you can’t feed a team with two pizzas, it’s too large.” You’ll have to find out your own rule, but as long as you keep the team small you should win.

A great read when you are thinking about the optimal team size is: Productivity and Team Size: Less is More

Culture of openness

Software is all about discussions and debate. No single person, no matter how many years he has been “doing software” or how many fancy places she has worked in, will always have the correct plan. Yes experience helps but sometimes experience leads to “this is how I did it in 1997” type sentences that usually lead to badly designed software. The only way to solve this is to have discussions and debates (we call them “fights”) where everyone has a chance to voice their concerns. Now this only works if everyone has a say, or rather feels free voice their ideas. If the culture of openness is not there in a team, junior members of the team will always stay silent, or people with louder voice will always be the only people speaking. This gets you nowhere. So cultivate the culture of openness in the team. Take steps that make the team members feel free and relaxed. Our strategies are always to take them out of work environment say in a fun party or in one of trips or adventures and break the ice particularly between junior and senior members of team.

Culture of excellence

Cultivating a culture of excellence is very important for the performance of the team. This is why elite commando forces have “we are the best” motto. A culture of excellence builds a bond between team members that is commitment towards keeping the standard up. This is a basic tribal need of humans - we don’t want to let our tribe down. And when the tribe’s culture is being the best at what they do - that is what everyone strives to do. HBR had a great article about the culture of excellence in companies that’s a good read: Creating a purpose driven organization.

And here’s the customary stolen Dilbert…

Documents every successful software project needs

When you start developing a software product, you need an idea of what you want each component of the software to do. From the part 1 in this series on defining products 3 Questions to define a software product, you now know the essential questions you need to ask to define your product. Today I’ll be doing part 2 that goes over how you document the requirements.

Knowing why, what and how your software product will be isn’t the end of the line for the product managers. You need prepare the documents, lists of requirements, UX modelling, etc. to make your development process easier. These, seems like a long process but it also serves over time as well.

If you don’t have your requirements straightened out, then how can you complete your project. And not just you, your developers will often want to freeze their development process based on some initial works of the definition. Once that is cleared out then proceed with development. Some call it the classic waterfall paradigm. This doesn’t work in any situation.

So, what can you do, keeping in mind you are the middle man, your failure to capture the whole product will affect both your customers and your developers?

You create baseline documents of the product you are planning to build.

Baseline Documents

Baseline Documents are documentations of a product that is formally reviewed, revised and accepted in their current forms, to serve as a detailed definition of what needs to be built. A simpler form of explaining would be to say a “blueprint” of the software that you will be developing. These documents may include the following types of requirement specifications:

• Functional requirements

• Non-functional (technical) requirements

Functional requirements

Functional requirement documents help SPMs to understand the characteristics of the product we need to build for our customers. As these types of documentations process helps us to capture the business of the product that the customers are asking for. As SPMs, if your goal is to capture the “why” there is a need of this product you are building and the “what” you can do to solve those needs, then this documentation approach is “THE” way to start.

Sometimes, functional requirements are also referred as “Business requirements”. And definitely don’t forget to share this document with your customers, as they need to confirm that this is what they want you to build. This document will detail the business end of the software product as well as the “requirements”. The requirements take the form of lists and with the help of UX specialists, you can show the outline on how it will work.

Technical requirements

Technical requirement documents will help to understand the “how” that “what” will be build. Someone with technical perspectives, like a software developer, or engineer, or architect, will need to understand the “what” you want him/her to build. They often don’t want to understand the business criteria of the product. But with their help you will be able to create a step-by-step instruction of the product. This will help you to understand the timeline to build and test the product before you release or hand it over to your customer.

Techies will have discussions with regarding the requirements that you have outlined for them to work on and you will go back-and-forth with which requirements have higher priorities and which have lower priorities, in terms for release planning.

The SRS

You can store both of these requirement documentation in to a singular document called the Software Requirement Specification (SRS) documentation. This will be helpful for the whole project as you can outline the requirements in priorities, from higher to lower, for the release plans. Developers will also be benefited from this document as it contains all.

Additionally, SRS documents can may also include several other software, hardware, stakeholders and interface requirement specification to fully define the baseline’s component. The goal is to provide customers and the developers with a clear understanding of exactly what is intended to go into the upcoming releases. This practice of storing requirements in a solution allows you to maintain an aggregated set of both present and future release commitments.

I’ll finish with WC’s tradition today of stealing and posting a Dilbert strip without feeling any sense of moral turpitude!

3 Questions to define a software product

Imagine you are in charge of creating a clear specification for a new software product. On one side you have your customer - a a high energy, super smart non-techie who flies off in tangents in every discussion yet has the most amazing business idea that needs a web and mobile app. On your other side you have software developers who want a precise software definition that goes over the nitty gritty of what the software needs to do.

What do you do?

Let me go over how we do this with our 3 question approach. This is part 1 in my series on defining software.

Back to the your problem:

How to define a software product?

Every software product we see on the market started from an idea. The idea came from the need. The need presented itself when there is a lacking of carrying out tasks.

This is where the software product management - SPM shines. Understanding the “needs” is the primary goal for any product manager. We use software solutions every day without understanding the true value of it. Mostly because we have it already. There was a time we didn’t have the most basic solution known to mankind, Emails. We can’t imagine that time when it took up to months to send a message, or “mail”, to another person living in a distance.

Then someone asked the question “why?”, the first step to designing a great solution is born with a word. Questioning the limits and vulnerability of the existing solutions. Once it was determined that the existing mail communication is ineffective, the new idea is born.

Then they asked the question “what?”, which is the second most important step to designing any solution. Now knowing the issues with the existing solution, questioning what can be done to improve it will give them more ways to think to replace the existing solution, or system, of communication.

Once they figured out what needed to be done, they asked the question “how?” they can replace the system. The final question to designing any solution, looking for the answers on how to replace the system gave them the access to the tools those were need to create the new solution.

The “why” the “what” and the “how”, the three fundamental questions to defining any products, or solutions. Understanding this paradigm can help any product managers gain confidence for defining products. Product managers’ lives becomes very easy when they understand the answers for these questions. To define a product that you are building, you must go through these questions in step-by-step process.

Understanding the “Why?”

First, the “why” will help you to understand the actual need of the software you are trying to build, for your customers.

The key to understand a product that you are defining, designing and developing, is to understand the need for that product. Without a clear statement of the need if you jump in to the “how” based on some rough ideas on the “why”, it will often result in a product with that don’t address the stakeholders’ requests (no matter how good they look and function well). Most of the time product managers can assume what the customers/stakeholders are talking about when they mention their need but to master it you must start with diving in to details at the beginning of your conversation with them. Ask them why do they need this software/solution, why don’t their current system/process isn’t working, how do they want to their current system/process to function, etc. once you gather the initial needs of your customer, document them to understand their lacking. Investigate the system that they are currently using. Research the answers that you might think is valuable to them and easier for you to design.

The ”why” often usually helps to describe the vision of the product.

OK, the comic strip on the right is just a joke but a really good one, the why should always be aimed at the end user not company that’s profiting from the software!

Awesome “Why?” joke thanks to rstevens

Planning for the “What?”

The next step is to find out “what” can you do to provide a solution (or a product as a solution) for customers to overcome their difficulties. A very good practice is to investigate the process on the Internet and see how many have solved this need. It always helps to learn from your competitors. One bad practice is to jump to the development phase. In this way you may not know for sure, that the solution you have provided to your customers will serve them longer, or they can get any value out of using it, with the tools and technology you used to build the product for the customers. You must be able to plan more than one solution for a single need and try to understand the flaws in them. You can also use the help of UX and other interaction professionals to develop mockups or wireframes to show how concept of the product you need to build.

The “what’ part of the process helps you to capture the requirements, feature specification and milestones.

Deciding the “How”

Now that you know why and what you are doing, you can now jump to code. The third step gets easier when you have finalized what you will be building and why. Now comes the challenge on “how” to build what you have defined. With all the materials, such as business requirements, feature requirements, UX, models, your life becomes more easier to decide on the technology you will be using and design milestones in building the product you defined. This part is where you can race to code to build the product that your customers desire. Developers and architects should be given the freedom to make decisions regarding the implementation process.

In another way of saying, the “how” helps “what” is required to be built.

Concluding

To put a product on the (hypothetical) shelf, product managers have to be very precise in what they define as their product, both for the customers and the engineers. Using the “why”, “what” and “how” approach will help you to achieve that more efficiently and precisely.

Software without anger: managing yourself

After our first two articles ( Software without anger: managing the development team and Software without anger: managing vendor relationship ) in this series of anger management in software projects we got a lot of feedback asking us about how to manage anger on a personal level. What can we, as software professionals, do to reduce anger in software project? Be it within the team, with stakeholders and even with ourselves ( this last one becomes obvious when you think about how many times you’ve wanted to bang your head on the table when you realized that you should’ve written that generalized class to validate the data before an insert or something along those lines… ).

So today’s article is about us. Us the software professionals (ahem).

We know we can do a lot (and we should’ve done a lot) to make software projects anger and stress free. Maybe we have our own list of those to-dos. Here’s our attempt at that list…

1. Expect and accept anger as normal in software development.

This one is the same for all of the articles... Since the situation is the same, so I’ll do another ctrl+C and ctrl+V from the first article:

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

It is the sudden rush of anger that you don’t expect in the otherwise calm and civil workplace (well for some I hear) that makes us go off balance. Instead of managing it we fumble and make it worse by being irrational and in many a case damage our relationships with others in the team and damage the chances of success in a software project.

The moment you expect anger as a natural outcome, you’ll be able to address it with strategies you know that work for you in other circumstances in your life. The particular strategy that works is very personal. Some people just takes a deep breath, someone I know takes a toilet break! For me the best thing is to stop saying whatever I was saying for a minute or so.

But expecting anger as a natural expected “artifact” doesn’t only mean that you can snuff it out when it comes. It also means that you can take steps to make sure situations that create anger do not happen, I discuss some such ideas below. And apart from snuffing it out, or avoiding it completely, anger can be channeled for the good of the project too! Anger is in essence passion and there is always a good use of passion in software projects! Good project managers us this passion all the time in situations like brainstorming or technical architecture discussions.

2. Prioritize, prioritize and prioritize

This is probably the most important single step you can do on a personal level to manage anger in your software project. There will always be way too many tasks coming towards you and there will always be a looming deadline that’s just too close for comfort. The only way to reduce stress (your own and the team’s when others are waiting for your work for theirs to be done) is to know what tasks are the most important.

Prioritize your tasks. Discuss them with your tech lead or manager. Discuss them in your daily stand-up. Scream (ok, maybe not scream in anger, that would defeat things ) if you feel you’ve been told to do something that you feel should not be high priority. Setting the priority of you tasks should be your highest priority :)

3. Read the spec!

OK, I probably mean understand what you are supposed to do in a task before jumping in to code it or test it. This might mean just reading the task ticket, or watching a video that explains things. But investing a little time to understand the task properly saves a lot of your time later on. It sounds very obvious, but I think we all know that we can be drifting with the flow on a lot cases and just jumping in to the code feels a lot easier sometimes rather than talk to a product manager about something that’s confusing. But that is a recipe for a heated conversation somewhere down the line. Not worth it.

4. Keep an open mind

Nothing in our field is set in stone. No technology is the final word and nothing is perfect. And today’s greatest stack will be the trash of tomorrow. That’s how our space is like, we knew it when we got into this. So there is absolutely no reason at all to be a staunch supporter of a technique, stack, idea, “pattern”, DB, __ (fill in the blanks). If you keep reminding yourself this fact then keeping an open mind is easy, and then discussions and debates about technology becomes finding out good solution for the problem at hand with the currently available skills and technology - rather than a religious war that these discussions sometimes warp into :)

5. Remember that there is always a next version

There will always be scope in your work. You will never be able to finish all the things you wanted to do. Scope your work, do what’s needed now and plan the rest for the next iteration. This helps move the project forward, keeps your boss and your teammates happy and you out of anger.

I’ll keep to the pattern of this series of articles by using a 3 stooges picture. This just one of them.

Software without anger: managing the development team

Isn’t that a great title for an article about software development? If you’ve ever been involved in a software development project this would ring bells!

This was the starting in the first article on this series - Software without anger: managing vendor relationship which goes over the distilled wisdom of 15 years or so that we’ve been around in this business of making software for our customers. That was all about how to manage the relationship with the software team that’s outside your company, say for an outsourced project, or for a team of yours that works offsite away from regular face to face interactions. Today’s blog is about managing your in-house team of software developers, designers and QA professionals. I can never decide if it’s easier if the team is in-house, but I think an entrepreneur is just faced with a different set of problems which require a different set of solutions. So here goes…as promised - a list of - “distilled wisdom” :)

1. Expect and accept anger as normal in software development.

Umm, this the same as with the vendor relationship. Since the situation is the same, so I’ll do the infamous ctrl+C and ctrl+V

In any endeavor where there is a lot of unknowns and yet the risks and cost of getting things wrong are big, anger is natural. Anger is actually sometimes a good sign in software projects - it shows people involved in the process are emotionally attached to what they are doing and they care enough to voice things out. It is the negative aspects of anger like the blame game, shutting off channels of communications, creating bias, etc. that are destructive, that you have to be worried about. If you expect and accept the fact that there will be anger, you can take steps to reduce it, manage it or channel its energy to a creative force.

The only thing to add to this for an in-house team is, since you see the anger first hand, as it starts to pick up steam you have to move quickly. You should never leave a conversation that started moving to anger without diffusing it in the direction of a creative conversation. Striking while the iron is hot is the name of the game for this.

2. Create a culture of celebrating a dissenting voice

A dissenting voice is a voice that checks assumptions, tests logic and make the overall process stronger. It is almost always good for a software development process. The only time you don’t want a good “fight” in software discussions is when ego is getting involved and the discussion becomes a war of words rather than a debate based on logic. So you should make it easier for people to voice their concerns, actually make it welcome and celebrated. That way people will speak out, and feel that it is accepted and is part of the healthy brainstorming that goes on in a team all the time. Taking the taboo out of the dissent makes it feel like professional skill and somehow takes away the purely negative “anger” component out from a discussion where two sides have opposing view.

It’s a delicate balance, but once you create that culture life becomes so much better and your software too!

3. Have a clear and readily available set of requirements at all times

When I say requirements, I don’t exactly mean like spec documents or a bunch of mock-ups. I mean at any point of time the team should have access to resources that make it crystal clear what they are supposed to be making at that point in time. So, to do that you’ll probably need a task management system (e.g. a Jira board), a set of mock-ups that have been scoped and discussed for the task in hand, a meeting or two beforehand that clearly goes over what you are trying to build over next few days/weeks, etc.

As soon as the team knows exactly what they should be making you’ll find that the destructive anger that comes from confusion and that always leads to a blame game goes away. That’s the type of anger you can never manage and resolve easily. Take that out and half of your job is done in anger management in a software project!

4. Always have a confident “supreme court” for final decisions

That’s probably the team lead or the founder or even the designer. It’s not very important who it is as long as there is only one at all time, whose decisions, people know, cannot be overturned and obviously someone who is just (most of the times).

Most tech debates (aka anger) have multiple possible resolutions. Usually more than one of the solutions being debated works great as long as everyone accepts it. But tech debates comes with people who are married to their ideas (“I’ve got a unique solution that no one has thought of”), philosophies (“Java is the best”), past (“It worked for the last project”) and the worst - latest fads (“micro-services is the future”). Many times the only way out of a prolonged discussion, that starts to loop over the same few arguments, is a judge making a call and putting an end to the debate. Not easy to find a judge who can instill that confidence but it’s not impossible.

5. A gelled team is the only way out

At the end, nothing is better than a team that trusts each other, considers each other as friends and are happy to work with each other - a gelled team. Just as in a family or a group of friends high emotions and anger fizzle out because of the strength of their relationships, a gelled team can absorb and diffuse any anger. We have written extensively about gelled teams. This is our big mantra, our grand unified theory, our secret sauce at Kaz Software. This is what makes us good at what we do over and over. Read some of our past blogs for some idea, Two ingredient recipe for a great software team or 5 Easy steps to kill the deadly PDI in your software team or Burn the cubicles - in the pursuit of happiness or the ever so famous Barbecued dog is good for software :)

Since I have the 3 stooges always fighting in this series, let me end with one where they are a happy gelled team which they actually are.