Agility, Team work and Pragmatism

Posted By Phillip Cave
Software Development Engineer

This week the extended developer (SDE) leadership team in Windows Embedded had a lively discussion around “agile” and how to foster a collaborative team effort. I followed up with the extended leadership team to help them understand some of the nuances of the transformation we are making.

The discussion was kicked off asking how we may focus working as a unit to ship product. A misunderstanding arose about specialist vs. generalist team members, how to review contribution, and an overall misconception about being flexible in an agile environment. What follows was my response to the team.

Yes, foster domain/technology specialists. Of course we should foster expertise around key areas of our product so that we may create technical leadership. Think of the system while doing so. Ensure we have redundant knowledge so that we do not constrain ourselves when delivering product.

Yes we have an HR review model to evaluate team members. However, an HR review system or rather our interpretation of an HR review system should not dictate how we deliver product.

Based on our discussion what I heard was that we are going to be evaluated based on the good things we deliver. This is as it should be. Our contribution to delivering product and the leadership on delivering product is all that matters.

Agility is about a team-focused effort on delivering features. We may reconcile working collaboratively to deliver product with an HR review model by focusing on our contribution to getting the product out the door. The daily feedback loop in an agile environment makes this rather easy to do. A daily feedback loop fosters behavior shifts and creates a focus on delivering quality product while giving us data points on what team members need in order to be successful in delivering product.

Agility is not about specialists or generalists. Agility is about creating opportunities and using good practices to ship quickly with high quality. It’s about breaking our work down into the smallest reasonable set of opportunities (stories), creating quick feedback cycles, crafting those opportunities with discipline and high quality and delivering them. We will need specialists (domain expertise) to help deliver on those opportunities.

Agility is about discipline. We have a business to run and customers to deliver product to. That means we discipline ourselves in our release planning and we create fast feedback loops around decisions and the changing landscape. If we have a hard date it means we have to make decisions about what we are not going to do if we are asked to do something new.

Agility means we create an engineering system to get feedback on our functionality and feedback on our defects as fast as possible. It means we develop our engineering systems infrastructure so that we are supported in getting quick feedback and build quality into the process every step of the way.

Like all things it is about balance and exercising pragmatism. We used an example in the meeting of having an “audio expert”. Yes, ensure we have domain knowledge, we need that. However, if I have very little audio work at the moment, then yes the audio expert is going to help out in another area of the system (no whining please) and when more audio work or audio consulting is needed, then that is what that person will focus on. Does the audio expert have a faster velocity working on their area of expertise? Of course they do. However the pragmatic application in a scenario where the most important work is some other area of the system the choice is to work on lower priority items just to satisfy a personal velocity or have the audio expert focus on helping getting the most important items ready to ship. Choose the most important items to work on. Shipping product is more important than a personal preference. Think. Pragmatism.

Deliver product in small increments to create faster feedback cycles. Create domain expertise so we are better suited to deliver product. Use the lean thinking behind agile to be smart and efficient (read not dogmatic) to deliver quality product based on the day to day changes we face.

Our enemy is not waterfall or agile or an HR system. It is us and our sometimes dogmatic way of thinking. Get out of the box. When you hear me say “I hate the word Agile” it is for this reason. No zealots please. Pragmatists and systems thinking welcomed. Together we can improve our engineering systems over time to deliver the quality product we desire in short cycles.