Here’s a video I shot for freeCodeCamp about the Definition of Ready.
Have you ever started work on a user story that wasn’t ready to work on yet? Create a Definition of Ready to establish reasonable guidelines as to what conditions need to be met before you pull a user story into a sprint or begin work on it. Creating and following a Definition of Ready could double the speed of your team.
Click “Continue reading” below for a transcript.
Here’s a video I shot for freeCodeCamp about the Tradeoff Matrix.
When we work on projects with fixed dates, scopes, and resources, we run the risk of burning out our teams and compromising quality. Use the tradeoff matrix to agree with your stakeholders as to what you’ll do when things—almost inevitably—don’t go exactly as planned.
Click “Continue reading” below for a transcript.
I shot an interview with Adolfo Foronda about building the right product as a product owner. Check it out! Click “Continue reading” below for my speaking notes, which are an approximate transcript.
I shot an interview with Adolfo Foronda about saying “no” as a product owner. Check it out! Click “Continue reading” below for an approximate transcript.
My dear friends John Furey and Vincent Fortunato have been working on a project called MindTime for many years. I first learned about it several years ago and it’s become a dominant—and very useful—lens through which I’ve come to understand myself, friends, concepts, and communities.
It is, at its simplest, a highly-predictive personality profile. At its broadest, it’s a tremendous lens through which to understand human behavior.
Unlike the MTBI and similar profiles which uses culture-specific linear axes (e.g., extroversion and introversion don’t mean as much in East Asia), MindTime focuses on people’s universal relationship with time.
If I were to say that people are varying degrees of past-, present-, and future-thinking, I imagine this would already make intuitive sense to you. Further, this can be applied to any word, idea, company, community, brand, and even country.
Here are some examples:
If a heavily future-thinking person finds themselves in a heavily past-thinking company or team, there may be a lot of conflict. Same goes for relationships (from personal experience). Simply understanding where everyone is coming from can improve empathy, happiness, and performance. My friend has used this to help develop teams at a variety of companies.
If you’re intrigued, check out their site or try the profile (free, no registration, takes about 2 minutes). I’d love to hear your thoughts, especially whether or not you find the results both specific and accurate.
For you past-thinking dominant types, you’ll be delighted to know that there’s very solid science behind it.
I recently came across Mark Graban‘s “Highlights from the Original 1984 NUMMI Team Member Handbook” series. Digging through the archives at Ephlin’s UAW office papers were archived at the Walter P. Reuther Library at Wayne State University in Detroit, Mark found some absolutely extraordinary gems, including this one.
Standing on the shoulders of giants, I reached out to the archivists at the library to see if I could get a copy of the full handbook. They cheerfully obliged, and rather quickly at that!
Grab the PDF and peruse for yourself. The first several pages are the most interesting, but even as you explore the rest of it pay attention to how human and reasonable it is. Mark provides an excellent commentary on several key sections, so I’ll try to avoid highlighting the same thoughts. I hope you’ll share your own findings and commentary in the comments below.
Here are some of the gems I’ve found:
Notice that the first objective is “To help [employees] develop to [their] full potential.” In fact, these objectives start with the individual employee, progress to the company, and then ultimately end with the customer receiving the “highest quality automobiles in the world.” This is a notable inversion from the usual objectives, which usually prioritize stakeholders and customers, then the company, then—if at all—the individual employee.
This is extraordinary in two ways. First, employees are given the expectation that they are going to have a greater autonomy and influence over how other aspects of the organization operate. I’ve heard the statistic that Toyota’s 300,000 global employees make a total of one million suggestions annually, 97% of which are implemented. Secondly, note that the employee handbook is characterized as helping the employee “do [their] job better,” a far cry from the usual purpose of this kind of handbook (protecting the company’s interest).
Are you doing Agile, or have you become Agile?
The difference seems pedantic at first…
You are doing Agile when you’ve changed your tools and processes. This is relatively easy to do but doesn’t offer much in the way of benefits. You’ve become Agile when you’ve changed you structure and culture too. This is relatively hard to do, but offers significant benefits.
Agile isn’t just a process. It’s a complete framework that brings together a shift in culture, structure, and processes. This framework is supported by tools such as Rally and other Agile Lifecycle Management (ALM) tools.
For our October 28th Agile Potluck, we’ll discuss Agile in a mobile world. Is Agile/Scrum right for mobile? What’s different from traditional web-based application development?
Come join us for a rousing discussion over great food! The potluck is from 7:00pm to 10:30pm at my home in the Dogpatch neighborhood of San Francisco. I hope you can make it!
Many of you may be familiar with Lean Coffee™, a “structured, but agenda-less meeting” that happens world-wide as a way of discussing Lean techniques in knowledge work environments.
I’d like to introduce the Agile Potluck™. It differs from Lean Coffee in a few key ways: They’re smaller, less formal, and require more participation to attend. While Lean Coffee is great for talking through the challenges we face in the office, the Agile Potluck adds a personal touch that forges deeper, more meaningful connections. When the barrier to entry is higher, the quality of conversations improve (just ask anyone who has gone to Burning Man!).
I’ve hosted five of these potlucks so far and we’ve found them to be very successful. Here are some of the reviews that we’ve received:
“Wow, this was a terrific event. Loved meeting everybody, talking Agile (including learning about Nummi!), and enjoying great Paleo food! … This was a great networking event as it turned out also – thanks everybody for any networking assistance you can help me with here as a transplant to Silicon Valley!” Brian M. Wills, Agile Coach
“Thanks for hosting this event Chris! I personally had a great time learning, dinning, and feeling honored to be part of a very refreshing and honest exchange ce soir!” — Alvin Du, Staff Engineer
“Lovely! What a wonderful evening. Truly one of my favorite experiences since moving to the city.” Brittany Fritsch, Project Manager
“We explored on how to best serve our clients/organizations :)” — Latha Swamy, Lean | Agile Transformation Leader and Executive Coach
“Great conversation, insightful discussion, and lots of insights.” — George Lawton, Technology Journalist
“We wined, we dined, we talked Agile, and had a great time!” — Lydia Sugarman, CEO/Founder of Venntive.com
George Lawton, a freelance technology journalist who writes for ServiceVirtualization.com and other blogs joined several other Agile enthusiasts and I at my home for a Agile Potluck. Naturally, we had a rousing discussion of all things Agile over food and a couple bottles of nice wine and liquor. Stemming from our conversation, George sent me some thoughtful questions that I’ve responded to for his blog. I’ve copied and pasted them here as well.
While talk about DevOps and Agile is all the rage these days, organizations need to address the culture required to ensure success. Sometimes, it can be useful to bring in a third party – a someone with no dog in the hunt, so to speak – to help guide the team to new understandings of development constraints and how to overcome them through iterative approaches and more frequent, better testing.
We caught up with one such guy, Agile coach Chris Gagné, who explains what’s involved in creating a new culture. As Gagné explains, without a full cultural transition – and even a spiritual transition of sorts – companies are doomed to revert back to old Waterfall-style approaches. Such companies are Agile-in-name-only, he says. Here’s the best of our email discussion:
ServiceVirtualization.com: What is an agile coach?
Gagné: An Agile Coach is someone who mentors, teaches, and facilitates the Agile transformation within an organization. Ideally, a coach has had the direct experience of actually working in a highly-developed Agile culture (at several seniority levels) so that they can more accurately convey what it “feels” like.
ServiceVirtualization.com: What are some of the ways that cultivating a good Agile culture that allows teams ship twice the work in half the time with 10 times the joy?
Gagné: First, what is a good Agile culture? I recall my days at Evolve Media with great fondness. We created a culture of trust and ownership. We trusted the teams to deliver the goods and gave them room to surprise and delight us. We made them the owners of their work: once they could demonstrate that they understood Agile principles, we took a step back and allowed them to define how they worked together.
People need a sense of autonomy, mastery, and purpose to feel motivated in their work. A culture of trust and ownership allows teams to develop autonomy and mastery of their craft. A joyful work environment allows companies to attract and retain highly skilled experts who have the liberty of working anywhere they like. A good Agile product manager makes it clear to their teams why their work matters.
We know from Dale Carnegie that people want to feel important. If you can motivate them to care enough to produce their best work, they will feel the satisfaction of a job well done and can appreciate their importance to their organization.
Finally, people want to grow in their careers. An Agile learning organization allows team members to blamelessly inspect the quality of their work and processes so that they can continuously improve.
ServiceVirtualization.com: How does the notion of “a schedule is only a hypothesis” improve organizational learning and development process?
Gagné: Mary Poppendieck talked about this in her talk “The Tyranny of ‘The Plan’” at the Lean and Kanban event in 2009. When a team misses a delivery date, it’s common for managers to consider this a “performance failure” and punish the team. A better way to look at it is that “a schedule is only a hypothesis.” If the date is missed, the hypothesis was wrong. Thus, there is a learning opportunity. Complex stems inevitably fail. A failure is evidence that we do not have a full handle on how the whole system works. Your willingness to learn from this event rather than throw someone under the bus will increase your ability to understand this complex system and reduce the odds that you’ll have a similar failure. Every single little detail matters.
ServiceVirtualization.com: How can organizations leverage the idea of lowering the cost of failure?
Gagné: Innovation comes only through fearless experimentation: nothing tested, little gained. If the cost of failure is high for either the company or individual members of the team, the team will only take safe, predictable bets. Agile lowers the cost of failure because less is lost through taking smaller bets. The increased pace of development further allows teams to execute more tests in the same amount of time. This reduces the cost to the company. A good manager understands that even when a bet doesn’t pay off, the learnings gained and willingness to fail was worth the cost. These managers will not punish the team for the failure unless the failure was reasonably certain or avoidable.
ServiceVirtualization.com: What lessons can modern enterprises learn from the construction of the Empire State building?
Gagné: These lessons again come from Mary Poppendieck. The Empire State Building, an 85-story building in Midtown Manhattan, was built exactly on time and 18 percent under budget. They did this in 1930, 40 years before the microcomputer became popular and over 20 years before the invention of the PERT chart. The building team literally did the detailed planning for upper floors as the lower floors were being built.
The lessons for companies everywhere is: If Toyota can build cars using Lean and builders built skyscrapers without computer-based planning with similar principles, there’s no such thing as a project that’s too big to be built using Agile. In fact, I’d argue that the larger the project gets, the more important it is to break it down to smaller, iterative chunks.
ServiceVirtualization.com: What is the best place to start in getting an agile culture off the ground?
Gagné: Expose the C-level executives (and ideally the board) to companies that have a truly successful implementation. The most successful companies may not even call themselves “Agile” as they often discover their own way and transcend the Agile bootstrapping.
Hire executives and senior leaders from successful Agile companies.
An Agile coach can help with locating both informational interviews and tours with successful companies. They can also assist during the interview process with potential candidates to evaluate their Agile experience.
ServiceVirtualization.com: What lessons can larger organization draw from Toyota’s success in implementing Agile-like practices?
Gagné: First, If Toyota can do it, anyone in the software/hardware industry can do it. There’s considerably more capital and time involved in setting up an automotive manufacturing plant and “beta testing” new product concepts. Because there’s no obvious connection between building cars and writing software, there’s no easy way to simply attempt to mimic the processes found in a Toyota plant. So, by studying Toyota, one is more likely to walk away and implement the principles. Scrum and Kanban are just useful process starting points that are compatible with Agile principles, not ends in themselves.
ServiceVirtualization.com: What are the worst ways of trying to implement agile?
Gagné: A successful Agile adoption almost certainly will require a complete overhaul of the organization’s culture, structure and processes. The culture and structure are guided by C-level executives and the board, who must embark on a journey of personal transformation to transition from command-and-control to servant leadership. This path typically requires a large deal of psychological (and perhaps even spiritual) growth on the part of the leadership and can be both challenging and time-consuming.
Without changing the culture and structure, the company can only expect “fr-agile,” a state in which the team has perhaps achieved a degree of performance improvement (typically 35 percent) that falls fall short of the several-fold improvement possible with Agile. Further, because the team is being asked to follow processes that assume that teams are truly empowered and supported by servant leaders, the implementation will always feel “forced” and subject to collapse. In these environments, the program management office will frequently “improve” the Agile practices to relieve the pain caused by a process that does not reflect the extant non-Agile culture and structure. Inevitably, this will reflect a transition back to Waterfall-style processes that are “Agile” only in misguided perception.