During Red Hat Summit, I was part of what we called Birds of a Feather session; this is the type of session where you place a bunch of people in a room to talk about a topic with no agenda or solidified content. The topic for the session was “Agile Software Development - the Red Hat Way.” The panel consisted of engineers, product managers, customer support reps and program managers who work on our product line using the agile methodology. The focus was to have an open conversation about how we work at Red Hat.
Most of the questions asked by attendees were common Agile problems – those that are easily found on the Internet and I often encounter when speaking to local Agile communities. The takeaway that I have is that while some companies are extremely nimble and able to move at record speeds, there are still many companies out there struggling with even the basic concepts. It always helps folks who are struggling to hear specific examples of things that have worked for others and was the foundational idea behind this session.
There were also quite a few questions about Agile frameworks that have been recently developed to handle scaled environments – specifically how to implement and get people to accept a certain framework. Many of the questions were wrapped around the concepts of “you must do it this way” and “we’re not able to do that.” The central advice that the team had was that the most efficient way to build self-organized teams is to provide them the tools they need to solve the problems they're experiencing in the moment. Frameworks implemented strictly can take choice away from a team and make them less likely to speak up about what isn’t working for them. We also discussed the concepts that process isn’t just about moving work around on a board but also focusing on your technical process wrapped around your engineer as well. If you are spending all of your time on the process, and none of your time on the technology you are going to hit roadblocks in the future.
One of the questions I found most interesting was, “does Red Hat have an Agile financial process?” Many companies are struggling with the fact that their engineering process is iterative but their financial budgeting process is not. When a team is funded annually, but their work is constantly changing, they have no way of figuring out how much they really need at the beginning of the year. It is rare that I bump into someone at Agile conferences who aren't experiencing this issue. It will be interesting to see where the industry falls in terms of best practices and how we accommodate nimble development teams vs. traditional planning processes.
Going into this session, I had two goals and feel we achieved them.
1) Allow customers direct access to people who are using a certain software methodology internally at Red Hat so they could learn more from the folks who were doing it.
2) Allow Red Hatters the opportunity to realize that regardless of what company you work for the problems that you’re experiencing are universal. Sometimes when you're trying to move people in a different direction or change the way they work it can feel very overwhelming and you can feel like you're on your own and no one is there to support you.
Whether you are new to Linux or have experience, downloading this cheat sheet can assist you when encountering tasks you haven’t done lately.
Last updated: June 26, 2017