After you’ve made the decision to run your application on Kubernetes, what are the next steps? Maybe you’re wondering how to organize your team to do development on Kubernetes. This, of course, is quite a large topic and involves many opinions and different strategies around organization and tools. We won’t dive into all of the different development philosophies out there, but what we will discuss in this post are five key areas to consider in order to take full advantage of the technology that Kubernetes offers.
In this post, we’ll explore:
Competition is widely believed to have a corrosive impact on trust, but what happens when that competition comes from a rival firm? Does the external "threat" bind us together? That was the conclusion reached by a recent study from the University of British Columbia, Princeton University and Aix-Marseille University.
The researchers collected data from the manufacturing sector in both the United States and Germany, and it emerged that the more intense the competition within the sector, the more likely it was for pro-social behaviors, such as cooperation and knowledge sharing, within each company.
Initially posited by author and businessman Peter Drucker in his book, The Practice of Management in 1954, OKRs find their roots in Drucker’s concept of the MBO, or Management By Objectives. MBOs are an individual-based goal-setting technique based on an annual calendar that required full completion and on which hinged an employee’s salary, or even their employment.
By 1968, MBOs were becoming outdated as attention turned to cost reduction in production, and the term and modern concept of OKRs was introduced by Intel co-founder and then-CEO Andy Grove in his book High Output Management. Applying the process of production to MBOs and advocating measurable, short-term outcomes, his idea became an inspiration to industry professions. This included venture capitalist John Doerr, who, after joining Google in 1999, brought the idea to the fledgling search engine company and popularized the idea throughout the company, as well as others he later invested in.
Niklaus Wirth, one of the pioneers of multiple programming languages, said in 1971:
“[…] the student obtains the impression that programming consists mainly of mastering a language (with all the peculiarities and intricacies so abundant in modern PL’s) and relying on one’s intuition to somehow transform ideas into finished programs. Clearly, programming courses should teach methods of design and construction[…]” —Program Development by Stepwise Refinement
In my previous blog, I presented the result of an interesting research study from Sam Walker.
Walker discovered that the most successful sports teams that ever existed all shared one single element: they all had a team captain that was the main driver behind this success.
In this blog, we will explore the character traits that separates great team captains (the 16 team "Tier 1" captains from Walker’s study) from the good team captains (106 captains that finished second place).
What is it about your job that sucks the life out of you? Chances are, it has a lot to do with the people around you. Oddly enough, when you think about what energizes you at work, people are probably high on that list, too.
Teammates matter. They influence the culture we’re immersed in at work as much (or more) than the executives four levels up the org chart. Thus, a healthy team culture requires fully-formed adults with healthy attitudes about their work and its challenges.
You have to hand it to Bill and Melinda Gates. As billionaires, sitting down for an hour-long, unfiltered Q&A session with an auditorium full of debt-burdened college students took some guts.
But sit down they did, and answered even the toughest questions with honesty and authenticity.
In case you missed it, last week I hosted an "Ask Me Anything"-style forum here on Atlassian Community. For you statistics fiends out there, we got 60 questions, 49 discussions nested under the questions, and nearly 27,000 views of the thread. Boom!
Not only was it a great time, I learned a ton from all the people who participated and want to share a few gems here.
One of the most common questions I am asked in my Professional Scrum Master (PSM) courses and in coaching engagements is:
"How do we build trust?"
Team Collaboration has multiple territories. The territory of time-tracking that entails project managers to track employee hours and monitor team accountability. Teams from various departments have varying patterns of functioning.
For growing businesses, each day is a struggle. Teams endeavor to battle the rising competition, reduce project overheads and meet weekly goals to keep the boat afloat.
The standard design process divides the product preparation period into various phases, which (depending on what methodology was adopted), separates interface design and its implementation. The combination of both phases and the creation of the one team working in Agile methodology allows us to save time, speed up the implementation process and improve the quality of a product’s usability. This occurs when the collaborative team is competent in both design and implementation.
Not sharing either knowledge and/or experience during the completion of tasks in both these categories may result in the preparation of an interface whose implementation will cause unnecessary problems for programmers — this is the most likely and easiest problem to avoid. Similarly, the need to modify accepted requirements of a project (due to the change in the scope or mode of application operation) increases the number of iterations and corrections at every stage of the process.
After identifying such issues in previous projects, the importance of including people with project competencies and experience in Agile methodology in the development team is obvious. Working on UX and UI applications in the Scrum formula and its appropriate synchronization with the ongoing implementation at that time guarantees an immediate increase in the success of implementation and improved quality control in the visual layer.
The length of the product design sprint is usually adjusted to the length of the standard development sprint. Using the same tools to manage tasks, each planning session defines project goals, their priority and amount in a given sprint for a given number of people in the project team (usually there are 1 to 3 teams, depending on the complexity and development of the project, with competences in analysis, UX, and UI design and independent work organization).
The most important assumption is to plan the work of the product design team at least 1 sprint in advance to that of the development team — to which the planning and backlog grooming is most often used. Thanks to this, everyone gains a wider perspective than just their current tasks, developers gain the possibility to take an active part in the process of usability and interface design, while designers get clear feedback in the context of the feasibility of the developed projects and their usability.
Depending on the complexity of the project, the demo takes place with the help of a clickable prototype or presentation of individual components or views in the presence of the whole team. Tasks that have not been accomplished pass to the next sprint. The main goal is always to provide developers with the materials to work well in advance, including usability testing and gathering feedback from users and customers.
Synchronizing the adaptation of Agile methodology to the design process and collaborative work with the development team (but with appropriate methodologies), automatically changes the perception of the entire project. A common definition of a backlog, a lively discussion about functionality and people with different competencies focused on achieving the same goal — providing the best possible quality of implementation — is definitely the recipe for success. This unusual approach allows us to focus on details and individual components of the project at hand, and also ensures that throughout the implementation, the main assumptions are remembered and a wider perspective maintained.
The use of the Agile methodology in the Product Design process also has one additional advantage, which is the close cooperation and frequent testing of the prototype with target users. This is due to the fact that we mainly work on the creation of a UI system that will be easily adaptable for different functional scenarios, and that concentrates on understanding users to solve and satisfy their problems and needs. This approach that focuses on users guarantees that the system we develop will also be easily adaptable in other, alternative applications, should there be a need to develop them (a good example here is LindaAI).
One of the most interesting and effective exercises that should be used in the analysis phase is User Story Mapping — this is regardless of whether we are working on a new product, where we focus on solving real problems of users, or we are working on a new instance of an existing project, where our goal is to make sure that our changes and introduced features have a positive impact on business indicators and user behavior.
This exercise allows us to define:
This is done with the help of a whiteboard, sticky notes and the joint work of the entire team. The actions performed by the user of our application are divided into the next steps of the project so that we get accurately mapped functional paths in the product, with selected MVP, division into releases and the ability to easily transfer data from the analysis phase to the backlog. What is more, the effects of our work can also be used to determine the conversion hopper (by identifying the most important activities on the site), control before extending the scope during work (thanks to easy migration to the backlog) and guarantees clarity in the common understanding of the product throughout the team.
It is worth noting that project competencies between the development and design teams are purposely reiterated throughout the duration of the project. In the phase of analysis and research, the technical insight of developers is undoubtedly a great value, which at the start, limits the number of potential problems. Most often, immediately after the analysis phase, the level of project work increases, so that the development team has already started with a specific number of ready-and-tested design solutions and that, thanks to the aforementioned synchronization throughout the implementation, the designers can deliver further modules and components for implementation. The intensity of design work usually decreases at the final stage of implementation, where designers can take care of quality control. The whole cycle is repeated for each subsequent release of the product.
We must always be ready to change priorities. The ability to analyze the visual layer and support in improving usability often requires additions to the standard scope of work in a given sprint of time, which will be used to help the development team solve current problems during implementation. Designers and analysts very often have the widest view of the project, so their competences can naturally expand — but we should always be focused on the goals defined within the sprint.
In Espeo we use the following set of tools:
• Slack as an everyday and basic communication channel inside the team (except for project meetings)
• inVision as the main tool for building prototypes of interfaces and testing them with users
• Zeplin as the main tool for the transfer of materials for the implementation of the development team
The adaptation of the project team to Agile methodology and the creation of a collaborative work environment, where there is the smooth exchange of information, had a positive impact on the quality of implementation (not only in the visual layer).
Improving this process is the key to building a complete set of competencies in a team that is able to efficiently deliver well-prepared solutions, focused on meeting the goals set by business and solving problems faced by users.
Inspired by a post on why business folks should play board games and a presentation from Karthik Nagarajan on why product teams should play dungeons & dragons, I decided to write a post on why programmers should do the same. Randomly select a starting player and prepare for the first round. Here we go!
You may already find playing any form of game fun and not need much encouragement here, but for those of you undecided, here are some of the positives that may help convince you.
For simplicity, unless specifically mentioned, from now on, when I mention a “game,” I mean a board game or a roleplaying game.
We all spend way too much time in front of a screen, and if you stick to the cardboard or paper variety, you get a good chunk of time not looking at one. Unless you’re a rude player who keeps staring at their phone during other people’s turns, but please don’t do that. Of course, it won’t help with too much sitting down, but one thing at a time.
Depending on the game and the group you play with, games can help your brain exercise in a myriad of different ways, such as:
Developers (coders, engineers, or whatever you want to call yourself) are somewhat renowned (and stereotyped) for their poor interpersonal skills. Like many stereotypes, there are elements of fact and fiction, and gamers aren’t always any better in the social skills department. Still, especially with cooperative (where you work together against the game) or roleplaying games, the onus is on you to work together as a team to solve problems, expected or unexpected. I would hope that the benefits of learning to work together better are apparent, but, again, sometimes taking you and your workmates out of everyday situations can be the best way to improve skills you use every day.
Cooperative games are generally a challenge, and you lose more than you win, but this is also a valuable skill to learn. The feeling that your team has bonded through a shared experience together is as valuable as success.
Games can help you learn better short and long-term planning, manage resources, and negotiation skills. Though in some games, negotiation skills are more about bluffing, which may or may not be a skill you want to improve.
Karthik had a handful of observations he learned about teams from Dungeons & Dragons (D&D) sessions. They aren’t likely to surprise you, but sometimes it can take an external (or alternative) viewpoint to reaffirm something you already knew. He noted that the character balance (roles) and how they worked together dictated the ideal team, not their size. Karthik noted one game where a large group failed a quest due to their inability to communicate. He mentioned that game planning and product planning shared surprising similarities when it comes to defining what a party (team) needs to achieve (user stories), overly dominant players (team members), and getting the level of rules explanation (team on-boarding) right.
You’re convinced, keen to play some games, and want recommendations on the best to get started with.
For role-playing, the choice is clear: the perennial D&D and it’s latest 5th edition is new, improved, and better than ever. There are certain ethical and moral discussions around themes such as D&D, and why heroes frequently unquestionably assume plunge into killing everything. If this attitude to good and evil bothers you, there are recommendations for non-violent RPG games here and here, but I haven’t tried any of them.
As for board games, well, you may be pleased to know that the gamer community likes to make comparative lists as much as programmers, so recommendations are easy to find. Search for “best gateway games,” and you’ll find more than enough to get you started. My personal favorites? Well, I’m glad you asked:
See you at the gaming table!
Think of it like an app running in the background.
Over time, avoidance drains our battery.
What we avoid is still being processed and affecting our thoughts, emotions, and behaviors. Sometimes we are aware this is running in the background, and we catch ourselves thinking about it. Then we try to distract ourselves. Often we don’t even have awareness, and the effects still show up.
Because we are human beings with integrated (not compartmentalized) lives, avoidance in one area often impacts other aspects of our lives. From how we interact with our co-workers to how we engage with our community. It impacts how we show up for our family and how we show up as leaders in our organizations. From how we nurture our friendships to how we take care of our own needs.
Things individuals may avoid:
Things teams may avoid:
Things organizations may avoid:
And the battery keeps draining.
Many times we point at the “other” as a mechanism for avoidance.
I am not going to look at my own mistakes and where I need to grow because the bigger problem is with team dysfunction and organizational culture.
Often I see teams point at organizational impediments and avoid dealing with challenges that are actually within their control.
There is a lot of effort going into these stories of justification. We dance around the unpleasant topics. All of this effort continues to drain the battery.
We are a culture of people who have bought into the idea that if we stay busy enough, the truth of our lives won’t catch up with us.” – Brene Brown
I’ve had relationships with colleagues, friends, and family broken (or nearly broken) because one or both of us was avoiding a difficult conversation.
I’ve worked in and with organizations where I sensed that a large number of people, from the front-line employees to senior leaders, had strong gut feelings that they were going in the wrong direction. Yet it was not allowed to spend a day or two coming together to assess and re-align.
Because they were too busy. Hitting the date was too important. That seemed like a lot of money to spend.
So they kept avoiding the difficult conversations, facing reality, and admitting they didn’t really know if they would be successful. And this actually put them at greater risk of failure. And it cost them much more in the end.
Get curious about avoidance.
You are specifically looking for that app running in the background, draining the battery, and taking energy away from where you want to focus it.
Start with yourself.
Then consider what your team (and you as a part of that team) is avoiding. Notice what your organization is avoiding.
Finally, dig into these powerful questions:
Every company has its own organizational structure that dictates which team handles this or that. There are teams assigned to managerial tasks, others that are assigned to promotional tasks and more. One of the most interesting groups to be in would be the product development team as they are challenged with a lot of tasks in everyday work. It can be a bit hard to keep up with everything that is happening, especially updates here and there within the group. The good thing is that there is a knowledge-sharing tool that can help out. Here are some ways that it can help out a product development team.
One of the major benefits that a knowledge-sharing tool can bring is in making better decisions within the team. While your client is waiting on the other line, you can plan strategies with your team, analyze the basic trends, handle your internal issues, and even look and share information you have found. Thus, you will be able to have a better hand at decision-making, being able to share whatever you may have seen or read as you were trying to search for a solution.
With a knowledge-sharing tool, employees can now just download the application into their phones and have access even when they are not inside the company. Even when they are away on a business trip, attending some conference or other events, they would be able to see the updates in real-time. Remote workers no longer need to wait so much, but instead be updated instantly. It also offers the choice to use videos in learning or training members so that they would understand the tasks at hand.
A KSP allows you to share and organize knowledge across your organization. When you share knowledge within the group, you can come up with a solution in a faster manner. This means that you get to develop and run a test for your products without having to take up too much time. After all, a client would always appreciate those who are able to submit on time or before the deadline. Since you are reducing the time you spend communicating with other workers for information since everything is already in your application, you get to secure a contract and have happy and satisfied customers.
Most teams do not have that much interaction as getting closer to each other is not that easy of a task. However, with a knowledge-sharing platform for your product development team, you can comment, like, and even tag other people on the posts that you will see your team group just like in other social media platforms. Working with your team members helps a lot as it improves your work since everyone gets to say their comments, ideas, and voice their opinions.
Collaborations within a team only happen when the people within the group are willing to participate and when they have built enough trust in each other. A knowledge-sharing platform brings team members closer to each other which makes it easier for them to work together in the process and do things such as collaborations.
The benefits of a knowledge-sharing tool to a product development team bring empowerment to each member so that they will be able to say what they are feeling, voice out the things that are within them, share their ideas, and allowing every member to interact with each other so they can get to know each other better. In the long run, the results are quite amazing and the improvements in the team are easily seen.
The shift to the cloud has disrupted nearly every aspect of the traditional vendor-customer relationship in the enterprise IT landscape. Today’s IT organizations are rapidly developing greater expertise in cloud computing, but they also increasingly depend on the experience and expertise of their cloud service partners and suppliers. This is especially true at the outset, when the organization begins to plan how they will migrate their line-of-business applications to the cloud.
Experienced IT professionals know that cloud migration projects present numerous risk factors, each of which must be understood and addressed to increase the likelihood of success, which — like many IT projects — is best defined as “nobody outside IT noticing that anything is different.” Application performance, systems access, data security and a multitude of other implicit expectations the organization has for its infrastructure must be preserved, even as applications, data, and network configurations are moved to run within a third-party’s environment.
Moving from an on-premises operations model to a cloud model means working with new participants and defining the roles, responsibilities, and priorities of everyone involved. I spoke to one IT manager who, when planning the migration of several thousand virtual machines, found it helpful to draw up a chart, like the one below, to get all the stakeholders on the same page.
Research has shown that teams with a greater degree of role diversity tend to develop more innovative solutions and achieve greater success in reaching their objectives. The same is true of the team that brings the organization to success in its cloud journey. Each player has an important role to play, and cloud initiatives that leave out a critical contributor are disadvantaged from the start. Just as dangerous is the initiative that assigns responsibilities incorrectly. If all participants work from a mutual understanding of each contributor’s strengths and roles, and communicate openly and frequently, the migration to the cloud is much more likely to succeed.
The chart above breaks out responsibilities among four types of participants in a typical cloud migration project. In practice, the roles and responsibilities presented in this example may be assigned differently in different projects, but it shows the kind of thinking that the team should embrace at the start. There will certainly be some overlap in accountability, as some responsibilities are shared and some lines of demarcation will be fuzzy. However, if there is any fundamental ambiguity about ownership and accountability, that’s a red flag for the project. In general, each of the four participants should be able to start with strong overall agreement on each participant’s unique mission statement:
“We are responsible for making sure that the project aligns with and satisfies the needs of our business. We can work at different levels of detail, depending on the circumstances.”
“We ensure that the project is executed such that the cloud services delivered to the organization are highly available, consistently reliable, resilient and recoverable.”
“We draw on experience across the cloud services landscape to identify the tools, processes, people and practices that are most appropriate to this organization’s objectives.”
“We ensure that the technologies provided for the project are appropriate to the organization’s requirements and that issues with those technologies are resolved completely.”
Given multiple participants, each with a unique skill set, project role, and mission, how does the whole team get explicit agreement on each contributor’s part in the cloud migration initiative? Quite simply, it’s a question of leadership. An IT organization that is proactive and leadership-oriented (rather than reactive and “firefighting”) is essential to set the tone for accountability and communication throughout the course of the cloud migration initiative.
From the initial planning phase, it is the IT leader’s responsibility to bring together the contributors and include them in the definition of the “three Ps”: project, people, and process. The project definition includes the schedule, success criteria, risk factors and operational requirements. In identifying the people who will participate, it’s important to go beyond defining roles and to also consider whether, based on the risk factors that have been identified, the composite team has gaps in its expertise. Additionally, it’s important to consider contingencies in the event that a team member leaves the project before completion. The process definition includes the tools and technologies that will be used, but it should primarily focus on ensuring protocols for clear communications, defining expectations for status reporting, and scoping knowledge transfer and documentation requirements.
Once the project is underway, the leadership-oriented IT team should provide a steady hand on the team’s work throughout the migration, ensuring clear communications, proper execution and thorough validation of the success criteria. However, there is a difference between being the leader of the project and controlling every aspect of its execution. Strong leaders operate with trust in their contributors’ expertise and, in doing so, get their contributors’ best work. This is especially important in a project like cloud migration, due to the number of — and differences among — the project participants.
It’s difficult to keep up with the changes in the cloud migration market as established vendors update their products to better address the new dynamics of cloud services. Some innovations for cloud computing represent foundational changes to better serve the multi-tenant, on-demand operations that cloud providers support. Differentiating truly cloud-centered technologies from rebranded on-premises solutions is more than a technology challenge — business factors such as licensing and professional services must also fit the cloud service provider’s business model.
Today’s cloud service providers have responsibilities that go far beyond managing facilities. Beyond keeping critical systems running, a true cloud service provider has a spectrum of customer-facing operational requirements: cost analysis and management, orchestration, migration, data management and lifecycle management. With new vendors and service providers, well-defined roles and deep trust are essential to the relationship between all parties.
The migration of line-of-business systems to the cloud is a unique kind of service offering that involves new tools, technologies and expertise. Just as cloud-native IT operations challenge established norms, migrating business-critical systems and applications to the cloud presents challenges to enterprise IT and services opportunities to their providers. Collaboration and a shared sense of ownership of the migration project are essential to success.
So if someone asks you who “owns” your cloud migration project, you should be able to say “we all do, and here’s how that works.”
As first published in ITProPortal.
I’ve never seen you, we’ve never met,
We never will, I’d wager a bet.
You speak a language I may not know,
And while I sleep, you begin to code.
Yet we’re on the same project, our workload is shared
Working on the same system, breathing different air.
“Communication’s a nightmare,” our Scrum Master gripes,
“We can barely keep up, even with Slack, JIRA, and Skype!”
But we can’t do it without you, you’re how we get by,
You’re the key to our DevOps, our CD and CI!
So shout out to you, remote worker, you’re great!
…And don’t forget about our meeting, it starts around 8.
Get it? Like, who’s awake? Because this is a roundup about remote working and remote workers can be on the other side of the planet, where their night is your day and vice versa? And also because it’s a double entendre inquiring who has the most pageviews this month?
Ahhh, you get it.
A JIRA Tutorial for Software Developers: Get The Most out of JIRA by Melissa McEwen — JIRA can be a bit daunting for some developers, so let’s take a look at how to demystify it and maximize your ROI for using it!
Don’t Hire Remote Workers Who Can’t Nail These 6 Interview Questions by Dominic Price — Remote devs can be just as productive as co-located devs, but not everybody has what it takes to work remote full time. Here are some strategic interview questions to ask your next potential remote hire.
Adopting to Agile — Through an Infant’s Eyes by John Vester — Observing the actions of his newborn son, a Zone Leader wonders just how closely these actions match that of the adoption of the Agile framework.
7 Traits That Make a Great Software Developer by Aleksandra Mladenovic — What’s the difference between a good developer and a great developer? These seven qualities will help you distinguish between the two.
6 Meeting Hacks (and 1 Weird Tip) That Build Trust in the Room by Dominic Price — Meetings can feel like a waste of time, and often times the people in the room don’t believe in the others in the room. We take a look at some hacks and tips that can help eliminate these issues and make meetings great again.
The moment you’ve all been waiting for!
We’ll start off simply with this catch-all article that gives some great general tips and best practices on how to create a socially collaborative workspace that will allow all of your team members to work together efficiently. It’s not specifically about remote working, but isn’t specifically not about them, either.
This one goes out to all my managers, Project Owners, Scrum Masters with teams around the world. If you’ve ever struggled to get everyone on one accord and working in sync, this article gives you five ways to not only manage better, but lead better.
Whether members of your team are working remotely five miles away or 12,450 miles away (literally halfway around the world), the studies this article references note that remote and flexible working may, in fact, lead to more productivity and higher reported job satisfaction.
For those times when you just need a little more manpower, outsourced teams can be a great help. The issue is, by their very nature, outsourced production often come with some logistical work on the front- and backend. Here’s how to make it work.
Whether if you run a small family business or a large enterprise, to make sure you’re getting the most of your business, build a collaborative spirit among your employees.
According to a study that examined more than 1,100 businesses, the companies that nurtured collaborative environment were up to 5 times more likely to have an extraordinary performance. That being said, it’s obvious how essential it is to switch from an individual to a collaborative mindset, even if you’re business is already highly successful.
This article shares some surprisingly efficient yet easily implemented tips that can help you out in building a team-oriented environment. So, read on and learn how to create collaborative work conditions at the workspace.
If your team members are not certain about your goals and visions, they may lose motivation and passion for their jobs which can easily affect their efficiency. Accordingly, when trying to achieve the perfect collaborative environment, it’s particularly important to make your employees understand your business purpose.
The more you’re capable of identifying your staff with your brand mission and compelling them with your business story, the more they’ll be motivated to work towards the realization of that idea.
The most important thing you should do as a business leader is to make sure your employees know what your expectations and goals are. Not only should you clearly communicate the business vision but also collective responsibilities and individual assignments.
When your staff knows precisely what they should do to benefit from the final outcome, only then will they be able to invest the most of their capacity. In addition, when everybody’s individual role is well-defined, you’ll decrease the chances of conflicts based on misunderstandings. At the same time, you’ll increase the efficiency of each team member, as they’ll know what part of the final result they are responsible for. Finally, they’ll be more direct to one another and more constructive when combining the results of tasks they’ve worked on into a bigger picture.
First of all, it’s important to realize that getting the most of your employees doesn’t mean draining their energy until it’s fully exploited. On the contrary, it means that you should only give them responsibilities that best suit their strengths.
One of the most popular ways of determining strengths and weaknesses of team members is letting them take a personality test. That way, you’ll get to know what kind of activities and environment they enjoy the most. Consequently, you’ll be able to assign them the tasks that they are more likely to perform providing extraordinary results.
According to statistics presented a while ago, the most used test for this purpose is the Myers-Briggs Type Indicator (MBTI)– about 80% of Fortune 500 companies rely on it.
When establishing a collaborative environment, it’s important to put to use the creative energy of each team member. And this means that you should build the setting that will motivate them to speak up, brainstorm, and offer an alternative solution, rather than making them feel shy and insecure.
If you let your employees actively participate in the process of decision-making and give them the freedom of speaking their own mind, they’ll feel like an important part of your organization. To make them feel included and give them the understanding that their opinion matters, it’s essential to break down the barriers between managers and employees.
As we’ve already mentioned, to create a stimulative and supportive setting that will lead to increased collaboration, you should work on creating a stronger bond between leaders and staff. And there’s no more outgiving way of doing so than organizing frequent and meaningful team buildings.
The co-worker socialization outside the office is a great way of opening communication channels and creating a less formal vibe among the employees. Team buildings are especially productive in terms of nurturing collaborative spirit if they are based on games, quizzes, and challenges in nature.
Efficient communication is one of the most important elements of the truly collaborative environment. To keep all the employees on the same page, you should find a good way to let them interact.
While the frequent meetings may be a good way of dealing with daily issues, the introduction of marketing project management software can also be a great help. Not only does it simplify communication when it comes to daily tasks but it also lets the employees keep the track of the entire project progress.
Making the employees interact easily and collaborate on project edits, project management software for marketing additionally increases their efficiency and they provide even better results while at the same time cultivating team cohesion.
The creation of a collaborative environment is not a process that lasts a couple of days. It may require a lot of time and effort to make the employees learn from their inefficiencies and become sincerely open to sharing a team spirit.
However, there are several ways in which you can speed up this process and start seeing improvements in the way your team members communicate sooner than you expect. So, if you’re willing to work on improving the collaboration in your team, you should:
Finally, nurturing collaborative environment may be the best weapon to win the competition. Healthy, stable work setting where co-workers don’t feel threatened but motivated to contribute to business goals can significantly impact your business results, eliminating weak spots and improving interpersonal relations.
If you give a developer a verbal warning for surfing social media all day, you are crushing their autonomy. Insisting on core hours of 10am-4pm violates self-organization. Personal development plans are so PRINCE II. Right?
Well, maybe. On the other hand, having someone relatively experienced and influential on your side, to help shape your career and keep you off the annual redundancies list might actually be quite useful.
Here are four case studies of line management observed with real agile teams, some effective and some problematic. Hopefully, this should help you to consider how to make your own HR practices supportive of great software product delivery.
A development team in online retail is doing pretty well. They are well on track to upgrade their eCommerce system to a modern and well-architected system, and they have established a collaborative technical community across the other half-dozen teams that build the site. Life is good for 11 months of the year, but then the annual ritual swings round again that causes the development team to focus on individualism, job titles, and elusive 2% pay rises. This year, two members of the team feel that it is their time for a promotion. They fill in all the right paperwork, their line manager supports their application at the big review meeting; but to no avail. The feedback is:
Standards are very high, and an “associate engineer” needs to demonstrate more industry experience to be promoted to “engineer.”
It’s difficult to feed this back to the people involved; they feel hard done by and I agree with them. The team carries on over the next month or so, but they’ve lost a bit of momentum and in the corner of my eye I can’t help but notice people looking at job websites.
The promotions process in place has the following effects:
Part of the role of a good scrum master is to work with organizations to help them to evaluate the policy choices they have made. It can help to put some numbers on it. Saying, “People are unhappy because they didn’t get promoted” is likely to attract sympathy but little change. Saying, “Our current promotions system is likely to cost the department hundreds of thousands of pounds,” has a better chance of resulting in positive action.
Takeaway: Good HR practice is like good office facilities management — if it’s done well, you don’t even notice it’s happening.
A small, close-knit development team has had stability in their personnel for many years, until a new developer joins from another department. They settle in well and their technical skills quickly establish a mutual respect among the team. However, the new developer is often late, even missing the 10:30 am stand-up at least once a week. After a few months of raised eyebrows and building tension, the developer in question opens up to the team about a long-term sleep condition that they have been managing for many years.
The team and the product owner (who line-manages the team) recognize this as a genuine problem and accommodate the new developer, and the team returns to a state of productivity and collaboration. Occasionally, people working alongside the team question the very visible fact of the developer’s lateness. The team is quick to highlight the much less measurable fact of the developer’s commitment to the team and the quality of their work. It’s good fun to arrive in the morning to find a 2 am code check-in that solves the current technical challenge.
Takeaway: Genuine productivity of useful, business-relevant work is the most important thing. Teams should be held to account, but only for the things that matter.
A major new product line has been initiated within an enterprise-scale organization. All they need now is a couple of development teams to build it. Hiring external developers will help a little, but most of the people will come from within the technology department. This raises questions such as:
Before the skills matrix excel spreadsheet maxes out the engineering manager’s hard drive, we suggest that we help the teams put together a proposal themselves. We give an example of having done this before, helping distributed team re-allocate themselves in order to alleviate time-zone issues. It took a couple of weeks and some bottom-up leadership but it’s usually a lot less difficult than people imagine. However, the response from the engineering manager is swift:
If we allow people to choose their own team, it will be impossible for the QA, UXD, DBA, and development managers to keep track of their staff!
As a result, both new and existing products were slightly compromised through delays, overheads, and sub-optimal allocation of people.
Having competency leads (QA manager, etc.) should have been a great asset, leading the development of good practice and helping to establish shared standards across the department. However, in this case, the competency lead roles became a constraint.
It might be difficult to make changes that affect people’s roles, but it would be negligent to prioritize maintaining an org chart ahead of forming the best possible teams to build a new product.
Takeaway: Leadership positions should make things better, not be a constraint to work within.
A development team working for a large public-sector agency is becoming increasingly frustrated with one of their number. The source of the frustration is a developer who has moved all around the department, and for the last three months has been a member of a Scrum team building an internal research tool. One of the characteristics of Scrum is that it is really obvious when someone isn’t pulling their weight. While the daily scrum is not intended as a reporting session or a way to micromanage the team, when a developer doesn’t complete a single task all sprint then you can’t help but ask why. Efforts by the team, scrum master, and product owner to encourage and support the individual have little impact. Three months later, the individual has been taken through a fair but increasingly formal performance management process, resulting in the termination of their employment. It’s hard work on all involved, but allowing the situation to continue would have been worse.
Takeaway: Leading agile teams is mostly exciting and rewarding, but if difficult decisions are avoided then it undermines the whole effort.
At DashBouquet, we are keen to learn new things and constantly improve our skills and knowledge. That’s why we always keep an eye on the most modern trends in order to stay atop the competition and not only satisfy the requirements of our clients but also the needs of the users. So we thought it would be a good idea to share with you the most expected UX design trends for 2018 and see why they will matter so much.
Today the world revolves around the concept of immediacy. Snapchat and Instagram stories, real-time streaming, and much more — people are now used to the fact that they can always see what others are doing right now and they expect such options to be in almost every app they use.
This week, for reader question Tuesday, the question couldn’t be simpler. It’s about technical debt, and here’s how it goes:
How do you get out of technical debt?
I told you it was simple.
I’ve talked about technical debt a number of times on this blog. I offered my own definition years ago (in another reader question, actually). I’ve talked about why it exists, and I’ve written at times about how you can use NDepend to identify and quantify it. But I guess I’ve never really talked in any detail about how to escape it.
Let’s do that today.
Come to think of it, there was another post that I wrote on the subject of technical debt. It was about the human cost.
On a long enough timeline, technical debt creates a lot of misery in the office. Team members tend toward finger pointing and infighting, and a sense of embarrassment pervades. Nobody likes explaining over and over again to stakeholders that seemingly simple changes are actually really hard.
So you might just take a breath one day and ask yourself if life isn’t too short to keep coming in every day and gingerly massaging some 20-year-old, battleship-gray Winforms app into shape. Maybe it’s time to move on to greener and more satisfying pastures.
Now, bear in mind that I’m not advocating that you quit your job every time the team makes a technical decision you don’t agree with. I’m talking about a situation that feels like a true dead end and where you can feel your market worth slipping day over day. It’s not a decision to make lightly, but you should understand that crushing technical debt isn’t something you have to tolerate indefinitely, either.
Moving away from your most dramatic option, I’ll get to one that probably won’t entirely be your decision. (Though maybe it will, if you get to level 4 on this scale.) That involves declaring the application with all of the tech debt to be a total. In other words, you rewrite/retire/sunset the thing and call it a day.
Now this is a nuanced recommendation for me, personally, though. Years ago, I wrote a post for NDepend entitled “The Myth of the Software Rewrite.” The idea with that post was to be leery of a team that worked itself into a ton of technical debt declaring a rewrite the only way forward. I said this because that team is just going to make a mess in the new codebase. A team should be capable of covering legacy code with tests and evolving it piecemeal into a more modern system.
I still believe that just as much now.
But that’s a narrower situation than what I’m talking about here. You might have inherited a codebase from somewhere else entirely, or the entire team might have turned over since the original writing of the code. Or maybe it’s just an application whose user base is in decline.
Whatever the case may be, this is an option for getting away from tech debt, though this should be more of a strategic business decision than a tactical way to make life easier.
Here’s something you’re likely to have more control over, if not total control. You can lobby to tackle the problem head on, with an intense effort. This is sometimes called legacy rescue.
The idea is that you put normal work on hold, and do the codebase equivalent of a massive spring cleaning. First you’ll need to get the thing under test. This means meticulously capturing current application behavior with characterization tests.
With a test suite in place, you can start to rework parts of the codebase, preserving existing behavior. The idea here is to pay down as much technical debt as you can with one sustained, Herculean effort. Go rip out that chain of singletons that has spread through your codebase like kudzu and is making it a nightmare. While you’re at it, get rid of the rest of the global state, too. Move away from your old-time, home-rolled ORM that uses code generation to spew out data access objects.
You get the idea.
Like band-aid removal, just do it in one fast, painful effort and get it over with. When you’re done and your tests are passing, the future should look brighter. You’ll certainly have some issues to contend with and a lot of testing to do beyond the automated suite you’ve created. But you’ll be on a path to joy, and away from crippling tech debt.
Speaking of band-aid removal, you can always go the other way, too. Instead of ripping it off fast and painfully, you can drag it out with marginally less pain as you go. But it goes on a lot longer.
Same with working your way out from unhealthy amounts of technical debt. If circumstances simply don’t allow you to spend many days or even weeks reworking parts of your codebase, you can come up with a plan to chip away at it little by little.
You can do this by adopting a policy of following the boy scout rule with code. Make sure you’re writing unit tests and that you’re constantly improving the code you touch a little bit at a time as you go. The unit tests are critical so that you always have the confidence to refactor.
But on top of adopting that as general good policy for tech debt avoidance, you should also make a plan. Look at the biggest sources of slowness and pain, and figure out how you’re going to address them over the long haul. Then break those big tasks into subsequently smaller component tasks until you hit a point where the component tasks fit seamlessly in with your regular work.
Then simply have a backlog and keep chipping away.
Those are really the main strategies that I can think of off the top of my head. Of course, to some extent you can blend them (e.g. remediate with a plan eventually to sunset or do a bit of intense rework followed by a longer tail effort). Or you might have other ideas that are more specific to a given situation.
But in the end, it comes down to two main things. First, you have to make the decision as to whether you can drive the change you’re looking for in the codebase or whether you have to go elsewhere. And secondly, no matter what you decide, understand the nature of the problem—how the crippling technical debt came about. That way you can get better at avoiding such situations in the future and contributing to the fix when you do encounter them.
Technical debt is neither completely avoidable, nor is it always even necessarily a bad thing (in the short term, anyway). It’s going to surround you and affect you throughout your career. So do you part to minimize it by not creating it and by helping to pay it down when it exists for whatever reason. And, failing those things, declaring bankruptcy and moving on from a hopeless team is a lot less painful than the financial world’s version of bankruptcy.
By the way, if you liked this post and you’re new here, check out this page as a good place to start for more content that you might enjoy.
Team meetings are significant and inevitable. They ensure the team’s projects are on time and on track and that everyone is on the same page. Team meetings make clear that everyone is working toward the same goal.
However, statistics show another side of the story. Generally, employees end up wasting approximately 31 hours each month in unproductive meetings.
Even at the management level, middle managers waste up to 35% of their time and upper managers waste up to 50% of theirs in meetings.
This being said, meetings are important. But how do you make them productive and effective, too?
We may have some tips to help you along the way.
While this may seem like unnecessary information — or a given — it may surprise you that more than 63% of meetings have no planned agenda.
With no pre-decided agenda, meetings can quickly become a waste of time. From conversations going off topic to discussing items with the least priority, a mismanaged meeting can do more harm than good.
A good method by which to stick to the agenda is by outlining the details of the meeting and sharing them with employees beforehand. This keeps the meeting’s discussions on track in a productive manner.
Creating an agenda also allows you to assign each employee a piece of the presentation, helping employees feel useful and focused.
While it’s good to have discussions outlined, it can also be effective to leave a time slot open in your meetings to brainstorm.
Employees have unique skillsets, thought processes and talents, and this gives your team members the opportunity to feel heard.
Employee disengagement is an unfortunate fact; a whopping 70% of U.S. workers report not feeling engaged enough at the workplace.
Thus, encouraging employees to speak up just may do the trick. Brainstorming sessions can help employees share ideas based on their unique skillsets.
These sessions can enable employees to voice ideas and issues that may otherwise seem invisible, which may contribute valuable information to the business and lead to finding unlikely solutions.
Visuals are an integral part of every meeting.
Did you know that over 90% of information conveyed to the brain is visual? Also, your brain processes visuals 60,000 times faster than it does words.
You may want to consider these statistics next time you arrange a meeting.
Don’t just talk over the matters using text on slides or paper handouts. Make use of graphs, pictures, and even videos to discuss progress.
Long meetings can make employees tired and distracted.
According to research, the time span for paying attention is between 10 and 18 minutes. For this reason, you may want to keep meetings to, on average, 15 minutes or less.
Short meetings help focus only on the issues without giving employees the luxury of time to get side-tracked.
Did you know that Yahoo’s Marissa Mayer schedules only 10-minute meetings?
Many modern companies have branch offices scattered in various locations.
Though face-to-face meetings are effective, traveling between branches can waste time and resources.
According to Verizon Conferencing, face-to-face meetings that require travel may be seven times more expensive than virtual meetings.
While you may consider the option of conference calls, you may also want to know that 65% of employees regularly do other work during a conference call.
This, in turn, causes loss of focus and wasted time.
Rather than conference calls, it can be useful to engage in video conferencing, allowing employees to meet face-to-face without actually being in the same place.
A good solution: online meetings.
Better yet, invest in online meeting management software.
A meeting management app has the ability to streamline multiple processes, from managing attendees and vendors to deciding budgets and schedules. It can also provide multi-party video conferencing and content sharing.
Some can even arrange your notes into professional meeting minutes and help you send them to the team. Meeting management apps can be the solution to nearly all meeting productivity issues.
Do you have any tips to make meetings better and more effective? Share them with us, in the comments below.
Feedback is a vital part of any project manager’s skillset. Not just giving it, but also receiving it. Let’s talk about its role, why it’s so valuable and how to get better at providing it.
For a start, providing feedback—when done regularly—keeps everyone on track. That’s beneficial for anyone involved in the project.
Clear and honest communication in the team and during a project helps your employees avoid major mistakes. Feedback saves you the time of correcting someone’s work, or the regrets of a worker who feels like he failed.
You also form better relationships with the people in your team. Feedback often involves criticism, which is something most people aren’t comfortable with. But when given in the right way, it can help them evolve.
A friendly approach works well here. You can not only help others see what they might be doing wrong, but allow them to use this as a piece of advice, not judgment. Make them feel like you believe in them and just want to help them reach the project’s goal sooner. That will make them even more motivated to do a good job. Constructive feedback can serve as a tool to motivate employees and boost performance.
It promotes personal and professional growth. Feedback is about listening actively, taking the time to analyze, and then thinking of the best possible solution to perform better. It provides positive criticism and allows to see what everyone can change to improve their focus and results. It brings people together and creates a healthy communication flow.
Creating a friendly work environment where everyone’s open to criticism and even seek feedback themselves (both from you and from their teammates) saves you big time. Often the best ideas can come from someone on the team who simply mentioned a solution to a problem or pointed out an issue that others hadn’t noticed yet.
Last but not least, there are the direct benefits of feedback related to business growth, such as saving money, making more sales, and completing a project on time.
All this makes people on the team more engaged in the work process. You might notice they show more respect and loyalty once giving feedback becomes a regular practice.
For a project manager, it’s extremely important to give feedback in the right way. While it is a powerful practice that creates a visible positive effect, it can also hurt people, lower their self-esteem or make them feel underappreciated.
To do this right, plan your approach. Avoid anything that can be heard as blaming or judging. You want to motivate people and show them areas for improvement. Always explain your employees how this is a win-win situation. Mention their strengths, too, after which you can point one aspect they can work on more.
Make sure you’re specific. The employee should know exactly what aspect of the project you’re talking about, what they did wrong, and how it can be improved.
Give people time to understand your feedback and make sure to receive their responses. They should be comfortable with sharing how they feel about it. Be open-minded and take into account your team members’ points of view.
Don’t forget to let them be part of the problem-solving process. Even if you already have a specific solution in mind, hear them out, then share your proposal using some of their words or ideas.
It is not uncommon that people aren’t actually sure what happened or what their next step should be. That’s why you should ask questions in the end and see if the other person received your message. Follow up after a few days to see how they are doing and whether there’s still an issue.
Last but not least, encourage team members to provide feedback as well. Leave your ego behind, ask them if they have something to add about your performance and role as a manager, and carefully listen to what they have to say. Let them give examples too so you can see what exactly they mean, then discuss this openly and together to find a way to make it work and use the feedback effectively.
Promoting feedback in a team should be your next move. Make room (and plan time!) for it in the process of planning and working on a project. In fact, it should be present at every step. Give your employees time to get used to this new, open-minded and feedback-friendly environment.
Meetings are an intrinsic part of professional life. Meetings provide employees the opportunity to share ideas, network, improve their understanding of each other, and update employees and management alike on new developments.
However, when meetings are unplanned, they disrupt the entire work environment. Without a set meeting agenda, it is difficult to know whose attendance is a must for the meeting to be a success. Do you need the large conference room or the small one?
Let’s look at three ways in which unplanned meetings can prove to be more harmful than effective.
Meetings are only productive when the meeting agenda has been devised in advance and the relevant people are made aware of the agenda and the time of the meeting.
Unplanned meetings catch people off guard; employees are not ready to discuss the meeting’s agenda. When called upon to highlight an issue, people are likely to not be ready to be ready to discuss.
Not only would people not be prepared for the meeting; some of them might not even be present in the office. Many offices now have workers who telecommute, and these employees must be notified ahead of time.
Meetings are an important tool for sharing information, exchanging ideas or even raising concerns. Unplanned meetings defeat this purpose entirely.
Furthermore, unplanned meetings affect worker productivity and morale. Employees may feel that they have been put on the spot during unplanned meetings. These employees are then more likely leave the meeting feeling less motivated and informed then before.
Meetings, even planned ones, take up a substantial amount of time out of the work day.
However, when employees are prepared for a meeting, they take conscious steps to ensure that their work is done on time. They might take a shorter lunch break, spend less time exchanging greetings, or simply arrive earlier for work.
With an unplanned meeting, employees do not have any opportunity to prepare for the time loss. They probably had tasks to complete during the time that the unplanned meeting is taking place. Because of an unplanned meeting, employees may be late on deadlines.
The time crunch employees feel during an unplanned meeting has the potential to keep them distracted throughout the meeting. Chances are that employees would be preoccupied during the meeting and miss important information being shared.
Unplanned meetings end up reducing employee productivity even more than planned meetings do. Not only are the employees late in delivering their assigned work — adversely effecting project KPIs — they probably will not take away as much from the meeting as they would from a planned meeting.
Successful meetings are run according to a set of rules. People have specific roles and the agenda of the meeting must be followed to ensure that the meeting is productive.
Without a clear and concise agenda, people cannot know what topics are to be discussed. People are not aware of the length of the meeting or what to expect from the meeting itself.
Without clearly defined roles, no one knows who is mediating the meeting. Several people may try to raise points that they think should be addressed first. People are likely break off into groups to discuss the topics they think are noteworthy. This can result in chaos and confusion.
Minutes of meeting may also be indecipherable.
A planned meeting is optimized with the view of increasing productivity and collaboration, whereas an unplanned meeting ends up adversely affecting productivity and hindering collaboration.
In order for a meeting to be productive, it is essential that people are expecting the meeting and are aware of its purpose. Online meeting management softwarecan be used to make sure that people are notified about meetings with plenty of time to prepare accordingly.
Remember the time you were sitting in the university lecture about staying focused?
The hall was full of students, all attentively listening to the energetic instructor. He really knew what he was talking about — or at least it seemed so.
Before you knew it, your friend was nudging you back from slumber into the hall, and only 10 minutes had passed.
Listening to an important lecture and trying to keep yourself awake is probably not a winning combination. The bright side of this type of memory: experience is golden. At least now you know that is not the experience you want for your own webinar attendees.
Much time and effort go into creating interesting webinars. The process involves content creation, organizing slides and working on your delivery. Unfortunately, of those registering, only between 35% and 45% actually report attending webinars.
Even though you know the topic is worthy of hosting a webinar around, the question remains: how do you keep the audience feel connected throughout the presentation?
Use our guide below to understand everything you need to make your next webinar unforgettable.
Make the audience excited for the webinar. Write a blog on the topic a few days prior. Tweet to a hashtag for the event. Arrange interesting giveaways. You can even create ads for event promotion.
It is worth nothing that about 29% of attendees won’t register for your presentation until the day of the event itself. However, as many as 17% of your attendees will probably sign up more than 15 days before the big day.
Make the most of the time before the webinar. Connect with audience beforehand and lead them to the event.
Did you know that only about 15% people surveyed agreed that the slideshows and other visuals were engaging?
Your audience will be more interested if they have a good view. Make your slide deck visually appealing.
In order to do this, you can add infographics, charts, and graphs. Avoid long paragraphs and stick to short sentences on the slides.
There are also many high-tech tools that can help you make beautiful presentations. If you aren’t interested in PowerPoint, you may want to look at Canva, Prezi, or Wideo.
Instead of using text to define processes and explain phenomena, use graphics and videos. A recent survey showed that 50% executives prefer video over text.
You can do this either by hiring animators to design and create short, animated clips, or you can make them yourself by using online tools.
You can even create simulations. Walk-through simulations can help the audience feel a part of the environment.
Make an agenda of the topics for discussion and keep your webinar running on time.
According to a research on webinars, 38% of attendees cited relevant and interesting content as the thing they engage with the most.
Thoroughly research resources and abandon old sources of information — unless there is history involved.
You also need to be meticulous in the facts and figures. Include the latest, most relevant trends.
Talk about the next big thing and what is going to happen around the corner; make it clear how your topic of presentation will add to this.
This may help you audience feel ahead of their time and even feel better about themselves.
A one man show throughout the presentation can make you tired and the audience bored.
Invite people that have information to offer to speak at the webinar, such as industry experts, motivational speakers or public figures.
According to a survey, about 15% of those surveyed cited interactions between speakers and attendees as the element that keeps them connected to a webinar.
You can even twist the presentation into a discussion between the speakers. This will highlight various points of view on the same topics.
You may be running the webinar and your speakers can enlighten the audience with their expert ideas — but don’t let the audience only be the listeners. Make them feel that the webinar is about them. Encourage them to ask questions and join the discussion.
According to research, 92% of webinar attendees want a live Q&A session at the end of a webinar.
This can also lead the audience to bring up a topic themselves, starting a new wave of discussion and making the webinar even more engaging.
Audience-speaker interactions can be worthwhile, but they can also go off track. At times, going off track can reach extreme levels, incurring adverse effects. For this reason, it is useful to have a host or moderator manage the discussions and the general flow of the presentation.
The host can introduce the speakers and can put forth questions from the Q&A sessions and conclude the event.
Off-topic questions or potential negative discussions can also be deterred immediately by the host, without offending the audience or the speakers.
Do not under-estimate the element of surprise. Research shows that surprises can intensify emotions by about 400%.
Keep surprising your audience and they’ll be glued to the presentation anticipating what’s next.
For example, invite a celebrity or influential person. Don’t announce their presence until the webinar starts. Call them out when the audience least expects it.
Making your webinar interactive can also mean using activities such as polls to connect with the audience. For example, ask the audience to vote for the speaker that they agree with or the recent trend they are most likely to follow.
You can even conduct quizzes or spontaneous, short games to keep the audience involved.
Better yet, announce giveaways at the end of such events. For example, prizes can be given to the top scorers or the first few that logged into the webinar.
Instead of using multiple media sand switching between them throughout the webinar, use a single reliable platform to host your webinar.
Online task management softwarecan be useful to this effect.
A study showed that about two-thirds of companies communicate using project management software. Companies need to cater to multiple interactions at the same time: between clients, teams, and other companies.
The same can be applied to a webinar, albeit on a smaller scale. Webinars cater to communication between multiple sources with a large number of people.
Task management tools can help schedule the times for speaker discussions, interactive events and prepare for potential queries.
You can also make use of a task management application to arrange pre-webinar meetings, define the agenda and instantaneously exchange information.
A well-organized webinar can really help reach to audiences and keep them connected throughout.
Have you hosted a webinar? What tips do you keep in mind to make your webinars engaging? Share your experiences with us in the comments below.
As a product manager in a high-growth environment, I have come to accept that at any given time, something is on fire.
Or, at the very least, smoldering.
During our highest growth periods, I’ve found the key to effective product management lies in two main areas: taming fires and winning friends.
To survive in a high-growth environment, you must learn to prioritize and then get your team onboard, so the whole team becomes focused on the strategic direction of the company. In this post, I’ll share how I’ve learned to tame fires and win friends along the way.
Building products is chaotic, and if you have too many fires and not enough buckets, you might find you spend too much time firefighting, not enough time building.
Product quality suffers from distractions, and problems determine your product direction instead.
In my experience, too many fires come from:
Early on, I recognized that there was a need to put some fire-taming strategies in place.
Here’s what I do on a day-to-day basis to ensure things don’t get the better of me.
Keep your leadership team in the loop. Most development teams have a daily stand-up and check in with the leadership team once a week.
This blog post by Folding Burritos summarizes 20 prioritization techniques nicely and outlines that prioritization is the result of not having enough resources to work on everything—a very typical scenario in product management. Each prioritization framework caters to different needs but whichever one you choose will help you organize, prioritize and establish relationships between company and customer.
In my team, we lean heavily on our tools like Slack, JIRA, and our own tool, Raygun. Raygun’s Real User Monitoring, in particular, helps me to see performance optimization tasks by priority, which is very helpful for when I’m prioritizing our engineering team.
The same way your marketing team needs to “get out of the office” and talk to customers to discuss pain points, so do product managers. Intercom and customer support are your next best thing. Answer support tickets as much as you can and frequent your company forums so you can understand your customer’s problems more. Your technical knowledge will also be put to the test here, and will keep you on your toes!
You are responsible for outcomes, not inputs, and to do that, you must be able to rally your team around your ideas. In a high-growth environment, you simply can’t afford internal team politics. Knowing the right person for the job can cut out a lot of time, instead of a generic Slack message saying “Can anyone help me with…?”
Do you have a “release and pray” model? Establish a clear line of feedback on performance, and invest in tools that will help you measure performance. For example, you may want to know if performance problems are affecting users in particular environments. I use our own tools, Real User Monitoring and Crash Reporting daily to understand how customers are navigating our applications and what problems they are experiencing.
Something I learned early was that too many fires are a result of overwhelm, so I learned to follow only three metrics closely, and keep the rest in my peripheral vision:
One thing that works well here at Raygun is setting a quarterly product deliverable, so surrounding your smaller must do’s is one overarching theme. We take it a step further, and ask design to make posters to put around the office, and have a team celebration once we meet that goal. We create a clear “definition of done” which keeps us on track for three months — which sounds like a while, but it always flies by!
I did mention this a little earlier, but, no one cares about the inputs, except you! So don’t fret too much about the details. In my team, we adopt Facebook’s previous motto with a twist. (The latest being “move fast but with stable infrastructure”) We say: “Move fast and break things — but fix them quickly.” This keeps the development team’s technical debt to a minimum, and you customers reassured that if something has a problem, it will get fixed in a reasonable timeframe.
When moving quickly, it pays for product managers to be a few steps ahead by anticipating company needs before they arrive. Where will your company be in three years? Or five? Or ten? You don’t need to know exactly, but it’s a fun thought exercise and can help you sort opportunities from distractions.
Your soft skills are your best friend as a product manager. You must be able to rally your team around a goal.
I’ve found that common challenges to winning friends while taming fires are:
As we have grown, I’ve continued to work on the communication process, especially because our team is multiplying and everyone needs to be in the loop — from marketing to board members.
Here are the things I do to maintain open communication lines throughout the product lifecycle.
Every two weeks, I send a simple PDF slide deck into the office channel talking about what is coming up. The slide deck is a high-level view of everything from minor performance updates to significant feature releases. Above all, these notes are for the whole company, so I make sure they are written in a way that’s accessible to both technical and non-technical stakeholders. If you are interested in creating your own, every update I send has:
Every two weeks, I meet with the marketing team for a catch up around what needs to be announced. This way, we can add announcements into the content calendar. If it’s a larger feature or even a new product, this also gives us time to organize messaging and a launch strategy.
To keep in touch with our customers, I send a monthly newsletter by email with all product releases and any significant marketing announcements. Any product updates get their own blog announcement and documentation which are then sent via an in-app message in Intercom.
A habit we got into early on was to send monthly Raygun updates to let our investors know what we are working on, and which releases are coming up. Our CEO John-Daniel Trask, wrote an article about what a good investor report looks like here.
Both prioritizing tasks and maintaining healthy communication are skills that are learned, which means they can be improved. Here are a few of my favorite books that help me on my journey:
Hooked: How to Build Habit-Forming Products (Personal favorite)
Product Leadership (Personal favorite)
Scaling Up (Personal favorite)
The Four Steps to the Epiphany (Personal favorite)
I also write for the Raygun Blog, where we talk about helping engineering teams build better performing apps.
Wіth mоdеrn web tесhnоlоgіеѕ, yоu can fіnd the bеѕt реорlе for thе job, no matter whеrе thеу live. But wіth distributed tеаmѕ соmmunісаtіоn bесоmеѕ muсh hаrdеr. If уоu hire single соntrасtоr fоr a tеmроrаrу рrоjесt, you mіght encounter minor issues lіkе mіѕundеrѕtаndіngѕ about ѕресѕ, but іf уоu have multiple distributed teams, thеrе іѕ muсh mоrе аt ѕtаkе. That’s where tools like Jira and Confluence come to help. Still in case you run an IT service company there are various challenges when it comes to cooperation with several customers or between several teams with their own Atlassian environments.
Wіth remote соllеаguеѕ, уоu саn’t juѕt ѕtор bу ѕоmеоnе’ѕ dеѕk and have a water сооlеr conversation. Lіkеwіѕе, durіng meetings уоu mіght not be able tо rеаd emotions, feel the еnеrgу in thе rооm, оr рісk uр оn сluеѕ frоm beyond thе ѕсоре оf уоur соllеаguе’ѕ wеbсаm. Communicating effectively becomes fаr hаrdеr, if you try to manage several development groups working distantly.
It can be dіffісult to fіnd tіmе overlaps for рrоduсtіvе meetings, especially іf уоur tеаm іѕ mаnу tіmе zоnеѕ аwау. However there are a few advantages—while you were sleeping, several members of your team delivered their work. So if you plan project accordingly, you can deliver even more within the same 24-hour period of time!
As a project manager you must maintain the task flows for team members and optimize their productivity. If your team is distributed, group planning and tasks estimation might be tricky. If each team plans their internal activities in their own Jira, you need a hub for consolidated view.
If all our teams worked with the same tools before starting to work together, that would a dream case. In fact, we often see that even using the same Atlassian tools, teams work with different add-ons, cloud/server versions, or replace some of the tools with others. This applies to the Client-Contractor cooperation, too. It is often the case that Client is using his Jira environment for communicating and assigning tasks for Contractor. While Contractor uses his own Jira instance to log all tasks and keep activities for different clients in one place for better tracking. Here we face the challenge of cross referencing of issues in different Jiras and the necessity to switch between various environments.How often do you find your developer’s hours logged in your internal Jira, but not in Client’s one? If your billing is chained to Jira, that’s what can happen one day.
Watchtower рrоvіdеѕ уоu with a capability of collecting tasks frоm multірlе environments, merging JIRA projects, аnd showing thеm on a single Agile board. Install it and create your own consolidated bоаrd by аddіng addresses оf JIRA hоѕtѕ from which рrоjесt dаtа will be pulled. The app can be connected to Clоud and Server іnѕtаnсеѕ simultaneously. Bу dеfаult, аll уоur іѕѕuеѕ аrе not vіѕіblе оn the bоаrd. As another dimension you can split issues by swimlanes organized by sources for instance. There уоu саn еаѕіlу rеоrdеr the соlumnѕ and rеnаmе thеm. Thіѕ wау уоu саn сuѕtоmіzе the lооk оf your bоаrd and mаkе іt handy tо use. After easy configuration the WatchTower board looks much like any other task board you already got used to. You can update statuses and provide supplementary information, including worklogs or cross-references to related issues.
What else? You саn еаѕіlу сhаngе thе ѕtаtuѕ оf уоur issues by dragging thеm across thе board tо thе appropriate column and by that updating the status details in the original destination—it is all done without leaving your WatchTower environment. Besides, WatchTower can be еxtrеmеlу helpful іf your сlіеntѕ аѕѕіgn tаѕkѕ to уоu іn their оwn JIRA іnѕtаnсеѕ—this way you will always see new critical assignment in your “home” environment.
Since this tool was created by the team, who worked with customers with their internal Jira instances, we know the issue from inside and also plan to аdd mоrе fеаturеѕ: applying quісk fіltеrѕ, viewing іѕѕuе dеtаіlѕ, commenting оn іѕѕuеѕ or pulling data from other project management teams.
Keep track of all projects you are involved in.
WatchTower acts as a unified board for multiple Jira instances by compiling the issues from numerous sources. Having the app installed, you can easily monitor all your issues pulled from Cloud and Server Jiras to a single Agile board. After you configured the locations, where the necessary data resides, you are free to:
Stay current with the project changes.
Once you have all issues arranged by swimlanes and allocated in appropriate columns you can start using WatchTower to the full. Change statuses, provide comments, worklogs and other details on the issue within the WatchTower board alone—all updates will be reflected in the original Jira. It goes the opposite track as well, WatchTower traces the status changes in original sources and notifies you if the configuration should be adjusted.
Board sharing is another useful feature to keep up on the project performance—share the board, add users and assign different access roles to them.
Have secure and reliable control of sensitive data.
When configuring your Jira environments in WatchTower, you are asked to provide relevant credentials to access the remote sources. However, WatchTower doesn’t store any of your personal data—it uses unique access tokens to interact with configured locations.
Dіѕtrіbutеd wоrk bесаmе a rеаlіtу. Mоrе аnd mоrе соmраnіеѕ choose thіѕ wау to bооѕt their prosperity. Sоmе bіg рlауеrѕ оn thе mаrkеt already рrоvеd tо be grеаt еxаmрlеѕ оf distributed tеаmѕ. These соmраnіеѕ іnсludе Buffеr, Zаріеr, InVіѕіоn, Hеlр Sсоut, аnd many more. So іf уоu are wіllіng tо оrgаnіzе уоur work and switch tо dіѕtrіbutеd tеаmѕ, you can do it more easily now. Did you also stick to Jira? Book a demo of WatchTower to see, how you can keep your team focused on their work!
[unable to retrieve full-text content]Original Link
I’m currently reading Tim Harford’s Messy and the Chapter on Collaboration I found interesting. Especially the section on the Robbers Cave Experiment. I find psychology experiments interesting. They show a lot about the human psyche that seems to get ignored.
This particular experiment took place in 1954. Eleven boys of around the age of 11 and 12. All Caucasian, all being Protestant and middle class. This was on purpose to reduce the number of variables for the experiment.
The boys were then taken to Robbers Cave State Park in Oklahoma US. Named because Jesse James and other outlaws used it as a hide out.
The first stage was the bonding phase. Before the boys boarded the bus, many of them started to make friends. Other activities during the camp of the first week such as swimming and hiking took place. The groups themselves took a name, The Rattlers, from a rattlesnake that entered the camp. They boys became good friends.
We see this type of bonding happen with teams that are thrown together in a working environment. I’ve seen this happen many times. There is one particular team that I worked with. We were a whole bunch of contractors back in 2005. We worked together on a project and every few years we get together for a lunch to catch up. There is no other team that I have worked with that does that.
Now, little did these boys know, was that a second group of eleven boys. Also aged between 11 and 12 and they were doing the same thing on the other side of the park. Their name was the Eagles. They bonded just as well as the Rattlers.
This leads to the second phase of the experiment that took place on the second week. The Competition Phase. Teams started to compete with one another in such activities as Baseball, Touch Football, A Treasure hunt and so forth. Each team was pitted against the other to cause friction. The camp councilors manipulated things to cause an adversarial relationship between the two groups, but a lot of it ended up not being needed. The boys started hating the other for the simple reason: the other group was not “their” group. Name calling, fights started, vandalism of the other teams property occurred. Things really got out of hand (but no one was seriously injured as the councilors stepped in when required).
As adults we see this type of thing happen all around us. Many wars have been fought and continue to be fought on the same premise. In the office, we see this as a rivalry between teams. An us against them. Workers against Management. IT department against the Finance Department. We do not see things get out of hand (at least not a majority of the time) but the friction is still there. Actually, the story of how NUMMI started out is a good example of how conflict between workers and management can get out of hand. Things got so bad at the GM plant that workers would sabotage cars, drink and take drugs on the line among other things.
In many work places, an underlying rivalry is normal, although usually ignored because it is done in a civil way. For example, every time you think a department is useless, or incompetent, but your team is great and faultless. We have all done this at some point, it is human nature, but we are propagating the rivalry.
The final phase of the experiment was to reduce the friction between the two teams. This was done by bringing the two groups together in non-competitive activities such as watching movies, campfire sing songs and so forth. These types of activities did not work—as expected. Even in the real world, we have team lunches to try to reduce tension and friction within a team, team activities like laser tag, or those team building camps I keep hearing about, but never attended. These types of activities do not work. Yes, everyone has a bit of fun during the period, and if your team is already working well, they are great, but as a method to get a team in friction to be a more cohesive whole, they are pretty much useless. My thoughts are simply that these situations are social situations, completely different to the work situation. They do not build up trust. If there is no trust before the activity, there will still be no trust after the activity.
In the experiment, the only way the two teams got over their differences was to work together to solve a mutual problem. For example, the councilors unbeknownst to the boys sabotaged the water tank and water supply. They boys had to work together to try to solve the problem. Another, a truck got stuck and the boys had to work together to get it out.
I’ve seen this many times in my career. I have always said, “If you want people to get together, have them work together”. In this situation, provided everyone is treated equally, you gain a mutual respect for one another. In the book Team Of Teams by General Stanley McChrystal, McChrystal talks about how he got the various military forces to work together. They would take someone out for example, the Army and place them within a Marines unit. They would stay there for 6 months or so if I remember correctly. Enough time for the unit to work with the new member, and gain each others trust, which is difficult when lives are on the line. That member would then return to their original unit.
What this achieved was a reduction of the degrees of separation between anyone within one military force to another military force. Taking our Army/Marines example, if the Army needed something from the Marines, intelligence, co-operation for an exercise, etc., normally each “silo unit” would resist politely. But after this method of seeding, the Army would approach the soldier who spent time with the Marines. They would then contact their buddies who would help out a friend. The same thing vice versa. Now, where you had rivalry, you now have cooperation.
If you want your people to work as a team, then you need to give them all a common problem or goal to work towards. A goal that is simply to get the work done just won’t cut it. Not if you want a high performing team, and what Manager doesn’t want that. The goal has to be greater than the team. Something that will inspire.
I am reminded of the story of the 3 bricklayers.
Once there was 3 bricklayers. Each one was asked what they were doing.
The first one responds grumpily, “Laying Bricks”.
The second one responds indifferently “Building a wall”.
The third one responds enthusiastically, “I’m building a cathedral”.
It is management’s job to find a way to inspire their people so that they feel that they are building a cathedral, not simply laying bricks.
In Scrum, the process of having everyone in the team work towards a common goal is written in the guide. This hasn’t been added for show, having people working towards a common goal is a proven way to get people to work well together, and work together well.
The second lesson is to remove the reasons for friction between two groups. In Scrum, there is the concept of “Servant Leadership” where management is there to “help” and “guide” the workers much like a teacher or a coach. They do not order people around like traditional management. Ordering people around creates a sense of “us and them,” whereas servant leadership promotes a sense of collaboration and uplifting.
The third lesson is to make sure that every team works together, and trusts one another, even if it is just one representative from each team for a short period. It may only take as little as a week for people to bond. Encourage collaboration and your people will do great things.
For more information on the Robbers Cave Experiment see
5 Minute History Lesson, Episode 3: Robbers Cave
So, let’s get the basics out of the way: we all know that Agile is a method that contains multiple frameworks (Kanban, Scrum, etc.) that is aimed at multiple priciples created in the Agile Manifesto. And while it’s easy enough to read the Manifesto and the principles it supports (both of which are, unlike almost anything else dev-related), putting them into application to improve your leadership and your team’s collaboration is often a more daunting prospect.
In this edition, we’re going to round up all of the article from the month that can help us “a face to a name” and identify concrete ways to implement Agile processes and improve…well, everything. Let’s get started.
Here were the most viewed articles from the past month.
Object-Oriented Analysis and Design (Part 1) by Muhammad Umair — This four-part series tackles the benefits of iterative software design and object-oriented analysis. We start with a focus on how design has evolved.
Object-Oriented Analysis and Design (Part 2) by Muhammad Umair — Second verse, same as the first. In part two of the same four part series on Object-Oriented Design, we go over some of the core definitions behind the practice.
The 2018 Olympic Games and Agile by John Vester — Zone Leader John Vester takes a look at the 2018 Olympic games, building parallels with Agile development lifecycle adoption.
Traditional vs. Agile Software Development Method: Which One is Right for Your Project? by Denisse Morelos — Everyone’s talking about Agile, but does it necessarily fit your business needs? Talk to your local product team today to find out if Agile is right for you.
6 Skills Developers Should Build to Unstick Their Careers by Eli Lopian — Feeling a little like a programmer in a hamster wheel? Maybe some of these tips will help you advance your career and escape the monotony.
I would caution that my selections this month may not have anything to do with the theme, but since Agile is all about focusing on the team in the product, everything should be theme-adjacent.
I think I speak for all Millennials in attendance when I say, “Thank. You.” Just as every other generation before us probably has (but maybe not as much), it seems that Millennials are consistenly criticized for how we are perceieved in the workplace. Here, Xander provides some insight into what Millennials may really be looking for in a workplace.
Consider the humble Sprint: a fixed-increment segment of development that includes agreed-upon, but changeable, production results. That’s the very basic gist of it, but the Sprint is sooo much more, and this article does a great job of highlighting what makes a Sprint so valuable to the Agile framework.
This ain’t your typical listicle. Full of rich content and expansive talking points on each design trend, this article goes a long way toward actually making you believe each of Magdelena’s arguments on the trends she chose. AI, CDD, video, animation, and design systems converge in this article, with a little AR for good measure.
With so many responsibities and roles to juggle, it can be easy for the Project Manager to get a little turned around about who they are responsible to for what. This infographic should give the Project Manager, his/her team, and upper management a better idea about what the PM is supposed to do and for whom.
Working from home isn’t always easy, and working with a team that works from home rarely is. Here, Arina puts the tools in your hands that will help you better communicate and work with a team that you may never see.
In the midst of all your stand-ups and Sprint plannings, don’t forget the root focus of any Agile transformation: a people-centric focus. While there certain implementations of Agile call for different layouts, Holger reminds us to stay true to the idea that a great product can only come from a great product development team.
That’s it for this week. As always, keep the articles coming and leave anything you might think I missed in the comments!
I was on vacation last week, thinking about value. Depending on my role, I might think of value as:
Notice that only the very first way to think about value is about the delivery of this feature. The other two ideas are about information for the product owner and possibly the product manager.
When product owners have feature-itis and treat teams like feature factories, they miss all the juicy information the team might have about this feature and what it means for the feature set and the roadmap.
One PO had what he thought was a high value-low cost story. The story created an easier way to import new data. The customers would be independent of their IT group if this import worked. The team finished the story, demonstrated it and asked if they could watch the PO demo the story to just one of their customers. The team specifically asked to watch this customer.
The PO didn’t quite understand, but he decided the team had good ideas so he did. He demoed the feature to this specific customer. The customer was thrilled and asked many other questions about other data sources and the general cleanliness of the data.
The team took a ton of notes, especially about the questions about other data sources. The PO checked with the customer about the frequency of those data sources. They had a spirited discussion.
Afterwards, the team explained that other data sources were known to have what they called “unclean” data. The import would not be as fast and the customer would have to scrub the data. The other imports would not be low-cost. The team couldn’t tell how high-value the other imports would be.
That discussion helped the PO review the roadmap with the customer. The PO and the customer agreed that the team would provide only one more automatic import. All other imports would be their own little projects to scrub the data as they proceeded.
That meant that of the feature set of 15 possible data imports, the team implemented two. The team provided their customer enough information to request (demand) that the vendor scrub their data before they would consider it for import.
This PO didn’t treat the team as if they were a feature factory. The PO treated the team as valued partners.
The PO didn’t treat the internal customer as if their wishes were king. The PO treated the customer as valued partners who could understand the problems the team might have.
The customer explained to the vendor the problems with the data. If the vendor wanted the customer to buy this data, the vendor had choices about scrubbing it.
Notice how everyone here collaborated to find the best solution for now? When we think about value as not just a delivered story, but also about information, we can change how we work.
Teams can provide more than finished features. In fact, teams should. These teams need a full-time PO to be able to understand and process the information.
Consider thinking about value in these three ways:
More information might help us collaborate better, inside teams, with customers, and even with vendors.
“Talent wins games, but teamwork wins championships.” This is a quote from Michael Jordan and actually, he is right. Any successful decision, whether it is a victory in a championship or the release of a new product, is achieved through the efforts of the whole team. Where does the path to success begin?
Here we’ll define all advantages of brainstorming process that can become the beginning of great success of your company.
Brainstorming is an effective way of solving problems and current tasks, based on stimulating the creative activity of team members. The goal of brainstorming is to generate as many ideas as possible and determine the best solution based on them. Besides, brainstorming is one of the great solutions if the team members have such questions as, “How do we avoid routine in work processes?”
How often did your coolest projects start with a simple brainstorming session? Should we use brainstorming as a permanent practice in the team working life? In this article, we define what brainstorming is: a must-have process or time wasting.
In fact, Agile brainstorming focuses on the same common goals as any other brainstorming. There are differences in team members — the majority of participants in Agile brainstorm are developers.
Do not confuse brainstorming and a daily Stand Up.
A daily Stand Up is a meeting that takes place in Agile frameworks like Kanban, Scrum, Extreme Programming to synchronize actions and discuss statuses on short-term tasks.
The Stand Up should not be turned into brainstorming because it has time constraints assigned by product managers or project managers (most often, 10-15 minutes).
Brainstorming in Agile teams is a thorough and detailed event with a specific goal to find a solution.
During the brainstorming session, all participants are invited to express as many options as possible to resolve the issue. As a result of the practice, several of the solutions most acceptable to the problem are selected.
In an ideal world, the agenda of brainstorming should be announced in advance. In this case, the participants and team members will be able to prepare everything. A moderator (a project manager or a product manager) chooses and notifies all participants, informs them about the place and time.
It is important for the moderator to understand who needs to be invited. It depends on the theme: a content manager is unlikely to be useful in technical development issues, and the CEO of the company does not need to discuss the concept of the site’s FAQ page. However, each case is individual and there can be exceptions everywhere.
Example 1: Brainstorming dedicated to the industry exhibition where a SaaS product participates. The goal is to design the booth concept and explore related product activities. For discussion, a marketing specialist, a PR specialist, a designer, a financing manager, a logistics specialist and a procurement specialist are invited.
Example 2: Brainstorming dedicated to the introduction of product’s Android application. The goal is to diversify the app and to create competitive features. A project manager invites developers, a designer, a beta tester and a support manager.
A clear formulation is important to all team members. It is necessary to identify the problem without any additional clarifications.
Often, the global results depend on the goal formulation. The more clearly initial data will be given to each participant, the more effective the brainstorm will be. There is no need to discover continents: set your goals according to SMART principle.
In fact, this is the most important stage, in which, among dozens of options, real solutions to the problem are born. It should be a continuous stream of ideas, from the most trivial to the most fantastic. The more active participants in a brainstorming session, the more chances for successful ideas.
Visualization is the first step in finding a solution to any problem. Fix your ideas on paper and you will quickly find additional ideas or you can build a chain from the abstract thoughts. Draw illustrations, graphics, use Kanban-boards with cards. All this will help to find the right way faster.
It is important to be able not only to listen but also to hear. Do not interrupt participants and give the opportunity to speak out to everyone. Even the craziest idea has a right to exist. Criticism during brainstorming can bring down the pace or even offend.
After active brainstorming, the stage of evaluating and ranking ideas begins. It’s a good time to remember about prioritization techniques and, if possible, to apply an accessible tool for prioritization that will quickly help visualize the most important and secondary ideas.
Even if the tool for prioritization is designed for long-term plans and ideas, it can still be useful for the short-term assistance. For example, Backlog Priority Chart by one of the platforms for product management includes the following criteria:
If the process of discussion has reached a deadlock or the votes of the participants have shared equally, do not hesitate to call “fresh” heads.
The brainstorming coordinator should not leave the process even for a minute. Some participants may be shy and not speak out on time. You need to track the timing, ask leading questions and give the voice to everyone.
Do not lose conclusions. It is very important to fix all the thoughts to have the opportunity later to return to them and to analyze something again.
Brainstorming can be held according to your rules, from timing to selection of participants, or can strictly follow the principles of one of the methodologies specially designed for successful discussion.
The stepladder technique is a simple method that stimulates the entry of team members into the decision-making group and demonstrates how they do it.
Decision-making within a group may not go smoothly. There are always more active participants and those who prefer to remain silent if his/her position does not gain the necessary “weight.” Some people need a lot of time to fight for recognition within the team, and some gain credibility from the first minute. Because of this, the course of brainstorming can get out of control.
The technique was developed by Steven Rogelberg, Janet Barnes-Farrell and Charles Lowe in 1992. It motivates all team members to participate on an individual level, without undue influence. This leads to a wider variety of ideas. It does not force people to “close” and excludes the pressure from the more active members of the group.
The technique involves 5 stages:
The method is a systematic approach that involves all members of the group and allows everyone to be heard. Stepladder is recommended to shy, modest and calm people.
This method is rather effective for everyday life and for professional solutions since it allows you to take into account the opinions of all people, by consistently combining proposals and conclusions. This is quite similar to Stepladder technology. However, this approach to brainstorming is different.
Participants are divided into two groups:
The technique involves three stages:
The questionnaire is returned to the experts. They have to tell if there is anything to add and if the information is enough. The experts need to offer their own solutions to the problem and explore alternative positions. They assess the effectiveness, availability of resources and the relevance of solutions. The analysts identify the main opinions and try to bring them closer. The steps are repeated until the experts come to a consensus.
Round-Robin is a brainstorming session with the principle of circular ideas creating.
This method lasts not as long as the previous ones. The more participants, the better results will be. This brainstorming is best conducted with a large round table.
Here’s how it works:
Reverse Brainstorming is useful when more traditional techniques are no longer work. This is quite a radical way to raise the team’s activity and come to effective results from the opposite.
Reverse brainstorming is considered as a negative process. Instead of generating better ideas, participants are asked to offer impossible goals.
People who fond of the technology think that with the help of negative thoughts the group receives useful information about what does not work.
This method can be helpful when the team members are “burned out” or the company has reached a dead end.
It is always easier to find negative than positive. Besides, negative emotions provoke to speak. Therefore, reverse brainstorming can turn into an exciting event within your team.
Rolestorming (role-playing brainstorming) may seem like a game or process, suitable only for creative teams. However, often, this technique allows you to go beyond the accepted and get completely new and fresh ideas by presenting the problem on behalf of another person.
You can generate ideas as Mark Zuckerberg, Steve Wozniak, Bill Gates, or even the Pope. Each participant describes his/her character and presents the problem and possible solution from the point of view of the person described. All ideas are discussed in the group.
You can understand which of the techniques is right for your team only by experiencing each of them. Testing the methods, you will find out that brainstorming is not a waste of time, but a productive event. The question “why” should give way to the question “how”.
Try them and share your experience!
Meeting deadlines is the essence of successfully conducting modern business. In this increasingly competitive world, companies that do not meet delivery deadlines risk their continuity.
Project management success comes from setting up an efficient and effective processes and workflows for collaboration.
According to a survey by the Project Management Institute, organizations are wasting $97 million for every $1 billion invested due to poor project performance.
Another study by the PMI showed that the presence of a project management office on average helps improve delivering the project on time. However, the mere presence of a project management office does not ensure that delivery deadlines are met.
To ensure that your project team meets delivery deadlines, steps should be taken to avoid the following three mistakes.
Successful project completion depends on committing to completing the project. Commitment would depend on many factors like a clearly-defined timeline, adequate budgeting, and a clear project scope. The main reason why project teams fail to meet the delivery deadline is that these key aspects of the project are not clearly identified.
Committing to a project involves establishing a realistic timeline, delivery date, and project scope at the start of the project. This is because the project timeline is devised keeping in mind the deadline of the project whereas a clear project scope protects the project from being delayed because of scope creep.
Without a set deadline, clarifying the project scope or agreeing to an unrealistic deadline provided by the client would result in over-commitment.
A PMI survey showed that project managers with poor performance experience 46% budget loss due to failed projects. As a result, these managers are only able to complete 24% of their projects on time and have a 68% chance of experiencing a scope creep.
To prevent over-commitment, you need to ensure that the deadlines set are realistic. Similarly, a set deadline is crucial for project completion as without a fixed deadline the customer can demand the completed project at any time and, being unprepared for it, the project team would fail to meet this deadline.
The same would happen in the case of an ambiguous project scope: the client could keep changing or adding to the project scope after the project has begun.
Clearly, projects that entailed delivering more than the team could handle would not be delivered on time. It is crucial to monitor that the project requirements are realistic and attainable in the given timeline to ensure that project is completed on time.
Once the project has started, the project management office is responsible for resolving any issues that arise in a timely manner. The issues and risks projects have to face can vary from the expected like team members going on leave to the unexpected like a team member leaving the firm.
The project management office analyzes project risks at the start of the project and devises a plan to resolve these issues efficiently and quickly. However, it is essential that the issues should be resolved.
While it is easier to put aside any unforeseen problems that arise, failure to tackle these issues might result in the project not completing on time.
The presence of a strategy for resolving unexpected issues would help the project team deliver projects on time. Furthermore, it is important to encourage communication and collaboration to resolve issues.
Encourage team members to report issues as soon as they arise so that they can be resolved just as quickly. Project management software like nTask can be used to improve communication and collaboration.
Project communication starts from the moment the project is conceived and ends at the moment the project ends and consists of project planning, sharing of information between stakeholders — basically the whole communication network.
Communication’s importance increases once the project starts. This is because communication clarifies what are the responsibilities of each team members and what the project timeline looks like.
Communication failure occurs when information is lost, misunderstood, shared late, not at all or too many times.
Most of the time, people use email for communication and collaboration. Keeping track of important information shared via long email chains might become difficult for some people, especially when working on large projects.
According to a study, 57% of projects fail due to breakdown in communication. Also, virtual teams identified long email threads as the second biggest challenge to communication.
Communication failure increases the chances of project being delivered late. A project management software tool can be used to ensure that important project communication is located in one place where every team member can access them at any time.
As the person in charge of a product, you are responsible for achieving product success. But you can’t accomplish it on your own, and rely on the development team and stakeholders. Their contributions are vital to design, implement, provide, and support a successful product. At the same time, you can’t tell the individuals what to do or assign tasks to them, and you are typically not in a position to offer incentives, like a bonus or pay rise.
So how can you align people and ensure that everyone moves in the same direction and carries out the necessary work? And how do you ensure sufficient autonomy so that the individuals can own their work? Part of the solution is to establish a set of shared goals, goals that people support and that help you progress your product. The development team and stakeholders then use these goals to determine the work they have to do — be it creating a marketing strategy, investigating a new technology, or preparing the distribution channels. This focuses everyone on the joint outcomes you need to achieve, and it gives people the freedom to manage their work, thereby creating purpose and autonomy.
Let’s take a look at the type of goals that help you move your product forward and align people.
The picture above shows a set of goals that are linked and operate at different levels. The first and possibly most powerful goal is the vision, which describes the ultimate reason for creating your product and the positive change it should bring about. An example I like to use is healthy eating. As this example shows, the vision is an inspirational, visionary goal that cannot be measured.
The user and business goals are strategic goals that are derived from the vision. The former describes the problem that users want to see addressed, for example, lose weight, or the benefit that users want to obtain, for instance, reduce the risk of developing diabetes. A business goal states the benefits of the company developing and providing the product wants to achieve, for instance, diversify the business, open up a new revenue stream, and develop the main brand. Whatever user and business goals you choose, make sure that they are specific and measurable. This allows you too select the right key performance indictors (KPIs) and understand if your product is meeting its goals. I like to capture vision, user, and business goals on my Product Vision Board.
With user and business goals in place, you can take the next step and determine release goals. Each release goal should be a step towards meeting the user and business goals, and it should describe the specific benefits a major release or product version will provide, for example, acquire users, increase engagement, generate revenue, or remove technical debt to future-proof the product. I like to capture release goals on the product roadmap together with their metrics, and I have a preference to work with a goal-oriented (or themed) roadmap like my GO Product Roadmap.
Finally, identify the right sprint goal. A sprint goal states the desired outcome of a sprint, such as find out if users are willing to share personal information, test integration with leading smart scales, or finish the dashboard to release a first version to the test users. I recommend that you derive the sprint goal from the goal of the next major release and state it on the sprint backlog or task board. This ensures that each sprint moves you closer towards the release. (If your development team works with Kanban instead of Scrum, then it might still be helpful to agree on weekly goals that direct the work of the team members.)
Every sprint goal should be a step towards a release goal; every release goal should help you reach a user or business goal; and the user and business goals should help you realise your vision. The different goals are therefore linked and form a chain that covers all product planning aspects: visionary, strategic and tactical ones.
It’s great to know what goals are helpful to direct and align the development team and stakeholders. But it’s not enough. The individuals involved in developing and providing the product must support the goals to move together in the same direction. Otherwise, people are likely to follow their own goals; orchestrating everyone’s efforts will become very difficult, if not impossible.
The best way to achieve strong buy-in is to actively involve the right people in the goal-setting process. I like to bring together the development team and key stakeholders and run a series of collaborative workshops: a strategizing workshop to come up with a meaningful, inspiring vision everybody believes in, and a product strategy that contains user and business goals; a roadmapping workshop that identifies realistic release goals using the product strategy as an input; joint product strategy and roadmap review meetings to update or change to the strategy and roadmap; and sprint planning meetings that establish meaningful and realistic sprint goals. (Note that stakeholders don’t participate in sprint planning meetings. Instead, they are invited to sprint review meetings, which provide an opportunity to offer feedback on the latest product increment.)
Bringing together the right people allows you not only to generate strong buy-in; it also leverages their collective knowledge and creativity, and it establish meaningful goals, goals that are worthwhile to pursue. But a collaborative approach also carries the risk of friction and conflict. In the worst case, powerful individuals (HIPPOs) might highjack the goal-setting process and dictate goals.
To mitigate these risks, I recommend that you involve an experienced Scrum Master, coach, or facilitator, who sets the ground rules, facilitates the workshops, ensures that everybody is heard, and nobody dominates. Additionally, make sure that you apply the right decision rule. As vision, user, and business goals are particularly crucial, you should attempt to achieve consensus with everybody fully supporting the goals. If that’s not possible, then discuss different options with the dev team and stakeholders, and then you decide as the person in charge of the product. (You may want to download my decision-making chart to select the right decision rule.)
If you feel that an open, collaborative approach is not feasible, then consider running individual meetings with the various stakeholders and development team to discuss a draft goal, incorporate people’s feedback, and rework the goal so that everybody can support it.
No matter which approach you choose, be careful that you don’t become a goal broker or mediator; actively shape the goals and avoid making weak compromises to strike a deal or please people. Don’t be afraid to push back and say no when appropriate. At the same time, appreciate people’s ideas and concerns even if you feel they are not helpful or appropriate. When you care about the individuals, empathise with them, and understand their perspective and needs, they are more likely to support a goal even if they don’t fully agree with it.
A colleague asked my opinion on the various teambuilding activities she was considering for a new-to-Agile team, to help them get to know each other and work together.
All the activities she considered were simulations of various kinds. I suggested she reconsider the simulations and focus on the work to help people learn to work together.
I’m not against teambuilding. However, I wonder if we overdo simulations, especially in new-to-Agile teams where people don’t have the context.
I recommended she consider pairing, swarming or mobbing as a way to build a team. I recommended she ask the team(s) to consider experiments. They were new to working as an Agile team. They’re new to the idea of team-based collaboration. When teams try pairing, swarming or mobbing (especially if the idea is to improve the products), they have many opportunities to work as a team:
I recommended she ask the team to consider three days of experiments: a pairing day, a swarming day, and a mobbing day. I was thinking of that order, but maybe a different order would work better.
I suggested she facilitate a debrief at the end of each day to help the team see the results of that day’s work. And, a debrief at the end of three days to see if they like any of these ways of working.
Maybe it’s time for an open space to see if they have better ideas. Or, ideas about why these possibilities won’t work here.
My colleague had several assumptions, primarily that the team members wanted to and could work together. In some organizations, people are called teams, but they’re not measured as teams. Best to understand the real issues in the organization when people attempt to work together as an experiment than to have them try a simulation that doesn’t work in their real world.
I don’t find value in teambuilding activities that don’t correlate with the work the team is supposed to deliver. I find learning to work together useful.
Recently I spoke at the LeSS meet up in Melbourne about the importance and the rationale for the Product Owners (POs) to maintain 5 key relationships.
I was happy with the turnout and the quality of questions that came up during the session. I used the following graphics exploring the the 5 relationships.
Most people already know that PO is accountable for the ROI and the importance of maintaining the relationship between the stakeholders, customers, and the team. But the importance of managing the relationship between the customers and the team is highlighted in LeSS.
LeSS highlights the difference between prioritization and clarification. One of the LeSS rules is, PO prioritizes the requirements, but clarification is done as much as possible directly between the customers/users and the teams.
Following graphics represents the above rule:
It is important to remember a few points about the clarifications vs. prioritisation perspective:
I have this growing digital notepad that I’ve started writing in over the past year: It’s titled “Be a Great PM,” and it’s a collection of information and encouraging quotes from books, online articles and discussions with others, or just plain thoughts that came to my mind. It serves as a motivational guide and supporting source when I feel I’m not good at my job (I bet I’m the only one in this world to feel that way, am stuck, or need to know how to move forward or away from a situation.
After revisiting it once again last week, I wondered if this is something I should share with the world, and fill it with some more words so others might be able to benefit from it. If you end up reading this post and find yourself going “Duh, I already know that” — I think that’s ok, as I believe it might help you and others remind yourself that you are not alone with some of the daily challenges you face as a PM.
Additionally (and still surprising to me), I’ve received about half a dozen personal messages from students via LinkedIn or Twitter over the last year asking me if I could chat with them about Product Management. Feeling still extremely honored, I’ve tried to set up calls with most of them, but of course, that’s time-consuming and we are all busy, right? Most of the students who approached me were female CS students eager to learn about product management. It reminded me of how I felt, coming from a mostly male-dominated engineering world, trying to score my first PM job, and how useful it was to get real-life stories and advice from people around me. I felt happy that it was my time now to give back.
A little disclaimer before the actual post begins; just to be clear, this blog post won’t mention “user stories,” “backlog,” “roadmap,” “CEO of the product,” or any “frameworks” to follow — this post is about all some of the interpersonal skills a product manager should possess and ideally practice in their daily role as a PM.
Even if your team members don’t really tell you that directly, they want you to make decisions, even if they don’t agree. In the book Making It Right: Product Management for a Startup World, I was backed by my belief that not everybody has to agree with every decision you make (as a PM). So while I reach and foster to build a collaborative environment with the team, I’ve come to understand that this means everyone gets a voice but not everyone can or should get to decide.
I always encourage everyone on the team to share their opinions and invite them to discuss their concerns and hopefully provide useful compromises if they don’t agree with something. It’s crucial that every team member I work with knows this; I will always listen and try to understand your point of view!
Don’t get me wrong, quite frequently, I’m not fully certain myself about the decision that I made but I normally have a gut feeling, and if you can calibrate this feeling with some (even very few) hard facts, it goes a long way.
I need to clarify though, rarely do I get the opportunity to make a decision with perfect information. As a PM, you’ll need to learn to be ok with making a decision with sometimes immature information.
Seth Godin said, “Nothing is what happens when everyone has to agree.” The product manager is there to make sure things happen and make the right decisions, which is most of the time not consequently the most accepted one.
I love working with my engineering manager. He keeps repeating what was brought to him by his manager who probably picked up the original quote from Jeff Bezos but adjusted it to: “Disagree but commit positively.” Brilliant!
I love this quote so much, and I hope everybody can follow this simple but yet so powerful approach to any team interaction (in life). It also doesn’t hurt to remind people in the midst of a discussion about this quote.
Assuming you’ve made the wrong decision resulting in some sort of failure, figure out (hopefully before) how failure is being treated inside your company and, most importantly, by your manager and upper management. It’s great if you get a feeling that the company you work for encourages failure. Do you feel comfortable and supported to propose a new feature or an entire product, knowing that management trusts your judgment and engagement to try your best to succeed, and if it doesn’t work out at the end, they won’t judge and are ok with it? Build trust and set clear expectations for your manager so they feel comfortable supporting you in your work and knowing you will try your hardest and best to succeed. (Thanks, Jeff + Nick)
As I go through life, my daily goal is to be more mindful of people and situations around me, and practice being reflective and introspective. Respecting people around me is as important as feeling respected. It’s extremely important, besides respecting individuals, to also respect their role and what their role entails, and most importantly understand their professional motivation.
It has happened so often in my professional career that I’ve heard coworkers complaining about specific departments, and that that specific team wouldn’t know what they are doing, or why are there doing XYZ. To be honest, we should all at least try to put ourselves in their shoes and reflect for a moment: is there a good reason this person might be proposing XYZ. Just breathe for a second, think about it and give the other side a chance to explain themselves. Ask them, “Why do you want to do that?” “How does it make you succeed in your role, and better us as a team?” Ask for the reason why they are doing this. What is their motivation? I hope it goes without saying that you should be careful to not make them feel they need to justify their role and come across as if you question their good intentions; don’t give them a hard time.
And of course, share your motivations as it relates to your role as well.
I know, you can’t choose who you get to work with, and I think it’s totally normal to encounter people in your career that you can work better with and the ones you can’t. Try as much as you can to reflect and understand why it is that this particular person has the power to push your buttons and figure out what these buttons actually are and mean. Be honest with yourself, listen carefully to your inner voice, and see if you can find out if you are intimated or just jealous because it’s something they do that you might be afraid of. I’m not certain where I picked this up first: you should try to focus on at least one good thing this person does, or can, and keep that in mind when interacting with them. I’ve tried it, it works.
I noticed I feel very thankful when I get the chance to work with solution-oriented people. The idea is that it’s ok to poke holes, disagree or block on something but provide alternatives or actionable feedback, similar to “disagree but commit positively.”
In order to be the glue, you’ll need to find out what sticks with the team; sometimes each team member needs different support. Overall though, I try to stick to the attitude that I will fill any gap where needed, that means in practical terms, get snacks for the team, or write a patch; do anything you can to help the team succeed. If they need you to unlock something that you’d thought is not something you should be doing, leave your ego at the door, and just do it!
Repeating a “why are we doing this,” a plan, a goal, or the strategy goes a long way when working with cross-functional teams. Don’t worry sounding like a broken record (seriously, try to let this go!). I still chuckle a bit inside when I begin meetings by saying “The purpose of this meeting is…”, or, “We are doing this because we believe we can move the needle on retention.” In addition to verbally articulating, put it in a shared document, email it around, and make it your channel topic in Slack.
I have to admit, I’m a people pleaser (well, who likes conflicts?) — and that makes it even harder to practice one of the most important skills a PM needs to perform on a regular basis: saying No. It’s still not easy for me but I’ve learned to do it more often and it got easier. And if it’s difficult for you, try saying “Not now.” This has worked for me in difficult situations.
In the book Making it Right: Product Management for a Startup World, the author breaks down what empathy means, and adds another word to it: Fair!
Fair: free from favoritism or self-interest or bias or deception.
Concentrate on these words, and validate yourself against them when talking to your team members, and of course, interacting with your users. It can be difficult, as a PM, to take your own emotions and feelings out of the equation when making decisions, especially if you, yourself really believe you are the “typical” user.
When dealing with product decisions and what we think users would want, I try as best I can to void using the phrases like “I think…” “I would” —
Another great piece of advice, stemmed from Stephen R. Covey’s observation, is try to listen to understand and not to respond, especially if it’s criticism. You need to be able to take that criticism constructively and not personally, and turn it around to make a better product. I remember several years back during my first product kick, it took me a while to not take trolls or user comments personally. Behind each angry user or troll there are normally solid reasons for their behavior; sadly, they might just want attention, they want somebody who listens to them, and wants to be understood, or a user who really wants to use your product but is frustrated because it’s not solving their problem (that’s an interesting clue for you to try to understand if this might also be a problem for others, less vocal users).
This list by no means is complete — however, like I do, if you have a bad day and feel you are not doing a good job, review these points and I hope they’ll provide you with some comfort and reassurance that you are not alone.
I’m sure you are a good PM.
One of the important decisions in developing a program is choice of language. As of now, we probably have hundreds of programming languages and the number is growing. Selecting the optimal programming language is probably the way to go, but sadly that’s not what happens in real life. In my experience, the teams tend to choose a programming language for the job without much reasoning.
We as developers like to explore and learn the new tech. As a result of this, we learn new programming languages and we want to code in that language. The easiest way to do that is to start a new project with the new language. Without much thinking, the developers dive into a rabbit hole with a new programming language and new tooling. The project works great and everybody is happy about it for a while. A bunch of people who were comfortable with the project quit and the code becomes legacy. Now, nobody else knows neither the language nor the tooling, or the developers suddenly understand the language chosen isn’t really a good choice for their project. So, they start hacking and making ways to make it better because there’s no turning back.
You start a new project and you pick the language which the senior engineer is comfortable with. S/he wants to code in that language because s/he’s comfortable with it and s/he can do code reviews easily. The project starts and you realise it’s not getting any better. Maybe the language lacks the functionality or framework support around the project you are developing. So, what do you do? You re-invent the wheel by adding these functionalities. It could have been free if it was in a more appropriate language.
Sometimes, the company heavily invests in a particular language for various reasons and everybody becomes comfortable with it. They hire people who know how to code in that language and the loop goes like that. Therefore, they solve every single problem with the same language and tooling. When they hit a shortcoming of a language, they fix/improve it with interesting approaches. However, they could have avoided the problem by using the legitimate language for each task.
Your boss doesn’t care about the language. The only thing matters is delivering the project reliable and fast. When you pick the wrong language for the job, you end up doing extra work for the above reasons. So, what happens to delivery? You can deliver neither quickly nor reliably, and your funding may get cut off, or the customer becomes unhappy and no longer wants the product. On the other hand, if your company makes so much money than it doesn’t matter, you can probably implement hacks. Maybe implementing the hacks are advantageous over switching to another language.
Before starting a new project or adding additional features, we should take some time to think about what’s the optimal language or tooling for the project. There are several factors to consider like options for maintenance, the payoff for choosing a candidate language, available frameworks, learning curve, deployment environment, user base and etc. If you carefully compare available languages for the job and decide which language to go for logically, it’ll make things easier in the long run.
Teams select a programming language for a given task because of various reasons. Nevertheless, the choice for the language may not really depend on the rational comparisons. Teams may choose a language because somebody in the team likes a new language, a senior member of the team suggests his favourite language, or the company is too deep in some particular language. All in all, right tooling or language matters as the time to market depends on it. Hence, we should better spend some time evaluating languages before starting something new.
To better understand the Scrum Guide, I’ve been deconstructing it by writing it longhand (yes, longhand — I’m a little crazy that way). I worked on the 2013 version of the guide, but I decided to backtrack a little, so I started with the section on Scrum values.
When the values of commitment, courage, focus, openness, and respect are embodied and lived by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life and build trust for everyone.
This got me thinking about the Toyota House metaphor that has the foundations of commitment, courage, focus, openness, and respect. Its pillars are made of transparency, inspection, and adaptation. Then, we have the roof of trust.
To me, this is the Scrum Team House.
It has been a while since I listened to Patrick Lencioni’s audiobook The Five Dysfunctions of a Team. This book is one of those fictional management novels that tells a story to get a point across. After reading the above passage, I saw the connection between Scrum values and Lencioni’s work.
Lencioni’s book describes the following five dysfunctions of a team.
This isn’t the type of trust whereby a manager trusts his people to do the job right, although this is part of it. This is the trust whereby a weakness, be it personal or professional, will not be taken advantage of. This is the kind of trust that makes you feel that your team members have your back rather than stab you in the back. If something goes wrong, they will not attack, criticize, blame, and shoot you down. Instead, they will help, they will encourage, and they will listen.
A lack of trust also leads to lack of respect for other team members. Would you respect someone who used your weakness against you? Do you show respect for someone when you have exploited their weakness?
Lack of respect causes fear — fear to voice opinions lest you be criticized. Fear to speak out when you think something is wrong or when you disagree with the team. Fear to try something new.
Things become opaque, convoluted, and complex. Knowledge is hoarded and ideas are not expressed. This lessens the team’s courage to lead constructive discussions and constructive conflict to help problems become openly discussed and explored for alternative solutions.
Fear leads to lack of commitment. Would you commit to something you had no say in? Would you commit to something you didn’t believe in? What you end up getting is compliance. People doing the minimum requirement. Work then transforms into being just a job — something you do for a paycheck. When this occurs, no one will want to take ownership of anything.
To avoid blame, finger-pointing ensues. Why would anyone want to take responsibility for something going wrong if you get in trouble? The blame game prevents the inspection of problems and thus the proper resolution to those problems. You will have one of two outcomes: Only superficial resolutions will be put in place, or the problem will be swept under the proverbial rug.
We have a saying in Australia, “Head down, bum up,” which is a figurative expression for working hard (think of a child kneeling down on the floor, working in deep concentration on something like a drawing). So in this climate, people are working hard, just doing their job, not worrying about their surroundings, and not focusing on results. They do only the hard slog (another Aussie slang term for doing grueling work). The team cannot adapt if it has this mindset.
I can see now that the Scrum values are precise. They exist to help build a team that lasts. They provide the foundation for a high-performing team. But as we also can see from Patrick Lencioni’s work, it does not take much to tear down a high-performing team until it becomes a mediocre team or worse — a team, or at least some members, that actively works against the group’s best interests.
By simply removing the “roof” of trust, a team can deteriorate quickly, and when that trust is gone, it is difficult to get it back. If the cycle repeats, each time trust is lost, it’s even harder to regain it, until trust will eventually reach the point of no return.
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.
“Teamwork… it makes the dream work.”
Gag. Every time I see these corny teamwork quotes floating around the internet, I die a little bit inside. Don’t you?
When people are asked to describe teamwork, they’ll mention trust falls, baton-passing in a relay race; in short, a fantasy world that no team really operates in.
Yes, teamwork is amazing, but it is also hard, sometimes ugly, and personally challenging. Definitely not the manicured depiction of teamwork we see everywhere from slide decks to Pinterest boards.
It’s no wonder people get jaded at work when everyone around them is promising it’s going to be picture-perfect. Could it be that all these lazy and trite ideas about teamwork are making it seem even more unattainable in our minds?
How can we think about teamwork differently? How can we admit the challenge that working with others provides, while also celebrating the power of working together?
To that end, I’ve compiled a list of teamwork quotes that don’t make me want to throw up a little bit in my mouth, that make me think deeply about the work I’m doing in my team, and what it all means. Let’s see if they pass your gag test.
So there you have it. Some down-to-earth quotes about the work we do in our teams that won’t induce a hard eye-roll. We hope they will be useful to the teamwork you do!
At Atlassian, we’re helping teams unleash their potential through open ways of thinking, working, and being. And we have some tools that help out with that, too.
To get more articles and tips on teamwork, subscribe to our blog.