Tag archive

Kanban

How do we change from individuals in workgroups to effective, self-organizing teams?

in Agile Engineering/Teams by

A colleague of mine at VersionOne, Dan Naden who works to support the Agile community, delivered several open questions from a recent Agilepalooza and asked for help answering. The one that jumped out at me and my experiences was “How do we change from individuals in workgroups to effective, self-organizing teams?”

Team hugWhen I first started looking at this question, I was keying in on the word “individuals” and how individual team members impact our ability to come together and self-organize. The more ideas I got down on paper, the more I came to the conclusion that it is generally not the individual team members that prevent teams from self-organizing and becoming effective. It is usually everything but the individuals that prevent teams from self-organizing. Based on my experience where I’ve lived through an inability to self-organize to efficient self-organization — the individuals are usually never the primary blocker. The things that I’ve seen prevent teams from becoming effective and self-organized are:

  • Teams Are Too Large. Teams that are too big will not self-organize because the team members are made insignificant because their contributions may or may not impact the overall product delivery. Not too mention that when teams are too large you will usually see the Alpha team members overpower and control the non-Alpha team members. This is why the recommended team size is in the single digits (I’ve seen the range of 5-8) thrown out there. Not only does right-sizing the team make planning more efficient, but it also reduces the discussion circle; thus, making it easier to share information and shorten the time to make and react to decisions that impact the team and the projects.
  • Workspace Challenges. Studies have shown that the right workspace leads to highly productive teams and in talking with many teams, it’s obvious that the wrong workspace fosters silos as well as the perception of meetings purgatory. Ideally teams are co-located and share a workspace that is conducive to easy chair-spinning conversation. A workspace with plenty of whiteboards, private zones, and an information radiator will ensure a well informed, collaborative team. When this cannot be achieved, the use of rapid and personal communication tools can help teams. IRC chat, video chat, and online collaboration tools are good ways for team members to collaborate.
  • No Vision. There are multiple layers of vision – company, product, project, and team. Obviously a team can control their vision; however, it’s usually a product of the upstream visions. So if the leadership and stakeholders are not sharing the vision. And more specifically, if the team does not have a shared vision of what they are working towards, then there is nothing to bring the team together to achieve. A clearly communicated and shared provision provides a group of individuals a common goal to achieve — this improves focus on decision making and clear definition on what it means to done.
  • The 3 C’s. And I’m not talking about Ron Jeffries’ Card, Conversation and Confirmation — I’m referring to a Command-and-Control Culture. It seems that even once a leadership team decides to adopt agile and they genuinely buy into agile values and principles, the individuals on the teams are still reluctant to take ownership of how to win (a.k.a. achieve). Not until the the team is forced to make decisions, do they actually make decisions. Team members that have worked in a culture that is historically command-and-control tend to have either a victim mentality in that they simply don’t believe change is happening, or they simply are scared to put their neck out there in fear of reprisal even when there’s never been a history of this kind of action. The only way that I’ve experienced changing this culture is to have the leadership share the vision and then leave the room (a.k.a. get out of the way). When the team has success, the leadership shouts it from the rooftops and when failure occurs the leadership should ensure learning and accountability ensues — however, doing so from a distance.
  • Lack of Shared Trust. A core challenge that organizations (the whole organization) have is the inability to trust others to make decisions. This usually stems from two factors: (1) a command-and-control culture that is a result of traditional project/product failures, and or (2) management team members that have been key to the organization over a period of years and have lived the battles — thus, they feel that because of their experiences — they must be a part of the decision. Remember that trust can go both ways, if the teams don’t have that shared vision — then trust of those making decisions is surely lacking.

So, how do we change from individuals in workgroups to effective, self-organizing teams? We give our teams the environment they need to be productive, provide a clear and shared vision, have leadership get out of the way yet be there when needed, and finally we celebrate our small wins and ensure that we learn from our failures (I’ll assume that this stuff sounds familiar; however, if it doesn’t give this a read www.agilemanifesto.org). I’m sure there are more organizational behaviors and I’m certain that individuals impact our ability to self-organize, but I firmly believe that everyone has the ability to work as a self-organized team and if they are empowered to do so — they will do it effectively.

Please let me know what you think. What are some organizational challenges that you’ve experienced that prevented teams of individuals from becoming effective, self-organizing teams? Or, do you think the organization has nothing to do with it and it’s the individual team members?

Agile Software Manufacturing

in Agile Engineering by

Early in my career, I was lucky to be able to work for a process manufacturing company that invented and produced engineered lumber products. Today I use many of my experiences on the manufacturing floor in my agile software development life. I know what you are thinking, how can you equate the manufacturing of engineered lumber products with development of software. Well you don’t have to look far to see that the whole product and software development communities have embraced efficient process manufacturing production line principles in the development of software projects and or products. This is a move from the world where building software was like building a house — lots of up front work regarding requirements and design, checkpoints and sign-offs along the way, and quality check offs at the end.

Scrum, Test Driven Development, Kanban, and eXtreme Programming — all of which are similar to the processes and best practices followed on a manufacturing floor. How are they similar? I’m glad you asked, over my next several posts I plan on exploring how they are similar and what we can learn from what transpires on the manufacturing floor.

Let’s first focus on what seems to be the most commonly implemented Agile practice – Scrum. I’m not going to get too much into what Scrum is – there are plenty of resources available for that and I’m sure one day that will be a good discussion for Agile.Agile.Agile.  So with Scrum, there are three areas which really stand-out:

  • Daily Standup (or Scrum) = Shift Production Meeting. All most all teams that practice Agile have daily meetings during which the team members answer the questions of “what happened since we last met”, “what is planned between now and the next time we meet”, and “what is preventing progress towards the goal”. Well these are the same questions answered during a shift production meeting at a manufacturing facility. They discuss the results from their previous shift, the happenings of the shift prior, planned production, and obstacles/challenges to meet the production goals. Much like the daily standup, issues are raised during the shift production meeting, but the discussion surrounding the actions to resolve are reserved until after the meeting and only those parties that can impact the resolution are involved. The primary reasons these meetings are similar are simple — it’s all about daily collaboration, team building, and ensuring the goals of the team are always in front of them.
  • Do what you said you would do. Well parents around the world have been saying this for a long time, but this is a core tenant of Scrum and working on a manufacturing floor. Actually, Scrum is about commitments and an agreement between the Product Development Team and the Product Owner (or Ownership Team). The crew that works on a manufacturing floor are committed to producing what was planned in the production schedule.
  • Plan in short periods that result in potentially shippable product. A key to meeting production goals is setting realistic goals that are derived from understanding production input constraints (raw materials and workforce) and an honest assessment of market conditions (understanding supply and demand of produced products as well as organization production goals). To do this successfully, planning is most effective when it is done within short time fences. Of course, all practicing agilistas know this to be true within most agile processes – and the sprint timeline is considered untouchable. This is because what was mentioned above – the team planned and committed to complete work within the specified sprint. It is also important to mention that using consistent short periods helps teams, production floor and or Scrum team, to get into a rhythm.
Go to Top