Compensation Strategies for Agile Teams
Last Updated on Wednesday, 16 April 2014 02:16 Written by Mike Cottmeyer Monday, 3 March 2014 09:17
I don’t consider myself an expert on designing compensation systems, but as of late this issue has come up with several clients, and of course, I have to deal with compensation issues leading LeadingAgile. I’d like to share some thoughts with you guys, get some feedback, and maybe even generate a little healthy debate.
The key challenges around compensation, at least for me, center around figuring out how to reward individual performance without encouraging internal competition, local optimization, or one person feeling rewarded while another feels punished. You want compensation to motivate people, not to have a negative impact on performance.
Ever since I read Dan Pink’s Drive I’ve been very aware of the distinction between intrinsic and extrinsic motivation. While you’d like everyone intrinsically motivated… the realities of having a mortgage, consumer debt, household expenses, kids that need to go to college, or even saving for retirement drive different extrinsic needs.
Some folks want to come to work, do a great job, and go home. Some folks want to go the extra mile and really make a difference. Some poeople really want to kill it, advance their career, and be rewarded for all that hard work. Just saying that everyone should get a fair base salary, with no performance based component, isn’t going to work for some people.
So the question becomes, is it possible to use money or other rewards to recognize performance without introducing the negative side effects? Can we build a compensation system that values collaboration without creating internal competition, local optimizations, or risks leaving one person feeling punished because they didn’t get as much as their peer?
Here is what we are doing with LeadingAgile…
First, we have all our coaches is a pretty narrow salary range and we are working to narrow that range even further. When we started hiring a few years ago, I was pretty risk adverse and you really had to be a true believer to come work for me. As we grew, salaries increased and we are making things right for the people that joined us early.
As a quick aside, I want to be able to justify numbers if we ever decided to publish salaries internally. For the record, I am totally open to full transparency and think it’s a good idea. Some folks aren’t so keen on the idea, so we are respecting that for now. It does influence decision making around salaries when everything might be out in the open some day.
We believe that baseline performance is binary, you are good enough to be on the team or you aren’t. We are starting to get more explicit about what it means to be good enough to be on the team, but if we hire someone, we have very high confidence they can work in our model and be successful. Occasionally something will come up after the fact, but that has been rare.
If you are good enough to be on the team, you share in the team’s success. For us, that means a 20% bonus on top of your salary. Everyone will get the bonus or no one will get the bonus. We are toying with quarterly payouts but for now, it’s annual. The idea is that if the company is successful, we want to share that success with everyone.
Success for the time being is defined as 75% utilization. We’ve debated setting the target a little lower and we’ve discussed a sliding scale. There is a ton the utilization implies about our ability to market, sell, deliver services, and manage cash… so it’s not just about revenue. That said, revenue is what drives our ability to get people paid.
Does this fall into the category of an extrinsic motivator that might actually demotivate people? Maybe. But how else would you share financial success when things are going well? If we just added that 20% to each salary, my cost structure would be too high should we underperform financially. I’d have to let people go in a slump and that’s not the goal!
We are intentionally falling on the side of keeping our cost structure in check and rewarding the team if we are able to perform at a high level. We are building the infrastructure to help the team support marketing and sales, educating folks on how to manage engagements, and really encouraging people to pay attention when we have unexpected downtime.
I’m hoping that by taking a whole team approach, keeping everything visible, and empowering everyone to influence the goal we’ve been able to strike the right balance. Time will tell.
That said, we still haven’t addressed how to compensate the people that really want to kill it. Those consultants that want to help market and sell, grow the practice, lead multiple accounts, and create sustainable economic value for the company. If someone is able to create that kind of value, I need to reward them or they’ll leave our company and start their own.
We are looking at introducing a variable component to our salary structure based on several other metrics we think might be relevant: overall financial contribution based on sales and marketing activity, the ability to keep yourself busy on one or more accounts, willingness to grow and develop professionally, customer feedback and peer feedback.
The idea is that for an individual component to pay, the team would have had to meet its overall goals. No local optimizations. Any compensation model over and above base salary and team based goals would have to meet certain design criteria to make sure it adequately rewards individual performance but doesn’t feel punitive to those that don’t make it.
It has to be inclusive… anything that one person is able to do, everyone is able to do. There can’t be some named subset of people able to participate in the plan.
It has to be based on abundance … everyone is able to be at the top every time. We want to build a system that assumes everyone has the ability to be a top performer.
It has to be transparent… whatever we choose to measure will be tracked openly so you can see where you are relative to your peers at all times. The measures and goals have to be clear and attainable.
It has to be cooperative… there cannot be any penalty for working together to achieve a goal. If two people work on a goal together, the reward has to be as much or greater than working on it individually.
It has to be sustainable… we will only ever reward sustainable growth. Creating incentives that encourage people to only look out for short term economic outcomes won’t help the company grow.
My hypothesis is that if we can fairly compensate people by way of base salary, give everyone something extra if we hit our financial targets, and create an inclusive, abundant, transparent, cooperative, and sustainable model for paying one person more than another… we might have a shot of making it work and allowing folks to meet their individual financial goals.
If an employee receives a fair salary, is compensated when the company does well, but decides not to participate in the broader plan… they may not like that they didn’t get anything extra, but at least they’d understand why and know what needed to happen in order to participate in the future. If your good enough to be on the team, that door is always open.
Okay… so what do you think? Is it fair or a slippery slope? What could we do differently? I realize we are a services company, but could these ideas work in a traditional software company? Would a model like this work for an agile team? An agile enterprise? If it would work, what kinds of measures might we consider for software developers and other team members?Learn More
Managing Risk and Uncertainty in Agile
Last Updated on Wednesday, 26 March 2014 09:42 Written by Mike Cottmeyer Wednesday, 26 February 2014 10:13
Okay… let’s set a little context here. In my last post we talked about two different types of projects. The ones that are knowable and the ones that aren’t knowable. Projects where it makes sense to estimate and projects that are more like R&D investments where we are spending money to learn and discover. Today, I want to talk more about the first kind. The ones where we do have some idea of what we are building and the technical challenges that might be involved.
Getting clarity on what we are going to build and how we are going to build it isn’t easy. This is especially true when we have multiple competing stakeholders, no clear way to resolve priority conflicts, more to do than we can possibly get done, and the technology while understandable, certainly isn’t trivial. In the face of this kind of ambiguity, I think that many of us have thrown up our hands and concluded that software isn’t estimateable and everything should be treated like R&D.
I think this is a mistake. If we keep pushing to treat everything like R&D, without understanding the delivery context we’re working within, the whole agile movement risks loosing credibility with our executives. If you remember from our earlier conversations, most companies have predictive-convergent business models. We may want them to be adaptive-emergent, but they aren’t there yet. We’ll can talk about how to move these folks, but for now we have to figure out how to commit.
Back in the day when I was just learning about agile, and immersed in the early thinking of Kent Beck, Alistair Cockburn, Mary Poppendieck, and Ken Schwaber… I came across this idea that the team had to commit to a goal or an increment of the product at the end of the iteration. There were some preconditions of course, the story had to be clear and understandable, we needed to have access to an onsite customer, and the team had to have everything it needed to deliver.
If the story wasn’t clear and understandable, there was this idea of a spike. I’ve always understood a spike to be some snippet of product we’d build to go learn something about what we wanted to do or how we were going to do it. This idea has expanded some over the past few years to include any work we bring into the sprint to do discovery or learn something we didn’t know before. It’s basically an investment the product owner makes to get clarity into the backlog.
Like most of you guys I’m sure, my planning approach was heavily influenced by Mike Cohn’s Agile Estimating and Planning book. Mike turned me on to Bill Wake’s INVEST model and I’ve used that as a tool for understanding and teaching good user stories ever since. The longer I use the INVEST model the more profound I think it is, but as widely accepted as this idea seems to be, I think there are a few under-appreciated letters in the model. The one most relevant to this discussion is the ‘E’.
E is for Estimateable
The idea behind INVEST is that these six attributes of a user story set the preconditions the Product Owner must meet before the story can be brought to the team. If they are not INVEST ready, they get deferred and we schedule a spike. The idea behind the ‘E’ specifically is that the user story must be well enough understood by the team that they know how to build it. The team has to be able to break down the user story enough to put detailed estimates on the tasks and be willing to commit.
Remember when I said that almost every disfunction on an agile team tracks back to the backlog? We’ll here is the problem… most teams are accepting user stories into sprints that are not INVEST ready and are certainly not estimateable. If the team doesn’t have enough information to make a commitment they shouldn’t make a commitment. So… do we conclude from this that software isn’t estimateable or do we conclude that we collectively do a poor job backlog grooming.
Because most of us work in dysfunctional organizations that don’t manage a roadmap, don’t stick to their vision, thrash around at the executive level, and generally can’t make up their mind… many of us have come to the conclusion that creating a backlog is waste. Why spend all that time writing up user stories when things are going to constantly change? This is indeed a problem, but giving up on planning is not the answer. Making up your backlog as you go isn’t the answer either.
When we make up the backlog as we go, everything the team encounters is going to be new to them. Everything they do is going to require a spike. The whole notion of Sprint Planning and Release Planning is predicated on the notion that we generally know the size of the backlog, we learn the velocity of the team, and based on those two variables we can begin to predict when we’ll be able to get done. If everything requires a spike, the backlog is unstable and indeterminate.
For every user story we attempt to build, we create at least one spike, and probably two to three more user stories. Even if we have a stable velocity, the scope of the release is increasing faster than we can burn down the backlog. We never end up with stable view of what’s happening on the project. The team feels like it’s thrashing, the product owner feels like their thrashing, and the organization gets frustrated because the product isn’t getting out the door.
Dealing with Backlog Uncertainty
To solve this problem… to get better at making and meeting commitments… even at just the sprint level… we have to plan a sprint or two ahead of the increment we intend to commit. That means if we want to get better at nailing sprint commitments, we need to have backlog properly groomed BEFORE the sprint planning meeting. If there is spike work to be done, that needs to be identified and done BEFORE the sprint where the user story is going to be built.
The implication here is that the team (in any given sprint) is going to have some capacity allocated toward the work of the sprint and some capacity reserved for preparing for the upcoming sprints. This could be as simple as having a meeting or two every sprint to help the PO groom the backlog, do look ahead on the backlog, to ask questions and to give guidance. Sometimes it’s more ad-hoc and sometimes it’s more formal. Some teams track this work, some just allow it to lower velocity.
Either way, allowing some slice of capacity for preparing for the upcoming sprints is an essential element to begin stabilizing delivery, agree? If you are with me so far… I’d suggest that stabilizing a release follows the same rules we just applied for stabilizing sprints. Don’t commit to anything in a release that the team doesn’t understand or know how to build. If there is a ton of risk and uncertainty coming out of release planning, Scrum isn’t going to necessarily help us delivery reliably against the release objectives.
So how do we get this level of clarity on the release level backlog? If we apply the same concept at the release level we applied at the sprint level, we’d have to suggest that the team has to do spike work BEFORE they get to the release planning event. That means that we need to have some idea of what’s in the upcoming release, and the unknowns associated with that release, BEFORE the current release is even done. If we are doing 3 month releases, I’m looking for high-level planning somewhere between 3 to 6 months out.
That’s NOT Agile!?
And here is what I’ll inevitably get when I make this point with some folks. Hey Mike… that’s not agile!? That sounds like Waterfall. You’re suggesting that I have to plan 3 to 6 months out, at the detailed user story level, in order to stabilize delivery and make and meet commitments at the release level? Just to be clear, that is EXACTLY what I am saying. And that begs the question… what is agile? What exactly does it mean to be agile at the corporate level.
In the context of a predictive-convergent company, one that is doing projects that are not R&D, where it is reasonable to understand requirements, and the technology is not totally unknowable… yes, it is perfectly reasonable and advisable to start looking at your backlog 3 to 6 months in advance. Maybe not at the finest level of granularity, but we need enough understanding of what we are going to build, and how we are going to build it, to sufficiently groom the backlog and mitigate risk.
Corporate agility comes not from the practices of Scrum, or from making your backlog up as you go, but from creating the ability to change your mind as you learn new information. If I plan ahead, sure I may create some waste and incur some carrying cost due to a longer backlog, but because I am building complete features in short time-boxes, and working toward potentially shippable code every two weeks, I make it easier to change direction. Some level of forward planning is the cost of making and meeting commitments.
I’d go so far as to say that in a larger organization, changing your mind every two weeks is the equivalent of thrashing.
Most companies need to be able to change their mind every quarter, some only every six months. Most do not need the ability to change their mind every day. In this case, if we can stabilize the roadmap, get some basic governance, apply some Lean/Kanban based program and portfolio management, and disciplined release management… you can get a stable well groomed risk adjusted backlog. And it is possible to estimate and make and meet commitments.
We do it with our clients all the time.
Building My House With Agile?
And this is why I told you the story about building my house. I think the metaphor holds well in companies that are trying to deliver in the predictive-convergent problem space.
1. We routinely recommend a 12-18 month roadmap level plan. Initiatives are broken into 2-3 month increments that can ideally be delivered within a single release. The roadmap isn’t just about business goals, it also has architectural guidance and maybe even high level UX. It’s enough to understand what we know and what we don’t know and provide budgetary estimates that should be close enough to reality such that they establish reasonable constraints. This is analogous to the time I spent with the builder coming up with the architectural design, feature list, and budgetary estimates for my home.
2. We routinely recommend a 3-6 month feature level plan. This helps us get clarity around what we can actually build in the current release and what’s coming in the next release so we can start grooming the backlog and mitigating risk. For me, there is no hard rule for a feature level breakdown. Of course I’d like the features to be smaller than the roadmap level initiatives, but they are going to be much bigger than user stories. I like to allow them to span sprints so somewhere around 2-4 weeks seems right to me. Having this view is analogous to a construction schedule that lays out the foundations, walls, roof, landscaping etc and puts the key dates on a calendar. We still haven’t made all the fine grained decisions, but the project is starting to come into focus.
3. We routinely recommend a 3 month rolling backlog of fine grained user stories. I’m not saying that the user stories have to be 100% sprint ready, but they should be risk mitigated and pretty darn small. Definitely smaller than a sprint and confined to a single team. They should have a clear definition of done and some acceptance criteria, but as we learn, we may split them up more hopefully finding ways to leave stuff out and focus on just the minimally marketable part of the requirement. This is analogous in my house building example to picking carpet color, paint color, the exact kind of hardwood and tile, and the placement of the bushes in the front yard.
Context, Context, Context
If we are building stuff that is unknowable… sure let’s not plan or estimate or commit to anything. But let’s also be clear with our stakeholders what they are investing in. They are putting significant dollars at risk hoping to find a solution to a problem that may or may not exist. That is a perfectly valid way to spend money and allocate investment as long as we are all in agreement that is what we are doing. If the stakeholders think they’ve got a guarantee, that is a problem.
If we are building stuff that is knowable… we need to have a plan for road-mapping the product, progressively breaking things down into smaller and smaller pieces, mitigating risk, planning forward, establish velocity, collaborating to converge on desired outcomes, making tradeoffs, communicating progress and reporting status. It’s not that things will never change, and maybe even our high level planning is off, or maybe we see a risk we didn’t anticipate, but at least we have a baseline to communicate how what we learned may impact the project.
If we are building stuff that is knowable… but we don’t have the organizational structure, governance, metrics, discipline, prioritization, or whatever… and it just FEELS like the work is unknowable… putting these projects in the unknowable category diminishes our credibility. Executives know this stuff is knowable. You’d be better off calling out the stuff that is broken in the organization and working with the organization to fix it. Scrum calls these organization impediments. Remove them.
In my opinion, regardless if you are a consultant or an internal employee, people appreciate a thoughtful consideration of their particular context and a willingness to adapt your point of a view to help them solve the problems they are really trying to solve. We started this thread with the notion that many in the agile community are solving the wrong problem. Even if it’s the right problem, it’s not the one that executives are trying to solve.
There is so much goodness coming out of the agile community right now. So much forward thinking and so many new ideas. Unfortunately we also see a ton of dogmatism and a profound lack of understanding about the real problems executives are trying to solve. I think we have had, and continue to have, the opportunity as a community to make a profound impact on the way companies operate and in the lives of the people working in them.
The early adopter ship has long since sailed. We are probably on the tail end of the early majority. That leaves us with the late majority and laggards just coming to the party. Maybe that’s what’s driving some of my consternation here. Maybe it’s time we start figuring out how to talk to the folks coming late to the party. Maybe it’s time to focus on how to help these folks adopt agile. For these folks it’s less about defining the end state and more about learning how to get there.
NOTE: This series has been an interesting exploration for me. We have been evolving our transformation model over the past year or so, and writing about this stuff has given me a level of clarity and understanding I didn’t have before. I’m actually talking about stuff differently than I was even a few weeks ago. I made some connections that I hand’t made previously.
This post ended up being a good setup for going back and reevaluating some of my first few posts and putting them in a slightly different context. I think what I’ll do is recap some of the earlier stuff in the new context and then build on the house stuff, planning and risk stuff, to start talking about governance and road mapping. The next few weeks are going to be a little crazy, so wish me luck actually finding time to write. Thanks for reading.
Check out the previous post: Understanding Risk in Your Project PortfolioLearn More
Understanding Risk in Your Project Portfolio
Last Updated on Monday, 24 February 2014 06:37 Written by Mike Cottmeyer Monday, 24 February 2014 08:57
A post or so ago I used the process of designing and building a house as a metaphor for how to plan an agile project. I was basically making the case that we would never spend our own money the way we are asking our stakeholders to spend their money. We would never give a home builder $500K dollars without some sort of commitment around what we were going to get for our time and money. As consumers, we want to know what to expect.
That said, I don’t think it’s reasonable for us as consumers to expect that nothing is ever going to change as we begin building and learn more about the kind of house we really want to build. We can’t go back to the builder and demand changes for free because we didn’t understand exactly what we wanted. We create high level plans, set budgetary estimates, collaborate through out the process to guide the build to successful completion and a satisfactory outcome.
Why This is Relevant to Software
Software projects are all over the place in terms of risk and uncertainty. If I am building an e-commerce site from scratch, and we are using known and well understood technologies, that is a pretty straightforward type of project. I might not know everything that I want on day one, but I can understand the major parts and pieces. I can understand the underlying implementation, create a budget, and probably come pretty close to meeting that budget at the end of the project.
This is the type of project where the metaphor of building the house makes sense. Create a high level plan, develop budgetary estimates, establish constraints, and work collaboratively with the customer to guide the solution into a successful outcome. As the consumer, I should be able to show up with my money, spend a minimal amount of time up front, and get started on the project. I should have a pretty good idea of what to expect when the project is done.
Not every project though follows this same kind of rule. Some projects are much more uncertain. Some projects are funded and neither us nor the customer know much of anything about the target product. They might know they have a need, but understanding how to solve for that need is elusive. Some projects are being built for customers that don’t even exist yet. We are creating a market and trying to figure out what we are going to sell as we go.
Some projects are built on top of legacy systems that have a ton of technical debt, poor automated testing, no ability to produce a daily build… let alone do continuous integration. Some products have so many defects and undocumented edge cases that interacting with or changing that software is an exercise in futility. How do you estimate for a project where requirements are unknown and the technology platform is virtually unknowable?
Estimating the Un-estimateable
I do believe there are projects out there which defy estimation. Projects where the requirements are truly unknown and maybe even unknowable. Projects where the risk and technical uncertainty are just too great to have any idea what it is going to take to do the project. When you couple this with the fact that people are not fungible resources and don’t burn estimates at necessarily the same rate, trying to predict anything doesn’t seem to make much sense.
It seems to me that we should look at these unknowable kinds of projects differently and apply a different approach to managing them. For the first kind, it seems reasonable to create a high level plan, look into the future to identify and mitigate risk, provide estimates, and plans, and have a pretty good idea of what we are going to get. We can still do agile, we can still inspect and adapt, we can still change requirements in the small while converging on our higher level goals in the large.
The second kind of project can’t be handled the same way. We don’t know the requirements are or what it will actually take to build them. We can’t do high level plan, or look into the future to identify and mitigate risk, estimates are nonsense, planning is an exercise in futility, and (if we are honest with ourselves) have to admit that we really don’t have any idea of what the customer is going to get for their time and money. It’s a bit of a crapshoot.
If we can fundamentally agree that both kinds of projects exist, maybe we need a different way to talk about each of them. Maybe for the ones we can predict, we use adaptive planning techniques… user stories, timeboxes, estimates, roadmaps, rolling wave planning, or whatever… to make sure we are driving up communication and collaboration, delivering early, getting feedback, and tailoring as we go. For the ones we can’t… I think we need to start use the language of investments.
Why Do We Call It a Project Portfolio?
If we use the notion of an investment portfolio as a metaphor to talk about a project portfolio… we can start to think about our collection of projects as a series of investments. In a balanced portfolio, I might have some of my money in lower yield, relatively safe, municipal bonds. I might put some of my money in a higher risk mutual fund and hope for a bigger return. I could allocate the remainder to even higher risk, higher reward mutual funds, individual stocks, or maybe even a startup.
The goal of my investment strategy is to preserve some of my capital if things go really bad, while at the same time, putting some my money at greater risk to get a faster payoff. The general principal is that the more risk I assume the more money I should make on the backside. The corollary is that the more risk I take, the greater chance I have of loosing everything. Let’s tie this back to our project discussion.
Projects are investment increments in our Project Portfolio. If I am investing in something that is well understood, in a well understood market, one where we can adequately predict outcomes, chances are I’m not the only one that can see the opportunity or has the capability to build it. I am probably in a more commoditized market and there is a pretty good chance that my long term yield on the investment will be lower. It’s important to control cost because margin isn’t as great.
What if I am investing though in something that is difficult or unknown? Chances are I won’t have the same level of confidence I’ll see a return on my investment. If I am successful, I might be able to change the world and get rich. If I fail, I might run out of money and be unable to feed my family. That is the nature of risk. I think the fundamental problem with projects and estimates is that companies are putting money in very high risk investments expecting a guaranteed return.
Managing Portfolio Risk and Return
Personally, I think we should estimate and plan for the stuff that is estimateable. Many, many software products fall into this category and with proper forward planning, risk identification, and a willingness to inspect and adapt and get continuous feedback, we would greatly increase the odds that these projects could deliver a relatively fixed scope within a set of established time and cost constraints. We’ll adapt in the small to deliver in the large… just like my house example.
The projects which can’t be done this way need to use a language of investment and risk. These are not safe investments. We are putting money at risk in hopes of getting significant return. In these projects, we are spending money to learn, and based on what we learn, we adapt and we change, and maybe we even pivot into something entirely different we never even expected. As an investor, I can continue to invest as long as I want, but I never get a guarantee.
The fundamental disconnect is when we start to blur that which is safe and that which is risky and try to use the same language to describe both. We try to use predictive techniques for stuff that needs to be adaptive and we try to converge on outcomes that need to be inherently emergent. Many companies see this and separate development from R&D. Some though are accidentally investing in R&D when they think they are doing safer product development.
When you are doing R&D, an inherently high risk investment, with the expectation of safety and safe returns… that is when we get into trouble. We get ourselves into an irrational place where we are making bets without understanding the risk profile of the bet. You can’t manage your business that way… you can’t manage ANY business that way. My take is that this fundamental disconnect is what is driving the discussion around estimating in software right now.
I get really tired with the never ending debate around should we have projects in product development. I get really tired of the debate over estimating or not estimating. There are fundamentals underneath these debates which are seldom addressed. What is our domain? What is our context? What are the goals of our delivery system? What is the nature of our customer and their needs? What do they have to spend? What do they expect in return?
How I manage my consulting company is often quite different from how I recommend that companies run their product delivery. The world I live in is often quite different from the world my customers live in. We have different constraints and different variables. We have different customers with different needs and sell different products. I like this notion of looking at projects or products as investment vehicles with different risk profiles. Understand your risk and invest accordingly is good advice.
Check out the previous post, Should You Use Agile To Build Your Next Home?Learn More
Religion, Politics, and Agile
Last Updated on Wednesday, 16 April 2014 02:22 Written by Mike Cottmeyer Monday, 17 February 2014 08:53
Most folks have heard the old adage that you never discuss religion or politics in polite company. Frankly, I’m guilty of both because I think it’s fun and I can take it. As a society, I think it’s time to consider a third category of zealotry that needs to be banned from our fancy dinner parties… agile methodology.
You’re probably wondering now what it’s like to go to a party with me, and why the hell would I be talking about agile at dinner for anyway… but that is beside the point. The problem is that some of us can’t seem to talk about agile without getting really upset and taking disagreement way too personally.
The past few nights I’ve been entertaining myself by posting controversial topics on my Facebook page. My goal is to see if we can spin up some lively discussion. Last nights topic was on the minimum wage in the US and the role of government in controlling such things.
People have very strong opinions about these topics. Many folks come at the discussion from the position of social justice and doing what’s right. Some approach it from a systems perspective and the impact such controls have on society. Some believe a free unregulated economy should determine the prices on goods and services.
What was interesting about the discussion, and I was really trying hard to facilitate a discussion… not a debate… was how personally people connect with these topics. It’s not some abstract political discussion, it’s about the people we know, our families, and how we perceive the world around us.
Religion as you might imagine is even more difficult. How do you have polite conversation about what you believe about God? It transcends the academic and moves into our soul. Questioning my faith isn’t about examining historical facts, it’s about the very foundation of my belief system.
Often, religion has a huge role in how we were raised as children, the relationship we have with our parents, our social structures, and how sure we are about the afterlife or the lack of it. It sets the tone and the underlying foundation for how we view the world around us.
Folks have a hard time distinguishing between a simple academic discussion and a personal attack on who I am as a person. The issues strike that close to our core.
Sometimes I feel like we get this way about agile… at least those of us that live, breath, and eat this stuff. Those of us who are zealots about one methodology or the other. Those of us who write books, publish blogs, and tweet incessantly about the topic… we are all pretty strongly opinionated.
Sometimes the conversation isn’t really about the merits of my methodology against your methodology… it’s more personal than that. It’s more about my perception of the world (and my place in it) in violent opposition to your perception of the world (and your place in it).
It can tie into issues of economic security if my business is built around one approach or the other. It might trigger ego issues if I happen to be heavily invested in one particular approach… as either an inventor or well known thought leader. It might just be that my experience simply isn’t your experience.
Many of us have a lot of experience and we’ve seen lot’s of stuff work. What I find absent from many of the online conversation is context. We are so busy arguing about what is right, what is wrong, what works, and what doesn’t… sometimes I think we forget that all of this stuff has worked in one context or the other.
Personally… I have made waterfall work beautifully at scale. I have made textbook RUP work. I have made Scrum, XP, RUP, and Waterfall hybrids work. More recently we’ve blended Scrum, XP, and lean program and portfolio governance into dynamic, situationally specific models for our clients… and it works.
I tell my clients quite often that most everyone they’ll talk to in this space is a consultant. We all have a point of view, we all have something to sell. Sometimes having something to sell get’s in the way of doing the right thing, or even going off message for the sake of the clients success.
I’d love to see more of our conversation start with context. What did you experience? Why did you experience it? What was it about the context you were in that led to your choices? What were your constraints? What worked? What didn’t? What would you have done differently next time or in a different context?
Wether it be religion, politics, or agile… I think some genuine desire to understand each other, and each other’s perspectives, would go along way to more constructive dialog and more meaningful outcomes.Learn More
Should You Use Agile To Build Your Next Home?
Last Updated on Wednesday, 16 April 2014 02:23 Written by Mike Cottmeyer Wednesday, 12 February 2014 07:24
Before we start our conversation about governance in the structure-governance-metrics framework we’re building out, I want to take a minute and see if I can finally tell you guys about the house my wife and I were planning to build this past summer. It’s an important conversation because we need to establish a shared understanding around what it means to plan on an agile project.
Scenario One – Team Agile Home Builder
My wife and I decide we want to build a new home. We find a piece of property we like in a nice neighborhood. We find a builder we like and think we can trust. We have a really good idea of the type of house that will work for us and our family. We decide that we want to spend somewhere around $500K to get the house completed but it needs to be finished sometime before our kids leave school for the summer.
Next step is to reach out to the builder and see what he can do.
The next day we show up at the builders office and tell him about our plan for our new home. The builder is really excited, seems competent, and is very confident he can get the house built within the time and cost constraints that we’ve established. We ask him what’s the next steps for planning construction on our new home. To our surprise, he tells us that he is an agile builder and doesn’t do any planning.
The builder proceeds to explain to us that as an agile builder, he doesn’t do any planning. He will meet with us every two weeks to determine our priorities and figure out the next most important thing to build. Every two weeks we can inspect what he’s built and change our mind about anything anytime. He tells me this is really in my best interest because I won’t know exactly what I want until I see it.
When I ask if I’ll have the house I want when I run out of time and money, he doesn’t know, but assures me I’ll have the most valuable parts of the house early. Furthermore, I could actually move into the house anytime during the build process, and if I decide I’ve built enough house at any time, I can cancel the contract early and pay him for only the weeks he worked plus 20% of the remaining contract.
So here is my question… would you spend your money this way?
Most people when they are spending their own money, want to have some idea of what they are going to get when the time and money runs out. They want some assurance that they’ll have enough bedrooms and enough bathrooms. They want to know the acreage of the lot and if they are going to get a one story or a two story house and how many cars they’ll be able to fit into the garage.
People understand they might have to make some tradeoffs later in the build process. They might go over on carpet and have to make some tradeoffs with the lighting. They might decide they want fancy cabinets and go with a less expensive hardwood floor. They might want to defer decisions about the colors, or the finish, or the bushes they want to put in the front yard. They aren’t willing to leave out bedrooms.
We wouldn’t spend our own money this way, but this is the way we are asking our customers to spend their money when they build software with us.
Scenario Two – Scaled Agile Home Builder
Fortunately for us, this wasn’t the way that our builder asked us to build our house. We did meet with him and describe our dream home. We talked about the property we wanted to build on, the number of bedrooms and bathrooms, and the number of cars we’d be able to fit into the garage. We talked about the quality of the finishes and flooring and how we wanted the yard landscaped. That took about an hour.
After that, we spent a week or two having meetings with the architect. We got pretty specific about the room layout, the number of floors, the layout of the basement, and the placement of the house on the lot. We made high level decisions about floors and cabinets, but didn’t pick any specifics, decide any colors, or pick specific appliances, light fixtures, or door knobs. There was way more left open then decided.
What we did decide was the stuff that would drive the cost of the house. The stuff that would be expensive to change later. We went into the process understanding that a ton of stuff was going to change, but there was also stuff that would be really difficult to change, and those decisions had to be made early. We talked about potential risks once they broke ground and buffered in case anything went wrong.
The result was a blueprint and elevation for the house. We had a line item budget for construction costs, material costs and miscellaneous tools and supplies. Every line item factored in a profit for the builder. Every line item represented some feature or attribute of the house that I would probably care about when the house was complete. We did all that in a few weeks and made no detailed decisions about the home.
It was interesting, the first cut of the plan was about $200K more than we wanted to spend and we were aware that there was some risk and should probably buffer another $50K just in case. Even though I trusted the builder, I had my CPA and advisor review the plan line-by-line just to make sure all the costs were reasonable and we were making a sound financial decision before we decided to move forward.
As we were reviewing the plan… the builder said something to me that was pivotal for how we were going to manage this project. He told me that I had a 20K budget for hardwood floors. For that price, he assured me that I would be able to get a high quality floor, extra long and extra wide boards, and a very high quality wood with a very high quality finish. That said, my budget was 20K for the hardwood floors.
When it got time to build put in the hardwood floors, it was up to me to choose what kind of floors I wanted to put in. If I decided I wanted a less expensive floor, I could save money and use it for something else. If I wanted an exotic wood like Brazilian Cherry, that would cost more and I’d pay extra. It would ultimately be up to me, but he would work with me to understand my trade-offs and any associated costs.
At Enterprise Scale, Estimates Become Budgets
I instantly made the connection that this was exactly how I coached teams to define, estimate, and plan software projects. You have to have a high level plan. You have to make key decisions early. You have to have time and cost estimates to present to the customer. What you don’t have to do is define anything and everything before you even get started. You have to establish budgets to bound your uncertainty.
At the point the builder made the estimate, he was bound to manage the project to that estimate… the estimate became a budget. The builder had to work with me as the primary stakeholder to help me make tradeoffs to live within that budget. As we break down software requirements, focusing on minimally marketable features and maximizing value, we are effectively doing the exact same thing.
Okay… let me drive this one point home. Just like you wouldn’t build a house with an open ended scope, your stakeholders don’t want to commit to an open ended software project. We have to do enough work up front to put together a credible plan, mitigate risk, and understand costs. We have to estimate the work, set budgets, and make tradeoffs to ensure the product is done on time and on budget.
It is important to be able to tell people what the project is going to cost and when it’s going to be done. It’s important to tell people what they are going to get for their time and money. It’s also important they know the risks and can buffer some contingency. They also need to know what’s locked and what’s open and the kinds of tradeoffs that they might have to make along to way to ensure success.
Why Is This Such a Difficult Problem to Solve?
The problem is that many software teams are trying to build products in less than ideal conditions. They are constantly realizing issues and risks they didn’t anticipate. They are working across too many projects at one time. They have external dependencies that can’t be managed or controlled. People are not dedicated to the team. The result is that people are coming to the conclusion software can’t be estimated.
Going back to the house analogy, it’s as if we are building on rocky soil and are constantly finding boulders that have to be broken up and hauled away. It’s as if we have contractors that never show up when they say they will. It’s as if we are constantly changing our mind between a one story house and a two story house or deciding we want a basement after the foundation has already been poured.
Summing It All Up
The answer can’t be throwing our hands up and refusing to make a commitment. We might have to pay a few thousands dollars to determine if the build is feasible. We might have to pay another few thousand for soil tests to make sure the land can accommodate our new home. You can spend money to mitigate risk. Sometimes you need to do some work to learn what you don’t know.
No estimating, no planning, and not committing won’t be the answer for most organizations. It’s not a starting place anyone can live with.
You have to ask yourselves what it is going to take to stabilize the delivery process. Forming teams that stay together helps, that was my previous post on structure. Having a governance model to control the flow of work helps too, that’s my next post. Having a means to mitigate risk, invest in discovery, establish baseline metrics, and the ability to measure improvement over time all play a part. More posts to come!
#noestimates is a #nonstarter
One final note… Kimi and I never ended up building this house. The neighborhood was beautiful. The plan and elevation were beautiful. We really liked our builder and trusted he could deliver our dream house within the time and cost constraints we agreed on. The problem was that housing prices were depressed in the county we planned to build in and the appraisal came in at 60% of the build cost of the home.
We could have moved forward anyway, but would have been instantly in a house that was worth less than we paid for it, with no indication it would recover in the foreseeable future. So sure, we spent a bunch of time and mental energy, and even some hard cash to find out we shouldn’t build the house. Had we built the house using mainstream agile thinking, we’d have found out too late it wasn’t worth what we’d actually paid for it.
We spent a few weeks of time and a few thousand dollars but avoided what would have been a very, very expensive mistake. That’s not waste in my opinion… that’s good risk management.
Check out the previous post, Shu Level Agile Isn’t The Same As By-The-Book Scrum.Learn More