Being an Agile team is all about adopting the Agile frameworks to the core – both in project management and team collaboration. It is all about efficiency and effectiveness, which means adopting methods to optimize resources, make the most out of teamwork and, especially, mitigate or avoid loss of time and costs.
But whether you adopt Scrum, Kanban, XP or any Agile framework, in the end, it all depends on the teams involved, the leaders managing the project and the customers at the receiving end. In order to make any project successful, the foremost thing you need is a competitive, skilled human resource.
Regardless of our feelings about it, the fact is that distributed teams have become an integral part of the software development ecosystem, with more and more companies and projects including team members dispersed around the world.
The reason for this range from cost-effectiveness, through access to better talent to the proliferation of new technologies and solutions that enable such teams to work in unison.
When I teach any sort of product/project/portfolio management, I ask, “Who believes multitasking works?” Always, at least several managers raise their hands. They believe multitasking works because they multitask all the time. Why? Because the managers have short work-time and long decision-wait time.
If you are a manager, your time for any given decision probably looks like this:
The work-time is short. The manager might have to gather some data and make an initial decision. Too many managers can’t make the final decision — they need to collaborate with others. That means they wait for the next decision state, often a meeting.
My experience is that many managers prepare for those meetings in advance. They gather the data, make their initial decision and then wait for the meeting. The meeting might not take much time. However, if the managers need more data, the managers have to collect more data and wait for the next meeting.
The managers spend less work-time and much more on wait-time.
Contrast that activity with a well-functioning team (Agile or not). That team will spend most of their time working, not waiting. I use swarming as an example because teams don’t have to be Agile to swarm. Here’s a value stream for an Agile team that tends to swarm:
Technical people — especially those who work as part of an Agile team — need time to think and focus. The more they work as a team, the less “wait-for-decision” time they need. They are all right there. They can decide without any waiting time.
When the decision wait-time dwarfs the actual work time, people stop work on this thing and move to that thing: multitasking. Throughput decreases.
When the work-time dwarfs the decision-wait time, people finish one thing and move to another. Their throughput increases.
Is your decision-wait time too long?
Technical teams, regardless of their project approach, need focus time to minimize their decision-wait time. If your decision-wait time is longer than you want, you might not have the people on the team or the information you need.
And, if you’re a manager, you might have the same problem.
Just because managers multitask all the time does not mean multitasking is the best way to finish the work.
You know the drill. Your manager or someone higher up says “We are all one Team,” but something doesn’t quite sit right with you.
You may be all one team, but no one works together. Everyone is working on their own thing. They are working on tasks that are not related to what you are doing. Your task isn’t related to what they are doing. There is no coordination. No discussion, just work. Are you really on a team?
The most likely answer to this question is “No.” You are not on a team. Despite what your manager says or his manager or anyone higher up. You are not working in a team.
Businesses like to group people into teams, and rightly so. Teams are powerful entities. Teams helped put men on the moon. Managers know this, they are not stupid, but due to decades of misinterpretation, culture, and misunderstanding, the real concept of “team” has been lost.
So, what are you if you are not a team? Quite simply put, you are in a workgroup.
Isn’t a workgroup a group of people working together? Isn’t a team a group of people working together? Aren’t they the same thing?
Well, not quite. All Teams are Workgroups, but not all Workgroups are Teams.
Well, to put it another way, there are some fundamental differences between workgroups and teams. According to Jon Katzenbach and Douglas Smith in their HBR paper “The Discipline of Teams,” there are some differences.
Let’s go through these one by one.
With a Workgroup, you basically have your head of the group who is in charge. This is someone who directs those under him or her what to do. They are in this position all the time. Everyone underneath obeys, at least in the extreme case.
In a shared leadership role, everyone collaborates. Sometimes one person directs, sometimes another person. The person most appropriate—the person with the “expertise” at the time—is in charge. Sometimes there is no one with expertise and discussion ensures. Sometimes the “team” as a whole decides.
Either way, everyone has a say.
With a workgroup, you are pretty much on your own with the task you are working on. If you mess up, you are to blame. If you succeed, you get the benefit. Achievements and failures are your own.
With a Team, you are accountable for the work you are currently doing, but the team is there to support you. Failure means that the team as a whole has failed, not the individual. It is the team’s responsibility to help those in trouble. If there is success, it is the team as a whole that succeeds. Not an individual. Think of a team sport. It is not the individual that won or lost, it is the team. The whole team.
With a workgroup, the group’s purpose is the same as the organizational purpose. In other words, there is no purpose other than the default one or the organization. The group itself just is there to work.
With a Team, the whole point is to accomplish a goal. A goal that the whole team has agreed upon. It is specific to the work the members are currently doing. The best purposes are the ones greater than the team. One that if the members all work together, have a hope of achieving as opposed to one for each individual.
In work groups, everyone is working on their own. One member is working on project A, another member is working on Project B and so forth. Each is on their own.
In a Team, everyone is working towards the same goal. So, everyone is working on Project A. Everyone is working on Project B. How they accomplish that is decided by the team.
For Workgroups, meetings are efficient. This may seem like a good thing, and it can be. But the reason meetings are efficient is that the leader dictates the meeting. Knowledge flows from the leader down. Very rarely does it flow up. Even when it does, the leader still makes the decision. This is not necessarily a bad thing. It can be quite good.
With Teams, problems are discussed. The team as a whole works out the solution through consensus. Each person has an opportunity to speak and be heard. Knowledge is disseminated from all individuals to all other individuals. This also gives the team as a whole ownership.
I’m reminded of the meeting Waigaya where some meetings are discussed this way. A Waigaya is a meeting where every member leaves their title at the door. No hierarchy; in fact, it is forbidden and frowned upon if someone does use their title. Everyone has equal say. Important points are discussed until a mutual solution by all parties has been found. Meetings can be quick—5 min or less, or can last a long time. For hairy topics, they can go on and off (an hour here, 5 min there) continuously for years. Yes, I did say years. This may seem like a waste of time, but Honda puts more emphasis on getting to the best solution rather than “a” solution and based on the quality of their cars and motorcycles, and I think it works. With an efficient meeting, a decision may be made quickly, but it may not always be the right one.
Workgroups measure based on outside factors that. For example, the performance of the company as a whole. How can they do it any other way? Individuals are working on their own. On their own little work areas.
With a Team, everyone works together, so the measurement is based on the collective work that they have done together.
Workgroups, as discussed earlier in meetings, have everything sent down from on high. The members may discuss together, but the leader is the one who makes the decision and then delegates to the members.
With a team, there is no real leader like in the sense of a workgroup. The team collaborates together and does the work together. There is no one person always coordinating activities and delegating.
As you can see, with Teams, there is more of a mutual relationship. There is more collaboration between members. Everyone is working towards the same goal. Be it complete a product, win a game or solve a problem.
With a Workgroup, everyone works on their own thing. It requires coordination. Therefore there is someone in charge to coordinate, direct and delegate.
No, Teams and Workgroups do have their places, but the best place for a team is when performance is required.
Now, you are probably thinking that your group or team is somewhere in the middle. That may be the case.
Marie J. Kane categorizes Workgroups and Teams into different levels.
Work Group – As we have discussed above.
Pseudo Team – Not focused on collective performance, or trying to achieve it but it is needed. These are the weakest type of group.
Potential Team – There is a performance need. It is trying to improve, but has no purpose or goals.
Real Team – Its members have complementary skills and are working together towards a common goal. They hold themselves accountable. The performance impact is significantly higher than a workgroup.
High-Performance Team – Like a Real Time, but also committed to everyone’s personal growth and success. They have transcended the commitment of the team and can outperform all other real teams. Think Navy Seals. They are the best of the best. Committed to one another.
Now, these differences cannot be taken individually. For example, just because members help each other occasionally, it does not mean they are a team. Workgroup members help each other too.
Ok, so you found out that you are not on a team. That is not necessarily bad. Workgroups are a working form of group that is better performant than a Pseudo Team. A Pseudo Team is trying to be a team, but only doing it half-baked. This actually turns out to be worse than being in a workgroup. This can happen if the “team” doesn’t even know what it is doing. If a team doesn’t agree at some point, things can stagnate, stall or be paralyzed from working. Getting agreement is a leader’s job and having a weak leader, one not willing to take professional risks in the team direction, can make it possible that the team won’t do a good job.
Then there is the problem where the team is always in agreement all the time. This creates another type of stagnation. One of lack of innovation. Having some conflict in the team of a technical nature, not a personal one, is good for the team. Alternative views are given. These alternative views must be explored and tested, not shot down, otherwise, there is a lack of trust between team members.
Then again, sometimes teams that do have conflicts of a personal nature do thrive. Just look at the Monty Python team. They hated each other, but each member knew that the others had their back no matter what when it counted. If your team is getting to the point where there is no conflict, and there is no innovation, then it might be time to switch things up a bit. Swap members with other teams. Bring in new blood with alternative views—a dissident who will “rock the boat.” Get the teams’ synapses thinking differently. The dissident also needs your support. They veer from the norm at great personal cost. No one wants to be the outsider, get shut down, or get told to shut up. So rather than let them be silenced, let them speak out and listen because, without them, your team can degrade to the point of being mediocre, but also make sure the dissident has the teams best interests in mind. You don’t want delinquency for the sake of it.
Another reason that Teams do not work is that they are not necessarily faster than workgroups. For the simple nature in teams where discussion between team members is encouraged, teams can actually be slower than workgroups. The trade off, though, with teams is that they produce better.
Teams may not work when they are large. Large teams have to communicate with one another. The more members, the more communication channels are required, the longer it takes to disseminate information, to discuss, the slower a team gets. Teams that are small. Between 3-9 members are ideal.
Only having a “Real Team” or “High-Performance Team” will give you the full benefits of having a team. Just saying that a group of people is a “Team” is not good enough to get the benefits. So, I request that if what you really want is a Work Group where you direct and delegate to members, call it a Work Group and not a Team. You are only confusing matters further and perpetuating the confusion with the term.
Just to quote the late great Steve Jobs, there is one document that I have left to last on purpose as Teams are not specific to Agile. That document describes how a team should work and it describes it very well. That document is the Scrum Guide. It mentions that Teams should be Self Organizing. Team members should be cross-functional. In other words, have all the skills to complete the goal.
Teams are altruistic in intentions. There is no hierarchical structure. Every member at least for the Development team has the title of “Developer.” There are no sub-teams.
The Scrum Master is there not to direct and delegate the team, but to support the team. Play interference and remove impediments from the team that prevents them from succeeding. No one but the team itself directs the team.
Accountability belongs to the team as a whole, not to individuals.
Jeff Sutherland and Ken Schwaber knew what they were talking about when they wrote the teams section in the Scrum Guide.
Jon R. Katzenbach and Douglas K. SmithHarvard Business Review
EcoForum – Volume 4, Issue 1 (6), 2015
Harvard Business Review
Harvard Business Review
Engaged and happy remote developers aren’t identified or sustained in a vacuum. Engagement of remote developers starts with practices championed from the top of your organization down. Your leadership needs to embrace the merits of a global, diverse workforce and support efforts that attract and retain remote employees.
Most of the best practices that apply to engaging and managing remote workers, in general, apply equally to engaging remote developers:
Like in-house developers, remote developers want to share their knowledge with peers and customers without having to jump through hoops or layers of technology. They want easy access to tools that help them solve problems. Providing a developer engagement solution that enables them easy access to collaborative spaces and unencumbered knowledge transfer will go a long way towards ensuring their engagement.
Developer forums are a place for developers and other members to come together, ask or answer questions, get support from their peers, and express opinions or concerns. Forums are a great collaboration venue for your development team, wherever they’re located, to interact simply.
An online developer community allows the same collaboration and functionality as a developer forum but with typically a little longer implementation time depending on all the functionality necessary. A developer community offers other features, such as blogs, to keep remote developers engaged and collaboration alive.
An online community that’s open 24/7 and accessible from any device truly caters to developers’ desire for knowledge sharing, and to help solve problems, and learn from their peers. Promote an ongoing dialogue among developers with a knowledge base of questions, answers, solutions, and code snippets. Make sure you eliminate redundant questions and tedious, endless threads.
Be open to feedback from remote developers. Encourage them to take ownership by moderating questions and answers in the areas where they have the most experience and knowledge, and look for knowledge management software that centralizes organic knowledge and makes it easy for developers to find what they’re looking for.
Also important for keeping knowledge sharing and engagement high: Recognize remote developers for their efforts. Gamification in the community is a great way to recognize engagement by topic experts and ongoing contributors and to incentivize developers to take more responsibility (that is, up their engagement) in the community.
Lastly, don’t forget the pivotal role developer evangelists can play in keeping developer communities informed and knowledge sharing fresh, along with keeping developers (in-house and remote) involved, engaged, and excited about your product.
If you work in the office, then you hear about Scrum quite a lot — either since people are using it or want to use it. People talk about it, but what does it really mean? I talked about it with my coworker Radek to find out — check out what kind of Scrum mysteries he decided to unveil!
It’s the second part of our Merix loves Agile series. In the first interview, I talked with Piotr, who described that one of the tools of a successful Scrum Master is chit-chat with the team. Today you can check out what Scrum is like in Radek’s eyes!
For me, it is a broader issue that includes an approach to work and a relationship with people. By being a Scrum Master, I have the opportunity to promote BOTH partnership and independent work, as well as setting goals based on values rather than calculations. I appreciate the opportunity to support the development of my colleagues’ skill, which also is very valuable to me.
Clear, adaptive, respectful, focused, open-minded.
Oh man, where can I start? Let me point out few attitudes that I find most irritating:
Lately, I’ve also heard about ScrumDude and Scrum Mum — the first one only acquiesces, while the latter treats everyone like children.
Scrum Masters are in a unique position that allows them to keep a distance and therefore see a bit more. By listening to the conversation, observing the work, and having a direct contact with everyone, they can understand what is happening in the project. It gives them a chance to gently guide the team to the path of improvement (but it’s only possible with more mature teams). First of all, they need to familiarize everyone with the basic rules. It all depends on who they work with and need to match up with the whole team.
Project Manager is a role based on control and command; Product Owner works with the product. Scrum Master is a very enigmatic role since his/her work is concentrated in large part on the team, supporting their development, and cooperation. At first, it’s easy, you explain what the rules are and how the development process will look. But the next steps must already be done by the team since Scrum Master can’t tell people what to do and how to do it. So, in short, the difference lies in areas of interest and approaches to the tasks.
…an example to others.
Certificates are a message to the world that you know something about the subject. In my opinion, people should strive to be masters in their field; therefore the certificates should only be treated as small steps toward that goal. As in every other area, Scrum Masters have to patiently expand their knowledge and learn from their mistakes through both theory and practice.
Scrum is just a framework, but it’s embedded in very important values. Each organization should ask itself whether these values suit them. Are they ready to bear the price of making changes until the whole process is finished? You have to give your organization time to learn, but you also have to set goals.
Really hard to tell.
Scrum Masters work in sprint cycles, both the beginning and the end of each one mean spending time with the whole team working on the project. They are listening, trying to help with cooperation and resolve conflicts. In the middle of the sprint, they separately analyze the situation and talk to team members individually. I try to be alert when it comes to the possibility of emerging problems and needs.
Being a Scrum Master is not about motivating people — that was a job of supervisors from the twentieth century. In my opinion, people don’t need the proverbial carrot. They need to feel that they are doing something valuable. Scrum Master just helps them do their job.
There are no universal rules to that. Let me know when you find them!
An open mind and a sense of when it is appropriate to say something and when to keep your mouth shut.
How much of an incomprehensible role it is. Previously I was working as a Project Manager, and no one outside the industry knew what my job was about. Now I have the impression that the people I work with need some time to understand what I do and why I’m not grabbing the wheel and telling them what to do.
There are many difficult elements.For instance, if there’s some kind of conflict within the team, then Scrum Master is bound to help people get through it and resolve every issue.
I became much more aware, as well as happier. I like my job and really enjoy that I can do something that is consistent with my beliefs.
And that’s all for today! Next time I’ll be talking with another star of ours, Kamil Grzyb, who’s going to describe the life of a Product Owner. Stay tuned!
Agile teams require commitment and focus, and these are in fact two of the core values which underpin the Scrum Framework. Moreover, it can be argued that without commitment and focus there is hardly an agile team to be spoken of in the first place. After all, a team must be able to frame a delivery commitment and be focused enough to meet it. Without that there is chaos.
Ironically though, the nurturing of such commitment and focus is not always valued within organizations, or it might be taken too easily for granted. The word “team” is often applied to a collection of people who have been brought together for some notional purpose, but the teamwork which would allow any goals to be met is not provided for. The “team” may not be truly self-organizing for example, and there may be managers who decide who works where and on what. Such decisions might be made seemingly at the drop of a hat, and on the mistaken premise that a reactive management style is concomitant with being “agile.” Those notional team members will find themselves rapidly pulled out to work on other matters which are considered to be more pressing by the higher-ups who control them. In effect the team is unbounded, since it is unclear who is on the team and who is off it. No meaningful commitment can be framed or an achievable backlog of work planned for, and no focus can be established while the sands continue to shift beneath their feet. The team is reduced to firefighting and its goals turn to pixie dust.
Intent: Use team members for work that is outside of their remit or declared purpose.
Proverbs: “What we imagine is order is merely the prevailing form of chaos.”
Also Known As: Firefighting
Motivation: The allocation of team members to certain workstreams implies that they will not be available for others. This is a constraint on organizational behavior, since it means that managers cannot assign people to multiple duties in a reactive or ad-hoc manner. Organizations can be tempted to compromise on such discipline for the sake of expediency.
Structure: A team member is assigned to a workstream but there is no limit to the number of assignments that can be made. Members can thus be expected to work on multiple concerns and this can include both project and business-as-usual work.
Applicability: Most agile methods, including Scrum, do not constrain team members to single workstreams. To this extent the teams are susceptible to becoming unbounded. It should be noted, however, that agile teams are self-organizing. Self-organization restricts the ability of managers to assign members to different workstreams in an arbitrary manner.
Consequences: Unbounded teams make commitment-based planning difficult or impossible. Team membership is unclear, and the time that members can spend on a particular workstream may be unreliable. Sprint goals can be compromised and the quality of forecasting will be poor. The morale of the team will suffer as a result of poor cohesion, a failure to deliver, or an inadequate sense of purpose. Inefficiencies due to task-switching are often a symptom of the unbounded team problem. The reassignment of team members by external authorities implies that the team is not self-organizing and therefore not agile. Reassignment of team members to multiple workstreams can also imply that portfolio and program level management is unfit for purpose.
Implementation: The Unbounded Team antipattern often occurs when organizations succumb to firefighting. Firefighting happens when inappropriate plans are made or the organizational response to change is poorly managed. The problem is also associated with reactive management styles and with incompetent managers who commit team members without appropriate consultation.
Over many years, we’ve found ourselves called into organizations to help after they’ve attempted an Agile transformation. Things hadn’t quite worked out the way they’d hoped and then, through a recommendation, they’ll find themselves talking to us. Every time we go in, we see some common reasons why their transformation failed. Here are 5 common mistakes behind these failed attempts, often made on the advice of the company they entrusted to guide them. Hopefully, you can use these insights to avoid similar mistakes or, if these seem familiar, get back on a better path…
This is often a consequence of buying “Agile in a Box.” A sure sign of this is when people talk about “The Agile Methodology” or “Our Agile Process.” The very first value statement of the Agile Manifesto is “We value Individuals and Interactions over Processes and Tools.”
Agile is a mindset, not a process. Nonetheless, many organizations take on a branded methodology wholesale, introducing many new practices simultaneously. They then see productivity drop through the floor and deadlines jeopardized. The entire pilot program struggles to take on unfamiliar practices while trying to deliver to a schedule that assumes an instantaneous improvement. In reality, they experience the inevitable dip in performance, management panics, changes are reverted before they can have a positive effect or continued in a suboptimal manner and we hear the common refrain, “We tried Agile and it didn’t work.”
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. – 12th Principle of the Agile Manifesto
Instead of a big-bang change, we can make a series of small changes. These could be small changes across teams or a large change in one small area (e.g. creating a pioneering or pilot team to explore new ways of working). Each small change gives us time to reflect on what’s working and what isn’t. We identify our current pain points and bottlenecks in our existing process and try small experiments to alleviate those issues. Don’t assume that copying the practices of other organizations will help you with your problems, in your context.
For more on this, see “Our Tack on Effective Change.”
Many business journals sell Agile as a panacea. They say it’s the strategy your organization needs to adopt if it wants to keep pace with or outmaneuver the competition. Attempting to “implement” Agile as an end in itself is unlikely to have the results promised. It’s a journey, a mode of transport, not a destination. And it is more than a strategy, it usually means a fundamental cultural change in the organization. As Peter Drucker said, “culture eats strategy for breakfast.”
First, it’s important to understand what success looks like for you. What do you want to see happen as a result? Do you want to innovate more, creating new products and services in your portfolio to grow revenue? Do you want to bring products to market sooner? Do you want to flatten or reduce the cost of change in your existing systems? Or, all of the above? When seen as a destination, it’s too easy to mistake Agile as a new process for people to follow. Agile is a lens through which we can see opportunities to achieve our end goals we couldn’t see before. These opportunities are not just in the outputs of your organization, they span People, Product, and Process.
Many organizations claim to be agile or claim to have tried implementing Agile and it failed. Often this is due to treating Agile as a box-ticking exercise: Daily Standups – Check, Occasional Retro – Check, “Stories” in Jira – Check. These practices have value in a certain context, but if they are being done without an understanding of the value we are hoping to achieve from them, then they are no better than a Cargo Cult. In this story, hoping to invoke aircraft supply drops…
“Islanders imitated the practices of US soldiers. They carved headphones from wood and wore them while sitting in fabricated control towers. They waved landing signals while standing on the runways. They lit fires to light up runways.”
What the islanders didn’t understand is that the soldiers did these things because the planes were coming. Doing those things would not cause the planes to come.
Another sign of this phenomenon is Anaemic Standups – where the team is simply updating a project manager on the work completed since yesterday, rather than synchronizing and creating serendipitous learning opportunities. This is the team ticking the “we have a meeting where we stand-up” box.
If we don’t understand why we’re doing a practice, then it will be inefficient at best and potentially harmful at worst. We can ask ourselves the question “What is the problem that this practice is trying to solve?” If the answer is “That’s just the way we do it,” or “That’s what it says in the book,” then we might look to do something differently.
Our approach is to identify our current biggest obstacle and think of something we can try over a short period of time to relieve that obstacle. Then we’d review; is it still the biggest obstacle? If not, repeat for the next obstacle. If it is, try another experiment. All the while, avoiding any big-bang change.
Could you imagine going on a two-day course on playing the piano and afterward being good enough to perform professionally? We’ve seen many companies treat Agile training like this. After a two day Test Driven Development course, they expect their developers to perform at a professional level on their first day back. Despite the presumed simplicity of TDD, it actually takes a deep competency that takes skill to do well.
With computers, we can upload new software, perform the upgrade, and expect instant performance improvements, but this isn’t how people learn. A short course can introduce ideas and show people the first steps on their journey to becoming competent. It then takes months (or years) of daily, deliberate practice to become competent and certainly years to master.
Just like learning a new musical instrument, you need time between lessons to practice. Each lesson then becomes a coaching session where the music teacher gives you feedback about where your performance is today. They help you find improvements. Between lessons, you may not even learn a whole piece. You may only get part way there and your task until the next session is to learn the next part of the piece and improve your expression in what you’ve already learned.
Training can be used as an introduction, or a taster session, to a new skill. It will take practice and coaching to master that skill and apply it. Eventually, you’ll be ready to perform professionally. Regular follow-up coaching and allowing your team space to practice is key to taking your team from their first step in a training course to professional levels of competency.
It can be quite disconcerting to realize that a transformation is never really done. Whatever solutions that we have today are based on our knowledge now, the context that we are in and the problems that we are solving. Any one of these things can change, and render our existing system inefficient or ineffective. By understanding that there are no such things as “Best Practices,” only “The best that we currently know,” we can keep ourselves flexible when our circumstances change.
“It is not the strongest or the most intelligent who will survive but those who can best manage change.” ― Leon C. Megginson
Both the values and principles of the Agile Manifesto point to the continuity of the process. Individuals and interactions over processes and tools highlights that dogmatic adherence to a process at the expense of individuals and interactions is “not Agile.” Responding to change over following a plan applies just as much to our processes as to our deliverables. Recall the 12th Principle of the Agile Manifesto mentioned earlier.
Remember that the process is never complete. The context that we adapted for yesterday might not be appropriate today and might be harmful to our survival tomorrow. Continue to reflect on what is making us effective and what is less than ideal; sense, adapt, and tune our behavior to better fit our current context.
How many people do you know that can fill these shoes?
The other team members leave the Team Lead to make the decisions because they can. When a piece of code doesn’t work, or when the team doesn’t know what tech to choose for the next project, they go and ask Team Lead to make a plan and produce the magical answer. Need a design or to resolve some dependency? Team lead to the rescue.
They have become like a spoiled child that expects Mommy to take care of their every need, including thinking for them.
So what happens when the Team/Tech Lead is not there anymore? Who will now make the decisions?
Let’s look at some reasons why the above scenario is a bad idea.
Other members of the team might never be heard, even though they might have great ideas.
Ownership does not sit with the team, where it should, but rather with an individual.
Responsibility is delegated to a single person instead of a team.
One person grows more than the others as he gets to do all the talking, researching, and struggling.
I believe that no one person is smarter than the group and that a group always out-thinks a single individual. Here’s why:
You have more brains. Literally.
Diversity brings perspective and creativity. One person might be analytical, another creative. People have different skill sets and specialties. These can augment and feed on each other.
Problems can be solved in more than one way. Having open discussions and welcoming ideas might highlight ways to solve a problem a single individual might never have thought of.
Like musicians, a tight group of developers (including programmers, test analysts, business analysts, UX specialists) riff off each other and feed on each other’s energy.
Technical leadership means that a group of like-minded individuals set the trends for technological excellence, set the culture and way of work in a responsible way. It also includes individuals that contribute a lot to this body of knowledge, but it should never exclude others.
You do need technical leadership, but instead of concentrating it in a select few individuals, make it a mob thing.
Yes and no. If someone’s a natural leader, people tend to follow that person, whether or not that person carries a title. People want to follow someone they feel safe with, respect and trust.
If you make the lives of those around you easier and more meaningful, help them meet their targets and overcome their obstacles, you’re a servant leader. This is a way of thinking and doing, not a role or job title. By doing this you will earn respect without having any title.
Try this out: remove the titles from the team. Then give them something to do together or figure out and watch what happens. Then, remove or swap out the person that led the team and do the exercise again. You will be surprised to see that your team actually has more than one leader. The others just never got the chance to shine.
Here are some ideas to try out.
Start by removing the titles and stigmas. It can be as simple as changing everyone’s email signatures or by putting non-obvious people “in charge” and rotating this role.
If you’re the one talking all the time, give the others a chance, specifically refer decisions to the rest of the team for a while. Sometimes a shy person just needs a small push to speak up.
Make it your passion to help others, to learn, and to encourage teamwork.
Try mob programming. This technique focuses the whole team on a single goal and purpose by physically programming or solving problems on the same computer or screen.
Learn to share the load instead of doing everything yourself.
I don’t believe that a single person with the title of Tech Lead is as effective as Technical Leadership owned by the whole team. You always need and will have leaders, but they rarely need titles to do so.
Managing an app project for a client, whether large or small, is no easy task. Keeping the ship on course while it’s pulled about by the currents and winds of changing client demands, budget constraints and your looming deadlines can be a rough job, especially when the ugly sea monster known as scope creep rears its head.
The Standish Group’s 2017 CHAOS Summary found that fewer than a third of projects (29%) were successful, meaning they were delivered on-time, on-budget, and with all the required features.
Of the remaining projects, 52% percent were delivered late, over budget or missing features and 19% failed completely, either through being canceled or delivered and never used. That means that in 2015, 71% of all IT projects were either failed or challenged.
And the main reason for these failures? You guessed it, that nasty old sea monster, scope creep.
Scope creep, otherwise known as feature creep or “kitchen sink syndrome” (as in, including everything and the kitchen sink), is basically where, over the course of the project, more and more features are added to the point where the allotted budget, time, and resources can no longer cover the workload and the project starts to flounder.
It happens for various reasons, but the two main causes are:
Both of these things usually happen slowly, a small change here, a suggestion there, but they quickly build up into a formidable extra workload that can crush the project or grind it to a standstill.
Don’t let the thought of an unsuccessful project get you down, here are three tips for managing scope creep to keep your project development as smooth as possible:
First things first: scope creep is going to happen. You’re not going to get around it. So it’s good to start with that assumption.
When you start working with a client, take time to define end results. That means, not only the required features of the app but also the budget, the time the project should take, and the resources that will be required to make sure the project is delivered within these constraints.
This is usually broken down into the “project triangle” of Scope/Time +Budget/Resources. If any one of these sides changes then so must the others to accommodate. Because of this, getting clear requirements is essential, as it covers the “scope” side of the triangle, and once that is in place the rest can be worked out.
When working with a client, good negotiation is essential so that you both understand exactly what the project is aiming to deliver, and, before the project begins, establish a formalized way for the client to request changes or new features, no matter how minor.
A great way to make sure that both you and your client are on the same page is by asking them the right questions before you even think about building their app. Then, when you and the client are ready, codify exactly which features are going to be in App 1.0 – the Minimum Viable Product.
By doing this, you not only manage to establish a way to organize and prioritize requests but also force the client to recognize whenever they are asking for something new, which can help with requests for tiny adjustments that are perhaps trivial.
When you’re working for a client, it can be very hard to break the mindset of “the customer is always right.” It’s heavily ingrained in the customer service industry, no matter their area, and it’s an almost expected part of customer interaction.
In the case of project management though, it’s not always true.
The customer may make a request for a change that to them seems like a minor job, but you know that it will take a few days at least and be a major headache. Rather than heed their every whim, it’s your job to negotiate with the customer and to try to change their mind, especially if the change is, to you and your team, unnecessary.
That’s not to say you should utterly discount their idea, and especially not rudely, but by showing them that either through time or budget constraints that it’s not possible without changing the project plan, they are more likely to back down or be willing to take a watered down version of the idea.
It’s also in your best interests to provide a professional counterbalance to your customer’s ideas and demands. If they’ve, say, requested that an app is to be developed for both iOS and Android after you have already started developing it for iOS, it’s up to you to convince them that within your project’s constraints, it is a much better idea to continue on a single platform. Show your customer that you and your team know your stuff and can provide good reasons as to why it is better to follow your advice. Remember, your customer doesn’t necessarily have to like you. It helps, but would you rather have a reputation for being “nice guys” who are average quality or the guys that always deliver great products but are more strict?
At the end of the day, it’s about profit for the customer; and if your app makes them a good profit, they’ll be much more willing to turn a blind eye to you not always heeding to their every whim.
Even with all of the above suggestions, it’s likely you’ll find yourself working on a few extra bits and pieces with the project; like we said before, scope creep will happen. The important part is to always research every request before you agree to do it. Here’s a good example: a client makes a simple request that you migrate the app database backend from your servers to theirs. Simple, right? But what your client forgot to tell you is that they’re running on Windows servers, while your app agency hosts everything on Linux. A simple request could turn into a week-long nightmare.
The same rule applies to teams on their own projects. If someone suddenly has a great sounding idea, always make sure to do as much research into how realistic making it happen would actually be.
It’s something that can be seen frequently in the games industry, where developers invest millions and millions of dollars into adding a feature into their games at the last minute that ends up pushing the game way over their deadlines and over their budget. This then snowballs as then they have to sell more of the game to recoup their losses and it makes it more likely the game, and all too commonly, the studio will fail.
Realise though, that scope creep isn’t just about vetoing obviously bad customer or fellow developer ideas. A lot of the time it is a two-way street. Someone suggests a feature idea and then, through either wanting to prove your worth or also being excited about the idea, you, as the project manager, allow the idea to be added to the scope of the project. Then, before you know it, you’re over budget, over time, and wondering just where the hell it all went off the rails.
Scope creep is an animal all projects, regardless of size, have to face. It can kill them dead if it’s allowed to, but with careful management and by keeping a firm grasp of the actual requirements of the project, it can be tamed. It can even become useful, providing ideas and features that take a project from mediocre to something special. It’s a hard line to walk, but, hopefully, these tips will help you keep it under control.
Most organizations today require strong team working skills and tout the collaborative nature of their workplaces, so it perhaps goes without saying that there is considerable interest in what makes teams effective. A recent study suggests that being friends with your teammates does no harm whatsoever.
The researchers conducted a meta-analysis of over 25 different studies on effective teamwork. The analysis revealed that when teams were mostly composed of friends, they performed a lot better than when team members were strangers. This was particularly pronounced when teams grew in size.
“Working with friends is not just something that makes us feel good – it can actually produce better results,” the authors say.
The analysis explored a range of studies that had examined the performance of teams where participants were friends versus those where such friendships did not exist.
The results revealed that friendship provided a big boost to team performance, regardless of whether the tasks were mental or physical. It was also consistent across age groups, with the gain growing as the size of the teams increased.
“Friends can coordinate tasks more effectively,” the authors say. “They know each other’s strengths and weaknesses and can figure out how to break up the work in the most efficient way.”
It should be noted that the type of task did play a part, however. For instance, teams with high friendship levels did very well when the goal was to produce the highest output, but they did no better than less friendly teams when the goal was to produce an optimal solution to a problem. The authors believe the output boost is because sustaining motivation can be the key factor in such tasks, and so friends can help do just that.
“When you’re working with friends, you tend to be in a better mood and can work through the adversity and strain that sometimes comes from having to produce a lot in a short time,” they say.
When quality is what’s needed, however, there is a distinct advantage in working with strangers as this increases the ‘thought diversity’ of the group. Such groups are also more likely to have the constructive disagreements that are crucial to the construction of novel ideas.
The researchers hope that their work will provide managers with a greater understanding of how teams perform in various conditions, and when it’s good to have teams with high friendship levels, and indeed when it isn’t.
Today’s technological world is bringing significant innovations to every aspect of our daily lives. From the health sector advancement with Radiology PACS to shopping online through e-commerce stores at the comfort of your home, technology is making our work more accessible.
Tech innovations are making the line of service delivery easier for different sectors within the business. The transformation process does not end there. More businesses are evolving with the help of emerging technologies to become more agile, competitive, and gain a foothold in their respective industry.
It is evident that technology has remarkably changed the workplace environment, just think about how much more desk-bound people were in the past. Technology has brought a work revolution and thus work can now be done from anywhere, anytime. Traditional ways of doing the job are no longer applicable, and the modern day workplace relies on tech devices or software platforms to carry out operations.
From the use of cloud computing to intelligence analytics, new technologies are changing the workplace scene. And how is this happening? Well, have a look at how the new tech trends are influencing your work environment.
Communicating within the organization no longer possess a challenge. Managers can issue orders and instructions to their employees, regardless of the physical distance separating them, with the help of video and web conferencing software. Old meeting areas are now areas for video conferencing. Furthermore, remote employees can access their information from the administration through the internet on their mobile and smartphone handsets. With a million and one options offered, when it comes to communication, the flow of information should not pose a challenge to your business.
The mention of big data might be confusing for some, but the concept is an excellent tool for gaining a competitive advantage. Firms are now employing intelligent software and analytics tools that give the business a capacity for smarter administration. You no longer require piles of files to keep your data. With the help of analytical tools, you can record, save, and analyze your data to glean significant meaning from it. This translates to a more efficient organization of data that helps you make better-informed decisions.
With the world trying to become more environmentally friendly, technology is a sure way to champion this concept. The use of software programs and applications are saving the workplace paper waste and consequently reducing the waste produced by the organization. Migration to cloud-based applications is also helping reduce carbon emissions, which is just one of the financial and environmental benefits.
Since technology is ever-changing, adapting new tech can be a tough task to undertake. As a company, you become agile to grow or shrink the computing resources with regards to demand and supply. The incorporation of new technology means the structure of the business must also adapt. A company that can quickly adjust is safe from the risks of failing due to a rigid structure. Additionally, new technology is creating greater flexibility for employees, with the ability to work whenever and wherever.
Never before has the workflow in an organization been so streamlined. Business applications connect different sectors of the business and create platforms that enable the collaborative way of working. Furthermore, the use of pairing devices allows employees to access self-service platforms of the business. A strong correlation between the employee and the company makes it easier to work from different locations or offices.
Recently, I logged into LinkedIn and saw a discussion headline they were promoting. It read, “why remote working will die,” and man did people have a lot to say about that topic.
The centerpiece of the discussion? An Atlantic article examining famous telecommute-advocate IBM’s decision to build “agile spaces” and then to call its remote workers back to home base. The article also referenced Apple and Google’s similar policies of office presence. This created the general impression that large tech companies succeed on the back of high bandwidth communications and physically showing up.
And yet, it seems as though the death of telecommuting may be greatly exaggerated. I won’t wade into the debate over the better approach here. But I will say that the rise of the gig economy, the inexorable march of progress, and increasing globalization of work all seem to suggest that remote work will remain a mainstay of modern companies.
So let’s proceed under that premise, and move on to discussing the idea of Agile software development.
Almost two decades ago, a group of skilled software developers and consultants got together and produced the now legendary, “Manifesto for Agile Software Development” (since widely dubbed “The Agile Manifesto”). It offered these four brief heuristics for software teams (emphasis mine).
It then followed with the clarification that, “while there is value in the items on the right, we value the items on the left more.” Note the highlighting, and then note how much they value high-bandwidth collaboration. You could say that collaboration serves as the backbone of the whole concept.
Like remote work, Agile software development isn’t going anywhere, either. Over two decades, it has grown from that conference room with a handful of folks to the de facto software development approach, and a billion-dollar consulting industry. Both things are here to stay.
So let’s look at how to reconcile the two of them. If you have a remote team, how do you successfully implement an Agile approach? And how do you do it without just throwing your hands in the air and giving up on the flexibility of remote work?
As I’ve already detailed, Agile methodologies heavily emphasize collaboration. Consider two popular Agile methodologies: Extreme Programming and Scrum. Development teams drawing from these approaches do things like the following.
All of those things rely heavily on teams sitting together. But while that may be sort of iconic, it’s not all that there is to Agile software development. It’s also about tightening feedback loops, adapting to change, and learning. And you can do all of those things without a team that sits together physically.
You can use tooling to recreate some or all of the above. And, while I’d suggest doing that as makes sense, don’t go so far as to force it. Instead, accept the reality of the distributed team and look at how to tighten feedback loops, adapt, and learn in that situation.
Let’s move from the philosophical to the specific. Embrace the reality of remote work and adopt practices that make sense within that context. One of the biggest ways you can achieve this is to facilitate as much collaboration as you can.
For instance, try to create teams such that members of the individual teams are in similar time zones. From there, you can also establish a set of “core hours” during which team members are always available to chat.
You take this kind of thing for granted in a physically present team that works traditional hours. Everyone comes in at 8:30 and leaves at 5:00. But you can achieve a good bit of the same effect by just establishing a mutual agreement as to when team members can collaborate.
When people cite the problems with remote work, lack of team cohesion always comes up. And, that’s real. Working alone, collaborating only over conference calls and Slack chats, doesn’t have the same feel as in-person collaboration. Participants feel more disconnected.
And, while you can’t easily recreate the office experience with remote teams, you can still build camaraderie. Have folks come to the office or travel to get together every now and then. Make sure you go out for some meals, too. Team members feel a good bit more cohesion when they’ve sat, laughed, and eaten together. You can get an excellent return on this relatively small investment in terms of the team dynamic.
Another way to get the most bang for your buck with synchronous communication involves the so-called Agile ceremonies. If you follow Scrum, these are as follows.
You may define others, depending on your particulars. But regardless of which specific ceremonies we’re talking about, strive to have these live, using teleconferencing tools. Use video. You want folks to be able to see each others’ expressions and body language while this happens. All told, this will probably only occupy 2-3 hours per week of time for the team. So find a way to do this live, and reap disproportionate rewards.
Collaborative activities like pair programming go less smoothly when you’re remote. There’s no doubt about that. So you might not emphasize this as much with your distributed team.
However, you can also keep tabs on the latest technologies that help with this sort of thing. For instance, Screen Hero (now part of Slack) specifically lets people share screens remotely. It’s far from the only one, and these techs are constantly improving. Other, non-live collaboration tools help as well, such as Trello, Slack, Google Docs, and ALM tools like JIRA. Pick ones that the team is comfortable with and work out a good, nimble collaboration workflow.
These tools don’t replace sitting in a room together, per se, but they let you define a sort of collaboration that doesn’t try too hard to imitate that. So try them out, and see how they work for your team. Leverage them to the extent that they help, and check back in with them from time to time to see what improvements have emerged.
Some of the best remote work success stories come from companies that bill themselves as remote first. In other words, they optimize for the difference, as I advised earlier. But they also go beyond just embracing the reality of remote work.
They define processes from the outset that make sense for remote teams. From day one, they’re leveraging cloud services and automating build and deployment from end-to-end. From day one, they’re making sure meaningful collaboration happens somewhere that it can be recorded for later reference. And, from day one, they’re playing to the strengths of distributed environments, which, in the dictionary definition sense of the word, make being Agile non-negotiable.
So if you want to go remote and you want to be Agile, don’t go halfway, and don’t pretend that you all sit together when you don’t. Understand that the lack of colocation costs you something. But also understand that you can profit from it if you lean into it.
Software is a model.
We’re used to thinking of models as physical models that occupy space, but software represents a different kind of model, not a physical model but rather a behavioral model. Behavioral models take place in time rather than in space. You can think of them as black boxes where some input comes in and then drives an output that goes out. What happens in between can be given a label and abstracted out.
Software is only clay. It’s a medium for creating virtual models based on our linguistic constructs and our understanding of the way things work.
Remember the myth of the Tower of Babel? Humankind wanted to build a tower so high that it reached up to Heaven, but God didn’t like the idea of associating with riffraff like us so he made everyone speak different languages. Because we couldn’t understand each other we couldn’t collaborate effectively and the tower fell.
Communication is central to collaboration. We must have a shared vocabulary and a shared set of standards and practices. Far too often, we use the same words but have very different meanings for them. We think in terms of our specific experiences, but our words represent generalizations. We’re constantly going back and forth between the abstract and specific, between the generalizations of what the words represent and our specific experiences.
This is where ambiguity and misunderstanding come in. Language is inherently ambiguous. But the kind of rules you need in order to articulate behavior in software have to be very precise. This is one of the reasons that requirements have failed as an effective way of conveying the features to be built in a software system. It’s far better to make software development a discovery process between the Product Owner or customer representative and the development team.
It’s nearly impossible to visualize an entire software system before it’s built. It’s far easier to visualize each piece as it’s being built with feedback from the development team. This kind of iterative development, where we’re constantly getting feedback from our customers and refining what we’re building so that we’re continually building the most valuable pieces, turns out to be a highly effective way for constructing software systems.
The key is to make the software that we build understandable by using effective metaphors that are centered in the domain language of the domain we’re working in. The domain language holds valuable information about the domain so we want to incorporate it into our designs. Our domain model should be understandable to domain experts even if they haven’t been exposed to programming languages.
If a class diagram of your system reflects an understanding of your domain that a domain expert would appreciate, you have an understandable design. If not, perhaps it’s time to refactor.
A visionary keynote was provided by Ayman Sayed, President and Chief Product Officer at CA Technologies during CA World ’17. He urged organizations to focus on solving business problems versus the latest technology. Here’s a link to his speech.
Observations from Sayed include:
Artifical intelligence (AI) has been used for decades but its role is changing. The waves of technological change are getting larger and more frequent and organizations need to be prepared to use AI to keep up with the change.
This acceleration of business adds to its complexity. It’s very difficult for enterprise organizations to evolve due to technical debt and inculcated cultures. As such, organizations need to use technology to be smarter without human intervention.
As companies become software companies, they need to keep in mind that ease of use is critical for all software developed. If it’s not easy it’s not smart.
Understand situations and assess business problem to be solved to make informed decisions in real-time.
All platforms and solutions must be able to integrate with solutions from other providers to deliver business solutions.
Every software solution needs four qualities: 1) agility, 2) intelligence automation, 3) insights, and, 4) security. Agility is the ability to dynamically respond to change, pivot and iterate quickly, putting customers at the heart of everything you do. Intelligence automation includes business processes, repeatable and precise business insights. Insights into how customers are using your product so you are able to constantly iterate and improve CX. Security is proactively monitoring and mitigating risk, stopping theft before it happens, and moving from reactive to proactive security.
According to Sayed, those who apply modern software factory principles have 70% greater productivity, and 50% greater profits than those that do not. They are the “masters of the modern software factory.”
Sayed provided five uses cases:
Aetna community care is using CA Agile Central to evolve its culture and promote collaboration, building a truly agile business. They are thinking outside box and taking small risks. They are implementing a cultural transformation with cross-functional team alignment which promotes collaboration across three areas of business: operations, compliance, and IT. According to Brian Thompson, Executive Director at Aetna, they have created an agile, nimble, and entrepreneurial spirit in the organization.
AMC Theaters has 390 theaters across the U.S. Concession stands generate the greatest revenue for the organization. AMC is using Automic to process more than 500,000 transactions every day. They now know what snacks sell best for a particular movie and they are able to send mobile promotions in alignment with the movie based on knowledge they have acquired. AMC needs automation to manage with a small IT team and they realize the criticality of on-time data. When the first Avengers movie came out, AMC used real-time sales data to learn that demand justified adding the movie to more cinemas.
BHI is Israel’s leading bank. The bank needed to reduce performance delays and outages while gaining mainframe operational intelligence including continuous insights on bottlenecks and outages. According to Scott Brod, AVP IT Infrastructure at BHI, they took an approach to proactively solve problems, stripped down their data center, and had a single pane of glass providing insights on operations so they can direct problems to the right talent and expertise. The application team, storage team, and infrastructure team use AI/ML to identify where the problem is occurring in real-time to reduce finger pointing and mean-time-to-resolution (MTTR).
McKesson is moving from DevOps to DevSecOps using Veracode to defend themselves against cyber criminals trying to access valuable personal health information (PHI). McKesson is protecting patient data and reducing risk and cost with no impact on their release and launch schedule.
21st Century Fox – Fox News is creating and disseminating digital content and dissemination using Agile Central, BlazeMeter, Veracode, and Runscope. Mobile is the dominant way people want to consume news. Social media platforms are a source of headlines. Video is a major component of the news landscape. Fox must provide a TV-like experience across all digital platforms. They took a fresh look at development and deployment workflows integrating vulnerability testing and security earlier in the SDLC and reinventing all mobile platforms in 18 months. They measure success – speed and efficiency, audience growth, time on site – on the mobile app because it has the highest consumption (100 pages per month) of any platform.
Businesses are losing over $700 billion every year due to outages. Sayed advised companies to trust the process, present the technology they have in place, specify what you’re trying to accomplish, and be open to opportunities to automate your processes.
Sayed’s predictions for 2018:
Current predictions for cloud spend will be proven to be grossly underestimated. Gartner estimates that public cloud growth will be 18 percent and Wikibon is estimating that enterprise cloud spend will grow at a CAGR of 16 percent over the next 10 years. In reality, we will see much larger growth as the established enterprise moves to a more agile infrastructure to support a nimble, software and services business model.
Private ledger technologies will find their value in the enterprise. From supply chains to sourcing and transactional integrity, companies of all sizes will take the same technology that supports public financial transactions and find value in using them for internal tracking and audit.
Security will remain top of mind for customers, but the software development lifecycle will now need to integrate security from start to finish in a seamless way. The need for speed and velocity with quality in development has created a “shift-left” movement that integrates security at development, which needs to be easy and accessible for developers as they write code. It also needs to morph and leverage the immense amounts of data generated by a business to protect data and mitigate risks. DevSecOps will become mainstream and security technologies designed for developers will dominate the security market.
As Mark Kilby and I work through the images and text for the geographically distributed teams book we are writing, I wanted to clarify what collocated and distributed mean.
Collocated teams sit near each other in space. However, not everyone agrees on what is “near.”
In Developing Products in Half the Time, Smith and Reinertsen use the Allen Curve to discuss the distance at which you can consider a team to be distributed as opposed to collocated.
Notice that there’s only a 30% chance of communication when people are 8 meters apart. It takes about 10 steps to walk 8 meters. Yes, 10 steps. It takes about 40 steps to walk 30 meters. That’s all. We’re not talking a lot of time and distance here.
Notice that by the time you get to 24 meters (30-31 steps), you have less than a 5% chance of communication. This is not just to ask a question, but any communication.
The Allen Curve explains why team rooms work so well for Agile teams.
If your team is not all on the same floor, in a close cluster of offices/cubes, you have some sort of a geographically distributed team. Yes, even if you are all on the same campus. If you are in one building or on one campus, you have what I’ve been calling a geo-fence around the team. Your managers might not realize you have a distributed team, but you do.
What do geographically distributed teams do? They create a virtual team room. They use that space.
The first step is to realize you have a distributed team. The next is to realize you need a team space so you can all collaborate.
Over the years, we’ve seen some dramatic changes in the workplace. If we look back even just twenty years, we find strict office layouts and not much room for collaboration. Nowadays, offices have more freedom and flexibility. Of course, we only need to look at the likes of Google to see just how much the working world has changed. With ping pong tables, creatives areas, and so much more, we see a business that has mastered the balance between work, play, and motivating and empowering employees.
Elsewhere, software has played a huge role in the business world recently. For employees, managers, customers, suppliers, and every other stakeholder, software has allowed for a more enjoyable experience. Today, we’re focusing on ‘teamwork software’ and why you should be paying this niche a lot of attention in the coming years!
Improved Communication – As mentioned previously, we’ve come from a time where each employee would have their own cubicle and essentially lock themselves away from the world to work. Today, we recognize the value of communication across the chain of command (as well as up and down this chain).
Often, small businesses suffer because there’s a lack of communication between team members and this leads to inefficiencies across the office. Whether it’s messaging not being passed on or employees unaware of what they should be doing on a day-to-day basis, poor communication can be detrimental. Suddenly, team members are wasting their time on tasks that aren’t important or they’re replying to emails that have already been checked and dealt with.
With the right teamwork software, communication becomes easier than ever before. With access to all the right information, everybody knows where they stand and questions can be answered within seconds rather than missing emails or chasing somebody around the office all day. With open communication, the office turns into a well-oiled machine and, ultimately, the customers will be the ones to benefit from this.
Improved Collaboration – In every single team, there are ideas just waiting to be shared; nowadays, several of the largest companies look for ‘internal innovation.’ For example, Facebook hosts ‘hackathons’ where employees can bring up new ideas while having the support to test their innovations with other employees and the right equipment. In order for something like this to be successful, teamwork software becomes pivotal.
Even on a day-to-day basis, teamwork software prevents each employee from being locked in their cubical (effectively a cage). Instead, they have a platform to come to their colleagues and ask for feedback on an idea, they can ask for help on a certain task, and the office space becomes one full of collaboration.
With teamwork software, tasks can be managed and worked on via the same platform. With messaging and access for all the right people, it becomes a better way of communicating and this leads nicely to the third benefit of having teamwork software at your workplace.
Increased Efficiency – As we’ve already seen, teamwork software cuts out all the inefficiencies that have existed within the office for many years. No longer do employees need to wait for replies to emails to complete a particular task; no longer is communication restricted to certain times and locations; no longer do employees have to hold back with questions or ideas. What’s more, all employees can see the stage of the selling process for each customer so their needs are fulfilled as expected.
With messaging services, calendars, and reminders, the team is always kept up-to-date with important information and nobody is ever left behind. If the manager has a simple question that needs answering before giving a task the go-ahead, this can be asked and answered within seconds using the software. Furthermore, work can be checked and feedback can be given instantaneously.
Increased Flexibility – Back in the day, when somebody was working from home, they were pretty much considered out-of-action. Today, teamwork software allows clear communication even when team members are working from home or attending a meeting on the other side of the country. Rather than waiting until they return, work can continue and collaboration can still occur regardless of where one party may be in the world.
While on the topic of flexibility, we should also note the power of technology these days. With the introduction of smartphones and tablets, the need for all employees to be at their desks in order to be a part of the team has disappeared.
Improved Training – For new employees coming into an office, it can be quite daunting and sometimes they fear approaching certain members of the staff. For the first few weeks, it can be rather awkward and they almost feel scared to suggest ideas. With teamwork software, this barrier is removed and new members of the team can jump into action immediately. With a simple message, they can have questions answered and their work can be checked with ease.
Improved Customer Service (Profits!) – In business, we have several goals but this is normally underlined by one major aim; to make a profit. The five benefits we’ve discussed so far all contribute towards improved service for all customers whether this comes through communication, efficiency, or collaboration.
An assembly line is where the machine or a process directs the person to perform a well-defined task. Here, the person is little more than a piece of the machinery to churn out the same product over and over again. There is no room for imagination and innovation. The human is reduced to a drudge. The pursuit of mastery is not relevant.
In his book, The Craftsman, Richard Sennett coined the term “Fractured Skill.” He laments that industrialization has caused practical skill to be compartmentalized so that craftspeople no longer have the full experience in making. The CAD (Computer Aided Design) package is another example of Fractured Skill. Here the engineer is working within the bounds of the CAD tool. The frequent contact with real materials is lost. The engineer may have extensive theoretical knowledge of their domain, however, they rarely go out and experience it, they have limited appreciation for how their designs materialize in the real world—the hand and the eye are divided. For this engineer, innovation is stifled, limited by the quality of feedback that the CAD package can provide. Of course, they occasionally see their work in progress and the finished product, but his regular feedback is diminished.
“You start by sketching, then you do a drawing, then you make a model, and then you go to reality– you go to the site– and then you go back to drawing. You build up a kind of circularity between drawing and making and then back again.” — The architect Renzo Piano quoted in The Craftsman
Fractured Skill is relevant to our craft as well, it is “fractured” at many levels. At its highest level the spectrum of skills required in our work range from Organizing to Making. Organizing ensures that we are building the right thing, that we cooperate to work in the most productive way with our team, our business, and our end users. Making is the act of producing, verifying, and operating the software. Making includes development, testing, site automation, and operation.
The skills involved in Organizing and Making are many and we cannot simply expect everyone to excel at everything. This has led to compartmentalization. In Organizing, we have roles such as Managers who coordinate/direct the team, Product Owners who usually act as a proxy to users, subject matter experts (SMEs), people who represent the business, Scrum Masters who try to coordinate and remove impediments, Architects who coordinate the systems and technologies. In Making we have roles like Front-end and Backend Developers, Automation Engineers, and Testers. Often each one of these roles represents fiefdoms where we grudgingly suffer intrusion from others.
It is not always that bad! We do sometimes cooperate. For example, every time we recommend that the Tester or QA needs to be an integral part of the development team, we see agreement, although in practice they often revert back to their fiefdoms where QA is automating tests without much knowledge of the rest of the team and where the developer is happy to know that some QA is testing their code without understanding what is being tested and how that impacts them.
The problem is much worst across the Organizing and Making divide. For example, usually, the developer has very little interaction with the end user or the business. You hear sentences like: “the business sponsor is very busy and they don’t have time to be talking to the development team”; “we will be wasting time getting everyone to speak to the users”; “I am not interested in the politics, I just want to code.” This kind of attitude only serves to compartmentalize the software craft. Of course, we cannot specialize in everything but we also cannot close ourselves to only our specializations.
There is a political element to this as well. Managers, Scrum Masters, Product Owners, Agile Coaches, are in a good position to consolidate control. They also suffer from Fractured Skill because they usually do not understand the technical aspects of the software craft, even when they do they have a technical background, they suffer from imposter syndrome for not being up-to-date with the current paradigms, tools, languages, and technologies. The Making side’s lack of organizational skill further widens this divide, causing the Organization side to consolidate control through positional authority. They impose explicit or implicit hierarchy to make sure that they’re adding the “right amount of pressure.” They’re then forced to defend this position by maintaining their fiefdoms. The Making side also resents the organizational side, often regarding them as the “necessary evil.”
Architects overlap the Organizational and the Making side. Those who do not actively work in development teams, and the business, also suffer from Fractured Skill. They lose sight of the real word on the Organizing and Making spectrum. They are akin to the engineers working with CAD but with little feedback from the physical world.
Agile Coaches or any other coaching role is different. Such a role is not necessarily part of the team but an external role to support the development of a specific set of skills within the team.
Are we doomed then? Will we ever bridge the Organizational and Making divide? My view is that we can never expect to specialize in everything but we can ensure that we have a working understanding of the different aspects of software development. The Organizational and Making are not sides, but two extremes on the same spectrum. The idea of the “T” shape describes the skill spectrum of individual team members who have a broad understanding of the skills across the Organizational and Making spectrum and deep knowledge of their specializations. For example, a developer fully understands the business domain but their knowledge may not go as deep as the Business Analyst. Similarly, the Business Analyst may not understand how to develop a feature on their own but they regularly pair with the developers to explore a new feature. The developers must share a good understanding of the product and the product owner must understand the technical considerations from the developer’s perspective. The Product Owner must understand how the Testers verify the system and similarly the Testers must understand the product roadmap and the feedback from the customer.
The skill of an individual team member is fractured when they have little or no knowledge of another role within the team, or worst yet, when a role, that is part of the software development skill, exists outside the team. You can have someone located within the team and still not behave as a part of that team. Being part of the team means that members are in constant cooperation with each other to achieve a common goal. They are making sure that all their work is understood and visible to the rest of the team, that the rest of the team has an active participation in their day-to-day work.
All roles within a software development team must understand that all aspects of software development concern them, albeit at different levels. These include: coordinating the project, managing risks and dependencies, understanding the customer, supporting the production system, deploying a release, managing business and technical risk, developing and testing the features, managing the time and the budget, and more. It is difficult to be mindful of these myriad concerns but the alternative is that you are not fully performing your role. The alternative is “Fractured Skill.”
Recently, I was reading the State of Business Agility survey from CA Technologies, and it struck me that according to this report, only 12% of organizations are on the path to achieving Business Agility. Only 12 percent! Hasn’t Agile been on the scene long enough to show the value it brings – not only to software development teams but across the business?
Thinking it through, I’ve seen first-hand how challenging it can be to realize true business agility – and, through a number of conversations with my clients, can share some of the biggest misconceptions and challenges organizations face when they think about bringing agility across their organizations.
I typically receive mixed reactions when I discuss business agility with my clients. Some leaders are excited to blaze new trails, while others were leery when realizing that they’d be forging a new path forward. It seems we went back in the innovation diffusion curve! This must be a new evolution! Early adopters – or those who realize that without change, they’re facing imminent doom – will embrace business agility and vie to test it, while the majority will need it proven with risks sorted out. In other words, we will need to cross the chasm with business agility. At least that is the case in traditional industries.
Business agility is new, and most don’t agree on a definition. Let us start with some myth busting on what it is not: it is not merely software delivery teams embracing agile methods and mindsets. It is more than training product ownership and management to support agile delivery teams. It is even more than engaging business people in Agile delivery. These are all “hows” to a bigger picture.
CA has codified business agility, based on its own transformation and operating as an agile business: removing friction between ideas and outcomes, to get to the shortest sustainable path to customer value. I see it as having your entire business, company, etc., operating as one organism with the same heartbeat; so that you can better sense and respond to change and market disruption. The “Why” is being able to pivot on a dime when necessary. Yes, there are the components mentioned above, plus more: transforming enterprise strategy settings and linkages to execution, portfolio planning and budgeting functions, business operational agility, and executive engagement.
This is not the first time I’ve encountered, “we once put an Agile Coach in front of the executives, and we will not do it again.” Before we discount all Agile Coaches for business agility transformation, let us first consider their background. The Agile consulting industry is still evolving, a standard does not exist for the “Agile Coach” title, it is mostly self-proclaimed. Many coaches grew from programmers or project managers, they became coaches because of working with Agile delivery teams. That does not necessarily prepare them to handle broader business transformations nor executive conversations. That trend is starting to shift, especially as Agile has become mainstream. We now have executives entering as Agile coaches, successful Product Managers, MBAs and startup strategists, are now coaches. You need a consultant that has depth in both their Agile experience as well as the right business and leadership background.
So, now what? Take a deep breath, recognize that you are an early adopter that can help shape this space, think big, and learn from innovative organizations as you take yours on the journey to business agility.
Go ahead, include it with the others. “Fail” has gone full buzzword.
Shield your eyes (if you can) from the event banners, the blog post headers, the office posters, all with “fail” and “fail fast” writ large. Can’t we do better than grease the wheels of the failure bandwagon?
Let’s forget failure. What matters is how you fail. What’s most important is a desire to learn, and to keep learning.
The business world is volatile, it’s full of ambiguity and complexity. What worked last year might not work this year or the next. To stay effective and relevant, we must try new things. New things that might not work, that might “fail” – and you keep going.
The biggest failure is to repeat last year, to repeat a previous failure. That’s the distinction. Sure, go ahead and fail fast. But you can just keep doing that, and will keep doing that, unless you learn from the process.
Part of the problem is that the trendy use of fail challenges how we normally understand the word itself. To fail means to lose strength, to fade away, die, or stop functioning as usual. It’s no wonder that the posters and presentations promoting “fail” have little or no impact on company cultures. Fail fast? Not exactly motivational.
Because it’s more than merely accepting failure, more than adages about the importance of failure, more than how artistic and creative and product-driven endeavors require a willingness to take chances and make mistakes.
It’s the learning from failure and applying that wisdom.
I see a difference between fear of failure and the fear of not being successful. It’s subtle, but it’s perfectly natural not to want to “embrace” or celebrate not being successful. And it’s perfectly understandable to have a fear of not being successful. Because nobody wakes up and thinks, “Yes, I’m going to excel at mediocrity today!”
So, rather than fail, and failure, and failing (fast or slow), instead let’s talk about how actions lead to lessons, and the better you get at observing your process, and learning from all the lessons that are a natural consequence of creating, the more successful you’ll become.
A powerful approach to putting this in action is to lean into the growth mindset, which is our desired modus operandi at my company, Atlassian. And, yes – part of that is, in fact, “embracing failure.” But rather than calling failure out, it’s more like: of course, that’s part of being in action. The reframing is, if you don’t “fail” (by which I mean have a growth mindset, try things, and keep learning), the only thing you’ll do is fail.
Learning new things requires us to come up with ideas, and use a combination of data along with our accumulated experience and intuition to keep trying new things. The fruits of these experiments are lessons. Some things go well, and you double down on them. Some things don’t, and you study why they didn’t and share those lessons with your peers and teammates.
As a leader, build an environment (people, practices, tools), that enables creativity and curiosity to flourish. Ensure that you are learning along the way. An environment where assumptions and hypotheses are tested, where early feedback is sought, and where the mindset is all about experimentation and exploration – that’s where real innovation lies.
This idea of, “We’re a certain size, therefore we need a certain amount of structure and certain ways of doing things” should be challenged. That’s where a lot of really successful companies become mediocre.
When you’re small, you take calculated risks; when you become successful and have something to lose, you get conservative.
Some companies experiment in labs and others innovation rooms, with the idea that you need a physical space for people to go and innovate. These worry me because they have a tendency to get detached from the core business and can’t assimilate their ideas back in.
These forms of “experimentation” inside otherwise stagnant companies seem like hollow tokens of innovation, ways to placate senior management and the board of directors. I think the entire company should be a living laboratory where experimentation is simply business as usual, and tolerance for (strategic/smart) risks are built into the operating model and the only true failure is the failure to learn.
I believe innovation exists in everyone. Which is pretty radical, especially if you’ve worked in an environment where innovation was beaten out of you, where your fear of failure kept you from stepping out on any ledges at all. This philosophy of innovation is a direct challenge to that.
A 24-hour innovation ritual – ShipIt
During ShipIt, Atlassians across the globe get the same 24 hours to set aside normal projects, form ad hoc teams, and work on whatever they want. Tech and non-tech teams alike hack away for those 24 hours, get three minutes to present their ideas at the end, and then there’s voting. The only prize? Bragging rights. And the satisfaction that what you’ve done might help the organization. ShipIt offers the perfect opportunity to learn about learning. That is, the ability to work on anything that’s inspiring you, with complete “freedom to fail” (read: opportunity to learn), teaching you how to bring that same way of working to your everyday practices and process.
A dedication to learning is the foundation upon which a culture of innovation can be built, and believing innovation exists in everyone – as I do – is the purest way to inspire “be the change you seek” (an Atlassian core value) which is how it’s put in action. I tell new and long-tenured Atlassians these three things:
And, of course, “fail fast.” That’s the point. Maybe that business-y mantra can help some, but I think “learn more” and “never stop learning” are better. Innovators, creators, developers, artists… they all know failure’s part of the process. So ok, sure, let’s “embrace” it. But I think the emphasis should always be on learning, growing, and encouraging innovation. Innovation, mind you, that doesn’t stop when some success comes your way.
Because staying hungry is the best way to ensure you don’t rest on your laurels and continue to push the boundaries of what’s possible.
A frequent answer I receive when I ask about an outcome organizations are looking for out of their Agile transformation is greater accountability. Leadership will say things like “We need our people to be accountable for what they say they’re going to do!”
That doesn’t sound like accountability to me, that sounds like commitment and conviction. Simply put, what is accountability? It’s who is responsible for something. Accountability does not directly correlate or cause commitment to get it done, just who is RESPONSIBLE if that does not happen. If we’re wanting people to be more responsible for things and think that they are not, we have a different issue to solve and need to ask why. Let’s investigate!
Perceived lack of accountability is a symptom of a larger problem in the organization. If the organization believes their people are not accountable or responsible, that points directly to a deficit in trust. We see both in Patrick Lencioni’s hierarchy of the 5 dysfunctions of a team, though avoidance of accountability is not the root problem, absence of trust is.
What I often see as I get to the heart of the accountability issue is that in a command and control culture, “lack of accountability” is a synonym for the blame game. “It’s not MY fault!” “Who was supposed to do that?” “Who is supposed to be responsible for that?” “We have to spend time proving the problem was not caused by us.” When sentiments like that frequently arise during my interactions at an organization, it’s a huge indicator of a problem. I also see an indicator of this issue in role confusion and the frequent ask for a RACI (Responsible, Accountable, Consulted, Informed) diagram to further pinpoint where every function of a role fits.
Does it REALLY matter who needs to do every little thing? Or is it more important for those things just to get done? Sure, people need to have accountability for their responsibilities but when everything down to the smallest task needs to be assigned out, we are essentially micromanaging ourselves and that is defeating a main purpose and benefit of self-organizing teams (at all levels of management).
Yes, our people do need to be accountable, but they need to be accountable to each other before they can be accountable as a team. We must believe that the people we work with are driven by motivations for their work, want to succeed, and are working under the Prime Directive:
“Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” -Norm Kerth, Project Retrospectives: A Handbook for Team Review
One way management often hinders teams in forming trust is by frequently changing their members around, thus causing them to have to re-form relationships. How can we expect people to be accountable to people they have never worked with before and immediately deliver on everything that is expected of them? Those are unfair expectations and teams are at a disadvantage from their inception (which repeats every time a member is relocated).
Another way trust is hindered is lack of involvement in the actual plan that the accountability is perceived to be lacking on. A key piece of information I’ve taken out of graduate change management classes is that we need to invite people to the change and invite them to be a part of the solution. Agile trainings have missed this point at times when discussing product ownership and product management. Those roles have the final priority win – every time – but if they are not collaborating and involving the people doing the work they are more likely to get it wrong. Priorities will lean toward subjective over objective and as a result the team will not be as invested, committed, accountable to the plan because they have less trust for it (and it’s likely worse for the customer, too).
Organizations that do not include the necessary players’ input in forming plans often face constant change and churn of that plan. Team players are not only development teams but the teams that help to prepare the work for them to develop. Often management teams spend much time delegating to the teams they lead, but it’s the teams they are a part of who cause the majority of the politics and conflict in consistently and rapidly changing priorities for the teams they lead.
Changing a plan is not bad, but the excuses and frequency often are and the implications turn to distrust in the organization and management. The shifts organizations feel they need to make are driven more by internal politics than market need. We think our organizations need to be able to shift priorities any and all the time if necessary; we’re “agile” after all, right? That is NOT what “being agile” means. This is not pivoting relentlessly, it’s pivoting recklessly. If leadership/management teams cannot commit and be accountable to a plan for a short period of time (and a quarter is short in context), how can we expect the teams we lead to commit to the plans? The development teams pay the price for not delivering on something that is far from certainty because it’s often viewed as lack of accountability to a plan they weren’t trusted advisors in.
Accountability was never the problem; trust and inclusion are what translate to true commitment and conviction. Until we solve those problems at all levels of the organization, we will always wrongly see accountability as the issue and chase relentlessly after a symptom while ignoring the root of the problem.
Nowadays Scrum seems to be almost a buzzword in the IT industry – a lot of people talk about it, but what does using it really mean? I decided to interview my coworker Piotr to find out – check out what kind of Scrum mysteries he decided to unveil!
What does it mean for you to be a Scrum Master?
First of all, working FOR the team that I cooperate with. Lately, I’ve had to focus on coaching the whole organization surrounding the team.
What are the five adjectives that perfectly describe Scrum?
I would like to quote the Scrum Guide – Scrum is lightweight, simple to understand, and difficult to master. To add something to it, I would say that it’s efficient when appropriately used and gives a real bite to a product.
What misconceptions about being a Scrum Master irk you the most?
That Scrum implementation resolves all organizations’ problems. It’s totally different – it will put them in the spotlight. However, it’s easier to shift the blame onto an “overrated framework” than to look for internal problems hidden deep within the company.
What are the main responsibilities of a Scrum Master?
Being a Scrum ambassador and advisor, which means ensuring that every team member, a well as the whole organization, has a proper understanding of the Scrum framework and knows how to use it.
How does the role of Scrum Master differ from the ones of Project Manager and Product Owner?
Ohhh… it’s hard to talk about the difference between PM and SM or PO because they have different responsibilities, even if they have mutual goals to achieve. A Scrum Master should be a “servant leader” for the team which opposes the traditional project management approach.
Take into consideration that the PM position is not present in Scrum because it’s a very lightweight framework that is distinct form methodologies like AgilePM, where project-level roles are existent.
End the sentence – “If you are a Scrum Master, you have to be…”
A very good listener.
Let’s think about the people that would like to be certified Scrum Masters, just like you. What can they do to achieve that?
It depends on the real reason behind getting certified. Scrum is very popular nowadays, and there is a pretty numerous group of people who want to be a certified SM just for the certificate itself. The Scrum Guide would be enough for them…
If your top priority is to gain valuable knowledge, then it’s best to extend the list of “must have” knowledge sources. For me, the most important are local meetings with an Agile society. Of course, events like AgileByExample (ABE), although very worthwhile, are uncommon. It’s good to read a variety of books (the bad ones too) to be familiar with the different approaches to Scrum.
What is your advice for companies that are planning to introduce Scrum? What challenges await them?
Now I know that not a Scrumbut, but a real Scrum Coach might be necessary for some companies if they want to implement Scrum. If you don’t have a budget for an additional vacancy, you must be sure that you have an experienced Scrum Master or Scrum Masters who will take care of compliance to the rules during the whole process of the framework’s implementation. And remember – engagement of management is crucial!
Talking about challenges, what are yours as a Scrum Master?
Working with people, of course! Working with individuals and with team-players is extremally different.
Walk us through your day-to-day responsibilities as a Scrum Master.
Each day is different, but there’s still a place for routine – all Scrum meetings are planned and constant. My other activities depend on the current situation.
What do you have to do when it comes to motivating your teammates?
It depends… There are no universal techniques that work in all situations and with all teams or team members. The best motivation comes from the inside of the team, but it’s not easy to extract it.
What’s your recipe for dealing with problems in the project?
Like in personal life – there are no magic tricks that will solve your every problem! I must analyze each situation and prepare a made-to-measure solution. Even if I fail, I try to learn something – lessons learned are the most valuable part of each decision.
Which tools are essential for every Scrum Master?
Talks and chit-chats!
What surprised you most when you became a Scrum Master?
The current level of knowledge about Scrum in companies which declare that they are using it. Sometimes it has nothing in common not only with Scrum but also with Scrumbut! The sentence “we work in Scrum” is definitely overused!
Tell me what are the most difficult parts of being a Scrum Master? What needs fixing?
Each day I learn something new, my knowledge about Scrum evolves, but I know that still there’s still a long way to go until I feel well prepared and experienced.
But let’s end it on a good note – how has becoming a Scrum Master improved your professional life?
I’ve changed my approach to software development and team-work. It has boosted my skills quite a lot!
And that’s it for now! There are more things to come – expect to learn even more about the ins and outs of not only Scrum but also the whole backstage of working in a software house!
At Atlassian Summit this year, we heard from author Kim Scott, who’s spent years studying the best way to give feedback, and eventually wrote a book on it called Radical Candor. In a previous article, we covered Kim’s elements of Radical Candor, but today, we are going to dive into some practical ways you can get better at giving (and receiving) feedback in your work.
If you want to be good at giving feedback, you also need to be good at getting it. Remember the old saying, “Don’t dish it out if you can’t take it”?
You need to feel comfortable asking your team or direct reports for feedback, and in doing so, you help establish a culture where feedback is not something to be feared, but a normal part of working as a team. One way that Kim recommends eliciting feedback is at the end of a one-on-one meeting with someone.
This one may be obvious, but if you want to give good feedback, you have to practice! And remember, it is practice, so you will fail along the way. Just keep these things in mind to help you out:
“Radical candor get’s measured not at your mouth, but at the other person’s ear.” – Kim Scott
One of the truest things about feedback is that it’s all about your audience. It doesn’t really matter how good of a job you think you did sharing feedback, if your hearer feels hurt or attacked that is on you. A good way to measure your feedback is to use the Radical Candor framework, and ask people how the feedback you offered landed for them. Sharing this framework among your team provides everyone with a shared vocabulary for offering good feedback.
Having a healthy feedback process at your workplace isn’t something that is just going to happen naturally. It takes a champion, like you, to encourage people to respond and communicate well with each other. Especially if you are in a leadership position, and you have people coming to you with complaints or seeking advice, insist on “clean escalation.” Here’s what that looks like:
Now, you may be thinking, “that’s all fine and good for some companies, but my company is different. That would never work here.” That may very well be true; every company culture is unique.
But Kim reminded us that it’s universally human to value love and truth. No matter what your work culture is like, remember that radical candor is measured at the ear of the receiver, so meet your coworkers where they are, especially given the business context you work in.
It takes a village to give good feedback, so please, share these ideas with your team, help them learn about the framework, and start having better conversations. And if you haven’t yet read our first article about Kim Scott’s elements of Radical Candor, give it a read through, too.
In Agile project delivery, a common escalation from the client is that “the feature with expected functionality is not delivered on time, even though we shared the expectations, well in advance.” The application users may complain to a support executive that “the feature of the application is not functional, while a similar feature of other applications performs.” In a nutshell, a well-planned and organized software development model is also facing a communication gap between the expectation and delivery.
Enabling BDD processes and implementation of Acceptance Test Driven Development will help to close the communication gap in Agile project development, up to an extent. In the BDD enabled environment, Acceptance Test Driven Development plays a crucial role to check whether the feature is developed and delivered as per the expectation of the business users.
ATDD is closely related to Behavior Driven Development (BDD), where the development team, QA team, and business analysists work together closely to understand the application’s behavior. A ubiquitous language called “Gherkin” is used to gather the behavior of the proposed feature with the ‘Given, When, Then’ Format.
ATDD is a practice where the development team, business analysists, and QA team will collaboratively discuss the feature which they are planning to develop and to deliver in a short span of time. Acceptance Criteria, with examples, will be defined and distilled into a set of acceptance tests before the actual development starts. The developed feature will be considered as completed once the acceptance criteria have been fulfilled.
Select User Story.
Write Acceptance Test scenarios based on Acceptance Test Criteria.
Execute Acceptance Test to “Fail” (Before User Story Implementation).
Implement User Story.
Execution of Acceptance Test by the development team.
Make the Test pass.
Get User Story Signoff and push to the next level. Refer to the pictorial representation of ATDD workflow for more clarity.
As mentioned before, BDD uses a ubiquitous language called Gherkin in ‘Given, When, Then’ format, which helps BA/non-technical teams to describe the feature’s behavior and its expected scenarios.
Gherkin is a business readable, domain-specific language created to describe the behavior of an application or feature. It is a line-oriented language that uses indentation to define the structure. Line endings terminate statements (called steps) and either spaces or tabs may be used for indentation.
The main moto of Gherkin is to write concrete requirements (features, scenarios, and steps) with its predefined keywords. The pre-defined keywords of Gherkin include Feature, Scenario, Given, When, Then, And.
Refer to the picture for a sample of a feature file prepared using the Gherkin language.
Open source tools are available in the market to perform Acceptance Test Driven Development. They are:
The ATDD implementation starts with features and their associated scenarios. Before starting the implementation, configure SpecFlow and Selenium with Visual Studio.
The following IDE/Tools are required for implementation:
|IDE||Visual Studio (Except Express edition)|
|UI Automation Tool||Selenium|
Create a new Visual Studio unit test project and name it appropriately.
Delete the Unit Test file listed in the project.
Install the required NuGet packages for the project.
Generate a Step Definition by selecting the Generate Step Definition option (right click on Steps in the feature file to get the Generate Step Definition option).
Refer to the below picture for the Generated Step Definition file.
(Added simple code for smooth execution)
Once the tests are passed with the refactored code, the next step is to push the feature to the next phase of testing, production.
ATDD enables the Agile development team to enable a Shift Left approach. It helps them to qualify feature development in the earlier stages of the SDLC and ensure quality from day one of the project.
Earlier this year while driving home from a client visit, I was tuned in to the (Jake) Query and (Derek) Schultz program on my local Fox Sports provider. A topic of the conversation during my drive home was how one of the two hosts had become hooked on a cable television program called Live PD.
Intrigued by what Derek Schultz had to say about the program, I decided to tune in to Live PD that next weekend. The show caught my attention and is something I have scheduled on the DVR when new episodes appear.
According to Wikipedia, Live PD is a “non-fiction program that follows police officers in the course of their duties but is unique in the fact that the footage is being broadcast in real-time, nationally. The program features live video feeds from multiple (usually six) law enforcement agencies throughout the United States.”
Basically, teams of law enforcement are performing their duties on Friday and Saturday evenings, from 9:00 pm to midnight (EST), accompanied by a film crew and remote producer. Their actions are recorded live (with minimal delays to sensor personal information, if needed), with the officers educating and updating viewers from time to time.
As I write this article, Live PD is celebrating their first full year of broadcasting the activities of law enforcement around the United States. While I haven’t watched the program a great deal over the past year, there are some lessons that I observed during my viewings that can apply to life as an Information Technology (IT) professional.
Hands down, the most repetitive action I have observed is the inability for those being questioned to be open and honest about their current state. On the show, this can range from the suspect’s current activity (what are they up to) to communicating if there are any illegal substances on them or in their vehicle, to being straight-forward about weapons being in the vicinity, to (believe it or not) providing their real identity.
This is really no different in IT.
Consider an example where a production support team has to diagnose an issue with an existing application. With staff attrition and use of external partners, there are times when the only source of truth is the underlying program code itself. Reading through thousands of lines of code can become a daunting task and one that can lead to incorrect results when method names do not reflect current functionality or comments in the code are simply not right (as I noted in one of my favorite articles “Code Commenting Patterns“).
This is really no different than an officer trying to quickly ascertain what is valid and what is invalid. Many times, we have limited information and have to make quick decisions, while under the extreme pressure of trying to resolve an issue.
When law enforcement responds to a situation, often times it is the result of someone trying to get away with something. Maybe the suspect is in the process of breaking and entering, transporting drugs across state lines, or squatting on a property which they do not own. In these cases, the result is a failed goal of trying to get something for nothing … or to simply cheat the system.
This idea parallels the often-repeated solution to cut corners as part of the development lifecycle. In my view, the biggest occurrence has to be situations where a lack of unit tests exist for production program code.
The path to this situation is often the same. Planning work begins, with trying to establish a project plan (on Waterfall projects) or a Sprint planning sessions (for Agile projects) – having expectations that every line of code will have a corresponding unit test to validate the desired functionality. As the project begins, unexpected events happen – which can range in a change of direction or additional details being discovered once development is underway. Knowing there is a limited amount of time before the published delivery date, the decision is made to forego the creation of unit tests and focus on delivering as much functionality as possible on the expected due date.
Taking the unit tests out of the development lifecycle is basically trying to cheat the system. The leadership team is basically rolling the dice, hoping every developer kept every requirement and scenario in mind to avoid introducing unexpected results. Like the criminal trying to cheat the system, the resulting approach is a short-term hope with the potential for a long-term disaster.
I’ve seen suspects lead teams of law enforcement on pursuits that span a large portion of the three-hour broadcast of Live PD. I have also seen suspects opt to flee the scene, pushing away from the officers and racing into the darkness. In every case, the teams (often employing some pretty amazing K-9 units) capture the suspect without issue. It is at that point that I find it interesting to watch the suspects actions from a psychological perspective. The suspect is caught and their demeanor changes to a calm and far-more subdued behavior.
Within IT, consider the example where a team member introduced logic which led to an unexpected issue. To avoid being associated with the issue, the team member may keep the details behind their actions to themselves, hoping to keep from being caught. While I try to tell my team members to be open and honest about mistakes, that can be a difficult barrier to overcome in the heat of the moment.
Just like the officers on Live PD, the root cause of the unexpected issue will be determined and the person behind the situation is recognized. Based on the severity of the issue, corrective actions can range from a one-on-one discussion to initiation of a disciplinary plan maintained by human resources.
In both interactions with law enforcement and your IT team, honesty is always the best policy and can be a huge time-saver when trying to get to the bottom of an issue.
I wasn’t sure if I would enjoy Live PD when it was discussed by Query and Schultz on their Fox Sports talk show program. However, I have gained a better appreciation of the daily activities behind the scores of law enforcement professionals who make our country a safer place. Watching multiple episodes gives one a familiarity with the officers in each area of the country, providing the opportunity to know them on a more personal level.
From a sociological-perspective, Live PD is an interesting view into human behavior, that I believe a majority of viewers would have not otherwise had the opportunity to experience.
Most notably, the show allows me to draw similarities to our world of Information Technology, which is something I always enjoy doing.
Have a really great day!
Jason Hand is a DevOps Evangelist at VictorOps and author of Post-Incident Reviews, a new ebook about learning from failure to improve incident response. Jason spoke with Marlo Vernon about the writing experience. This interview has been edited and condensed.
JH: Since I’ve been working at VictorOps, the topics covered in the book, especially blameless postmortems, have been not only the most relevant to the company but also the most interesting to me. It’s a very different perspective from what you typically hear in business.
The concept that somebody always has to be held accountable is a twist on what I had learned about IT and about managing problems. There are many guides, templates, and blog posts about doing postmortems, but there isn’t a lot of material that goes deeper into why we do them, their purpose, their value, how to understand complex problems within systems, root cause, things like that. I thought this topic was in line with what VictorOps stands for, and is helpful for a lot of people.
Post-incident reviews are part of a family of retrospectives called learning reviews. The point of them is to simply learn as much about what the “system” is doing at any given time, including the people part.
When you do a learning review, you try to expose as many observations or learnings as you can. The more you can identify what information isn’t common knowledge, the more it should be surfaced and shared among the group. That way, everybody has the same awareness and the same expectations about what should happen.
There are many different things you can learn: how people interact with each other, where information on how to resolve incidents is stored, and who has access to which systems when they need them. A lot of this isn’t discussed in most settings.
The lifecycle of an incident as we define it at VictorOps goes through five steps and starts with detection.
The detection phase kicks in when some expectation with the software or infrastructure is not being met. Monitoring services will detect the situation and then let somebody know.
The next phase is the response phase, which is focused on getting the right people together to deal with what’s happening. So if you’re using a service like VictorOps, there will be some sort of paging and escalation policy in place. They’re all designed to make sure that the right people are alerted to the problem as soon as possible.
The third step is the remediation phase when the people have looked into what’s going on and are starting to take steps to fix the problem and restore service. At that point, the incident is “resolved,” paging stops, and the incident can be closed.
The fourth phase brings in some sort of analysis of that whole process. You go back to the beginning and ask, “What can we do better about that? What happened in the response phase? Can we shorten the time it took to respond? What happened in the remediation phase?”
Then the fifth and final phase is the readiness phase. This is where you take what you learned and try to make proactive changes, enhancements, improvements, and countermeasures to make the system better. That way, the next time something happens, the whole lifecycle might be shortened because you’ve found a better way to detect the issue or solve the problem. It should help you shorten the whole lifecycle, but you’ve got to go through all five phases.
The main reason why blaming can be so detrimental is that it actually creates incentives to not share information. If people don’t feel that it’s safe to share information so that you can learn as much as we can, then you’re missing out on the opportunity to make things better. I might be afraid to speak up, even though I know that there’s a problem in the system. If I had spoken up, I could have helped the team make improvements. It has to be a safe space.
The first takeaway is that your best bet for increasing system uptime is by improving the ways that you learn about and respond to problems. There are a lot of companies who spend too much time focusing on “root cause.”
This leads me to the second takeaway: please consider moving away from searching for a root cause. Most systems are complex, so there is usually not a single root cause of a problem. I hope people recognize that when you think you’ve found a root cause, you stop asking questions. All those additional questions could have been helpful for learning more about what’s going on.
The third takeaway is that there is no real prescriptive approach to conducting post-incident reviews. I offer some basic guidelines and some suggestions of things you want to try to capture, but what works for us at VictorOps, or what works for any of our customers, isn’t going to work for every single team. Hopefully, you’ll absorb the ideas in the book and then take that back to your teams and design your own post-incident review in a way that’s going to benefit you.
Read Jason Hand’s O’Reilly eBook, Post-Incident Reviews.
Early in my career as a software engineer, I never thought about process – to be honest, it was irrelevant in the large scheme of things, just something that hampered my team’s progress. Fast forward to today and here I am, making process, or more precisely, ‘methodology,’ front and center in everything I do. I could have never imagined it would be so important! And Agile? No way! True enterprises don’t do Agile, won’t work for us. Now that’s all I talk about. Funny how things change.
I was at the Agile 2017 event, speaking about the future of Agile and meeting lots of practitioners and methodologists like myself who have seen great strides in the growth and popularity of Agile at scale. Read on to get a recap of my session Do We Still Need Business Analysts and Systems Engineers? Now More Than Ever!
In this session, I talk briefly about the future of Agile and the importance of what some may consider traditional roles in this new world. I remember well what it was like to be an engineer… that’s where I started my career. Today, I am a solution architect, a role very much aligned with business analysis and systems engineering, and I have realized that there is so much value in knowing both the business and engineering perspectives.
In fact, Business Analysts and Systems Engineers are the new sheriffs in town, wearing many hats, from designers to advocates, and they work closely with their customers to not just help organization speed delivery cycle time, but more important to ensure faster time to “happy customer.” This is the fundamental wow factor behind an organization’s Agile transformation.
Consider three essential tonics for your Agile transformation:
Delivery of value: It is not just about engineering anymore, it requires knowledge and collaboration between business and engineering, working together to achieve the desired customer value.
Focus on business analysis and systems engineering: Enterprise scaled Agile specifically addresses the new sheriffs in town. Business Analysts and Systems Engineers are the organizational change agents defining new solutions and innovation.
Outside-in “design thinking”: It is a key element of successful product and software delivery of the future. We need design thinking to bring together a unified vision to wow not just the customers but also the executives and business stakeholders. This approach will help to get to the “Why” before the “What” behind the very idea of doing it. Agile will remain a foreign word until you try your hand at it.
A few weeks ago, we gave you a breakdown of the basics behind user stories. Now that you know what they are and how to write effective user stories, there’s one more thing to learn: how to avoid writing bad ones.
There are a few common mistakes that happen when writing and developing user stories. Anyone who has worked on a Scrum team or has written stories in the past has likely made all of these mistakes once (and usually more than once).
Here are four common mistakes you might make when writing user stories, and what to do instead to avoid them.
User stories are specifically written to describe the what, why, and for who – but not the how. A user story should not describe to the developer how to accomplish the feature. It’s intentionally left open-ended to allow the creator freedom to decide how to best accomplish the end goal. This might be one reason why developers creating in an Agile environment have been found to have higher job satisfaction than in non-Agile environments. They’re more able to influence technical decisions and tend to have a higher degree of autonomy.
A non-technical product owner or client will have no problem avoiding this one, but one with a technical background (maybe a former developer or someone playing the role of product owner and developer) may be tempted to influence the decision-making for specific processes.
How to avoid it: Give your team the ability to be honest and correct you if your user story includes too many technical directions. If you’ve committed this user story sin, it’s likely your team has already noticed. If you’re reading this and worry you’ve been guilty, bring it up in your next retrospective and ask for honest feedback. Going forward, ask yourself if your user story answers, “How will this feature be achieved?” If it does, remove it.
It’s important to clearly define who the user in each user story is. It can sometimes feel silly typing the same type of user over and over, but it does matter. Often products have multiple end-user roles or personas. The more specific you are in describing this role in the user story, the more tailored the end result can be for this person.
This is particularly important if you’re building a product that has multiple types of users – like an admin and a customer. Some features will be built for the admin’s benefits, and others for the customer. It’s important for your developers to know the end-user that will benefit from the feature and have their preferences in mind when building it.
You might also have two or more distinctly different personas of customers who are using your product, like a banking app that is used by both personal and business accounts. Each of these personas may have different primary uses for your app, even though the basic functionality will be the same.
How to avoid it: If your app interacts with multiple personas, clearly describe the user in each user story to avoid confusion. This means the “As a…” statement won’t just say “user,” but will describe exactly who will benefit from this new feature.
Like we explained in our first blog post on user stories, user stories are generally written in the format: As a (type of user), I’d like (end goal) so that (reason for end goal).
The “so that” statement at the end of each user story should describe the business value of the end feature for the user. What often happens is this statement describes the specific function that the development team needs to build instead – it’s easier to think up and describe because it’s more tangible.
How to avoid it: Double check your user stories to make sure you’re describing a benefit for your end user instead of a technical feature.
This issue is self-explanatory, and perhaps the most common one that occurs when writing user stories. It’s very, very difficult to break down feature ideas into small user stories. It takes time and practice to get good at, so don’t expect to get it right on the first try. And you likely won’t actually realize your story is way too big until you’re nearing the two-week mark in your Sprint and the story is nowhere near complete. But after a few Sprints worth of work, the entire team will surely notice when stories are too big and need to be broken down further.
How to avoid it: Always start with an epic and work down from there. If you have an idea for a new feature for your app, it’s likely that this broad idea isn’t a story, but an epic. There will be many user stories within this new idea.
Let’s go back to the banking app example. Based on user feedback, you decide to implement a new feature in your app: the ability for personal and commercial users to transfer money to outside accounts.
While this seems like just one feature, there are many layers to accomplishing the desired result. A user would need to view and add an external account, an admin would need to verify and approve this external account, there needs to be an interface for the user to choose how much money to transfer and when to schedule the transfer – and that’s just the most obvious steps.
If you’re new to writing user stories or developing products based on them, these common mistakes will happen. By knowing what to look for, and what to do when you encounter them, you’ll be better prepared to write effective, concise user stories in no time.
We software developers are a fortunate lot. We love what we do, and a lot of the time, when we’re actually building software, we’re very happy people. Unfortunately, this isn’t universally true since so many software development projects require developers to do a lot of other things aside from writing code such as sitting through boring meetings and building documentation or other artifacts. This is not as enjoyable to us as facing the challenge of solving unknown problems, learning and discovering as we go. This is what attracts us to writing software.
Professional software development is fundamentally different than most people think. It has nothing to do with using software or networking or virtually anything else. Building software is an immensely creative activity.
One of the questions I ask almost every group of students I teach is do they think writing software is more art or science. The majority of developers say that although there are elements of both, that software development is more art than science. By this, they mean that there’s more creative and abstraction skills required to be a good software developer than there is an explicit process. Of course, it takes a tremendous amount of discipline to write even the simplest of programs but this is an area where we get addicted to growth. Developers love the challenge of building things that have never been built before, solving problems, and providing tools that improve people’s lives.
We really don’t conform to the typical stereotype of the antisocial nerd or geek who found friendship in silicone circuitry. Modern software developers come from all walks of life and all backgrounds.
Writing software is perhaps the most engaging and challenging profession of all. Software development requires a greatly diverse set of skills and we have to be good at all of them to be successful. To design software takes a tremendous amount of creative visualization-after all, we’re using our imagination to understand a problem and model its solution. To write software requires a great deal of tenacity-we must keep track of a large number of details and use a whole variety of techniques to manage the enormous complexity of even a relatively trivial program. To debug code takes exceptional analytical skills-completely different from the skills required to design software, but developers must be good at both. As a result, we tend to use both sides of our brain in the process of building software, and this can make for a highly satisfying experience, but also a highly challenging one.
I’ve asked a number of non-software developers what they think the process of writing software is and I’ve heard of lots of different answers, none of which are anywhere near what the process really is about. I supposed that’s true for other fields. Professional acting is much more than just pretending. Great actors become their characters and transform into another person. It’s a great skill to have and certainly very few people have it, but what they do is not anything like the title of their profession implies. They are not act-ors, they are “be-ors.”
I know people who have gone into the restaurant business because they love the process of sharing food with their friends. But preparing five hundred meals a day is very different from sitting down with your friends and enjoying a scrumptious dinner. Chefs are some of the hardest working people of any profession. It’s a highly intense environment, which is why a lot of people drop out of the profession. I think a lot of people in a lot of fields feel like they have to make compromises because that’s just the way life is, and perhaps it is for many of them, but software developers still find fulfillment in our work every day we actually get to build software.
Of course, it takes an enormous commitment and it’s certainly not easy to break into the profession. Most of the developers I know learned what they needed to on the job or through a lot of self-study. As such there’s a huge divergence in skill sets and knowledgeability in this industry. There is no set of clear standards so it can be challenging to work on teams when everyone has their own ideas on how to do things.
Writing software is a group activity. Most software development projects do not have coders siloed from each other just turning code out. Most of the code built for business today happens in a subdued environment that requires entire teams of individuals to work together. Of course, developers aren’t really known for their social skills, but a lot of that is changing as we realize the desperate need for communication among teammates.
How do you evaluate a design?
This is a question I often ask software developers in my senior advanced software design classes. I tend to get blank stares in response, not because they don’t know how to evaluate a design but they rarely have a common rubric to apply. This can be a challenge for teams, making it hard for us to communicate and collaborate when building software. So I spend a lot of time in my classes defining terms that will serve us in being able to evaluate what’s virtuous in software designs.
Developers love my classes because they immediately recognize the value of talking about and thinking about these things. I’ve had the chance to work with many senior software developers and I’ve made it my mission to find out why the successful ones are so successful then I share that with other developers I work with. It seems as if we each have a piece of the puzzle, and when we put it together we get the big picture. That’s precisely what I do in my work, which is amazingly satisfying.
One of the most underrated aspects of a quality business is having a team that works like a well-oiled machine. Your business tends to only be as good as the people who work there and making sure you have people who care about the success of your business can make a huge difference when you want to feel good about where your company is going in the long run.
Here are reasons why you might want to consider taking time to develop the right team for you.
Having employees that are devoted to your business can make a huge difference in terms of hiring and how much time you spend finding workers to replace those who might leave. You want to feel as though you are putting together a team that has your business’s best interests at heart and that won’t want to abandon you once work becomes difficult. Over time, it can end up saving your company money and can help you develop partnerships with your chosen employees.
Working as a manager can be a difficult part of owning a business, and the more disorganized your team is, the more likely you are going to run into problems down the line. Before you make any major decisions for your company in terms of hiring, you’ll want to think about how a certain prospect will fit in well with your business model and how you can see him or her working with you rather than against you. Find specific people that you can see bringing good ideas to the table but who also want your company to do well.
Like any relationship, communication should be at the center of your business. A big part of making that work is finding employees who want to communicate with you. You want to feel as though they would approach you with any questions or concerns that you might have and that you feel could help your business. Fortunately, even if you have a remote business, channels like Slack and Trello make it easy to talk to people and put together a plan that could work for your team.
A good manager is willing to see things constantly from another perspective. While you can form your own opinions and thoughts, that doesn’t necessarily mean that they are always right or that they can benefit your business. Sometimes, you need perspectives from people who work for you. If you’ve hired an intelligent team who wants to see your business succeed, then it can serve you to ask for some suggestions to see where you can improve. You might not always agree your employees’ views, but they can help you know where they think your business can shine and what might need some care.
With a little time and effort, you can put together a team that works for you and that also cares greatly about your business and what you can accomplish together. Before you can feel good about your company and where it’s going, you need to have individuals who care about the future and helping you.
How does this effect:
Quality of the code
Obviously, any company prefers to hire experienced developers into the team. The return from them is better. They offer more reliable and creative solutions that are convenient to scale. The senior developer understands the problems and probably knows how to avoid getting in trouble and minimize the number of bugs. In addition, the code for such developers works faster than for beginners, and they know how to work independently.
On the other hand, money rules the world, and juniors are much cheaper. The salary of an experienced developer can double the salary of a beginner. In addition, there are a lot of novice developers, and sometimes one wants to hire one of them.
We at Alconost translated an article about how risky it is to rely on a team of young developers and how this situation affects experienced developers, mentors, and product quality.
The young developer needs a tutor. Not every hired developer will cope with such a task without guidance and clear understanding. Many managers make the same mistake: they recruit many young developers into the same team. They think that if you give the newcomers the guidance of a strong mentor then all their problems are solved. But the mentor is not a magician. Being a mentor is hard work.
Not every developer is suitable to be a mentor. As a rule, the average developer should not undertake such a mission without training in mentoring. The abilities of all junior developers are different, and the mentor cannot teach them all at the same time, especially if the junior team was connected to the team at different times. Creating a team that is overly tied to a lot of novice developers can lead to destructive consequences, and managers sometimes miss the moment of truth and do not have time to cope with the situation.
Usually, the nascent projects are busy and only have a few developers assigned to them. Time passes, and – a buoy! – the project has moved to the stable development phase. You invest more and more time and money, you are under pressure from customers, you feel pressure. Then recruiters-technicians are working around the clock to look for new developers. You can not build a team from some beginners – so you have to resort to shuffling. The commands are re-arranged.
So, now there is a lot of work, and you need to manage a lot of developers. Another manager decides: “I’ll throw them into it, and let them figure it out.” Such a mistake can be fatal, and you will soon find this out. What then? Again, hire someone and shuffle again. People do not like change, especially frequent change. Such measures can really shake up the team members and the team’s chemistry. Colleagues must work to feel each other out and know the strengths of their comrades-in-arms.
Any manager who takes a person on the team makes a decision. If the rookie is experienced, the coach often does not need him. Even with a mentor, the experienced developer is usually independent and knows how to learn on their own. When the developer is inexperienced, the mentor will have to be stricter. The mentor still has their main development duties, and now they take on an extra, pedagogical, load. Every hour new questions can come to him. The mentor should not only help the developer solve the emerging problems, but also teach them how to learn. Otherwise, the mentor will not have time to fulfill his/her basic duties.
When a mentor has several mentees, they can become bored or annoyed with their requests for help and have no time for the main job. A good mentor should be patient and able to listen. Long-term mentoring can sometimes be exhausting, and sometimes you might feel a little burned out.
Not all experienced developers are mentors, and this does not simplify the situation. Naturally, the mentor gets a lower load than the rest. Therefore, a typical manager realizes that if he does not burden the experienced developer with mentoring, he will work more productively.
Make this a rule: when some teammates are busy mentoring the young developers, others must redistribute their load among themselves.
They receive more key tasks and thus allow mentors to teach, and beginners to learn. They are responsible for the progress in product development. Over time, this role can become very burdensome. The manager in charge of the process should not deprive such developers of contact with other team members.
The mentor may find it difficult to keep the bar on the quality of their code high if they have several beginners under their mentorship. If you’re one of the ones who can, then you are worth a lot.
So, how much does the quality of the code change? Probably quite a bit. The scale varies, as it all depends on how much junior developers are expected to contribute, and the types of training they’re given in your company’s standards. As a rule, the tutor will say: “There will be refactoring – we will correct your mistakes.”
Usually, this is nonsense. For the same reasons, there is usually no refactoring, and the quality of the code in this application becomes the “standard” for the entire project. What is the most convenient way to get sample code? In our application. All the standards of code execution are met there. And, why not? Ctrl + C & Ctrl + V, farewell, programming standards, calls.
The quality of the code has suffered. And what about the fragility? When a newbie writes a block of code, he does not yet know where this code might break. The code is called fragile if bugs easily appear in it. For example, a function does not check the value of the arguments, their type, or the range of validation. This is a simple example. But sometimes it’s more difficult to catch a bug, for example, if in the JS code the instruction checks for undefined, but not for null, or if the if condition turned out to be complex, and the programmer did not take into account the order of precedence of operations. The editor viewing the code should be aware of such shortcomings and watch them cautiously. Testing the code allows you to radically reduce risks.
Bugs in Code
Each of them is important and plays a role. Whatever it was, everyone once starts with the first step. No senior developer was born an expert.
You cannot bite the hand that feeds you. It should be understood that shaking and shuffling the team is an intervention that can be costly. If you can not do without shuffling, do it no more than at an interval of nine months to a year. Make sure that mentors do not burn out, and the rest of the developers do not work on wear and tear.
A set of young developers is a tactic with many advantages. If it is necessary to arrange mentoring and to choose the appropriate curriculum for your company’s junior devs, such work can be very fruitful. A novice developer is easier to form according to his taste than an experienced one.
Beginners also tend to have a higher desire and motivation to spend their own time on pumping-up their skills and building a career.
Great talking with Patric Palm, CEO and co-founder of Favro regarding the evolution of enterprise collaboration that is being driven by a new generation of collaboration tools in the market.
From Patric’s perspective, the evolution began as large enterprises began moving to the cloud, and adopting cloud-based services to save money and adopt modern applications that improve efficiency and speed to market.
Now companies are waking up to the need to be secure and have data locality, as well as IT governance. Microsoft led the way with its 365 product while Slack has been moving aggressively against easy-to-use, cloud-based apps like Trello and Basecamp that are not particularly secure.
With Slack’s shared channels, they are enabling organizations to share across geographically dispersed workforces, as well as clients, channel partners, service providers, and suppliers.
Big firms must change with the times. Clients want real-time interaction and transparency with providers as well as third-party partners. Patric sees this trend growing across the organization and deeper into the organization as the accounting department collaborates with their accounting firm and operations and manufacturing collaborates with suppliers and logistics.
Editors Note: Originally written by Mateusz Fligier and shared with his permission
In an earlier article on the NearshoreIT Blog, my colleague Radek Okarmus reflected upon the role and image of IT companies and mentioned the difficulties of building trust with the customer, especially on the Polish market. I would like to take a closer look at this issue, as I get the impression that this is often the reason behind delays to, and sometimes the cessation of, software projects.
One of the most common indications of a lack of trust is a reluctance to cooperate remotely. In my opinion, this is a somewhat paradoxical phenomenon. We live in a time of technological development unprecedented throughout the history of civilization. We can conduct a video chat from Munich or London with a cousin from Australia, or show our parents in Poland photos of our trips from Canada, or study via courses taught by lecturers in the United States without leaving our home in Manchester. Moreover, doctors who are hundreds of kilometers away from the patient can consult and even perform surgical procedures.
So why would a potential customer, on hearing that a developer could work for him remotely, respond as if someone was trying to get him to dive head-first into an empty swimming pool?
Where does this need for control, which may be illusory in practice, come from? Why assume that remote tasks must involve lower quality, as well as security risks? The paradox is that often the same person shares his private network and confidential matters in good faith that no one will use this data against him, yet prefers traditional forms of carrying out projects at work. But technology can carry a threat in both our private and professional lives, because eavesdropping, tracking, or data theft are just as commonplace as the positive examples mentioned earlier. Technology is ethically neutral, but the way it is used is determined by people. Security is also a product of the technologies, rules and good practices used, both privately and professionally. The same is true both remotely and on-site.
But returning to the topic at hand – an unwillingness to work remotely is most often explained by the following arguments:
But let’s look at the facts. Around 70-80% of developers at JCommerce work remotely for clients. Interestingly, these clients are mostly foreign companies: from Switzerland, Germany, and Scandinavia. How is it that cooperation proves successful, despite the tyranny of distance, the rarity of face-to-face encounters (due to the optimization of flight and accommodation costs) and the need to communicate in a foreign language? Communication works smoothly, the quality of service is high, and problems are solved as and when they arise.
It is also important that the customer does not have to take care of office space, furniture, and equipment. Security, which is of vital importance, is ensured through the appropriate management of access and permissions (in accordance with previously agreed procedures). In some cases, the client passes equipment on to the developer, including the computers they administer according to the company’s standards. Remote work is generally not a security risk, at least no more than on-site work.
Finally, we come to the so-called ‘soft’ issues, such as the problem of employee integration. The brutal truth is that if the project is badly run and such factors as chaos, lack of documentation, lack of consistency, or a bad working atmosphere arise, then even the physical presence of team members in the office will not change anything. Developers, whether they are permanently employed or just on a contract basis, will look for other options, and will soon find them in today’s business climate. Conversely, a good atmosphere and efficient communication within the project can also be achieved from a distance, merely by using the appropriate tools and techniques of team management. The conclusion is that the integration of workers and the possible problem of rotation within the project are not in any way dependent on geography.
In summary, it is worth knowingly leaving one’s comfort zone, abandoning the stereotypical limits to development, and exploiting the benefits of remote work, which would mean:
The modern office is getting smarter. It is using the right smart office technology for the modern workforce to help employees perform in the best possible environment. However, bringing a change to the company culture is a daunting task. Nothing can be worse than your employees working in a negative environment. They spend most of their hours in the office and don’t want their life to be sucked out in those 8 or 9 hours each day. So, what does an office work culture mean?
Culture is all about the employees and making sure they are in a fun and productive work environment.
We need to take care of our office work culture. We know that happiness means more productivity. And a good work culture will bring happiness. So, for companies, it is worth the investment to build their culture that involves up-to-date technology, gadgets, and a warm working environment.
People are stuck using outdated technology.
Employees do not like coming to the office.
Working hours and holidays are always an issue.
They are more attracted to how other offices are working.
Employees are not socializing apart from work.
Meetings are quiet and boring.
If these describe your office, then your office culture is really toxic. It’s your company’s unique beliefs, mission, vision, and values, it’s vibe and passion that will bring the change. A few organizations’ nowadays recognize that culture is a way to drive business performance. Here are the things that these organizations are doing to bring about a positive change in their office culture.
Technology is changing and it is bringing a change in how we interact with the world, including our colleagues. The recent progress in artificial intelligence is dramatically changing our personal and professional lives. Artificial intelligence is making innumerable changes in the trends of office work culture and it has made it possible for a building to decide when and how it should modulate temperature, air quality, and more. It is becoming capable of understanding how people work and automatically optimizing building control systems to efficiently meet the needs of everyone.
For a modern smart office, real-time collaboration is an essential technology for improved productivity and collaboration between teams. Collaboration is important for sharing important project details and for feedback sessions. Giving and getting feedback is an art and the most important part of your work. Not every bit of feedback will be great, it can be negative and sometimes positive. But every kind of feedback needs to be taken care of and communicated in a decent manner. It is an instrument for measuring the quality of your work. And collaboration expands the scope of projects on which remote teams can work to transform their work and tasks.
The idea of a changing workplace culture may sound simple and you may be wondering how hiring/firing can affect it. Hiring and firing may be the hardest thing to do for your company. It is quite difficult to reject someone for certain reasons and fire someone to hire somebody new. Hiring the right talent is important, but you need to know that some people are not as good in interviews as they are on the job. So make a wise decision, because indirectly it’s your culture being affected. Hire the ones who fit your culture. And also if you need to fire someone because of reasons like laziness, irresponsibility, or the inability to adapt to the work, make sure you are considering the reasons carefully. Match your company’s values to the big picture of the hiring and firing process.
Is your office work sailing smoothly? If not, you need to make a change. The more organized your work is, the more your employees will enjoy doing the work. My employees at 1SEOIN work in an organized way because their work is all controlled under Hub. They manage their tasks, reports, and statuses in our project management software. So companies today are incorporating these types of software into their work to have an organized work culture. This is greatly changing the trends of office work culture.
Cloud computing is changing the behavior of the internet, as well as the way we live and work. Offices that are adopting the new cloud computing trends are making technological changes to bring an impact to their companies. Companies are providing cloud solutions to businesses for better and productive results. There are several applications that are stored online and can be operated anywhere and anytime. Data is manipulated in the cloud and there is no need for bulky servers. Remote employees usually see the biggest benefits from the cloud, as they can easily manage their work and access data outside of the office.
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.