Photo by Jon Tucker

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.  

Photo by April

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.

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.

Photo by Krissy Venosdale

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.

Photo by Ian Sanderson

It's difficult to slow down when you have multiple high priorities competing for attention.  But focusing your attention to just one thing at a time allows you to complete something faster and with higher quality.  It's not easy to prioritize our focus to just one thing at a time, but we have to pay attention to our attention.  Slowing down is easier when the work is always prioritized because it is easier to see where to focus next and there is visibility around what is and is not going to be done.  We must make the hard decisions and acknowledge we cannot get everything done.  Slack needs to be built into our lives for sustainable pace, learning, innovation, and improvement. 

Seth Godin admonishes that there is never enough:

...the organizations that get around the universal and insurmountable problems of not enough time and not enough money are able to create innovations, find resources to be generous and prepare for a tomorrow that's better than today. It's not easy, not at all, but probably (okay, certainly) worth it.

We're going to spend our entire future living in tomorrow—investing now, when it's difficult, is the single best moment.

My body is telling me that I need to add more slack into my life, and I am trying to obey.  What is your gut telling you?

Photo by Christian Bradford

We do not want our teams to come to the office day in and day out going through a given routine, following rituals and upholding traditions--if teams do not understand why routines, rituals, and traditions exist, how do they know they're getting the right things from them?  It reminds me of the Pot Roast story:

A young woman is preparing a pot roast while her friend looks on.  She cuts off both ends of the roast, prepares it and puts it in the pan.  “Why do you cut off the ends?” her friend asks.  “I don’t know”, she replies.  “My mother always did it that way and I learned how to cook it from her.”

Her friend’s question made her curious about her pot roast preparation.  During her next visit home, she asked her mother, “How do you cook a pot roast?”  Her mother proceeded to explain and added, “You cut off both ends, prepare it and put it in the pot and then in the oven.”  “Why do you cut off the ends?” the daughter asked.  Baffled, the mother offered, “That’s how my mother did it and I learned it from her!”

Her daughter’s inquiry made the mother think more about the pot roast preparation.  When she next visited her mother in the nursing home, she asked, “Mom, how do you cook a pot roast?”  The mother slowly answered, thinking between sentences.  “Well, you prepare it with spices, cut off both ends and put it in the pot.”  The mother asked, “But why do you cut off the ends?”  The grandmother’s eyes sparkled as she remembered.   “Well, the roasts were always bigger than the pot that we had back then.  I had to cut off the ends to fit it into the pot that I owned.”

If continuous improvement could be automated like machine work, we would automate it.  But the heart of agility relies on people, and it can be wasteful for people to go through motions without understanding the underlying why.  Coaching helps remind us of the why so we can determine how to get the what that is needed.

Photo by Sasan

The article is "Your Path through Agile Fluency," by Diana Larsen and James Shore.  Our presentation gives a high-level overview of the agile journey that development teams take, and the article provides a more vivid image of what each level of agile fluency looks like.  The highest level--level four--is the bleeding edge of agile, and it's what we as coaches strive for each day.  Radical self-organization and alignment with the rest of the organization.  Transparency and innovation.  Rainbows and unicorns.  Ok, maybe not rainbows and unicorns, but certainly amazing results.  The best example that I can think of for this type of team and organization is Valve--their employee handbook paints a dramatic picture of level four concepts that I find challenges conventional thinking about how organizations are structured and function.

I'd love to hear your thoughts on agile fluency and examples of the highest level teams!

Photo by Elyse

How other employees and managers react to mistakes plays a large part in how someone will react when they make one.  If others place blame, then it is only natural to be fearful of the consequences.  But if they look at the system to see what caused the mistake to occur, they encourage contractors to do the same and learn.  It is by making mistakes and failing that people learn to adapt, be more attentive, and become better problem solvers.  

So the next time someone makes a mistake, ask questions.  Question everything.  Find out the root cause of the mistake and see if there's an opportunity to prevent it.  But use it as a learning opportunity, not a witch hunt.

Photo by Steve Johnson

Pawel Brodzinski shared how he is unable to hide his emotions in the workplace, and one of my coworkers is the same way.  Rather than view it as a negative, Pawel classifies it as authenticity--it's part of being honest and transparent.  But organizations don't always want honesty and transparency from their leaders; they expect leaders to put on a mask to protect the organization's interests because employees cannot be trusted to know everything or shouldn't be distracted by the ins and outs of organizational details.  In such situations, managers are caught between company culture and their employees.  

It's known that employees often quit bosses--not jobs--but studies have also shown that the exit rate of bad bosses (those who don't improve the productivity of their workers) is almost twice the rate of the average-quality boss.  According to the researchers, the best bosses are teachers and cheerleaders.  I suspect that the best bosses might also use those skills to shape company culture, making it more transparent so all employees can be more authentic.  After all, it's tiring to not be yourself in the workplace, and it's associated with lower job satisfaction.

So go on, be an authentic leader.