Agile has become the de facto standard in Software Development. While more and more companies start carrying the “we are agile” badge, the experiences with this shift seem to diverge. Some can’t imagine a better format, others seem to have problems with the imposed changes.
It boils down to the concrete implementation. A bad implementation will lead to a bad experience from a Developer perspective.
A lot has been written about implementing Scrum or Kanban, very often from a Manager / Project Manager perspective. Makes sense. Because very often you need to sell the idea to Management.
The following are just ideas and they will not apply to everyone and every environment. See them more as starting points. Not every company is the same, neither are Developers.
1. The Daily Standup
Too many Developers hate the daily standup. Very often the situation is perceived as unauthentic, very intense or very boring. If you have an excellent Scrum Master with people skills you might be able to navigate around the problems and turn it into something meaningful.
If you don’t have an experienced Scrum Master then you might try to rotate the Scrum Master role between the team. Let every single team member understand and see the problem from a different perspective.
This might lead to new and better ideas when approaching the Daily Standup.
2. The Retrospective
I think the retrospective is the most important meeting. This is the Scrum event where we can reflect and learn. Make sure the meeting is perceived as authentic. Don’t try to copy other people’s implementation.
Very often the retrospective is built around post its and artifacts. Maybe shift the focus on the individual team members. Find a middle way between having people speak openly (this is not for everyone) and hiding between meaningless post its. This might take time, but the more we can create an open culture (at least during the retrospective), where everyone has the opportunity to speak without being interrupted, the more open and honest the feedback will be.
3. The Blame Game
If you’re still playing the “who broke the build” game or stuck in a “who wrote this crap” type of culture then stop. Please Stop.
Use proven technics like Pair Programming or Code Reviews, move towards a team effort. If the code is bad or not up to team standards than everyone is to blame. Every single line of code has to be passed through the team to ensure that the team itself is to blame not single individuals.
Grow up and start building a culture of respect. Start working at removing the blame game if this applies to your team.
4. Go have an after work Drink
Communication is key. I’m not suggesting to go for an after work drink every day. Rather take the time to have lunch together, at best outside the office, on a frequent basis — or grab a drink after work and discuss non product/project related topics.
Although this sounds too simple to work, it more often than not works.
5. Talk to your customers
Really? Yes. Avoid endless discussions on what the team believes the customer or user wants or needs. This is annoying and costs time and money. Even worse when none of the team members ever talked to the customer or a single user.
This might be seen as the opposite to creating a better Developer experience. If the team hates to pick up the phone, maybe try other options like Skype for example. Step by step. You will learn the most when talking to your users and customers directly.
Give it a try. Pick up the phone the next time and call the customer - instead of having long discussions on what the users really need.
Remember, talking to users and customers is not exclusive to the Product Owner.
6. Learn to Listen
If the discussions inside a team are chaotic, aggressive or lead to nowhere then decide on adding a facilitator to your meetings. The facilitator should be a non team member.
Creating a culture where everyone listens like he wants to be listened to might take a lot of time. This is nothing that can be achieved after a couple of sessions. It takes practice and focus.
Take your time and focus on creating a culture where listening is valued just like or more than talking.
7. Be Authentic
No matter what you do, make sure to be authentic. Nothing will work when the underlying motives are perceived as unauthentic. This means, don’t copy other people’s implementation. Use them as an inspiration or starting point but then make sure it fits the current situation and environment.
Obviously there is more that could be written about the Developer experience including Estimations, Product Owner — Team Communication and more, but this will be the subject of a followup post.
I would really like to hear your ideas and suggestions. The ab0ve suggestions are only starting points. In best case, change could be triggered by every single team member, but this really depends on the current team and company culture.
Some of the suggestions can be triggered within a team, think the blame game and having an after work drink. While changing the daily and retrospective might not be within a teams capability.
