|A||Acceptance Criteria/Test, Automation, A/B Testing, Adaptive Planning, Appreciative inquiry|
|B||Backlog, Business Value, Burndown, Big Visible Charts, Behavior Driven Development, Bugs, Build Monkey, Big Design Up Front (BDUF)|
|C||Continuous Integration, Continuous Deployment, Continuous Improvement, Celebration, Capacity Planning, Code Smells, Customer Development, Customer Collaboration, Code Coverage, Cyclomatic Complexity, Cycle Time, Collective Ownership, Cross functional Team, C3 (Complexity, Coverage and Churn), Critical Chain|
|D||Definition of Done (DoD)/Doneness Criteria, Done Done, Daily Scrum, Deliverables, Dojos, Drum Buffer Rope|
|E||Epic, Evolutionary Design, Energized Work, Exploratory Testing|
|F||Flow, Fail-Fast, Feature Teams, Five Whys|
|G||Grooming (Backlog) Meeting, Gemba|
|I||Impediment, Iteration, Inspect and Adapt, Informative Workspace, Information radiator, Immunization test, IKIWISI (I’ll Know It When I See It)|
|K||Kanban, Kaizen, Knowledge Workers|
|L||Last responsible moment, Lead time, Lean Thinking|
|M||Minimum Viable Product (MVP), Minimum Marketable Features, Mock Objects, Mistake Proofing, MOSCOW Priority, Mindfulness, Muda|
|N||Non-functional Requirements, Non-value add|
|O||Onsite customer, Opportunity Backlog, Organizational Transformation, Osmotic Communication|
|P||Pivot, Product Discovery, Product Owner, Pair Programming, Planning Game, Potentially shippable product, Pull-based-planning, Predictability Paradox|
|Q||Quality First, Queuing theory|
|R||Refactoring, Retrospective, Reviews, Release Roadmap, Risk log, Root cause analysis|
|S||Simplicity, Sprint, Story Points, Standup Meeting, Scrum Master, Sprint Backlog, Self-Organized Teams, Story Map, Sashimi, Sustainable pace, Set-based development, Service time, Spike, Stakeholder, Stop-the-line, Sprint Termination, Single Click Deploy, Systems Thinking, Single Minute Setup, Safe Fail Experimentation|
|T||Technical Debt, Test Driven Development, Ten minute build, Theme, Tracer bullet, Task Board, Theory of Constraints, Throughput, Timeboxing, Testing Pyramid, Three-Sixty Review|
|U||User Story, Unit Tests, Ubiquitous Language, User Centered Design|
|V||Velocity, Value Stream Mapping, Vision Statement, Vanity metrics, Voice of the Customer, Visual controls|
|W||Work in Progress (WIP), Whole Team, Working Software, War Room, Waste Elimination|
|Y||YAGNI (You Aren’t Gonna Need It)|
|Z||Zero Downtime Deployment, Zen Mind|
In today’s complex and dynamic environment, where companies are mercilessly eliminating waste and optimizing their processes to lower costs and improve operational efficiency, the term “slack” conjures up a host of negative perceptions.
Time and again, we run into companies that focus way too much on capacity utilization and ignore turn-around time and throughput. I’ve worked for companies who would hire more people, so work can be parallelized and done faster. But when that does not happen, they create work to keep everyone busy. Work expands to fill the available time and to keep everyone perpetually occupied.
Over and over again, we see companies batching work into large chunks, introducing all kinds of specialization, fancy workflows, layers of indirection and integrations in the name of better efficiencies. They might get better output, but are they achieving better outcomes?
Efficiency is the enemy of Effectiveness – Tom DeMarco, Slack
Let me share a story about Slack:
Yesterday I was invited to share my experience on “Enterprise Agile Adoption” to the entire Sr. Management @ big fortune 500 company.
During my talk, I describe my job at a company, which adopted Agile across the board. I said:
My job was to do nothing! I was not leading any team. The founder of the company (who hired me) did not set any targets or goals for me to chase. Basically I was there to do nothing.
People in the room, started laughing accusing the founder to be stupid and naive.
Don’t jump the gun yet. I discovered something magical.
Since I was not running around like a headless chicken, more people would stop by to have an informal chat. Like the one you have at a water-cooler or a coffee machine (think of serendipity & its implications on creativity for knowledge workers.) Many times we would end up in a spontaneous discussion/debate, shaping each other’s perspectives. Some times people would come to me with a specific questions/issues. Some times they would ask me to lend an ear for their rants. At times, when they were completely swamped, they would ask me to roll-up my sleeves and help.
Because I was not as smart as most of those guys, I would simply connect them with someone else in the company who could help. We also did a lot of random events to ignite their thirst for learning.
All of this led to a great bonding with the teams. In some sense, I was playing the role of a connector. I won their trust. And soon, in a couple of months, I was the go-to person (at least start-with person) in the company.
Team members would compliment me saying:
Many deep-routed, hard organizational problems are being silently solved without anyone making a bid deal about it.
Which I thought was profound. And frankly I never felt this kind of satisfaction or sense of accomplishment before. This was by far, one of the best Agile transformations I’ve experienced.
Let’s step back and see what was going on there?
By bringing me in and not assigning me to any specific tasks, the founder introduced Slack into the organization. (I don’t think it was all planned, but the end result far exceeded our expectations.)
I experienced both kinds of slack:
- Time Slack – Since I didn’t commit to a task list nor was I being measure on how occupied I was (busy-ness metrics), I had a lot of flexibility. I had extra cycles, over and above the time required to finish the current work at hand. Which allowed me to be creative, experiment with new ideas, learn new stuff, adapt to changing priorities and be available to help anyone at a very short notice. Sounds like your grandmother’s advice “Work smarter not harder!”
- Control Slack – I wasn’t running to the founder for every little thing. I could take many decisions on my own. I even had a flexi-budget to invest/spend on things. In general, the company’s culture was very flat. Employees would make a lot of on-field decision. The company had a very decentralized decision making approach which lead to quick turn-around on issues. People were free to choose which projects to work on. It was perfectly fine to make some mistakes while learning new skills or attempting new projects. They massively leveraged the knowledge of people on ground to make well informed decisions. Even if the decisions were wrong, it took a small amount of time to fix them. Things would just happen at this company.
Exciting right? Slack sounds like common-sense right?
But for many years, there has been an ongoing debate among organizational researchers on the role slack plays in organizational adaptation (Bourgeois, 1981). Some argue that slack provides resources for innovation and change, thereby enhancing a firm’s ability to adapt to environmental shifts and improve long-term performance (Cyert & March 1963; Carter 1971; Mohr, 1969). Others argue that slack is an analog for inefficiency – a buffer which shields the firm and, in some cases, blinds it from changes which are needed to meet external demands (Litschert & Bonham, 1978; Thompson, 1967; Yasai-Ardekani, 1986; Williamson, 1963; Liebenstein, 1969; Migué and Belanger, 1974).
Nohria & Gulati (1997) took an intermediate position and argued that there may be an optimal amount of organizational slack because limited slack inhibits innovation by discouraging any experimentation whose success is uncertain while an abundance of slack also may inhibits slack by fostering complacency and lax controls.
Based on my experience with organizations, which rely on knowledge workers, I tend to agree with Nohria and Gulati. You can think of slack like a rubber band. A rubber band works best when it’s tight but not too much tension, and it doesn’t work at all when there’s absolutely no tension.
For example, 3M is legendary for providing it’s scientists with semi-structured time to work on their own projects of interest.
Google encourages its engineers to spend 20% of their time on projects that interest them, and the VP of Search Products and User Experience found that 50% of new product launches originated from the 20% time. Notable products from time off include Gmail and Google News.
I would strongly recommend reading Tom DeMarco’s book- Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.
In his book, Tom DeMarco compares slack to an open space in an 8-tile puzzle.
Organizations without the slack, are like a 9-tile puzzle with no open space. The result is highly efficient, but change becomes impossible: People are just too busy with operational work to think about the future.
eXtreme Programming has a practice called Sustainable pace. But unfortunately this practice is often forgotten or companies struggle to put it in practice. The idea is that productivity does not increase with hours worked. Tired programmers are less productive than well-rested ones.
Tom suggests that businesses that build in sensible amounts of time and control slack enjoy four specific competitive advantages:
- Better responsiveness.
- Enhanced flexibility.
- Greater retention of key people.
- An enhanced capacity to invest in itself
Kanban seems to be a good starting point to adopt Lean thinking on a team. Of course Kanban alone is not sufficient to become lean. You need to Trust & Respect team members and you need concepts like Single Minute setup, Mistake-proofing, Zero Inspection, Kaizen, etc. Kanban to me is a great manifestation of Queuing Theory and to some extent Theory of Constraints.
Jeff Patton wrote a great intro to Kanban.
Of late I’m hearing a lot about Kanban and its application to software development. IMHO Kanban is nothing new. If you look at a lot of “traditional” maintenance and support teams they’ve been using Kanban for ages.
Back in 2004 when I was leading an offshore maintenance project without knowing anything about Lean or kanban, we really evolved to using a pull-system (Kanban) on our team. That was the only logically way we could work. Of course we started off with Iterations and Releases and so on. But we quickly implemented a simplified Kanban on our team.