Takeaways from (r)evolution of the development organization

In the last couple of years I’ve seen and gone through several organizational changes for the software development organization.The different methods/frameworks that were applied to the organization I’ve seen are Waterfall, Scrum (of scrums), DevOps, Feature teams and Agile scaling. In my last blog, I have given a short overview of these methods/frameworks. This follow-up blog gives my five takeaways from my experience with these methods/frameworks. Most important, be flexible and change the method it that is needed.

I will not give advice on which method/framework will work best for your organization. Every approach has its own characteristics. But despite their differences, they also have their similarities. My takeaways can be applied to all methods/frameworks.

Look at project as well as organization

My first takeaway is that you choose the method/framework that fits your project as well as your organization. For each project, you should choose which method/framework fits best. For example, you can take the size of the project as a consideration.

Do you have to do some small changes or build a small system, maybe even without integration, and can it be analysed completely up front? In this case, you could still use a waterfall approach. The advantage would be that you have a complete overview of the functionality and architecture before you start to build.

When the system becomes bigger or more complex, you could decide to use one of the other mentioned methods/frameworks. The advantage would be that you can respond to changing requirements. These requirements can change because of new insights or new regulations.

Next to the project, you also need to take a look at your organization and especially at the maturity of your organization. For example, you can take a look at whether the organization is ready to work on continuous integration/deployment so that you can work with DevOps teams.

Depending on the outcome of your analysis of the project and organization, you could even decide to use a combination of different methods/frameworks. You could combine waterfall and scrum, which is sometimes also referred to as agifall.

Be flexible

When you’ve chosen a method/framework to organize your project and you notice it doesn’t work, don’t hesitate to change according to your needs. Even if it means that you have to choose a different method/framework. That also leads me to my second takeaway. You should not only be flexible in relation to the functionality you are/will be working, but also as flexible in relation to the way you are working and have your work organized. The mentioned methods/frameworks are not cast in stone and can always be adapted to the needs of the project and/or organization.

In some organizations you really have to be flexible as a person working with a method, because many changes will be applied to the organization and to the project. I’ve noticed that some people can handle these situations better than others. So keep an eye out for those people that otherwise will get disconnected and loose interest in their work. Everybody can change, but some need more time and/or guidance.

Keep units of work small

In my opinion people have the tendency to lose focus when the amount of work becomes overwhelming. So try to have small units of work for people to work on. In this case, units of work can be user stories or use cases. Small units of work are especially useful when working in sprints. It helps the team to focus on their work so you can finish the unit of work within a sprint. This will give the satisfaction that functionality is completed and motivates the team for the next sprint. As a result, the productivity of the team will be more predictable and you can plan releases more reliable.

Business analysts work ahead

When working with an agile method/framework, all team members should be working on the same units of work according to the theory. However, when a sprint starts you want all team members to be productive when the sprint starts. You don’t want the developers and testers to wait for the analysis of the unit of work to finish, before they become productive. So you don’t want them to wait before implementing the change or creating test cases/scripts. In practice, you will see that the business analyst will usually work ahead of the rest of the team. They will be analysing the units of work for the next sprint or the sprint after. You don’t want to work too far ahead, because when working in an agile environment the planning can change each sprint. In case the functionality is cancelled or reprioritized, the effort of the business analyst is wasted.

Of course the business analyst is still part of the team and the business analyst will need the developers/testers’ input related to the technical (in)possibilities. Developers/testers will need the business analyst for questions about the functionality that is being implemented/tested.

Cooperation/communication

The interaction between business analyst and developers/testers takes me to my last takeaway. Everybody involved in the project should cooperate and communicate with each other. This is not restricted to business analysts and developers/testers, but also between peers, between developers and operation, between product owners, etcetera.

This communication should rather not be through documents and emails, but preferably much more personally. It works most productive when people are working in the same room. In this way, they can ask questions or make remarks directly when needed. People are more aware what happens in the project when they can hear other people talk about their (issues on) work. They can also directly intervene if needed. Of course you still need documentation for reference and for documenting design decisions. This should be done preferably not just in emails, as you will lose track why certain decisions were made in the past.

Conclusion

I hope this blog will give you some inspiration for thinking about how to organize your project/organization and I hope you will be able to make the right choices for your project/organization. And when you didn’t take the right choices right away, don’t hesitate to be flexible and adjust the things that are not working for your project/organization.