In this article I want to cover what some of your rights are in the workplace. With this I don’t mean things like the right to regular breaks and access to coffee etc. What I mean is your professional rights when working on projects in a team, and these rights are very important if you are ever in a position of conflict with another person on your team. It is in times of conflict that rights are very important, so they are described below from that perspective.
Your Rights in the Workplace
The rights are:
To be treated with respect. No matter what you dispute is, you all deserve to be treated with respect no matter what the outcome is.
To hold my views and have them heard. You have the right to an opinion just as the other people in a conflict do, and it is all your right to express these viewpoint as long as you treat each other with respect.
In my post on Retaining Software Developers, I had a number of really good comments to the post. One of the comments made reference to a fantastic video about the Truth about what really motivates us.
This video is an animated short which summarises a longer video by Dan Pink. If you are a software developer or a lead of developers, then I really recommend watching this video.
As a company owner or hiring manager, attracting software developers into your organisation is one challenge. You have to hook them in with a job specification and then sell your company to them in an interview as-well as gauge their technical abilities.
But once a developer starts at your company, you then have to retain them. The jobs market is quite vibrant at the moment and developers have a plentiful choice of companies to go to as a permanent or contractor developers.
Retaining Software Developers in Your Company
On-boarding and training up a new developer is quite a large commitment to a company in terms of time and costs, so how do you keep a developer engaged and wanting to stay so they can be productive and give a return on your investment.
In this short article I want to share some of my thoughts and view on this, but what I would really like to happen is for you to comment on this article and give your opinion either as a developer or as a companies hiring manager.
Has your company done something else to retain staff, if so what and how well did it work? Did they try something and it didn’t work?
Advantages and Disadvantages of Agile Software Development
Advantages of Agile
Customer Satisfaction by Rapid, Continuous Delivery of Useful Software
Your customers and users will be satisfied because you are continuously delivery value to them with usable software.
This is a stark contrast compared to that of a traditional waterfall product delivery, that if your customers are used to waterfall, they may find it strange adjusting to having working software sooner.
The big downside of waterfall is that you deliver large pieces of functionality towards the end of the project life-cycle. This means that all throughout the development stages of waterfall, your project is incurring costs with no return on investment.
By delivering working pieces of functionality sooner and more regularly you are giving your users an opportunity to get a return on their investment sooner. Sure, they may not have all the functionality they need upfront, but they can start to make use of the solution to make their lives easier and start realising the benefits sooner.
I have already written a number of articles about agile development, agile misconceptions and agile benefits. In this article I want to cover common mistakes that are made by teams new to Agile. They are in no particular order and are all equally as relevant. Not all teams make all of these mistakes, but these are observations I have seen over my career.
Common Mistakes of a New Agile Team
Fear
Fear is a powerful emotion that is encountered in many forms. For a team new to agile this is fear of the unknown as working agile is completely different to that of a more traditional waterfall process. Fear drives bad decisions and practices that can frustrate a new Agile team. The enemy of fear is trust. You counter fear by instilling trust at all levels.
Start by letting the team know that the organization trusts them to make the right commitments and decisions. The team should be trusted to learn, grow, and make choices as a group, instead of taking directives from management.
A common example of fear stifling team growth is the issue of commitment. Teams often under commit or pad their estimates, due to fear of being responsible or blamed for failure. Initially, allow your team to give themselves permission to miss in their estimation. Foster an environment of trust, such that the team can explore the causes of a miss without finger-pointing.
This will help you find the true limit of your teams velocity. A single miss should translate into dozens of future successes.
I am pleased to announce that my first Pluralsight course, Developer to Manager, is now live and available to watch for all Pluralsight subscribers. You can view a demo of the course below.
The course is based off an article I wrote earlier this year called Transition from Developer to Manager. This has been the single most popular article on this blog. I frequently receive emails from people asking advice on moving into a supervisor / leading role, so I hope this course will help everyone who watches it.
Stephen Haunts Pluralsight Author Page
The course will start off by covering what a typical supervisor / management role looks like and its aim is to set the listeners expectations about the role to help them make an informed decision. The course then goes on to help the listener come up with a 90 day plan to help them make a real impact in the role if they choose to make the leap.
I was reading a good article the other day in INC magazine by Aaron Skonnard, who is the CEO of Pluralsight, who I have recently started Freelancing for. The article is called How to Build a Kick-Ass Exec Team, and talks about 8 leadership traits company heads / CEOs can use to create a good working culture within their organisations.
The article is aimed at people who run their own companies, but I thought the leadership traits Aaron talks about also apply to other leaders and managers lower in an organisation. From my point of view I am thinking as a Development Manager running a software team in a healthcare organisation.
8 Leadership Traits for Software Development Leaders
In this article I want to covers the original 8 leadership traits and say how they apply to managers and leaders of a software team in an organisation, as I feel there is a direct correlation. I recommend reading Aaron’s original article first.
Leaders Help Their Teams
The team I leade, I try to run agile using Scrum. I say, try, because the project I am currently running is part of a larger program of work that is very much waterfall. We are one of the donor projects in a larger agile transformation plan. As part of the running of this team I want to avoid being the guy at the top dishing out orders or even worse, Micro Managing. I believe a team should be self organising in their workload with inputs from the product owners and business who guide our direction. My role is very much about removing barriers and blockers that get in their way so they can concentrate on doing what they do best, developing software. I feel it is much better to be a servant leader as opposed to a more traditional autocratic leader who controls a strict hierarchy whilst leading from the top.
