Operational issues are one of the most complex moments in every business. If your business involves various processes and groups of professionals, applications can deal with the main issues.
How do you define what tools does your team need? Collect communication use-cases that the team utilizes at the time, then analyze current processes and company needs, and think what needs may be present in the future.
The success of any project in many ways depends on the team. Even a small product is mostly designed by a team, even if that team consists of just two people. Building an effective team is very important and, at first glance, this looks like a much simpler task than it really is.
Each member of the team has his own opinion and vision about the project, its development, evolution, and other processes. It is necessary to organize everything in such a way that all these factors will be in harmony with each other, and specialists’ joint efforts will be focused on achieving the customer’s specific business objectives. Therefore, this must be taken into account when starting a project.
On the surface of it, the idea of an internal superhero seems like a great notion for any business. At one time or another, we’ve all found ourselves pulling our hair out while our co-workers flap around like headless chickens, as we try in vain to save a project that has gone wildly off the rails. In those situations, many of us find ourselves wishing and praying for someone, anyone, to step in and save the day. Someone who understands the workflow and systems inside-out, and who is able to pull off those seemingly miraculous feats of software engineering even when time constraints are at their tightest. Someone you can turn to in a bind and know that they will be able to fix any issue.
These individuals, who we often mistakenly view as being the jewels in a crown when it comes to software development teams, can be an absolute godsend in an emergency. The problem is, we all too often start to view the internal superhero not just as someone to be called upon in times of crisis, but as the only person we can call on. This level of responsibility on one person’s shoulders does not establish a sustainable way of working.
This is the first post of my blog post series about the five phases of a Scrum Retrospective. I will cover the most crucial ideas for Phase 1: Setting the Stage.
These five phases are presented in the book, Agile Retrospectives – Making Good Teams Great by Esther Derby and Diana Larsen. They are:
Over the past year, I had the chance to be quite close to a significant project in terms of scope and team size. All in all, over 100 people were involved, with more than 60 working full time on the project.
Out of those 60 people, over 40 were involved in engineering, while the others worked as the Technical & Solution Architects, Business Analysis, User Experience Engineers, and Project Managers. Out of the 40 engineers, over 60% of the team was involved in mobile and frontend implementations while the rest were focused on backend and QA automation.
The methodology selected for the project was Agile, more specifically Scrum. Multiple teams have been assembled with Scrum of Scrums high-level sync between teams. Everything looked good and ready.
Fast forward six months, the progress looked good compared to projects similar in terms of scope and team size, well above average. Still, there were things that could’ve gone better at all levels.
Looking past the inherent challenges of the newly formed team and the time to find its own rhythm, the communication process within large organizations, the delays from integration with dozens of external systems and the typical overhead when managing a large team, here are some of the things we’ve learned, that anyone should be aware of when dealing with a similar situation:
A Scrum recap before project kickoff–while the vast majority of the team members were familiar with Scrum, each had some variations in understanding the process based on personal experience. Aligning team members as well as key stakeholders before the meeting might be a useful practice before kicking off any project, regardless of its size.
While there are millions of articles on how to implement Agile within a team, the topic of what should stakeholders / top managers expect from Agile probably still needs more exposure. While it is usually part of the digital transformation programs or part of the whole process of making an organization Agile, setting up expectations through a very specific alignment session, can help a lot along the way: “Here what it means for you, how you will interact with the product development, how it can affect deadlines, etc.”
Agreeing on a Definition of Done is fundamental to successful agile. What happens, however, if the live environment is gonna be ready in 5 months? Over the course of 5 months, no user story will respect DoD, and the product owner’s perception is basically that nothing is actually done.
Adopting and adapting an intermediary DoD, valid for a certain phase of the product is key to setting the right expectations. Ideally, any project should have all its environments ready before project kickoff. The reality is different and it’s not just about the typical multi-stage deployment of one solution, but also the various stages of other external systems. Within this particular case, a critical external system hasn’t had its staging (or live) environments ready for over more than 5 months since development kickoff.
When dealing with dozens of good engineers, project governance should also include a way to address the typical healthy technical tensions that can come up in time. Setting up a technical escalation point per technology from the beginning is critical in preventing the potential delays from various team dynamics. Technical leaders for mobile (iOS and/or Android), frontend, or backend should smoothen things as the project progresses.
A lot of time is spent integrating with external systems. As specifications become more and more clear, API changes make team members go back and forth, and can be a headache for both the team and the agile coach. A good architectural choice is to use an SPA framework that would allow mobile and desktop versions of an application to consume the same API implementation from the backend team.
In such a case, backend and frontend (be it mobile or desktop) can often be regarded as two different systems integrating through an API. While for this project the initial choice of cross-functional teams with 1-2 Backend engineers, 1-2 iOS, 1-2 Android, 1-2 desktop-frontend seemed like a good one given the flow of the input from the Business Analysis team, as the project progressed it became clear that the delays were mostly from the back and forth communication between frontend/mobile, backend and business analysis team.
One way to optimize this is through better planning in the backlog grooming meetings, trying to get the team to agree on API signatures as early as possible.
A second way is to try and have the backend move one sprint faster than the frontend/mobile teams since, as in most cases, there are still issues when doing the actual implementation that a grooming/planning session cannot foresee. Hence, the system cross-functional teams moniker. While three engineers (one iOS, one Android, and one frontend) could work on the same functionality, having the API agreed and preferably ready before the sprint starts can drastically improve the overall team efficiency.
“Any tool that has attempted to be ‘everything for everyone’ has failed miserably.” — Dr. Mik Kersten, CEO and founder, Tasktop
In the fable “The Man and The Wooden God,” the protagonist spends most of their life praying to a wooden idol for wealth and fortune to no avail. One day, in a fit of rage, they smash the idol on the floor and an immense number of coins spill out. The moral of the story? There’s a few: that you should beware false gods, that faith alone won’t bring you success, and that sometimes it’s up to you to get things moving.
Which brings us to the “One Tool Fallacy”: organizations continue to be led astray by the misguided notion that all stages of the software delivery value stream, from ideation to production, can still be successfully migrated into one system, despite no evidence to support this theory.
First, we overloaded very promising tools like Rational Team Concert (RTC) by adding every feature for every stakeholder and process. Now some organizations are trying to do the same with Jira; a reaction to the growing complexity and feature set. We keep making false gods.
Having “one tool to rule them all” is naturally appealing in terms of perceived simplicity and cost benefits. The idea, however, is inherently flawed. History speaks for itself; any tool that has attempted to be “everything for everyone” has failed miserably. There’s just too many nuances within the different workflows across the various specialty teams that plan, build and deliver software at scale.
When you plug too much workflow into Jira (or any one tool), you will inevitably flood the tool and hit a wall, undoing all the productivity achievements that Jira and other leading development and delivery tools have brought to the software delivery process
The key, then, is to find where that wall is, helping you to leverage Jira to the best of its abilities, and ensure the tool becomes an effective development hub within your software value stream.
Download our new white paper to better understand why the “One Tool Fallacy” is dead, and why you need to embrace an integrated best-of-breed toolchain to optimize the value of Jira and all the other tools you use to deliver the right software products faster.
Let’s face it…there are periodically going to be those unfortunate instances when you absolutely must bring on one or more new resources in mid-project.
It may be to replace an outgoing resource. It may be to get the team caught up to meet an important deadline or deliverable date. It may be to help fix a current issue that is stalling the project. Or it may be just to cover some new work that has been identified on the project including the need for a previously unnecessary area of expertise.
For whatever reason, this need to bring on one or more new resources in mid-project happens. And we say “unfortunately” because bringing on new resources in mid-project causes a longer learning curve and adds considerable expenses to the project – especially if the new resource’s efforts are not covered by a change order.
When on-loading project resources in mid-project for various reasons, the project manager must still consider what to do with that resource long term. It’s not always an option to take on a resource and then just offload them quickly when the need is over. Resources and their department managers — if you’re working in a matrix-type organization — still have resource utilization targets to worry about. So that is yet another angle the project manager must consider when bringing on new resources to the project in mid-stream beyond just learning curve, cost, and customer satisfaction.
Overall…is it necessary and is it worth it?
The best consideration is to determine what the new resource can and will bring to the table and in what ways may they be utilized.
Does the resource possess the right skills for the task? You want to make sure that the resource gatekeeper – whoever that may be in the organization – gave you someone useful for the tasks or issues at hand and not just “what’s available” at the moment. Every project manager had that happen… and it can lead to unnecessary costs, time wasted, and grave customer concerns over the competency of the delivery organization.
Is the resource overkill for what you need? You don’t want to go that route either as you may be bringing on a more expensive resource than is necessary. No need to bring on a shotgun when you just need a BB gun to scare away the issue. You may increase your burn rate on the remaining financial resources on the project causing serious budgetary concerns.
Will this person look like the right fight to the project client? This is a bit of an overlap of the first two considerations, but let’s looks at it entirely from the customer’s viewpoint. When they are introduced to this person and begin to interact with the resource, will they still think you are managing the project and the issue at hand well or will they have delivery concerns?
Finally, will the new project resource be a good team fit? Sometimes you get what you get. And sometimes you can’t be too picky… you need the coverage now and you may just have to roll up your project management sleeves and make the round peg fit into the square hole. But if you have the opportunity to make the call, make a resource acceptance decision in the best interest of your project team and client. An abrasive resource may make matters worse. Be careful.
What are you looking for? That’s sort of the bottom line here. Are you looking for the best tech skills? Are you looking for just one skill? Are you looking for a leader? A follower? Obviously, a good personality fit is a nice consideration as well.
Different skill sets and different availabilities will probably cost the project different amounts of money and will probably require less or more project management time from you. It’s not just about acquiring a warm body to fill a team spot.
Businesses working with remote teams are becoming increasingly common. For instance, your company headquarters may be in Sofia while you have remote workers in London, Dublin, and Istanbul. Bringing in remote employees raises several workplace issues which you will need to address. These include:
How do you build trust and communicate effectively?
How can you manage a team which operates in different time zones and multiple countries?
How do team members stay in touch with each other?
How do you develop an effective work routine for the team?
While most employers are aware of these issues, they nonetheless have a hard time getting great work out of their remote teams. We have developed a five-point guide which provides you with simple strategies to help maximize the potential of your remote teams.
This first point is a no-brainer. Having regular touch points with your remote workers is equivalent to having workplace meetings with your local employees; the only difference is the mode of communication. To make sure that there is no communication gap between you, your workplace employees, and your remote team members, you need to do the following:
Maintain a schedule of team meetings, using tools such as Skype or GoToMeeting.
Make sure that your workplace employees also use these same apps so that remote
workers don’t feel excluded.
Always set deadlines for replying to communications, so that remote workers feel
an obligation to the organization.
Set up a chat room or a group, e.g. in WhatsApp.
Choose the appropriate form of communication for a particular task. For example,
use email for official work, Skype for meetings, and instant messaging apps for quick
Encourage both your workplace employees and your remote team members to
communicate with each other. To help with this, you can distribute tasks in such a
way that different groups of employees will need to talk to each other to complete a
It is your responsibility, as manager, to set expectations with your team members, whether they are local or remote. This will help you hold your employees accountable for the work they do. You will also need to regularly check in with your remote workforce, just as you would with employees in the workplace. Take care to ensure remote team members feel that there is a level playing field: all procedures and the criteria for success should be the same for everyone, regardless of where they work. This way, no one will feel like a second-class employee or become discouraged.
To make sure everything runs smoothly, you should lay out some basic ground rules. We at Dreamix, being an Angular software development company, use the following rules:
Set time limits for replying to an email.
Make online meeting and video conference call attendance compulsory.
Set clear deadlines and agree upon the scope of work to be completed.
Establish appropriate modes of communication.
Establish workplace points of contact for remote team members.
Depending on the specific needs of your business, you may find you need to develop additional rules and responsibilities.
It is key to make sure that you don’t impose your work habits on your remote team members. Once you have established the tasks, deadlines, and your expectations, allow your team members the freedom to complete the work as they see fit.
As you are managing a remote team, it is imperative for you to choose good platforms for scheduling, task management, time tracking, etc. For example:
Desktop apps such as Time Doctor to track the work done by your remote team
Staying in touch with remote team members takes effort. It can even be hard to know what to talk about! Think about the sorts of conversations you have with your workplace employees: you need to have the same kinds of conversations and develop the same kinds of relationships with your remote employees. The only difference should be in the mode of communication.
A situation could arise where workplace employees and remote employees feel themselves being pitted against one another. It is vital for you to take care of the language you use when talking to remote employees. Don’t dwell on what separates your employees or how they are different. Instead, focus on the common goals which unite you, e.g. organizational growth. You may also find that a remote team member feels underappreciated. Always take care to acknowledge work completed. Remember that recognizing one individual’s achievements with the whole team goes a long way.
Let’s return to the example we began this article with: a manager in Sofia working with team members in Istanbul, Dublin, and London.
This manager should take the time to talk to his or her remote workers. For example, things are very different in each of those cities. By talking with team members, it is possible to learn a great deal about the business culture, market structure, and ways of thinking for each country. What does this achieve? Not only does it give valuable insights into different markets, but it also helps the manager understand what motivates the employee and gives insight into his or her thought process. It is also a great topic of conversation and can help build rapport between manager and employee.
In conclusion, keep these five things in mind when managing a remote team:
Public recognition and motivation.
Becoming familiar with each employee’s working habits.
Please get in touch if you have any questions or would like to learn more about how we
manage our remote teams.