Get to know the team

As soon as possible it’s worth speaking one to one with each of the team members. I tend to start with Jnr members, having explained my motives to any managers/leaders, as this makes them feel important and I can then also collate the feedback and discuss it with the managers/leaders afterwards. It’s also important to work across any existing teams to ensure that you’re not seen to favour one team. I also like to ask everyone the same questions so that we use the time effectively and everyone has the same opportunity to contribute.

Some questions you might like to ask are:

  • What is your job role? (I’m always amazed that people will not always know this)
  • Why and when did you join the company? (this helps with motivation and also with further recruitment)
  • What’s your background prior to joining the company? (again staff resent having skills which they are not allowed to use)
  • What would you like to achieve whilst at the company?
  • How are you measured? (Again many people cannot describe this!)
  • Is your work recognised by anyone?
  • What motivates you and what are you most proud of at work?
  • What works well here?
  • What doesn’t work so well here or what has already been tried but was not successful?
  • What should we focus on to improve the company?
  • Do you have a clear way to raise suggestions and are they monitored and updated?
  • What stops you from performing at your fullest potential?
  • Do you have any skills or abilities which make you stand out at work?
  • What skills/training/support do you or the team require to perform further?
  • How can we deliver quicker/better quality/reduced cost/reduced risk?
  • How can we innovate more?

As we’ve asked everyone the same questions we will typically see trends starting to form. I then collate these and replay them (anonymized) to the team leaders and start to form an action plan to address the findings.

Please let me know if you’d ask different questions or have other approaches.

 

 

Find yourself

So you’re in the door and you’ve introduced yourself. Depending on the reason for your role being required (you did ask during the interview didn’t you?) you now need to find out the truth about the state of the development capabilities. You’re responsible for delivering against expectations so you need to have confidence in the team’s ability or you’ll need to start figuring out another way to get some sleep. You really need to be seeking the answers to the following questions:  

  • What is the development Process?
  • How are requirements captured?
  • Are requirements progressed unambiguously through the entire dev process?
  • How are estimates made and are they credible?
  • How are requirements prioritised and signed off?
  • Are non-functional requirements tracked with functional requirements?
  • How are requirements and resources scheduled?
  • How are plans clearly presented and tracked throughout the company.
  • How is information shared within the company (Wiki’s, IM, presentations etc.)?
  • What version control do they use?
  • What issues tracking tool do they use?
  • Do developers write test cases before they code?
  • Do developers use mocking?
  • Do developers develop in a maintainable way such as employing “S.O.L.I.D.”?
  • Is code peer reviewed before being committed?
  • Do they have a tool for continuous integration/build management?
  • Do Testers and Developers sit together to understand the work?
  • What test management tool do they use?
  • What artefacts are produced to support the work?
  • Do they have sufficient environments/accounts/licences?
  • Do they have automated regression tests?
  • Do they have clear metrics which they can measure themselves against?
  • Do the team have the required skills? Are they motivated?
  • Do the team perform reviews and retrospectives?
  • Does the company have preapproved training and budget?
  • Are suggestions tracked?
  • Is there a clear escalation process?
  • Who are the main stakeholders – what is their measure of success?
  • What information do the stakeholders require and what is their comfort zone?
  • Does management understand the term “technical debt”?
  • Does management have a clear roadmap?

I’m sure we’ll think of more questions given a few more minutes and we should really look to structure them better (let’s not get into analaysis paralysis so early in our blog) so we’ll be looking at these in detail in later posts. One of the best ways to find the answers to the questions above will be to speak independently to the staff and identify the longest serving staff. I typically find the longer they’ve been in the company the more loyal they are to the processes (and may not know better). We’ll be using this quality later when we feel it’s time to start moving to best practise and need to find the most difficult people to convince that we’re headed in the right direction. Convincing these people will ensure that the majority of concerns are addressed.

In the meantime let me know if the questions above are clear and match what you’d expect or have I missed some obvious ones? How could we put a little more structure around them?