Tips, Expertise, Articles and Advice from the Pro's for Your Website or Blog to Succeed
The definition of 'empathy' is apparently more complex than I thought. However, in the context of the workplace, I believe the following suits best:
Empathy is the power of understanding and imaginatively entering into another person’s feelings.
A few times recently, I've been asked about retrospectives -- specifically how to keep them from becoming a gripe session. Here are a few things that I've found effective:
While we certainly want to talk about and address any issues, I like to talk about the positive things that have occurred during the last period before we delve into things we might want to change. I haven't yet been involved in a retrospective where the list of positive things wasn't long. This helps set the tone for the rest of the retrospective.
Over the last couple of months, I have met several young developers that are either looking for the first job or are still trying to get their bachelor's degree. Many of them asked me to give them my advice on how they can make their first steps in a software development career.
You may also like: 3 Pieces of Bad Advice on How to Keep Your IT Job
It’s really nice to see young people care so much about their career. I don’t remember that the guys of my age had the same mentality. Whatever the reason, I like it, and I'm happy to help.
Changing the way we work is extremely difficult . We all know this. It requires us to find novel solutions to wicked challenges, to deal with cultural baggage (i.e. 'the way we do things here'), and to bring along the people needed to make a change successful. And yet, this difficult challenge is a core responsibility of Scrum Masters.
But how do Scrum Masters and Agile Coaches go about this? What strategies do they use to change the system? Who are their most important allies? And what else can we learn from them?
"Every single soldier must know, before he goes into battle, how the little battle he is to fight fits into the larger picture, and how the success of his fighting will influence the battle as a whole." - Bernard Law Montgomery, a great leader of troops during World War II
Have you ever been part of a Scrum team that struggled hard making any progress? Team members had plenty of talent, required resources, and opportunities, but they just couldn't progress enough and create impact.
If the above plot sounds familiar to you, there's a strong possibility that you might find reading this article valuable.
A few years ago, I gave a talk at the SFRails meetup. It was by far the largest group I've spoken to and a truly enjoyable experience. I titled the talk "Leveling Up Rails Developers," and it was geared towards helping engineers build a team which fosters learning and advancement of skills.
You may also like: How Do You Learn?
One of the major issues in the Bay I've been interested in lately has been getting more junior engineers into the industry.
The real problem is this: Why should you care about how much a delayed release costs you? Maybe you have a “sweet spot” in the way you start your projects or release them. “It just takes that long here.” (That’s the sign of a system impediment.)
Now, let’s try to calculate that cost of delay.
Though the employer will first be looking at the tech background and the experience with specific tools, soft skills determine whether the person will stay in the team for the longterm.
But, what exactly are they and how do you determine the ones that really matter? Let’s find out.
I had the opportunity to hear from a panel of executives at Appian World discussing their experiences leading digital transformation efforts across their organizations. The discussion was led by Kristin Scott, Vice President of US Sales, Appian. She was joined by:
Kimberly Bryant, Founder and CEO, Black Girls Code and Aspen Institute Fellow
There is always time to talk about work ethics and rules that influence the turnover rate of a software development company. It doesn’t matter what kind of bonuses or incentives you offer – if the company doesn't have strong leadership and clear guidelines, chances are high that employees won’t stay there for long.
At DashBouquet, we value the fact that our employees have been with us for quite a long time and new people keep joining the team. We think one of the reasons for that is our 'Blackbook of Rules.' Thus, we’d like to share some of it with you, so that maybe you'll be inspired to come up with your own.
What parallels can we draw between football and software development? You can hire stellar players that cost a fortune, but they will most likely lose as a team if they do not have a shared vision and strategy.
Before hiring new team members for your existing team or building a new team from the ground up, you must define your goals clearly.
A paradox is something that is seemingly absurd but really true. When I experience complexity and uncertainty, I find comfort and power in paradox. It opens up creativity, possibility, and collaboration. Let's take a look at four paradoxes we need to navigate in the agile world and beyond.
Agility is about accepting that the work is complex and unpredictable and committing to working in a way that honors the truth of this. In Scrum, we take an empirical approach to minimize risk and enable informed decisions along the way.
In 1935, U.S. biologist Hugh Smith found himself lost deep in the Southeast Asian jungle, floating down a river in pitch darkness. As he progressed farther in his canoe, he saw what appeared to be lightning strike one of the mangrove trees on the banks of the river. And then, to his astonishment, it struck the same tree again, and many more trees around it, one by one.
You may also like: A Happy Workplace Is a Successful Workplace
What Smith saw that day turned out to not be lightning strikes, but rather a biological phenomena called synchrony, wherein the lightning bugs that were sitting on those mangrove trees all lit up in perfect unison. And this discovery turned existing research on these insects upside down.
Scrum is one of the most-adopted methodologies in the technology industry today. So what do you know about this framework and how to implement it into your organization?
It is essential to mention that the philosophy of Agile is that all the tasks, whether big or small, must be completed by a small group of people. As a method developed from Agile, Scrum works the same way.
In Agile practice, the completion of work is seen as being the responsibility of the team. Although individual team members may action a particular backlog item in whole or in part, it will be the team which owns it. This principle is ingrained to the point that — in the Scrum framework — it shapes the way in which roles are defined. Hence, you will find a role in Scrum called "Development Team," but not one filled by an individual "Developer."
Each Agile team member is considered to be a peer to the others. For this to hold true, there must be a shared sense of commitment to team goals, and an ability for those people to work together. In an efficient team, the various members will "go to where the work is," rather than waiting for work to come to them. This implies that a degree of cross-skilling and cross-training ought to be in evidence, and which is sufficient to overcome the waste that would otherwise be accrued through bottlenecks and skill-silos. Efficient peers will collaborate with regard to who performs certain tasks at certain times. Any scheduling that they agree amongst themselves will thus become orthogonal to the flow of work.
Micromanagement commonly occurs when an old organization tries to establish Agile practice. Agility requires the empowerment of largely autonomous teams, and some managers can find it hard to let go of the authority they have traditionally held. They will involve themselves in the details of the work and how it is conducted, rather than letting an Agile team get on with the job. There is a desire, for one reason or another, to retain control.
Micromanagement can result in the inability of a team to inspect and adapt product and process. The manager takes action instead. Waste is then incurred since team focus and collaborative potential cannot be fully brought to bear. A micromanager can often become a bottleneck. Sometimes a micromanager will "dip in and out" of work, leading to inconsistencies in team approach and productivity.