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.
A team should be able to complete 80–110% of their planned stories each and every sprint without heroics.
Why is this important?
- The work output from this team is predictable. When the team commits to a set of stories at the beginning of the sprint, other teams can rely on them to deliver.
- Predictable output breeds confidence. If a team consistently delivers on their commitments, they are considerably more credible when they need to push back on unrealistic expectations.
- The team will likely feel motivated because they’ve demonstrated a degree of mastery in their craft.
- The team has a stable base. Because they are delivering on their expectations, they can focus their energy on continuous improvement and optimization.
If a team regularly completes less than 80% of their sprint objectives, why does this happen?
- The work tasks do not meet INVEST criteria and thus cannot be estimated accurately.
- New work is given to the team mid-sprint.
- The team faces new and old impediments that interfere—usually unpredictably—with their ability to deliver the work.
It’s not always easy to glean these issues from tools like Rally. Thankfully, there’s a simple solution that can help both individual teams and the program discover the severity and nature of the issues that prevent a team from achieving fast, flexible flow.
The Status Quo
Let’s take the example of a 2-person team working a 2-week sprint. (This isn’t an ideal team setup, but it keeps the numbers easier to work with.) Here’s their sprint backlog a few hours after planning:
They’ve taken on 39 story points, which is one fewer than the 40 accepted story points they completed last sprint. That’s perfectly reasonable.
They’ve added tasks to each of these stories and began work on the first one.
I like to assume 6 hours/day of productivity per developer to account for planning meetings, standups, retrospectives, breaks, lunch, etc. Two developers * 2 weeks * 6 hours/day = 120 hours. Assuming a 25% “safety factor” (some teams use 30%, others use 20%, the truth is that we’re splitting hairs at this point), the team should be able to complete about 96 hours of planned tasks this sprint. They’ve identified 93, so this “smells” okay.
(Note: the team should use story points to gauge how much work to accept into the sprint backlog. Use the task hours as a sanity check.)
Let’s fast forward a week and a half. It’s Tuesday afternoon, and there are about 2-1/2 days left in the sprint:
The product owner accepted 18 points or 46% of the sprint. There’s 36 hours of work left and about 30 hours of time left, so we’re a little behind. Most novice Scrum teams would not register concern at this point.
What happened during the sprint? The development team raised impediments during the standup and worked through them. One developer was out sick for a day. The team had to go to an unexpected all-hands meeting, and they had to do a couple of side projects.
The problem is, there’s no measurement or record of these unexpected requests and impediments. The unexpected requests should not have been added mid-sprint unless they were (rare) “on-fire” issues. The team (and anyone who attended the standups) would know what the issues were, but this knowledge is limited or non-existing at the program level or higher.
This is a missed learning opportunity as we do not have the transparency we need to inspect and adapt.
Introducing the Unexpected Requests and Impediments Story
Let’s rewind and add a new story to the sprint backlog:
Note the addition of “Sprint 5 Unexpected Requests and Impediments” at the bottom. This doesn’t get story points and it’s at the bottom because it’s the last thing you want your team to be working on.
Each and every unexpected request or impediment gets added to this story as a task (with hours) during the sprint, like so:
Suddenly these side projects and impediments become real.
Let’s take a look at that mid-sprint view of the backlog again.
Suddenly, the problem becomes even more clear. We should be able to complete about 120 hours of work in a 2-person, 2-week sprint, but our task estimate is now up to 139. Unless this team works overtime (which they should not do as it is demotivating and ultimately productivity-killing), we’re not going to complete all of our stories in time for the demo.
So here’s where this team ended up right before their demo:
They completed 28 story points or 72%. A “pointy-haired boss” might look at this team and say “you failed.”
That statement in and of itself is a failure. It jumps to the conclusion that the team experienced a performance failure. In reality (with all credit due to Mary Poppendieck), the more likely failure is that of the original hypothesis: that the team could have completed the work in the first place. There’s a major missed opportunity: the opportunity to learn something from our system and adapt.
We budgeted 25% of our time for these sorts of issues, or 24 hours. We wound up with 46 hours of unexpected requests and impediments, 22 hours “over budget.” We had 15 hours of work remaining on the two stories we didn’t complete, so it’d be pretty reasonable to say that had it not been for those extra 22 hours of work, we would have completed this sprint (and perhaps even added a 1- or 2-point story).
Ideally, you’re keeping track of your velocity from sprint to sprint. Add another metric: keep track of the percentage of task hours each sprint that came from unexpected requests and impediments.
Now we have transparency. Transparency allows inspection, inspection allows adaptation. Here are some ways to use this information to inspect and adapt:
- The team can review the impediments and suggest user stories to the product manager (often spikes or technical user stories) to help address some of the underlying technical impediments.
- The team can use this as feedback that they may need to slow down and refactor to address technical debt. They may not want to create new user stories, but they should at least spend a little extra time on their new user stories to clean up old debt and avoid creating new debt.
- The Product Owner can show stakeholders the cost of unexpected requests and impediments on their predictability. This gives them the evidence they need to hold off on new requests until the next sprint and spend more time building quality into the work that they are doing.
- Engineering managers and program managers can review impediments across teams and look for impediment patterns to solve. For instance, an engineering manager may be able to quantify that the company spends 10-15% of their development time fixing broken environments. This data could justify an much-needed investment: “We lose $1M a year in productivity fixing broken environments [based on salaries multiplied by time lost]. A new VM system would reduce this cost by 50% and cost us $100K.”
There you have it. Regardless of the software you use (if any), you can add the Unexpected Requests and Impediments story to your sprint backlog. You can use the data it generates to gain knowledge and take corrective action.
What are your thoughts? Have you used something like this in your own team? Please share your thoughts!
Photo from Kyle Pearson on flickr
We’ve all been admonished to work harder at some point in our lives, whether it was from a well-meaning parent, a sports coach, or a manager facing a deadline.
What many Agilists have come to empirically observe is that the more we can get people to feel happy and have a good work/life balance, their total productivity goes up. We’ve come to learn that “busyness” is not productivity. I have heard managers brag of how dedicated their teams are because they’re working 100-hour weeks on their latest and greatest innovation. Yet, they seem miss out on the fact that had their teams spent 35–40 hours a week on their latest and greatest innovation, it would be less late and even greater.
So, why do some managers insist upon added stress and arousal? Clearly there must have been a time or place where “cracking the whip” made sense.
Hint: It’s not in highly creative fields like software development.
It turns out that there are some times when it makes sense. According to the Yerkes-Dodson law, an “empirical relationship between [physiological and mental] arousal and performance,” performance increases when arousal does but only up to a point. In some cases, further arousal lowers performance.
For simple tasks, more arousal equals more performance, at least up to a point at which it relatively plateaus. For difficult tasks, more arousal equals more performance, until it reaches a peak and begins to plummet at the rate that it rose. This is because stress negatively affects cognitive processes such as attention, memory, and problem solving, all critical for the modern knowledge worker.
Put another way…
One of the things that I really like about Agile is that it’s all about staying empirical… Transparency benefits inspection, inspection benefits adaptation. And over the years, we’ve come to learn in the business context what many have learned in the psychology and biology contexts.
For instance, a 2007 review of the effects of stress hormones like glucocorticoids found that people’s performance on memory tests and the levels of stress hormones in their blood produced very similar responses to what Yerkes and Dodson found nearly a century earlier. One example: the ability to form long-term memories was highest in the face of small quantity of glucocorticoids were in the bloodstream, but removing the adrenal glands (thus no glucocorticoids) or injected glucocorticoids produced poor long-term memory formations.
Interestingly, this same review found that in order for something to induce a stress response, it has to be perceived as: novel, unpredictable, uncontrollable, and/or possibly leading to social rejection. Naturally, any knowledge worker’s office is likely to be plagued by novelty, unpredictability, and a lack of control (at least from external circumstances like competition).
One of the things Agile teaches is is how to manage these constants well. Rather than stressing out and feeling like we need to “replan” because “things didn’t go the way we planned,” Agile assumes that things won’t go as planned. Uncertainty is embraced. Servant leaders who understand the nature of software development reality deeply understand these things, and so don’t unnecessarily create a culture of fear that produces the sense of a “social evaluative threat” when “the plan isn’t met.” The plan hypothesis was wrong in the first place.
Thus, workers in strong Agile cultures are more productive not only because they aren’t working 80-hour weeks, but also because the whole culture (especially the leadership) is mature enough not to freak out at every single change. These workers experience less stress, therefore they’re producing less stress hormones, and therefore their brain isn’t acting like it’s about to be eaten by a tiger. Keep in mind the tiny amount of time that has elapsed between the constant fear of violent death and the modern 72°F office environment, at least from an evolutionary perspective.
This is your brain on stress.
Truly Agile companies then put A+ talent in environments where they feel autonomy, mastery, and purpose, thus providing strong intrinsic motivation (which does not cause the same sort of stress). A+ talent will not tolerate an environment of mediocrity, fear, or command and control, so any such talent in such an environment exits post haste. This leaves behind giant teams of B and C players who send the company into a tragically-slow death spiral from which few can escape. Further, small teams of A+-level absolutely run circles around giant teams of B- and C-level talent (kudos to Steve Jobs for popularizing this). Many people have never seen this in action.
It’s easy to feel like a hero or a martyr when you’re working those eighty-hour weeks “for a cause.” Managers can tell their employees that they’re not “strong enough” and need to “man up” and put in the hours. But try as we might to ignore them, rarely can we escape the simple facts of our physiology and biology.
Thanks to Wikipedia for illuminating me on the Yerkes-Dodson law, from whose article I borrowed liberally for my own.
I’m not normally a huge fan of white papers, but Rally Software has done something extraordinary with this one. They’ve analyzed the process and performance data for nearly 10,000 teams using the Rally platform to extract some rather interesting findings. While there’s empirical evidence to support many of the prescribed Agile behaviors, Rally’s unique access to performance data as a SaaS process tool provides them with the ability to get an inside look across many different companies and teams.
Here’s Rally’s introduction:
Though people have made Agile recommendations for many years, we have never been able to say how accurate they actually are, or how much impact a particular recommendation might make. [Chris: I disagree as many of these recommendations have been made based on other data and evidence.]
The findings in this document were extracted by looking at non-attributable data from 9,629 teams using Rally’s Agile Application Lifecycle Management (ALM) platform. Rally is in the unique position to mine this wealth of SaaS (cloudbased) data, and uncover metrics-driven insights.
These insights give you real world numbers to make an economic case for getting the resources you need, and your people to commit to change. That’s the underlying motivation of this work.
A few highlights that I’ve copied and pasted:
[T]here is almost a 2:1 difference in throughput between teams that are 95% or more dedicated compared with teams that are 50% or less dedicated.
Stable teams result in up to:
60% better Productivity
40% better Predictability
60% better Responsiveness
Teams doing Full Scrum estimating [both story points and task hours] have 250% better Quality than teams doing no estimating
Teams that aggressively control [work in process]:
• Cut time in process in half
• Have ¼ as many defects
• But have 34% lower Productivity
Small teams (of 1-3 people) have
• 17% lower Quality
• But 17% more Productivity
Than teams of the recommended size (5-9)
While these are the summary findings, the white paper is short and well worth a read. Check it out!
You do not get capacity by attempting to forcefully take it. You get it by gracefully creating it.
Agile is exquisitely simple. Empower people and expect high performance. While it’s no guarantee that they can solve all of your problems, they have a better chance of it than you do.
- Workflow steps
- Defer performance
- Major effort
- Business rule variations
Check out the full flowchart, here. This is an especially useful resource for product managers who are coming from a waterfall environment and are new to writing Agile user stories.
I’ve used relatively standard Agile Retrospective questions to great success over my career:
- What’s one word that best describes this sprint? (one per person)
- What were the positive aspects of this sprint that we’d like to persist?
- What were the deltas we’d like to change?
- How can we change our behavior, process, or definition of done to address the above?
- What actions can we take (with volunteered date commitments from one or more individuals) to address the above?
- And the most important “Big Daddy” that we should ask ourselves constantly… Why? Repeat that one another four times…
While this is a nice base, I’ve been looking for other questions to ask. Here’s several that I liked from Ben Linder’s blog, Sharing My Experience:
- What still puzzles us?
- What helps you to be successful as a team?
- How did you do it?
- Where and when did it go wrong in this sprint?
- What do you expect, from who?
- Which tools or techniques proved to be useful? Which not?
- What is you biggest impediment?
- If you could change 1 thing, what would it be?
- What caused the problems that you had in this sprint?
Here are some nice why examples:
- Why did you do it like this?
- Why did this (or didn’t this) work for you?
- Why do you consider something to be important?
- Why do you feel this way?
- Why did you decide to work together on this?
From Debategraph, I liked “What don’t we know yet?”
Are there other questions you like to ask during retrospectives?
Photo from Magnus D on flickr