Learning Attitudes and Coaching

Photo by Anne DavisI am participating in an intensive 12-week program through work that is a combination of reading, discussion, group journaling, group meetings, and individual coaching.  The intent is to broaden your individual skills, however, one of the aspects is to gain an understanding of service businesses in general (financial aspects, sales, etc.).  We're exploring ideas that feel very timely to me, and one of the first concepts we talked about was learning attitudes.  I now see the differences prevalent in organizations.

One's beliefs about nature (innate ability) vs. nurture (developed ability) lead to different attitudes toward the learning gap, and Fred Kofman refers to these two attitudes as the Knower and the Learner:

Those who approach the learning gap with a "Knower" attitude generally have a closed mind because they assume that they already have the answers and are therefore incapable of any significant improvement. This tendency not to admit that they don’t know something, according to Kofman, is the hallmark of Knowers. Yet, as he points out, it’s difficult (or even impossible) to seek and acquire new knowledge unless people are awareand can admitthat they do not know. 

On the other hand, those who approach the learning gap with the "Learner" attitude are willing to admit that they don’t know. This awareness and admission of the learning gap allows them to approach situations with an open mind and a sense of ease and even enjoyment as they learn new ways of understanding and doing things.  

I now have a new language to explain some of my observations as a coach, like when I try to describe the person who alienates his fellow team members with his strong Knower stance (I previously might've used other language to describe him, and it might've led to different results).  Given the talk of "self-organizing teams," "continuous improvement," and "inspect and adapt," I'm surprised by how many Knowers there are trying to firmly lead or manage agile teams.  As a coach, I'm glad for new language to reflect back to them what I see happening.

Budgets and Agile Software Development

Photo by Jon TuckerAgile delivers results earlier than traditional methods, and organizations can manage ROI more effectively by focusing on the most valuable work and doing less [by cutting lower value features and projects].  It seems like funding agile software development should be simple--provide enough money to pay for the team for a given period of time, don't change who is on the team, and prioritize the most valuable work first--but the budgeting practices of most organizations are far more complicated.  Capital vs. operational spending, a heavy reliance on contractors rather than full-time employees, and a focus on projects rather than product development make it more difficult to keep teams stable and focused on the highest value work.

Daniel Greening wrote a lengthy article about agile capitalization that I found interesting, although I suspect organizations will likely be unable to get rid of timesheets completely as long as they have contractors on their teams.  But in an agile adoption, it may be wise to talk to the organization's CFO or finance department to build support for investing in people and resources that can further enable success.  Lisa Crispin has some great tips on how to talk to the CFO about agile.  

Team Collaboration and Monkey Chatter

Photo by AprilI overheard two testers who work on different teams talking the other day.  One defines tasks in sprint planning for creating test cases, executing test cases, and re-testing defects for each user story.  The other thought it was insulting to the developers to create a re-test defects task before defects are found.  Was it merely a difference in how they created tasks?  Apparently the teams are very different in how they collaborate.

The team that plans for defects upfront is not co-located--people are scattered in cubicles across two buildings--and testing does not happen until the code is pushed into their QA environment.  The team that does not plan for defects upfront is co-located, and the developers have the testers start reviewing the features early on in the development environment--defects are found and fixed earlier or avoided through conversations that clarify the user story because of the team collaboration that happens through co-location.  It reminds me of an article I read about monkey chatter.  Monkeys don't necessarily try to communicate certain messages to each other, but their proximity to one another allows for sharing of information [e.g. a certain sound indicates that a predator is near].  Co-located teams have more conversations because they can see and overhear each other; asking a question is seen as less disruptive because of the shared space.

Co-location makes a big difference in a team's culture, and it disheartens me that a team trying to be agile isn't pushing to be co-located.  Teams should be co-located as quickly as possible during an agile adoption--otherwise teams might get stuck in their "good enough" processes and take their distribution for granted and as unchangeable.  Leaders should map the office design to the culture they want because it can have a big positive impact.

Creating Safety for Teams

Photo by Laura Bittner

My friend/mentor Gary likes to say that a good scrum master knows when to let a team feel some pain so that it can learn and grow, but he keeps the team from injury.  It can be difficult at times to know if a team's decision will cause pain or injury, but it is a question that should be asked before rushing to solve problems for the team.

Scrum masters, agile coaches, and managers need to create safe environments for teams to experiment and grow.  Yes, it can be nerve-wracking to watch a team make decisions contrary to what we would do, but learning may be stifled if the team is not free to make those "painful" decisions (again, we do not want teams to injure themselves).  It is our responsibility to provide relevant information to the team regarding any constraints so it can make wise decisions, to encourage open communication and collaboration, and to eradicate fear through knowledge sharing. 

One of the teams that I am coaching has its sprint retrospective this week, and there have been a number of challenges and issues that they've faced in the last 2 weeks that need to be discussed as a team; the scrum master and I chatted briefly about some of the issues that might come out during the retrospective and how to facilitate the meeting.  As a facilitator, he needs to stay neutral in the content of the meeting so the team feels a sense of ownership in improving its processes, practices, and working agreements.  He has decided to try the Constellation activity.  It's a great activity to "hear" from all of the individuals on a team without pressuring people to talk, which can help quieter team members to feel safe.  I've participated in this exercise a few times myself, and I am anxious to hear how the retrospective goes.

Learn by Teaching

Photo by Krissy VenosdaleTake what you've learned and teach it to someone else--when you do this, your depth of knowledge increases.  It reveals your understanding of not only the what, but also the how and why.  

I recently attended the Coaching Agile Teams class taught by Lyssa Adkins and Michael Spayd, and one of the activities was to explain an agile framework [e.g. scrum] to two classmates.  Lyssa gave a demonstration that was much like her overview of scrum video, and our goals were to really try and to push ourselves to find our weak areas in our understanding of the agile framework--I knew that I went outside my comfort zone in my explanation of scrum for a business audience when I realized that I forgot to explain the role of the Scrum Master.  It's an obvious oversight, but in the moment of teaching, it slipped my mind.  

Scrum is fairly simple, but it can be difficult to teach.  People often want to describe it as a methodology or a process, but it is neither.  Scrum is a framework that describes roles and rules; it is based upon values and facilitates people in a low-prescriptive way. The Scrum Guide holds the definitive description, and it takes a deep understanding to explain it to someone else effectively in under 10 minutes.