- Agile Leadership Development
- Product Owner
What are the Agile Engineering Skills, Scrum Developer Practices, or Software Craftsmanship practices?
These are three (of many) common names for a set of practices assembled in the mid-1990s to support and improve Agile software development efforts. They are a collection of practices that help teams work in an incremental, iterative, and simultaneous way (i.e., all functional departments working towards a clear goal on a continuous basis, and not waiting on each other at explicit or implicit process gates).
They were first combined as a complete collection of practices within Extreme Programming, another popular Agile method, around 1996.
It’s a classic facilitation blunder: You start giving instructions for an activity, and as you’re talking, people begin the activity. You try to reel in those eager participants so you can get the rest of your instructions out. Then, as everyone starts, you realize you forgot something important and need to get the group back together for more instructions.
The best facilitators are extremely deliberate about how they give instructions. Read More
A major challenge we run into when helping organizations shift or improve is leadership misconceptions. Agile leadership myths cause a lot of these misconceptions. We need to help avoid falling into the trap of these common myths because they limit our success. A root cause of many of the myths is that people simply don’t know what else to do. For example, Myth #1: ‘telling people “you are empowered” actually works.’ Leaders often don’t know what else to do, other than tell teams they are empowered. We see this with Development Teams, Scrum Teams, Delivery Teams, AND Leadership Teams.
A bit of background — there are many agile leadership myths out there. These myths (or assumptions) limit leaders ability to improve, help others, and succeed. Many myths seem to occur at a nonconscious level, meaning they function like many biases. People are not even aware, consciously, that they are happening. Read More
I was co-training an Agile for Teams workshop with Rob Myers last week. This group had been trying to do Scrum, with some success. Our job was to help them solidify their Scrum practice. I love workshops like these. There’s enough knowledge and experience in the room that if willing to learn, can create a huge uptick in satisfaction and performance. Fertile ground for the ‘aha’ moments!
At one point the managers left the room so that the teams could, without fear, talk about what they were going to do differently going forward. The managers suggested they leave. A nice move on their part, and one btw I hope in the future they don’t have to repeat as the organization embraces the Scrum Values. But given where they were in the journey, it was a great offer.
When the teams had talked about what they had learned and what they thought they might do differently, we debriefed a bit. It was a great conversation, with a lot of the ‘aha’ learnings. However, for me there was a lack of clear action as an outcome of the debrief. I asked, “When the managers return, what do you want to tell them?”
We require environments where people can provide input and ideas. If we limit engagement, we limit success. We still have organizations who either believe or act like they believe some types of workers are “stupid.” This idea dates back to the ideas surrounding Scientific Management, Fredrick Taylor, and Henry Ford. The concept of the stupid or unskilled worker that I mentioned was common in the early 20th century. In various writings about agile and agile ideas, we often refer to or see references to avoiding Scientific Management, Classic Scientific Management, or Taylorism. These management ideas limit engagement from people, which is going to limit success.
Understanding the past can be quite helpful to see where you might be able to improve today. Read More
Let’s cut to the chase: No one likes meetings. A status meeting every day is enough to drive you crazy.