3 Steps To Help You Prepare For an Enterprise Development Team

Before development teams of an enterprise organization are ready to pick up their work, the whole process is prepared. This process is essential before a developer can write their code.

Since 2014, I’ve worked for big enterprise organizations in the Netherlands (Rabobank, ANWB, Nato, Ministry Of Health, Wealth and Sport), and I’ve seen how those organizations prepared their work for their development teams.

Note: This is not a guarantee that this will work in your organization! Even though you are doing Agile with the Scrum or Kanban methods, you have to put in the work and adopt change when needed.

I learned a ton from it, so I would love to share that workflow with you.

Foreword

This workflow is the baseline that I use in all of the organizations I work for. From small to big, it doesn’t matter. It’s essential to have a workflow that supports the “business” and “development” teams.

• When I say business, I mean people who know how the business works, how their clients interact with their products, and the people responsible for these products. Most organizations call these people product managers or product owners (if they adopted Scrum).
• When I say development team, I mean people who are on the development team. These are developers, testers, scrum masters, team lead, designers, and more along those lines.

1. Preparation

Almost every person on earth knows that excellent preparation will make your chances of success bigger than if you don’t.

Working in a small organization is easier (I don’t mean that it’s easy) than working in a big organization. So if you are in a small organization and want to grow, start with preparation. Always keep in mind that it’s not only clear for you but also for others.

Preparation for the business

The business people must do their preparation way before the development team has to do something.

If your organization works with Github, Azure Devops, or Jira, make sure this work is being done in the “backlog.” Or, if product managers prefer to work on their visions and features in Word or Excel, let them do that.

Make sure this preparation work doesn’t interfere with the work of the development team.

What should be prepared

It’s hard to define what a product manager or owner should prepare if you don’t know an organization. But I will try to explain the most general things.

A feature should describe the following:

1. Goals. It would be best if you defined what the goal is for the user. Why is this important for a user? What goal should a user accomplish? (A development team likes to know a bit of the reasoning behind a feature.)
2. Scenarios. It’s important to write different scenarios on the vision the user should follow to accomplish its goal. This also helps to set guidelines for the team so they can expect a particular feature should work.
3. Devices. Nowadays, the different types of devices that can interact with an application are massive. So it would help if you thought about how the development team should handle those different screen sizes.
4. The un-happy path. Don’t forget to think about handling errors because systems can go down and users can click on buttons you don’t expect. This part is super hard, but the development team can help with this if you’re missing this part.
5. Forms. When your application has forms, you must think about the requirements for these. Can a user send an endless string with all kinds of characters, or does it have a maximum? For a development team, these details are super important.

It’s not that the business should know every single detail. But all the known facts must be written down. As long as information is not written down, but in people’s heads, people will guess.

When people are guessing, you, as the product manager, are going to be sure your expectations aren’t met.

2. Refinement

The main priority for this refinement is that the business and the development are on the same page and create one complete package of information — so no one has to search for all kinds of documents.

When the business has done all the preparation, it’s come to a phase that the development team will see that preparation for the first time.

In my experience, it’s vital for the success of a product or service that development will plan time to read through all that documented information. For sure, they will come with questions about specific details. Yes, that is a good thing!

The responsible business person must create multiple user stories on the backlog of the development team. Mainly if the business person worked its features/ideas out in a Word or Excel document.

Breaking features down into smaller pieces will help developers fully understand why it’s so important that they need to build them. If the parts are too big, developers can’t fully grasp the ideas and make reasonable estimations.

It’s good to plan a “refinement” meeting with the responsible product manager or product owner to discuss those details with the development team. Being in the same room or online discussion will ensure the development team asks questions to the source.

When details are not precise, the development team should clarify the information in the backlog. Sometimes it can help if they add details, screenshots, or external documents.

Now that the development team and business agreed on the plan of the feature, they should be able to give an estimation.

3. Estimation

Estimation is one of the hardest things in software development (I’m sure doing estimates is hard for every human on this planet 🌍.)

Making estimations requires developers to understand the feature they need to make fully. They must have user stories that are broken down into smaller pieces, which will help them make better estimations.

If the user stories are too big:

• Developers tend to have loads of questions instead of a few
• There will be huge gaps between the estimations of the team
• Developers will see big problems

If the estimations are too far from reality, people like product managers and product owners are not happy.

It’s also essential to know that it can take a development team a lot of time to learn to work together. But in that state of perfect collaboration, the estimations in a group will be better.

For these managers that require perfect estimations, please don’t expect this from your team. It requires years and years to get good at estimates. This is only possible if the techniques and domain stay the same.

If developers switch between techniques, domains, or projects, it stays tough to estimate your work.

So, for all the managers that want their team to do estimations, you need to create optimal circumstances and prepare all the work for the team. Make sure that they don’t have to dig deep for their information because this will cost a lot of time. Prepare and package all the information they need in one place. This will help with preparation and estimation.

Conclusion

I hope this process will help you shape the workflow your team needs as a developer or manager.

I would highly recommend using an Agile framework that helps you and your team work well together to deliver valuable software projects. I’m a big fan of Scrum and Kanban.

If you have any questions about this workflow, please let me know. Any suggestions are more than welcome!

The success of a software development project is in the preparation phase. If all the information is available in one place, it will prevent a team from losing valuable time on searching, which will help the team make better decisions.

An Agile framework like Scrum or Kanban can help organize the process around a development team. I love both of these methods!

Thanks

After reading this post, I hope you learned something new or are inspired to create something new! 🤗

If I left you with questions or something to say as a response, scroll down and type me a message. Please send me a DM on Twitter @DevByRayRay when you want to keep it private. My DM’s are always open 😁.