Just a Development Department

Home » Blog » Just a Development Department

— agile, blog, management30

This blog describes my current vision, important values and the required focus of an agile software department. This text is not a silver bullet, it is my personal vision. It is a summary of my experiences, blogs, knowledge and ideas. It is based on visions of, for example, Jeff Sutherland, Mary Poppendieck, Micheal Bolton, Jurgen Appelo and others.

What is the goal of a Software Department

The primary objective of a software development department is to deliver, on a regular basis, quality software using a light-weight process.

Regular: when a product is not released on a regular basis, there is no link with the business. In today’s markets, it is required for almost all organizations to be able to deliver new features on a frequent basis.

Quality: quality is the value of a product to someone who matters. A product that does not deliver value to a user is of low quality. A product could have several bugs and still have much value, the other way around is also possible.

Light-weight process: a development process should be based on a light-weight process framework. It should contain no or as little overhead as possible. There should be a process in place that teams can rely on; a process with clear and meaningful process steps. It could be Scrum. However, any light-weight process is possible. The process should empower teams to deliver software.

What Kind of Process?

Software development is a creative and empirical process. It is not possible to compare software development with, for example, construction work or an assembly line. It requires a different approach when you need to solve problems. In most cases, it is not possible to use common root-cause analyses. Problems in a software development process require, in most cases, systems thinking.

Trust in Employees

I believe you should trust your employees. You should trust employees that they deliver the best possible within the given constraints of the available processes and tooling. When teams, processes and tooling are stable, the output will be stable. There will be some variation in the output. However, this is statistic variation.

Measuring Productivity or Creating the Possibility to be Productive

In books and blogs, people talk about hyper-productive teams. When is a team hyper productive? I believe measuring the outcome of a team is not how you determine if a team is hyper productive. As management, you should create a hyper-productive environment for development teams. I wrote a blog about this topic. Below is a short summary.

The most important environment variables are:

  1. Constantly Improving;
  2. Good Preparation;
  3. No Dependencies;
  4. Have Fun.

In the sections below you will find more information about the above values. Constantly Improving, A team should constantly improve themselves, remove impediments constantly. A software development process is never stable, technique changes, requirements change, the organisation changes, knowledge of people changes, everything changes;

Good Preparation, Agile or not, you need to prepare your work before you start working. I believe when product backlog (PBL) items are well prepared, the team is able to have a high velocity. Preparing PBL items for me is enough communication between team and product owner. The team should clearly know what the goals are of the PBL items, it should be clear what the product owner expects and there should be some rough ideas about the technical solutions.   

No Dependencies, Dependencies between teams increase communication. Communication is difficult, there are a lot of blogs/books/articles about how difficult communication is.   

Have Fun, when a team doesn’t have fun, it will never become hyper productive. Are you motivated to do something that you don’t enjoy? Fun is not only telling jokes, fun is much more for example: good hardware, a comfortable Office, appreciated by colleagues or management.   When all the above is in place, I believe a team can become hyper productive. How do you know when your team becomes hyper productive… you will know trust me, trust your own gut feeling. Transparency

Management should be as transparent as possible. It is dangerous to think employees are not able to handle certain information. When something is decided or not, and the information about the why is lacking, people will make assumptions. This will often lead to a lot of unrest. It also implies that you think your employees are not capable of handling certain information. Again, this is not showing that you trust your employees. There are of course situations when information is not ready to be shared with employees, such as some financial data, discussions about reorganizations or issues related to individuals.

Standard Process As said before, a process is important. You should strive to have standard processes in place that are used, and therefore understood, by all teams. As soon as there is a standard process, an organization will always be able to rely on this process. It should always be possible to deviate from the standard process. However, when there is a standard process in place, it is possible to deviate. When there is no standard process, every deviation could be the standard.

Teams Versus Individuals

I speak about teams and not about individual programmers, testers or technical writers. This is with reason and not without. No individual is able to deliver software alone. Building and delivering complex software is something that needs to be done with a group of people, a team. Individuals are not able to deliver the same quality software as teams are. When you have a good team, 1+1 = 3 or even more.

Discuss or Just Start… Starting to use a new tool, process or building a new product is difficult. However, it will never be a success when you only talk about it. When something new comes in, discuss it shortly and start using it or build it. After the first days/weeks you will have gained new insights and you will be able to make better decisions. Additionally, you could use retrospectives to improve the team or process.

Scrum Evolution

Many teams start using Scrum or any agile method leaving sometime between the iterations. The time between the iterations is used to finish up the old iteration and to prepare the new iteration. When a team is able to finish and prepare the iteration during the iteration, the time between the iterations is no longer needed. A next step is to prepare every product backlog item when it is needed and to start working on the product backlog item when it is possible. In this last scrum variant, the team slowly moves to Kanban. A Kanban process delivers new features continuously. This requires a very high quality automated environment of for example test automation and build environments. It should be possible to deliver software at any moment in time.

Conclusion This blog described several important aspects of software development. It is my current vision. However, this vision can change every day, week or month. I try to continuously improve myself by using the feedback from my environment. Is there currently an organization that has all of the above in place, probably not? Most important, however, is to realize that in most organizations, there is always room for improvement. The most important thing that an organization can achieve, is to realize that there is almost always room for improvement and that the organization is willing to improve.

This blog describes my current vision, important values and the required focus of an agile software department. This text is not a silver bullet, it is my personal vision. It is a summary of my experiences, blogs, knowledge and ideas. It is based on visions of, for example, Jeff Sutherland, Mary Poppendieck, Micheal Bolton, Jurgen Appelo and others.

 

What is the goal of a Software Department

The primary objective of a software development department is to deliver, on a regular basis, quality software using a light-weight process.

 

Regular: when a product is not released on a regular basis, there is no link with the business. In today’s markets, it is required for almost all organizations to be able to deliver new features on a frequent basis.

Quality: quality is the value of a product to someone who matters. A product that does not deliver value to a user is of low quality. A product could have several bugs and still have much value, the other way around is also possible.

Light-weight process: a development process should be based on a light-weight process framework. It should contain no or as little overhead as possible. There should be a process in place that teams can rely on; a process with clear and meaningful process steps. It could be Scrum. However, any light-weight process is possible. The process should empower teams to deliver software.

What Kind of Process?

Software development is a creative and empirical process. It is not possible to compare software development with, for example, construction work or an assembly line. It requires a different approach when you need to solve problems. In most cases, it is not possible to use common root-cause analyses. Problems in a software development process require, in most cases, systems thinking.
Trust in Employees
I believe you should trust your employees. You should trust employees that they deliver the best possible within the given constraints of the available processes and tooling. When teams, processes and tooling are stable, the output will be stable. There will be some variation in the output. However, this is statistic variation.

 

Measuring Productivity or Creating the Possibility to be Productive

In books and blogs, people talk about hyper-productive teams. When is a team hyper productive? I believe measuring the outcome of a team is not how you determine if a team is hyper productive. As management, you should create a hyper-productive environment for development teams. I wrote a blog about this topic. Below is a short summary.

 

The most important environment variables are:

  1. Constantly Improving;
  2. Good Preparation;
  3. No Dependencies;
  4. Have Fun.

In the sections below you will find more information about the above values.

Constantly Improving, A team should constantly improve themselves, remove impediments constantly. A software development process is never stable, technique changes, requirements change, the organisation changes, knowledge of people changes, everything changes;

 

Good Preparation, Agile or not, you need to prepare your work before you start working. I believe when product backlog (PBL) items are well prepared, the team is able to have a high velocity. Preparing PBL items for me is enough communication between team and product owner. The team should clearly know what the goals are of the PBL items, it should be clear what the product owner expects and there should be some rough ideas about the technical solutions. 

 
No Dependencies, Dependencies between teams increase communication. Communication is difficult, there are a lot of blogs/books/articles about how difficult communication is. 
 
Have Fun, when a team doesn’t have fun, it will never become hyper productive. Are you motivated to do something that you don’t enjoy? Fun is not only telling jokes, fun is much more for example: good hardware, a comfortable Office, appreciated by colleagues or management.
 
When all the above is in place, I believe a team can become hyper productive. How do you know when your team becomes hyper productive… you will know trust me, trust your own gut feeling.
Transparency
Management should be as transparent as possible. It is dangerous to think employees are not able to handle certain information. When something is decided or not, and the information about the why is lacking, people will make assumptions. This will often lead to a lot of unrest. It also implies that you think your employees are not capable of handling certain information. Again, this is not showing that you trust your employees. There are of course situations when information is not ready to be shared with employees, such as some financial data, discussions about reorganizations or issues related to individuals.

 

Standard Process

As said before, a process is important. You should strive to have standard processes in place that are used, and therefore understood, by all teams. As soon as there is a standard process, an organization will always be able to rely on this process. It should always be possible to deviate from the standard process. However, when there is a standard process in place, it is possible to deviate. When there is no standard process, every deviation could be the standard.

 

Teams Versus Individuals

I speak about teams and not about individual programmers, testers or technical writers. This is with reason and not without. No individual is able to deliver software alone. Building and delivering complex software is something that needs to be done with a group of people, a team. Individuals are not able to deliver the same quality software as teams are. When you have a good team, 1+1 = 3 or even more.

 

Discuss or Just Start…

Starting to use a new tool, process or building a new product is difficult. However, it will never be a success when you only talk about it. When something new comes in, discuss it shortly and start using it or build it. After the first days/weeks you will have gained new insights and you will be able to make better decisions. Additionally, you could use retrospectives to improve the team or process.

 

Scrum Evolution

Many teams start using Scrum or any agile method leaving sometime between the iterations. The time between the iterations is used to finish up the old iteration and to prepare the new iteration. When a team is able to finish and prepare the iteration during the iteration, the time between the iterations is no longer needed. A next step is to prepare every product backlog item when it is needed and to start working on the product backlog item when it is possible. In this last scrum variant, the team slowly moves to Kanban. A Kanban process delivers new features continuously. This requires a very high quality automated environment of for example test automation and build environments. It should be possible to deliver software at any moment in time.

 

Conclusion

This blog described several important aspects of software development. It is my current vision. However, this vision can change every day, week or month. I try to continuously improve myself by using the feedback from my environment. Is there currently an organization that has all of the above in place, probably not? Most important, however, is to realize that in most organizations, there is always room for improvement. The most important thing that an organization can achieve, is to realize that there is almost always room for improvement and that the organization is willing to improve.
Share:

Have you already read these?

Leave a Reply

Your email address will not be published. Required fields are marked *