Thursday, February 18, 2016

6 Types of Employees Who Frustrate Their Bosses (and How Smart Managers Deal With Them)

Ref: https://www.themuse.com/advice/6-types-of-employees-who-frustrate-their-bosses-and-how-smart-managers-deal-with-them?ref=home-small-tile-1

Being the boss is never easy, but some employees make it particularly difficult. How do you cope with those who do their jobs well but are equally skilled at annoying both you and their colleagues? Tim Eisenhauer, co-founder of Axero Solutions, which makes the workplace intranet Communifire, has some practical suggestions for coping with challenging employee personalities.
Here’s his list of the six most common problem personalities, and how to motivate them to improve their behavior.

1. The Gossip

“It’s estimated that around one in every five office workers engages in gossip, and that office workers spend up to three hours each work week hearing, seeing, and speaking gossip,” Eisenhauer says. If you pay attention, you’ll see that certain employees are always in the middle of these discussions, and often initiate them. “Gossips always know—or think they know—what is going on at the company, and they aren’t shy about forming their opinions and seeking out other people’s opinions,” he notes.
You can’t eliminate, or even reduce, the amount of gossip in your workplace, he warns, and trying will lead only to ill will. Besides, you don’t necessarily want to eliminate it. “Relationships between co-workers have been shown to improve productivity, collaboration, and employee satisfaction,” he says. When employees talk about the things they have in common, including co-workers, managers, and the company, they are creating a bond that will benefit both them and you.
The smarter approach is to use gossip as a tool to encourage all your employees to be better. “As a manager, accept that your employees will gossip about you,” he says. “Use your ‘star power’ to demonstrate behavior that you want to see in your company. Do what you say you are going to do, be open and transparent, and build trust. In short, put yourself beyond reproach.” The more your employees observe and comment on the way you do things, the more likely they will follow your lead.

2. The Grump

The character Stanley Hudson in The Office is a perfect example of a grump, Eisenhauer says: “He is uninterested in his work and the workplace, beyond taking home a paycheck, and clearly does not want to be there. Stanley grudgingly does what is asked of him and nothing more. His negativity and disengagement are palpable.”
Dealing with a grump can make you grumpy yourself, but don’t give in to that feeling, Eisenhauer advises. “Some office grumps have generally cantankerous personalities, whereas others’ grumpiness stems from [their] being unhappy at work,” he notes. “Whatever the case, the best strategy is to kill them with kindness. Give praise when they do a good job and don’t let their negativity bring you down.”
At the same time, he says, try to find out the reason for their unhappiness. “Ask what you can do to make their work life more enjoyable,” he says. “The key is to communicate and listen. Make sure they feel heard and that their contributions are recognized.”

3. The Overachiever

“In school and in work alike, there are always overachievers,” Eisenhauer says. As the boss, it may not be obvious to you why an overachiever is a problem personality. “Authority figures tend to respond well to overachievers,” he notes. “They go above and beyond what is asked of them and clearly care about succeeding.”
You want overachievers on your team, he notes—they propose big ideas, move projects forward, and generally get things done. If you give them a task, you don’t have to wonder whether it will be completed or not.
“However, overachievers can often be impatient,” Eisenhauer says. They may not work well in situations where they have to strictly follow orders. And they can cause jealousy and resentment in their less overachieving co-workers.
“Approach them as a supporter and a coach,” Eisenhauer advises. “Give them projects, but don’t micromanage. Check in often, but not to dictate how things are done. And make sure that you don’t heap praise on these employees at the expense of others.”

4. The Suck-up

“Suck-ups can sometimes seem like overachievers, but they are actually in a category of their own,” Eisenhauer says. “These people do not necessarily perform better or even work more than the average employee. Rather, they strive to tell bosses what they want to hear and ingratiate themselves with authority figures.” Interestingly, he adds, suck-ups may not even realize they’re sucking up.
Suck-ups are usually insecure, he says. Their lack of confidence in their own abilities leads them to attempt to compensate with excessive flattery and ingratiating behavior. “As a manager, don’t get sucked into their behavior and drama,” Eisenhauer says. “Be polite, but don’t reward them for their fawning. Stick to the facts and try to subtly discourage their behavior. When you do issue praise, make sure it’s for a legitimate accomplishment.”

5. The Slacker

Most managers hate working with slackers because they appear lazy or incompetent, or both, Eisenhauer notes. “They may not get their work done, or at least not in a timely manner, and they do the bare minimum,” he says. “Slackers jump on every opportunity to not work and may spend a majority of their work day on non work-related activities.”
You may be tempted to simply terminate slackers, especially if they aren’t pulling their own weight. But before you do, consider trying a few simple interventions that may dramatically improve a slacker’s performance. “Often what they need is more structure,” Eisenhauer says. “Work with a slacker to set goals. Make sure these goals are emotionally appealing, meaning they connect somehow to their interests and strengths. Create a sense of urgency if you can.”
Boredom and being under-challenged can often turn people into slackers, he notes. So try finding something important for them to do, and urge them to do something that will be difficult and outside their comfort zone. “Disrupt their usual automatic way of thinking,” he says. You may discover that your slacker isn’t so lazy after all.

6. The Clown

“The office clown is the grown-up version of the class clown—someone who may be highly entertaining and funny, but at the cost of being disruptive,” Eisenhauer says. Clowns love to play pranks and joke around, and it can be tough for them take things seriously.
Most clowns mean well, but they can still be a big problem in the workplace. “Clowning on the job is distracting and can be offensive or hurtful to other people,” he says. Since clowns crave attention, don’t fall into their trap by disrupting them in the middle of their “act” or having a big blow-up in front of the whole team, he warns. Instead, sit down with the clown and have a serious conversation.
Once you’re in private, you can ask or order the clown to stop being disruptive. Or, you can try a subtler tactic that may be quite effective: Give the clown a big, complicated project with a tight deadline. That way, he or she will no longer have time for clowning around.

Wednesday, February 3, 2016

Sustainable Pace – A True Measure To Agility

Ref: https://agilegnostic.wordpress.com/2016/01/21/sustainable-pace-a-true-measure-to-agility/



In Agile Software Development, ‘Sustainable Pace’ practice refers to the consistent and sustainable software development through a longer period. This sustainability in development should be maintained continuously until completion of product development with the consistent endeavors to improve the rate of software delivery maintaining the quality output. Originated from the Extreme Programming methodology, and having specially mentioned in Agile Manifesto; the practice has been widely accepted into Agile Software Development. It’s applicable to all kinds of development projects, for both at small and large teams at scaled agile. The phrase ‘Sustainable Pace’ was coined to denote that the team works daily for the same number of hours so that their pace of development remains consistently same or improve slowly without draining teams performance; making them fatigue or raising their frustration level such that they lose interests.
“In the long run, sustainable pace of development is the fastest way to deliver the quality software.”
The Sustainable Pace in very important, especially in long running software projects. It’s similar to maintaining the Constant Pace of Running in long distance running events like Half Marathon or Marathon. Unless a runner maintains constant pace; (s)he won’t be able to run long distance for a longer period. If runner sprints fast or has too much variation in running pace; (s)he will get tired too early and may get injured or body can resist completing the race. In software development also, if team push too hard in few iterations, they will not be able to keep up the same pace for longer period. The small variations in running pace also important, which depends in the nature of race terrains. When a runner gets into the upward or uphill terrain, (s)he slows down the pace a bit to reserve energy until plain/flat surface comes. Similarly, if the development team has come across rough patches in forms of technical debts, impediments; they would need to slow down the pace a bit, so as to take appropriate actions first before moving on with development further. Like running, keeping a constant rhythmic pace of development is important to keep the team energetic and motivated.

Where does it apply?

The sustainable pace is expected to be maintained across the software engineering disciplines; programming, quality assurance, and delivery management. One of the Agile manifesto principles read as following…
“Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.”
This principle states that it’s not just developers but also the sponsors and users; who should maintain the constant pace. Let’s discuss how the sponsors and users can contribute to a sustainable pace of development…
  • There must be Subject Matter Experts (SMEs) from customer representing sponsor (most members of Product Management group, Product Owners) and users (end-users of the product being developed); who have vested interests in the development process. 
  • They are committed to giving a certain amount of time that is sufficient to the team.  They actively participate in software development process by owning certain defined activities and responsibilities. Activities such as defining prioritizing product features, and taking business decisions whenever needed.
  • Users, when interim product increments are given the demo (iteration review meetings) or handed over for review and testing; they should provide active and timely feedbacks. Any changes or improvements can be planned by the team on time earliest with their future impacts.
  • Customer provided feedbacks on changes in requirements could be due to any reasons; which should be taken into consideration with appropriate planning in consultation with customer representative (the product owner).
For me, the sustainability in software engineering applies to entire software lifecycle – during the development and while in production; when the product is in actual use. The sustainable pace needs to be maintained across the software product lifecycle from product envisioning, it’s development, quality assurance, and future enhancements and changes; while the product is business facing.

What are the impacting factors?

There are many factors that directly or indirectly impacts the teams sustainable pace.
  • Abnormal Working Hours/Days – It has been observed that majority of teams have extended work hours, either they continue working late evenings or until nights, they either miss to enjoy the company holidays or have prolonged weeks working on weekends. Also, in many organizations abnormal and prolonged working hours have become a normal phenomenon. These kinds of working styles for a long time are the major deterrents to sustainable development pace. Initially, it may lead to increase in productivity, but over the longer period, it degrades the  individuals and whole team’s productivity as well as the quality of work.
  • Agile Anti-patterns (Culture & Mindset) Sustainability depends a lot on the ways in which teams works and how their works are managed. The management style depends on the people in the management roles as well as on the organization’s culture and working styles. Many times managers and leaders do link the overtimes works to employees commitments and dedication to finish the tasks in hand. The worst part is many of the managers pressurize the teams to finish the work in comparatively shorter time and make a mistake to see it as increased productivity.Employees working late or on weekends are appraised for their elevated performance, (which truly does not translate to that) thereby creating a culture of imbalance and illusion in projecting achievements. This creates an unhealthy culture and unbalanced work environment. Sometimes even the senior management attempt to make a comparative distinction based on such unreasonable and unrealistic parameters. Organization should create healthy culture and mindset favorable to Agile. Read my post “Four Facets of Agile – Part 1” to get more insights on Agile culture and mindset.
  • Distributed Teams – Especially in Software Development space, it has become a very common phenomenon to have distributed teams in which members work from different geographical locations and time-zones. Having the distributed team is the reality today due to various factors like cost effectiveness, availability of talents pools and other such numerous reasons; which can not be avoided. Having team members at distributed locations in different time-zones create challenges in communication, collaboration, work distribution, and synchronization etc. Without effective uses of tools and technology as well as planning of suitable team composition and placements; maintaining the consistent pace would definitely be a challenge. Refer my previous blog “Bringing Agility To Distributed Agile Teams” for more details.
  • Inappropriate Planning – Insufficient and inappropriate planning of works, lack of prioritization,unresolved dependencies, unbroken users stories, unidentified tasks and insufficient estimation are the critical factors that hampers the team’s productivity and inability to maintain a sustainable pace.It is of utmost importance that team does the appropriate level of  Release Planning, Sprint Planning on time and revisit them frequently in order to adjust any deviations and anomalies caused by impediments. Having appropriate, revised and meticulous plans help a team to be organized and focused to both short-term and long-term goals; which increases teams moral, confidence and commitments.
  • Unrealistic Improvement Pressure – There is constant pressure on the team, both from customer side (i.e. Product Owner) and management; to improve the velocity, by taking more and more work every iteration; even though the team’s capacity remains same. It should be left on team’s discretion and comfort to increase the velocity on a continuous basis through inspection (process, tools and practices) and adaptions (remedies and workarounds).Increased pressure without understanding and removing the root cause of problems, process and practices improvements, reducing dependencies and mitigating the risk occurrences; it becomes impossible for the team to improve velocity (and so as productivity) without working extra time than whatever was planned. In many cases, I observed that teams are pressurized to even plan for working on weekends intestinally due to the growing backlog and pressure to deliver them at earliest. In such cases team is not going to remain productive for a longer period.

How do we measure?

“The pace of development should be sustainable, measurable and predictable.”
With references to team’s daily working schedule, widely it’s been seen as whether team works consistently for the same number of hours or not. This is a common misunderstanding that if a team works consistently for the same number of hours; say for examples 40 hours per week; then they have Sustainable Pace of development. It’s just same as undervaluing the importance of sustainable pace and inappropriately measured.
Daily work schedule and the total work hours per iteration definitely have an impact of team’s productivity, quality and output of work completed. It’s worth noting that actual productive hours must not be compared with working hours.
“The actual measure of sustainable pace should be based on Consistency in Velocity and the Business Values delivered in relation to team’s capacity in every sprint .” 
If a team who havie it’s capacity constant, is able to maintain the same Velocity or Business Value delivery or even slightly improves the delivery rate; then we can say the team has a sustainable pace. 
The velocity and business value achievement should be calculated only for those piece of work that are fully completed; that is those features that are developed, integrated, tested and are production ready without any known bugs.

What to do to be sustainable?

The Sustainable Pace should be looked beyond the perspective of daily working hours. If a team has sustainable pace then through inspection and adaption they can plan to consistently improve the software delivery rate slowly maintaining the deliverables quality utmost. But while improving the delivery rate with improved pace, if the team loses focus to improving on quality then the improvement is not sustainable. The team can only have sustainable pace if they have…
  • Sustainable Development – at every iteration works with consistent velocity and business values delivery, maintaining the consistent productivity
  • Sustainable Quality – at end of every iteration produces deliverables (i.e. Product Increments) with no or less technical debts accumulation
  • Sustainable Delivery – maintains the consistent, frequent and stable software releases to test and production environments
  • Sustainable Improvement – continuously improves the processes and practices based on introspection, review feedbacks, and subsequent course correction
Measuring Sustainable Pace
Following are few pointers that will help teams to be sustainable….
  • Create agile mindset and culture healthy for working in Agile Software Development
  • Keep team’s morale high, motivated and committed throughout development
  • Trust your team, honor and value their works, give then autonomy to make local decisions
  • Allow your team to set their pace and rhythm; achievements will keep them excited and motivated to do better
  • Don’t let team members work overtime or force them to work weekends
  • Don’t demand to take more and more works or put unrealistic pressure to increase the velocity
  • Don’t let the technical debts be accumulated, address bugs at earliest
  • Team members should avoid multi-tasking and wasteful works
  • Promote balanced work-life and resolve personal issues
  • Don’t keep asking team to increase delivery speed without optimizing the processes and practices
  • Let the teams find out their perfect velocity and using that plan releases and sprints appropriately
  • Team continuously inspects and adapts through course correction and improvements
  • Optimize the processes and practices in whole software delivery chain; try eliminating the possible wastes consistently
  • Maintain transparency, keep stakeholders and customer informed on any issues, impediments, risks, and blockers
  • Wherever possible automate the repetitive manual activities, perform continuous integrationand test automation
  • Involve team in estimation and planning sessions; ensure all risks and dependencies are thought off and planned accordingly 

Conclusion…

Sustainability does not mean a team should take their work slow and easy; rather team should be steady and consistent maintaining the pace of software development and delivery with slowly improving on productivity and quality of work. It has more to do with achievement of long-term goals rather than short-term peak performance.