Being a Software Development Manager

Looking for its best definition, the one that most caught my attention was that the Software Development Manager is “everything else“.

The main concern when considering a Software Development Manager is: Should have more technical skills? Must have a Project Manager profile? The answer may vary depending on the IT organization, size or type of business, but if it’s really technical or manager is rather irrelevant.

Ideally, should combine technical expertise, with planning and resource management, to bring projects to success.

The main difference compared to the Project Manager would be that the Development Manager shouldn’t only ensure to reach the end of the project in a given or estimated time, but also how you get to that endpoint.

There are some practices and tools to use or maybe consider:

Communication: Good communication is essential when carrying teams, when playing with the uncertainty of projects, and also when handling with customer expectation. Must communicate continuously, be transparent, and must be bidirectional: Must know how to receive feedback from both the people from whom it is responsible, and the people that it depends on.

Methodologies: The Development Manager defines what methodologies will allow carrying out the work, and will be who reviews the metrics and analyzes the performance. A common methodology in software development is Scrum. I recommend the implementation of certain practices such as Scrum Meetings.

Planning: Must have some control of the project, and plan together with the Project Manager (if any). But above all should have a clear idea of the project status, and keep the full view of the project. Not control obsessed, better to know how to develop and improve team performance in order to reach the proposed deadlines.

Professional Development: Is responsible for the people to be formed and letting them grow within the company, though that means also letting them leave the company sooner. Should identify potential, interests, and help meet the needs of each individual, as far as possible. And it isn’t always a matter of budget, there are serveral ways to develop talent and creativity of the people without any cost.

Best Practices: Define and implement the set of best practices is also one of its responsibilities. You need to know what works and what doesn’t work, identify gaps and develop strategies to avoid as its impact.

Leader: A development manager holds a leadership position, and the first important thing should be to lead by example. Must be professional and know how to react, with serenity and analytical capacity, in the most adverse situations.

Decisions: Through thick and thin, has the will to decide. Don’t be afraid of making decisions! This is probably the hardest part. It’s very important to have necessary calm to analyze the situation and make the right decisions in times of “crisis”.

At the end, the Software Development Manager is responsible when things go well and bad, is responsible for its people, and also for the achievement of objectives. The proper application of the above points could help on its success.

Will be happy to add or modify any point through your feedback ;-)

About Scrum Meetings

Implementing Scrum in a business is not an easy task, sometimes it may be a hard and long road. It involves a change that usually affects much of the company, and change management is always traumatic.
I would also like to point out that it isn’t a methodology only for software development projects.

The most common process is to adapt the concepts and practices of Scrum gradually based on the real needs of the company or department.

In this post I want to talk about the Scrum Meetings, part of Scrum practices in a Sprint (or iteration).

Usually, in my experience with Scrum, meetings are the easier concepts to implement. Receive good feeback in short term, could be considered as quick wins.
Each meeting has its own function or purpose.

Daily Meetings

The Daily Meetings are (as they mean) daily morning meetings that serve as synchronization between the different team members, and also for the Scrum Master or meeting moderator.

In this meeting, each team member answers 3 questions:
– What I committed yesterday?
– What I commit to do today?
– What blocks or impediments I have?

This meeting cannot exceed from 15 minutes, in fact it usually takes less time. It is recommend to carry out the meeting at a specific time, without waiting for late members. In our case, we apply a “financial penalty” depending on the time of arrival.

It usually has a positive reception and feedback among Team members. Sometimes there’s a lack of communication even within the same department, and this quick meeting allows a very efficient way to communicate and share the situation point of the project, cross project issues, and of course raise problems.

Normally, the term “commitment” isn’t used on the questions examples of the Daily Meeting. In Scrum, self-tasking is an exercise in self commitment and above all with the team. Scrum needs maturity. This is a detail I was told (with other colleagues) at the Scrum Training.

Also it is said that team members should focus on answering the three questions, and resolve blocks outside the meeting. But in small teams with more than one project in parallel, it is good to use the meeting to resolve conflicts and share knowledge, not allowing to become a debate.

While not considering moving to Scrum, I recommend the practice of Daily Meetings even though is to make up for a lack of communication.

Sprint Review or “Demo”

Sometimes confused with the Retrospective. It is an assessment of the project by the customer or owner. May be equivalent to user acceptance testing.

According to manuals of Scrum, should be done at the end of sprint, but in my opinion should be carried out once the development is considered completed within the sprint. If it’s done before the end of sprint, we’ll receive earlier the feedback, which is essential in an incremental development.

It is very important to know customer’s feedback from a project before deploy into productive environment. And its validation involves the owner or customer directly to the proper functioning of the project (or should be).

Sprint Retrospective

It is a very important meeting at the end of the sprint where to analize the sprint, focused on improving team performance and productivity. It is said that should be carried out after the Review (if the review is done once at the end too).

The basic points of the meeting are:

  • What works. Not only must focus on negative things, we must also celebrate well done job.
  • What must we improve. Identify areas of improvement in a constructive way, not need to be taken as negative points because this meeting isn’t for blame on anybody.
  • Identify the obstacles that doesn’t allow carrying out the work of the team. This will be a task for the Scrum Master or moderator. It is also very frustrating when you don’t have any authority, because this blocks tend to repeat over the sprints.
  • Define targets (milestones) to improve for the next sprint. These objectives can be assigned to team members. This permits to involve team members with roles of responsibility.

A game that usually works in this meeting: tell the team to write 3 things that are done well and another 3 that need to be improved. So everyone, without any external influence, should express their personal opinion. This may motivate and involve the team.
Once you have all the points, unify them by received votes. And in case of negative ones (to be improved), one by one search for solutions that would be the objectives or points of improvement for the next sprint.

In 2-week sprints, I do not usually spend more than an hour.

I hope this post would be helpful. I personally recommend adopting these practices of Scrum.

I also want to note that only speak from experience I’ve acquired, but I’m not a “guru” or Scrum Trainer and Coach, although I am a certified Scrum Master.