No Need For Scrums

BLUF: Rules are there to be prescriptive if your team needs to be told explicit instructions.

I have a team that has no problem conversing about issues, problems, or just to BS about something that is going in life or work.  Not one of my team members has ever had an issue coming to me to talk.  That isn’t me looking at the world with rose colored glasses.  They have come to talk to me about career growth, anger with other team members, benefits, and just life in general.  I am 91.1111% sure that they would come talk to me about anything if they needed answers or discussions.

I have never been a fan of the agile process, but I am in a spot where if you don’t do it, then people think you are weird.  So do we need scrums?  No.  If your team does not have a communication problem or deficiency, then there is no reason to have a scrum everyday.  If you maintain your tickets, then you keep the scrum master happy, if you complete your sprint tasks, then everyone is happy, and if no one has questions or misunderstanding, then what do you need to communicate everyday?

Our scrums are not long, 2-3 minutes on average for a team of 4 developers.  I hold to it that scrum is not for discussion.  We do have conversation bleed over into more discussion in case there are problems or issues.  The rule that is place to have a scrum everyday seems to be there just because.  A rule exists because someone needs to be explicitly told how to perform actions:

  • Holding hands when crossing the street.
  • No toys at the dinner table.
  • Do not run in the house.

These are some of the rules that my wife and I have for our kids, but these rules will diverge, change or be removed completely over time because they will not make sense or are no longer necessary.

Your team should be treated the same way as well.  If they understand what they are suppose to be doing and the rule becomes a hindrance more than a business process, then take it away.  Keep rules around indefinitely if they promote a good business process, such as, two developers need to review a pull request to ensure that code is correct, it implements the right solution and unit tests are written.

Normalization of Deviance

BLUF: You must maintain standards in order to drive projects to the right place.

In January of 1986 Challenger launched and shortly after succumbed to an explosion.  It was later found that an O-ring caused the explosion and they later learned that it was a set culture to accept deviation from the norm.  All actions pointed to an almost certainty that Challenger was not going to make it.

Dr. Diane Vaughan wrote about this situation and coined the phrase normalization of deviance.   It is defined as “The gradual process through which unacceptable practice or standards become acceptable. As the deviant behavior is repeated without catastrophic results, it becomes the social norm for the organization.”

Normalization of deviance is a widely known problem in many areas, but most obviously in aviation because of the safety aspect that encircles the aviation industry.  You can accurately chart a timeline where safety violations occurred prior to a major safety accident that was either major damage to an aircraft or a person.

In software an example would be that you continuously let teams or teammates manually deploy out of cycle to fix bugs or when you let a merge occur without unit test(s).  You continuously let this occur and you eventually do it yourself without fixing or adjusting the problem.  Eventually you don’t notice the problems and every merge request continuously becomes worse along the way.

I recently admitted to exactly this problem.  I was allowing the team to commit merges without the proper merge request process where we need two developers to review the merge requests before a merge can occur and you also need to write unit tests.  I let these slide because the timeline was quickly approaching and for 2 months I didn’t adhere to the process.  When the deadline passed and we had some leeway in our timeline.  I recaged everyone’s expectations to know that they need to have 2 other teammates review the merge request and ensure that unit tests are written if needed.

While you are working through a project and if you are looking at team trends through after action reviews (AARs) or retros.  Plot the bad things that happened and track your team trends to find the violations that could create a damaging issue in the future.  Take the time to exercise on an issue that already occurred to see if you can find the precursor events that you could have changed before the event occurred.

Team Advocacy / Assertion

BLUF: Any team member needs to have the ability to call out any issue without fear of repercussion.

Advocacy

Advocacy is the act of supporting a policy or cause.  You advocate for an action to take place by announcing it and not waiting until the error has occurred to give the big “I told you” speech.

Assertion

Assertion is the act of give a forceful statement of belief or fact.  You assert your knowledge by announcing the problem that you know exists.

Before every flight that we take as a helicopter crew during our crew brief we discuss advocacy and assertion.  In order to provide others that are not able to manipulate the helicopter to do something their only recourse to a problem or situation is to announce that something is not right and provide the solution if available.  Sometimes what saves a helicopter crew’s lives is one simple act of speaking up to say something is wrong.  The rest of the crew’s job is to acknowledge that it was said and either discuss the solution or announce the corrective action that is being taken to resolve the problem.

In a helicopter if you don’t speak up when something doesn’t feel right or act right, then a serious consequence can occur; 4 people die.  Before a fatal problem occurs or the helicopter is destroyed or incapacitated a crew member has the right to prevent a problem if it is known.

Any team member needs to have a right to speak up and announce that there is an issue before the problem persist and eventually causes blockers or timeline delays.  This action of announcing the issues sets an expectation and alerts the rest of the team to a problem before it starts to snowball.

If a leader does not allow others to interdict these problems than a culture is created where the team lead has to see all the problems for him/herself.  You are not taking advantage of others on the team and utilizing all resources to take action on problems.

Conclusion

Let others announce problems or issues without repercussion and you will have greater aptitude to be ahead of the curve and set the right expectations for the project timeline rather than waiting until it is too late to resolve issues before a release.

How to attract talent, hint, it’s your culture

BLUF: Build a culture that attracts the talent you want.

Benefits

Provide a package to attract and keep the right talent.  The benefits package gets people in the door to make them excited about the opportunity, but it doesn’t always keep them there because priorities change.  This is a delicate balance.  I have seen pet insurance coverage, college tuition reimbursement, family leave, etc.  These are great but what if you don’t have a pet or don’t have time for college.  There are some benefits that are great for some but not for all.  Here is the biggest thing, if you say you have a benefit, then honor that benefit.  I have been a part of a company that touted that they sent developers to conferences and professional development courses, but they never approved any of the requests.  We had 100% turn over in less than 2 years for a team of 11 developers at that company.  Not because of that one issue, but you can imagine what the rest of the culture was like.

Interviewing

When interviewing candidates make sure you are giving them the correct information and not the smoke and mirrors to get them to accept.  If you have problems, then put them on the table.  I don’t like wasting my time on a company that told me one thing, but then I saw the truth and it was nothing like what they provided in the interview.  The interview is your first step to setting up your culture with a no BS information session.

The opposite is true.  If the candidate does not meet your culture needs and characteristics, then don’t hire them.  Your culture is what makes people happy and keeps people productive.  If you hire someone that injects their own culture and doesn’t fall in line with yours, then you will see the change.

Expectations

Set your culture expectations from the start.  Have new hires know what the culture is with everyone operating the same and instituting that knowledge across the board.  You will not always be around, but you want your team to embody the culture that you need to accomplish your mission.   There is ownership in this.  It is not just your team.  It is the team.  The team members have as much ownership in the final product as you do.  You need to present that way to them and show that you are doing the same thing and providing the same day to day work ethic and culture characteristics that you expect out of them.

Champions

Build a culture that provides champions.  The strength and scalability of your team/company lies in the fact that you have culture champions.  These are the people that follow the culture rules and institute it without being authoritative.  People get on board without being persuaded or forced into the culture.  If your process was fully engaged, then by this time you attracted the talent with the right benefits package, you hired the candidate that had the right characteristics and skills, and the employees are part of the team and understand what it means to be a team player.

Conclusion

Culture is what makes people jump when you say jump.  Culture is what makes people listen to you and perform when the days happen that you need someone to work until 3 A.M. to get the deployment done for release.  Don’t take advantage of people’s time because you failed as a leader to plan and execute tasks well.

A couple books to check out is:

Radical Candor by Kim Scott.  Kim explains how honesty up front keeps people happy.

Team of Teams: New Rules of Engagement for a Complex World by Stanley McChrystal

Culture eats strategy for lunch – Peter Drucker

5 Delegation Techniques for Tech Leads

BLUF: Delegation is the best tool you have as a leader.

Delegation is the best tool in your kitbag.  But there are several things you have to do in order to make delegation successful.  In the military there is an absolute must that you have to be able to delegate in order to accomplish tasks.  The military has a clear hierarchical organization structure that allows you to manage your tasks and expect people to accomplish the mission and hold them accountable for their actions.

  1. You cannot multitask
    You are not different than everyone else.  It is impossible for you to multitask all of your duties to make you more efficient and successful as a leader.  You have to be willing to give others your work or tasks.  There are meetings, timesheets, and other non-technical things that need to be done that you cannot give to your team members, and frankly they didn’t sign on for those things.
  2. Micromanaging is for losers
    Micromanaging is like that annoying roommate that was always “accidentally” looking over your should at your computer to see what you were doing.  It makes people very uncomfortable.  If know that you do it, then give people the heads up.  I try to warn people when we have new tasks and deadlines that popup that I will be breathing down their neck to make sure they are on task and getting things done.
  3. Clear direction
    You have to give someone as much information as they would need to accomplish the task.  Don’t just tell them to go correct the UI on the login page.  I tend to give enough to get the job done, but I leave some wiggle room for my teammates creativity to shine through.  This is two fold.  They might teach you something and you might be able to teach them something at the end.
  4. Play to your team’s strengths
    Assign tasks to team members where they will perform extremely well or at least will be best suited for the task.  I give all of my CSS tasks to one guy on my team because he has made it clear that he enjoys writing and figuring out CSS fixes.
  5. Add in responsibility/accountability
    Accountability is the biggest part of all of this.  You have to be willing to tell people when they screwed up and how to fix it.  There is some balance and compromise here.  Don’t give people tasks that you know they are going to fail (i.e., lack of inexperience, knowledge, or confidence).  This final technique will also provide you insight into who is next up on your team for a lead role.

It takes some experience to get delegation right.  Apply it everywhere you can to see what works for yourself and doesn’t make you have OCD about control of your team’s tasks.

Contingency Planning

BLUF: There are times when you won’t have 100% of the answers to create a plan.  Creating a contingency plan is to account for the remaining percentage of the answers you couldn’t find.

Contingency plans are critical to any operations or projects.  It is the “if X, then Y“.  You have to be able to account for these possibilities.  Play devil’s advocate or punch holes in the plan.  In the military this is a common practice.  After we devise a plan a group will provide all of the counter plans that the enemy will execute.  This is all in the process of war-gaming.  In war-gaming you answer all of those IFTTT questions.

In software development you can also apply contingency planning.  Have you ever been creating an architecture design that requires other teams to provide services or architecture in order for your design to work?  I run in to it regularly.

  • What if we don’t have access to a SQL Server database?
  • Who controls federated logins?
  • When will customers transition?

What is your plan at certain decision points?  At some point you have to just build your solution knowing that you no longer have the ability to talk to a SQL Server instance and you have to use PostgreSQL.  You have to run with it.  Do you extend your deadline claiming you couldn’t get it done?

Always have a contingency plan for your project critical paths.  A contingency plan is not pivoting.  It is providing a solution to get over blockers or hurdles, and sometimes that solution is compromising with the product owner that there will be risks in the application if we cannot do things a planned way.  Eventually you need to accept the risks or mitigate some or all of them.  Only after that will you make the decision to not deliver on time because the risk is catastrophic to cause customer issues – exposing confidential data.

It doesn’t take long to run through some simple scenarios where you think something might go wrong.  Cover your bases in the situations that you don’t have accurate or unknown answers.  What database will you use if you don’t have access to a SQL Server instance at the current moment when you are designing and planning.

Entitled Developers

BLUF: You have to try.  You cannot not just play the part and get a job.

Last post I talked about interviewing candidates with a simple, or what I thought, data structures problem.  Since starting to be involved in the interviewing process I am noticing that there is becoming a staggering number of candidates who think that they can ask for high salaries and do minimal work to earn that salary.  I have only hired 7 candidates in the 80+ phone interviews that I have performed over the last 2.5 years.

Should a candidate who asks for $120k a year in salary know the difference between static and instance fields?  Yes!  I get that some people think white boarding a problem is a waste of time, but a simple white boarding problem has a lot of information about a person.  Can you communicate your code?  Can you implement with minimal instruction and ask questions to get to the end?  Can you even code at the foundation level?

The projected growth of software developer jobs, on average, is 17% in 10 years.  The industry is not being over saturated with qualified or over qualified candidates, so the need is rising but the candidate pool is being diluted with unqualified candidates for the needs of a most companies.  What’s my take away?  Sometimes you have to compromise on candidates that are not going to be the best fit because you have to deal with the delicate balance of needing the people to get the work done and the skills of a candidate.

My criteria for a candidate in all situations that I have interviewed is the need for a “full stack” developer.  My “full stack” definition is a candidate that has strong skills in one of the 3 main pillars.  These pillars are front-end, back-end, and database.  Those candidates need to possess enough understanding in the other 2 pillars to make them a compatible candidate.  I have never been looking for a subject matter expert in T-SQL or Linux, so my opinion might be skewed compared to a larger software development firm that is building a product backed by a team of 50 front-end, back-end, data, big data, UI, UX, QA, QC, testers, technical writers, scrum masters, and product owners.

I perform at least one task for all those positions in a week’s worth of work.  As I have always said though, this causes me to be dangerous enough to get me in trouble.  There is a balance in my work that keeps me up to date with what is going on in the industry, but i try to stay focused on one piece and that is web development.  I have pet projects in mobile development but my 40+ hours a week are dedicated to the former.  I have also mentioned that I always try to do an interview or two for a well known software or product company each year.

Conclusion

If you have been in the industry for a while and cannot write a NodeJS application, then you might be out of touch with what is going on.  I am not saying you need to be an expert, but do the “hello world” example to get an idea.  Out of the need for NodeJS we are now seeing WebAssembly coming on with full force.  I’ll counter this with that there is always a need for legacy coders that need to upkeep an old code base.

Extra

https://www.captaincodeman.com/2014/07/01/top-10-ways-fake-software-developer.  Yes, they exist.  I think this list points to all of the most common things that a faker will do, but they only need to exert one of these characteristics for you to realize that it is a problem.