No, not people, people aren’t resources, they’re people. I’m talking about our favorite books, websites, and blogs related to agile. Read on and feel free to recommend additional sources in the comments.
Author Archive: Peter Green
My first post on this book (read it here if you haven’t already) generated quite a bit of feedback & social media activity, and one comment by friend and agile coach Rob Myers (@agilecoach) really stuck out for me:
These align nicely with Dan Pink’s autonomy (decentralized control), mastery (technical competence), and purpose (clarity of the mission). Thanks for the excellent analysis! I’ll be sharing this.
The funny thing is, I’ve probably watched the RSAnimate video of Dan Pink(@DanielPink – check it out below – well worth the time) more than 100 times since I often show it in training classes, and I’ve read the book (Drive) twice. I’m a big fan of Dan’s podcast (Office Hours) and his other books, and I still didn’t make that link! Thanks to Rob for connecting the dots for me between Turn the Ship Around (experience) and Drive (behavioral economics/neuroscience).
Here’s the Dan Pink Ted talk animated, just in case you haven’t seen it yet!
I recently finished reading former U.S. Navy Submarine Commander David Marquet’s book “Turn the Ship Around”. It is a powerful story of learning what leadership means and the struggles Marquet had putting it into place in his role as commander of the Los Angeles-class fast attack submarine USS Santa Fe (SSN 763). Marquet proposes that Leadership should be defined as:
“Embedding the capacity for greatness in the people and practices of an organization, and decoupling it from the personality of the leader”.
The paradox is that more traditional leadership creates more unthinking followership; less top-down leadership creates more engaged leadership – at every level of an organization.
Leadership and productivity guru Stephen Covey took a tour of Marquet’s submarine in 2000, a couple of years into Marquet’s command, and reported that it was the most empowered organization he’d ever experienced, of any type, and wrote more about it in his book “The 8th Habit”.
The hyper-quick summary of Marquet’s approach involves three pillars: Control, Competence, and Clarity. These form the basis for what he calls “Leader-Leader” behavior, as opposed to the much more common “Leader-Follower” culture found in most organizations.
Marquet talks about shifting the psychological ownership of problems and solutions using a simple change in language. I’ll attempt to illustrate the evolution of leadership behavior through a series of conversations:
Traditional leader-follower pattern:
Captain: “Submerge the ship”
Subordinate: “Submerge the ship, aye”
To push Control down in the organization, Marquet began using the following speech pattern:
Captain: “What do you think we should do?”
Subordinate: “I think we should submerge the ship, sir”
Captain: “Then tell me you intend to do that”
Subordinate: “Captain, I intend to submerge the ship”
Captain: “Very well”
Giving control without an assurance of competence could lead to disaster on a nuclear submarine, and so over time, the pattern evolved to include an assurance of technical Competence, becoming:
Subordinate: “Captain, I intend to submerge the ship.”
Captain: “What do you think I’m concerned about?”
Subordinate: “You’re probably concerned about whether it’s safe to do so”
Captain: “Then convince me it’s safe”
Subordinate: “Captain, I intend to submerge the ship. All crew are below decks, the hatches are shut, the ship is rigged for dive, and we’ve checked the bottom depth.”
Captain: “Very Well”
The final evolution of the language added the third pillar – Clarity of mission, becoming:
Subordinate: “Captain, I intend to submerge the ship. All crew are below decks, the hatches are shut, the ship is rigged for dive, and we’ve checked the bottom depth.”
Captain: “Is it the right thing to do?”
Subordinate: “Yes sir, our mission requires that we submerge now in order to (classified reason (-: ) ”
Captain: “Very Well”
The book is highly engaging and I found it to be a fascinating model of leadership extremely well-tuned to the needs of leading complex organizations in the knowledge work era.
So, what does this have to do with Agile?
Empowerment is a core concept of agility, and specifically the scrum framework, but it is something that can be a major challenge to get working well in organizations without decentralized control, insurance of competency, and clarity of mission. Marquet’s approach provides a simple pattern to follow in empowering teams.
Interestingly, empowerment is a term that Marquet dislikes, since it implies that individuals can only be “powerful” once it has been granted by a leader. His claim, and one that I agree with, is that all human beings are naturally powerful, they don’t need to be “empowered”. Rather, leaders simply need to remove cultural norms and processes that are meant to exert control, resulting in people tuning out and becoming disengaged. When the right leadership behaviors are in place, people will naturally bring their whole selves to their jobs. From a lean standpoint, such controls can be viewed as creating waste – people that show up and go through the motions, rather than devoting their creativity and energy to their jobs, and the lean leader’s job is to remove waste from the system.
Empowered Product Owners & Teams
Scrum is fundamentally based on the idea that a Product Owner is the single accountable person for setting the priorities of the team(s). Leaders can ensure that Product Owners have this accountability by using the “Intend To” language.
Product Owner: VP, I intend to move this new feature to the top of the Product Backlog and deprioritize this other feature that was in our original plan. Customer validation tests indicate that the new feature would increase retention of existing users by around 4%, more than any other feature we’ve tested, aligning with our highest priority goal for this quarter of increasing existing subscriber retention rates. The team has done some high level scoping and forecast that this feature would be completed within two sprints, a similar size to the feature that we’ll be cutting.
VP: Very Well
The leader gets what they really want: an assurance that the Product Owner is aware of the business concerns and have done their due diligence to address those concerns. The Product Owner gets what they want – mentoring to understand what business leaders are most concerned about (a great career development aspect of this approach), with the autonomy to meet the business need however they see fit.
Agile Leadership is the missing link for many organizations
Agile has had a major impact on some organization’s capability to balance delighting customers, keeping people engaged at work, and delivering great business results. It has, however, struggled to make an impact in many organizations where Cargo Cult Scrum, “scrum-but” and other half-hearted implementations of agile are the norm. The difference is in the leadership of these organizations. Where agile is seen as the latest trend, something the developers do, or a bandaid to fix some specific annoyance, agile will have a marginal (if sometimes still improved) result. Where agile is viewed as a mindset for both teams and leaders, it can have a profound impact. Marquet’s book provides some simple rules that leaders can apply to start seeing that bigger impact of agile at the organizational level.
Check out the animated talk on this topic by Marquet:
You can find his book and other info on his site: http://davidmarquet.com/
Check out part 2 of this post to learn more about the link between Marquet’s approach and Dan Pink’s “Drive”.
This article by angel investor and advisor Jocelyn Goldfein is one of the more honest looks at the challenges and opportunities for innovation in large companies that I’ve seen.
Recently I’ve been hearing people use the term technical debt to describe all sorts of things that are related to system improvement. However, used properly, technical debt is not a catch-all phrase for system improvement work, but a subset of that work.
What is Technical Debt?
Ward Cunningham first described technical debt in an experience report in 1992:
“Shipping first time code is like going into debt. A little debt speeds development so long as it is paid back promptly with a rewrite… The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code counts as interest on that debt. Entire engineering organizations can be brought to a stand-still under the debt load of an unconsolidated implementation, object-oriented or otherwise.”
To better understand technical debt, let’s explore the analogy to financial debt.
Four out of five people buying a home in the United States in 2013 took out a mortgage to do so. For the most common type of mortgage (30 year fixed with 20% down) on the average home price in the U.S. (~$200k), the total cost of the loan is 175% of the cost of just buying it outright. That’s right, for a $200,000 house, you’d pay about $350,000 over the life of the loan, or $150,000 just in interest. Why would anyone do that? Of course the answer is simple – it might take you years to accumulate the cash before you could own a home, so people make a decision to accumulate debt in order to get the home sooner, knowing full well that they’ll need to pay more in the long run for that early entry. They are trading an advantage (early entry) for a disadvantage (higher total cost).
Technical debt, then, is the conscious choice to get to market faster by skipping some steps required for long term code sustainability. Just like financial debt, we know that in the long term it is more expensive (we’ll need to pay interest on top of the principle), but we do it because the advantage of getting to market sooner outweighs that cost. And just like financial debt, we need to create a budget for paying it back down.
Are All Bugs Technical Debt?
Let’s use three of example defects to answer this question.
- Defect A is an error that was reported by a customer a few months after a release. It happens when a specific workflow is followed that the team didn’t anticipate, and causes the program to freeze. The team was using good automated testing, but we didn’t catch this one due to the unusual customer workflow.
- Defect B is an error that was discovered in a regression test, and was determined to not be a “release-blocking” bug – in other words, we knew about it but decided to release anyway. Now customers are complaining about the bug and the team decides to go ahead and fix it.
- Defect C is a display problem that happens on a new version of a browser that was released after our software was released. It didn’t occur in previous versions of the browser.
In this example, only Defect B is technical debt, Defects A and C are not because the business never made a conscious choice to ship with those defects. In any moderately full featured software product, the level of complexity involved results in some defects making it through to customers. Some of those may have been known prior to shipping and others weren’t. If we didn’t consciously choose to release with the bug, or were consciously skipping some defect prevention steps in order to get out the door sooner, these are just defects, not technical debt.
Is Refactoring Technical Debt Reduction?
As in the case of defects, it all depends on whether we were making conscious trade-offs on architectural and design approaches in order to release sooner. If we know that there is an area of the code that is a mine field, and no one wants to touch it (except for that one coder that’s an expert), but we chose not to refactor due to the amount of time & effort involved, then we have technical debt. If, on the other hand, new code has been added, the system is becoming more complex, and we just need to do some refactoring as part of the standard craft of software development, that type of refactoring is not reducing technical debt, it is simply the good practice of continuous system improvement. Think of it as entropy reduction, not technical debt reduction.
Lack of robust test automation is probably one of the most common instances of technical debt. In the craft of software development, using automated tests is equivalent to a surgeon counting the sponges prior to a surgery to make sure we don’t leave anything in the body of the patient. If we’re not doing it, we are really being irresponsible. Now, I’m not stating that we need 100% code coverage for unit tests, or 100% functional coverage for automated regression tests – there is a point of diminishing returns. Again, it comes down to a case of intention – do we want much better coverage but just don’t have time to do it? If we don’t have time, that is just another way of saying it is not as high a priority as shipping the feature. In other words, we are consciously choosing to get to market faster by skipping automation that the team thinks would be helpful. In such a case, we are creating technical debt.
Technical Debt reduction is one important category of system improvement. To lump all system improvement under the banner of technical debt does us a disservice because it seems to imply that any problems or inefficiencies in the code were just a conscious choice by the team. That is not the case. Sometimes we make decisions to ship a less than optimal product in order to get earlier feedback or a market advantage. Even if we aren’t doing that, there will be ongoing improvement required. Separating out Technical Debt as a specific category helps us acknowledge the prioritization decisions we’re making regarding quality vs. speed, and watering that term down by lumping it together with everything else muddies the waters and can lead to disengagement by the team that didn’t “get it right the first time”, an impossible task in a complex domain.
It is critical that Technical Debt be paid down as soon as possible. It follows the rules of compound interest – the longer we wait to pay it off the more it accrues, and if it’s not paid off in time, eventually it leads to a bankrupt code base. It simply needs to be abandoned and started over from scratch, an extremely costly result. Clarifying when we are making a conscious choice to accumulate technical debt needs to have a payment plan associated with it to avoid these risks. Lumping ongoing system improvement into that category makes the payment plan much more difficult to plan for.
A new meta-analysis of 88 recent studies shows that the famous 10,000 hour rule (see the original study by Ericsson or the popularized version told by Gladwell) for mastery accounts for only a small percentage of variance in expert level performance. Other factors that seem to be at least as important: intrinsic talent, how early in life one is introduced to the area, and, perhaps the most important factor, how much the individual enjoys the activity.
So, to put this in context, the most likely path to mastery of some topic in life is to explore many different things at an early age, find one that is really enjoyable and that you have some talent at (in other words, you find it much easier than many of your peers do), and then focus on it. You’ll be naturally motivated to spend the 10,000 hour figure, making that figure a result of the real root cause – enjoyment.
Bob wanted to chat. “We can’t seem to make this work”, he said. “I just don’t think scrum works for a team like ours.”
I had provided scrum training and a bit of coaching for his team a few months back to get them going. Their story was pretty common – they had been using kind of an ad hoc, waterfall style process. They weren’t very strict about it, but the traditional phases were all there – Product Managers writing requirements documents, the team building out the requirements, a few months of testing, then release. They had heard about scrum and how other teams had really liked it and after the training, they were pumped up about how it could be a much better process for them.
Now things seemed to be falling apart. The team was cheating on the definition of done to get features into the demo by the end of the sprint. “We’ve got to meet our commitments!” they stated. The daily scrums seemed more about rote reporting to the engineering manager, who was also the scrum master. Product Managers were regularly adding “emergency requirements” in the middle of sprints. Retrospectives had quickly devolved into a disengaged, repetitive finger-pointing session focused on what went wrong in the last sprint.
I handed Bob a copy of the book “Tribal Leadership” and asked him to read it and see if it gave him any insight into solving his problems.
“Is Tribal Leadership an agile book?”, Bob asked.
“Not exactly, but I think it will help your team be more agile”, I replied.
While our first inclination may be to jump in and fix each of these problems, I’ve learned that the problem probably is not about the team or about the process. In short, Scrum and other agile approaches are patterns of a Tribal Stage 4 and 5 culture, and if you’re working in a Tribal Stage 2 or 3, you’re going to struggle to make it work. Hit the break for more about cultural stages and some ideas for how to move the needle.
In Scrum Training courses, we do a scrum simulation that is pretty fun. Early on in the simulation, teams need to do sprint planning. If you’re familiar with scrum, you’ll know that the primary purpose of the Sprint Planning Meeting is for the team to arrive at a commitment to delivering a Sprint Goal and/or a set of Product Backlog Items during the Sprint. In the simulation, I push the teams pretty hard as far as the amount of time they get to do sprint planning. They usually have not quite enough time to really think through the plan, but I push them to make a commitment anyway. Under this pressure, most teams will smile and make a commitment to a plan in which they’re not very confident. This pattern of commitment with low confidence is a persistent challenge with many of the teams that I work with.
To help highlight this pattern of commitment without confidence, I use a facilitation technique called “Fist of Five”. As soon as the team has their commitment and I’ve looked around the table asking if everyone agrees (typically with everyone nodding, and often with at least one person’s body language screaming “no way” while they nod their head), I’ll ask them to think for a moment about their own personal confidence that the team will meet its commitment. I ask them to think of how confident they are on a scale of one to five, with one meaning not confident at all, and five meaning completely confident that barring some highly unusual circumstance, the team will meet the goal.
I tell them that once they’ve got their one to five number in mind, to simply put their fist in the air without revealing their vote, indicating that they’re ready. When all of the fists are in the air, I ask hem to reveal their votes together on the count of three. It’s always a revealing moment when some people who had passively nodded their heads to the team’s commitment hold up a two or three (or even a one). I then ask anyone with lower than a four to share their concerns about meeting the commitment. Often this results in a quick change to either the plan or the commitment itself to address the concerns of those that were not at a four or five. With the modified plan, we’ll re-vote until everyone is at a four or five.
I’ve found this facilitation technique to be useful in many situations where there might be tacit agreement to a plan without true confidence. I’ve used it in sprint planning meetings, release planning sessions, and even family discussions where we’re deciding what to do.
One of the biggest challenges for teams that are new to an agile approach is the change from what we call horizontal splitting to a “vertical slice” approach. Teams often aren’t used to thinking about problem decomposition this way, and I’ll hear comments like “well, our system is too complex”, or “we need to build really big features or our users won’t get what they need”. I always tell people that in the eight years I’ve been using this approach with hundreds of teams, I’ve only been stumped once to where we just couldn’t figure out how to slice something small enough to fit into a two week sprint. Well, we could have split it, but it didn’t add any value.
Below I’ll give a quick overview of why we prefer this approach and four simple strategies for splitting stories into small slices.