Last summer, I moved into a new role at my organization as the Development Manager for what we call the Tools Team. While not maintaining the title of an enterprise architecture (EA) team, my team provides similar EA functionality that is found in other organizations. As thought leaders, we provide technology guidance and leadership to the Agile teams that make up software engineering. Our primary areas of focus are communicating patterns and practices, intentional design, and fostering the ability to work smarter, not harder.

Recently, our team participated in an Agility Health session. Either directly through stakeholder feedback or through conversations and analysis since that point, three key items have been revealed that our team will focus on in 2017. I thought I would share these learning points for those in similar roles.

1. Provide Better Documentation

Last year, I wrote an article about Code Commenting Patterns, which took a humorous look at some of the documentation I have seen over the years. For the record, I am a believer that well-designed code can go a long way with providing self-documentation. However, this type of documentation is really at a higher level, providing background information and how-to instructions instead of documentation at the method level.

To keep my team focused and producing the next greatest thing, I was often writing a lot of the documentation for the team. This served several benefits in my view:

• I kept my engineers focused (and excited) on building the next thing on our list.

• I enjoy writing, so creating the documentation was a strong suit for me.

• I was able to understand more about what was being produced by the team since I was writing the documentation.

Unfortunately, the documentation I was producing was too high level for day-to-day consumption from the software engineers. What I provided helped explain the "what" and the "why," but the "how" (or how-to) was simply not deep enough for practical implementation.

While I was focused on letting my team continue to dive deeper into technologies and frameworks that interested them, the unexpected result was that more separation between my engineers and the customers they support was being introduced. Plus, I feel like being able to document a project is a good attribute to maintain. As a result, my engineers are adding and updating documentation as part of their tasks.

2. Listen, Support, and Evangelize

Another learning point for my team was in the area of listening to the needs of our customer. This tied closely with how well we were doing supporting the needs of the software engineers focused on using our recommendations. Our customers felt like we tossed solutions over the wall, then began working on the next task on our list with little availability to listen to their needs and support them as needed. In both cases, there was room for improvement.

In order to resolve these issues, our team decided to hold weekly check-in meetings with our customers. These meetings would not only discuss what we were working on (and why) but also allocated time for our customers to provide feedback and ask questions. The meetings were held to a 30-minute maximum and we have documented our meeting minutes and takeaways for everyone to see.

Since starting the weekly check-in meetings, we feel like we are better supporting and listening to our customers. As an added benefit, we have been able to evangelize our solutions, which has caused interest in our tooling and solutions to gain momentum.

3. Get Teams Contributing

Lastly, we have seen engineers from our customer base begin to check out and make updates (as needed) to our solutions. This is a result of discovering new needs for our tooling or uncovering a use case that did not exist before. In both cases, it is nice to see developers from the feature teams take ownership of the code that was created by our team, since that has always been a goal for the artifacts we produce.

Conclusion

I am looking forward to 2017 and the solutions that our team can provide for our customers. Without the Agility Health session and the feedback that was received, my team would likely not have the information needed for us to improve.

I plan to post an update at mid-year to provide an update on my team's progress.