Are You a White-Collar Factory Worker?

April 30, 2010

If you are, you need to start making some immediate changes...

Seth Godin made the following observation in his book, Linchpin: Are You Indispensable?:

“Most white-collar workers wear white collars, but they’re still working in the factory. They push a pencil or process an application or type on a keyboard instead of operating a drill press. The work is planned, controlled, and measured. It’s factory work because you can optimize for productivity.“

Seth’s point is that the structure of many organizations today is actually modeled on factories is an interesting one. In this configuration, only a select few perform any meaningful thinking – they determine the work processes and outputs. As Seth states, “Management wins when it can get the most work for the least pay, and the more controlled the output, the better.“

What else happens when you have this type of structure? Management systems organize to define the rules, and compliance is expected in order to produce the controlled output for the least amount of pay.

How can you tell if you are a white-collar factory worker?

Dan Pink, in his book A Whole New Mind: Why Right-Brainers Will Rule the Future, suggests asking yourself these questions:
  1. Can someone overseas do it cheaper?
  2. Can a computer do it faster?
  3. Is what I'm offering in demand in an age of abundance?
If you answer yes to questions 1 and 2, or if your answer to number 3 is no, you have a problem in the making.

In case you need further convincing, Micheal Lopp (a.k.a. Rands), in his book Managing Humans: Biting and Humorous Tales of a Software Engineering Manager has these questions to ask yourself:
  • How much process is in your job? 
  • Can you see a flowchart from where you are sitting right now? 
  • Are there big black binders that describe what you do? 
  • Are you handed specifications from nameless, faceless designers? 
The writing is on the wall. In the global economy, there won’t be great-paying jobs where someone else tells you precisely what to do. To win in this economy, you need to be a creative difference-maker.

In the software industry, creativity and innovation are essential. These days, use of cross-functional teams are growing more common as Agile development gains in popularity.

Developers who are highly collaborative and able to work productively in team settings, who generate options and solutions to difficult problems, and are able to do extraordinary things (for developers) like presenting at user conferences and interacting directly with customers are highly prized. The difference-makers can do all of this along with being the ones who produce solid code that solves those difficult problems.

As a manager, I’d be crazy to attempt to outsource the value provided by difference-makers. How could I hope to? They provide – some people hate this word – indispensable value. (Just what Seth Godin wants us all to provide in one way or another.) There’s an old saying, “No one is irreplaceable.” True enough, but some people are damn hard to replace.

What you don’t want is to be viewed as someone who is performing commodity work. Sure, we all have some administrivia to tend to, and no one produces indispensable value every minute of every day.

Producing indispensable value involves dealing with the tough problems, and a portion of your “work” involves wrestling with options and poking at a problem from different angles. This requires research, think time, conversation to stimulate your thinking, and even sleeping on the problem.

The key is to challenge yourself without worrying about making mistakes (we all make them). Don't be that person who requires someone else to define and orchestrate your entire day. If a manager can do that, it's a sure bet that the work can be performed less expensively somewhere else on the planet.

Book Review: The Power of Strategic Commitment

April 27, 2010

The Power of Strategic Commitment: Achieving Extraordinary Results Through Total Alignment and Engagement by Josh Leibner, Gershon Mader, Alan Weiss, Ph.D. Copyright © 2009 by Josh Leibner and Gershon Mader

Do you feel that your organization is operating up to its potential? If you are anything like the leaders that the authors of this book have dealt with, the answer is no.

Guiding your organization towards optimal performance is a significant challenge, and The Power of Strategic Commitment points out that while today’s business is more complex than ever before, customers want to reduce their complexity when dealing with a seller or provider.

This conspires to make optimal performance a moving target. And in order to achieve a higher-performing state, there must be a condition of total ownership and alignment for the organization’s direction and goals, with everyone acting in concert with the desired future state.

Here’s the rub: The book notes that Professor Robert Kaplan of the Harvard Business School and his associate David Norton at the Balanced Scorecard Collaborative have determined that as much as 90% of all corporate strategies are not executed successfully. Most corporate initiatives fail.

The book points out a common way to fail. Have you ever been a part of an organization that refers to their corporate strategy – one that was developed with the help of consultants – as “the XYZ consulting group strategy”?

The recommendation is that leaders must always be perceived as the owners of the strategy. They must also own it more so that simply setting the strategic direction; leaders should also avoid handing off of “change management” to HR or an outside consulting group. This produces doubt and skepticism and will erode commitment. You need more than a slide deck or a memo to achieve commitment.

What is required is to have senior leadership engage in a robust dialog about the content of the strategy. Middle managers must be told the truth about why changes are required and what the likely outcomes will be. Full disclosure is required for full commitment.

The advice is that leaders need to focus on both the content and context aspects of their strategy.

Content: Validity in the objectives, plans; that they are relevant and accurate.

Context: Clarity around the messaging. It is about getting everyone on the same page about content.

Leaders must also be perceived as credible, sincere, competent, having the courage and resolve to make the strategy stick, and they truly care about the impact of the initiative. And don’t delude yourself into thinking that the business is moving so fast that you don’t have time to deal with the context issues. Slow is fast. Taking time to gain strategic commitment pays off; a slower start ensures a faster finish.

The book did an excellent job of contrasting commitment and compliance:


Commitment
Compliance
Proactively suggests improvements
Only reacts to others’ suggestions
Works longer hours on his own volition
Works only by the clock
Pushes back on ideas deemed weak
Blames others when ideas fail
Takes pride in her own achievement
Looks only to compensation
Identifies with outputs of the work
Identifies with job title or position
Prudent risk taker who will accept failure
Conservative and risk-adverse
Informal leader
Permanent follower
Volunteers
Passively accepts
May be unpopular at times, and doesn’t care
Seeks acceptance above all else
Searches for cause
Searches for blame

Overall, I found that the book provided an excellent discussion on the need for strategic commitment and how to achieve it – along with avoiding common mistakes.

Counterpoint: Agile “Baby Talk” Kills Developer Creativity

April 23, 2010

Kai Gilb’s blog post Part 2 of 7: Agile “Baby Talk” Kills Developer Creativity takes issue with how Agile development practices handle requirements, stating that the Agile approach is simplified “baby talk” that fails in practice. Kai states, “This “baby talk” Requirements practice makes the popular Agile methods useless to anyone creating competitive systems, to anyone creating systems requiring high value, and to business.”

Interestingly enough, Kai reveals that he understands Scrum more so that I was led to believe in his first post. He states that Scrum, “… is an “open development framework”. 'Open' meaning that you can use any Requirement method, testing method, prioritization method etc. that the Scrum team sees fit for purpose.”

He follows with that statement, “You cannot just do Scrum. To put the framework to practice you need to plug in methods for the various sw engineering domains, like testing and Requirements, and practices from XP.”

It sounds like Kai gets it! So what is the difficulty?

He doesn’t like User Stories. Kai feels that User Stories do not capture the values of the stakeholders. He feels that User Stories mislead development, and that “The point is not sw functions, the point is to enable some Stakeholders to improve something.”

The example Kai gives is from the Scrum Primer (© 2010 Pete Deemer, Gabrielle Benefield, Craig Larman, Bas Vodde):

"As a buyer, I want to place a book in the shopping cart (see UI sketches on wiki page)."

Kai goes on to talk about what is wrong with this User Story. I won’t go into all of the details here, but I urge you to read Kai’s post first. The following are the conclusions that he arrives at (which are incorrect, in my opinion):
  1. The User Story describes a solution, “to place a book in the shopping cart,” and not a pure function, like “to order a book.” Kai asserts that this automatically restricts the options and any potential for creativity. (Actually, Kai is correct that this does describe a solution, but this can be dealt with.)
  2. That the developers are reduced to “bricklayers,” that they are told what to do. 
Kai then proceeds in his post to describe how the real requirements should be expressed, but he deviates from the User Story format in doing so.

I my opinion, this is an example of a need to tighten up the approach to User Stories and Scrum.

In the first place, User Stories are not full requirements. One of the problems with software development is that users don’t understand computers as well as developers, and they aren’t used to communicating abstractly. Sometimes they need to express their requirements in concrete ways that they understand. User Stories help to express what the user wants, but they are not the end requirement. User Stories are a reminder to have a conversation.

Agile development is collaborative development. The conversation with the Scrum team, the customers and/or Product Owner are intended to provide the understanding about the real requirement. If you are developing to just the User Story, you have a problem! In addition, the conversation may yield additional User Stories, and there should be a conversation about the acceptance criteria – those elements that will help to determine if the User Story is “done.”

User Story creation can also be performed by professionals who are adept at expressing requirements. A properly constructed User Story can be more complete than the example used. Let’s refer back to Kai’s post and his example. There might be performance considerations, as Kai points out. There is also a missing component in the example. I’ve crafted a new User Story that addresses Kai’s concerns and adds the missing piece of the puzzle:

As a customer, I want to complete a purchase of up to 3 books in 1 min or less, so that my satisfaction with the speed and efficiency will make me a return customer in the future.

We’re still at one sentence, and I’ve added detail (3 books) and captured the need for speed as part of the goal. Did you catch the other add? It was the “so that” component. The full User Story template is:

AS A [type of user] I NEED (OR WANT) TO [perform some task] SO THAT [benefit]

Now, when the team has a conversation with the user/customer, they can explore the goals that the user has, they will understand the motivation, the real need, and the desired benefit. This will address another one of Kai’s concerns:

“Developers are essentially reduced to “bricklayers”. They are told what to do. The mighty Scrum framework is reduced to a big cooperative To-Do list that tells the Developers what to do, and you the Developer should just do it.”

If the team is having a true conversation, then developers most certainly can and should talk about how to best represent the business in software. There can be brainstorming and white-board sessions to figure out how to best meet the true goals and objectives of the business. Developers can and should have the ability to be creative. In fact, that is what the business is counting on.




Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai will make his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.

Multi-Tasking Shouldn’t be a Job Requirement

April 20, 2010

Job descriptions frequently list the ability to “multi-task” as a requirement in one way or another. What does this really mean? And should those job descriptions require something else?

As I pointed out in a previous post, Task-Switching is for Computers, not Humans, computers are much better at multi-tasking than humans are. This is because computers are designed to multitask. When a computer switches from performing one task to another, it saves the entire state of the task being switched out, enabling the computer to literally pick up where it left of when it returns to that task.

We humans aren’t that good at task-switching. We need ramp-up time to get ourselves back to the state we were in before we switched tasks, causing us to lose productivity. The more task-switching that we perform, the greater the productivity drain.

How much productivity we lose is a function of other things, like the type of work being performed. We are much more effective at multi-task with simple activities, like scheduling meetings, ordering lunch, and responding to simple questions.

As Jurgen Appelo pointed out recently in his post, In Praise of Multi-Tasking, there are some projects actually support one another, and Jurgen asserts that multi-tasking between each one improves your overall performance due to cross-pollination. I agree with Jurgen that cross-pollination is a plus, but I don’t agree that task-switching improves actual productivity – unless you need a break.

There are studies that demonstrate that people need to mental break to get their concentration back. A short break doing some web surfing can make you a happy, productive employee. Task-switching in this respect is a good thing.

Switching between related projects (not tasks) will keep you productive in the grand scheme of your entire project portfolio. I think that this is what Jurgen is really talking about. The key here is to do so when you reach a good point to set the current project task aside, so that you don't lose valuable time remembering where you left off.

Since very few of us have only one priority to deal with in our lives, the reality is that we need to manage multiple demands of our time. What is a priority at 8:00am, for example, (your job) may not be the same priority at 6:00pm (your significant other). We all need to allocate slices of time to our various priorities to maximize our effectiveness.

It is a question of who controls the interrupt.

If you control the interrupt by taking a break to do something else, or to switch to another project when you reach a good breaking point on a current task, that's productive. If someone else interrupts you while you are in the middle of writing a blog post or programming a complex algorithm, there will be a cost in terms of your productivity.

Multi-tasking is really all about your ability to handle multiple inbound requests of your time. Instead of attempting to multi-task, you should prioritize the requests and deal with them as productively and expediently as possible.

Being productive involves little tricks like dealing with e-mail only once or twice during the day and not on a continual, real-time basis that will divert your attention from an important task at hand. Or taking appropriate breaks. Or working at home or in some other closed-door location to prevent interruptions. This is true for independent tasks and tasks where you are collaborating with others.

Multi-tasking can be abused in the workplace. If you are interviewing for a job, it would be wise to probe your prospective manager about the nature of this requirement if it is present on the job description. And ask to talk to some of your potential peers if they are not a part of the interview process. Do they have the appearance of being run ragged? What sense of accomplishment do they have in their work? Do they feel that they are performing valuable, important work that they are proud of?

Extreme multi-tasking will keep you very busy, but it will bring a lack of accomplishment. You can quickly determine if you are walking into a bad situation by keeping your eyes open and asking a few questions of your own during the interview process. Just make sure the meaning isn't something along the lines of:

"We want the ability to interrupt your work to put you on another, completely unrelated task at our sole discretion. And by the way, we expect you to complete the assignment that we just interrupted in the exact amount of time that you estimated.”

In terms of the job descriptions, the “ability to multi-task” is a poorly-worded requirement. We should be asking for someone who is “able to prioritize and work tasks to completion.”

Counterpoint: Does the Agile Manifesto Have the Wrong Focus? Part Two

April 16, 2010

Kai Gilb’s blog post Part 1 of 7: Completely wrong Focus: Agile & Scrum is not focused on delivering values to Stakeholders for a minimum or a reasonable cost takes aim at the Agile Manifesto as being too developer-centric and not even mentioning “a word about delivering specific and varied values to stakeholders.”

Kai makes the observation that, “The Manifesto is overgeneralized, and should instead instruct us better on how to make intelligent decisions for our stakeholders.” He then moves on to discuss the Scrum backlog process, asking, “Where, in the Scrum process diagram, is 'delivering value to stakeholders'?”

This highlights a major misunderstanding about Scrum, one that I noted in my post, Are There Fundamental Problems with Agile/Scrum? Scrum is a framework for team interaction, and not a paint-by-numbers approach with everything explicitly defined.

When it comes to Scrum, the business is responsible for defining and prioritizing items that will provide value, not the developers. Scrum is a process that involves the business to deliver value to the business; how the business defines that value is completely up to the business and the stakeholders.

As far as the developers are concerned, Scrum dictates that the highest-priority items from the backlog are those that must be worked first. The business and the stakeholders will get what they value the most first, within the limits of what they were willing to invest (staffing being a key investment, given the people-intensive nature of software development.)

The key point is that the Agile Manifesto does not instruct you on how to define business value, nor is it an instruction manual for software development.

The Agile Manifesto is an instrument to succinctly state the mission of Agile development. It provides a statement of Agile’s core values and some guiding principles. If you want a deeper understanding, entire books have been written about Agile, adhering to mission and principles of the Agile Manifesto.

Kai objects to some wording from the Agile Manifesto showing up on page two, like the first principle of the Agile Manifesto: “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.”

Okay, perhaps one of the values should have been something about delivering software that was of the highest possible value to the customer. However, I’ll defer back to what I feel is the stated purpose of the Agile Manifesto, which is to uncover better ways of developing software. And you can't have everything on page one.

Another issue that Kai points out is with the principle that states, “Working software is the primary Measure of progress.” Kai explains, “Guess what, have you heard the expression, ‘what gets measured gets done’. So if you Measure progress as working sw, lets say through a burn-down chart, then what gets done? ‘Working sw’ gets done. Not ‘Our highest priority’ not value to stakeholders.”

I'm puzzled by this comment. Kai appears to be taking one sentence in isolation, removing it from the intended context. Agile is all about defining value and prioritizing the work so that the highest-valued features will completed first. And that value is realized when the prioritized business features are captured in working software.

What is the issue with measuring yourself against delivering complete, quality working software that contains the highest-valued features – as determined by the business?

Kai closes with the following:

"This is a message, as loud and clear as I can be, to all fans of Agile.

"It is not about working software. It is not about your preferred working process. It is not about user stories. It is not only about your customer or user.

"It is all about delivering, to your set of Stakeholders, value improvements, which they care about, which makes their world better, within agreeable, minimum or pre-determined costs.

"If that is not the main focus, if that is not clear to everyone on the team, you will eventually lose! If your methods are not focusing on delivering that value, as todays most popular Agile methods are not, they will fail to deliver, they will become last years fad."


Agreed, software development is all about meeting the needs of your customer(s) as well as your stakeholders who have a vested interest in achieving a solid return on their investment.

In the final analysis, this requires a cross-functional, multi-disciplinary team working effectively and efficiently to produce results.




Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai will make his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.

Counterpoint: Does the Agile Manifesto Have the Wrong Focus? Part One

April 13, 2010

Years ago, a hardware technician friend of mine called me at work and asked, “How does a programmer change a light bulb?”

“I don’t know… How?” I asked, knowing full well that some type of leg-pulling was coming. And it did.

“They hold the light bulb up to the socket and the whole world revolves around them!” my friend said, completely pleased with himself.

Kai Gilb’s blog post Part 1 of 7: Completely wrong Focus: Agile & Scrum is not focused on delivering values to Stakeholders for a minimum or a reasonable cost takes aim at the Agile Manifesto by taking the position that my hardware friend was doing with me in his jest.

Kai states, “All the ideas in the Agile manifesto are 'solutions' to what is seen as convenient for developers.” And that, “Agile is far too centered around the developer. The world is seen from the eyes of the developer, the world revolves around the developer.”

Hmmm... Two individuals using the same wording: The world revolving around the developer. Is this coincidence or conspiracy? Maybe, just maybe, there is a kernel of truth here. Developers do spend a LOT of time developing and tinkering (we call it learning).

And when it comes to software development projects, developers are the ones everyone looks to in order to define what it will take to produce software. The is only natural, since developers are the experts in software development, after all.

I wasn’t present when the Agile Manifesto was created, but my understanding is that it was in fact created by developers, in response to the challenges and frustrations experienced by far too many developers. The goal was to come up with a better way of producing software, one that met the needs of the business and reflected the realities of software development projects.

Kudos to those who challenged themselves and delivered the Agile Manifesto! We are all benefiting from the efforts of these pioneers.

Back to Kai’s issue; I concede that the Agile Manifesto is developer-centric. Get a death march project or two under our belt, and you’ll want to exercise some control over your work too! The Agile Manifesto is important as a historical document, it provides the foundational principles and values that Agile supports.

In the spirit of “standing on the shoulders of giants,” I view the Agile Manifesto as the beginning, a great start that we have been building upon ever since. There has been a lot of practical experience gained since the Agile Manifesto was created, along with plenty of thinking and discussion.

In short, there has been a whole lot progress, and a growing body of work is being published about Agile and Scrum. The verbiage of the Agile Manifesto may strike you as developer-centric, but look beyond the Agile Manifesto to gain a greater insight about the state of Agile development today.

I’ll continue examining Part 1 of Kai’s concerns in my next post.




Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai will make his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.

Are There Fundamental Problems with Agile/Scrum?

April 9, 2010

We’re approaching three years of Agile/Scrum development in my office, and I believe that we’re really starting to come to grips with the advantages and pitfalls of Agile development. Overall, I feel that there are significant gains possible with Agile, but “getting it right” looks easier on paper than in actual practice.

It’s certainly easy to get the wrong impression of Agile and Scrum, and there are still far too many implementations using the ScrumBut approach. (“We do Scrum, but we don’t have a Product Owner,” or “We do Scrum, but we don’t have daily stand-ups…”)

I’ve come across an interesting perspective of Scrum in the blogosphere, 7 truths about Agile and Scrum that people don’t want to hear, posted by Kai Gilb. In his introduction, Kai states, “In this blog series that will be written in 7 parts, or blogposts, I will highlight 7 major challenges and hint as to what needs to be done to rectify them. Most writings on Agile, talk about its glory, here I will write about the faults: faults that are so serious, that if not rectified will ensure that your favorite Agile method will become last year's fad.”

Personally, I believe that Agile development provides many benefits, some of which I outlined in my post Achieving Higher Productivity, Stimulating Innovation, and Maintaining Morale. However, there does seem to be a great deal of confusion about the implementation of Scrum. I agree with Kai on this point, a problem with a methodology like Scrum is that it is very lightweight. But perhaps the problem is that we’re collectively doing a bad job of explaining what Scrum is and what it isn’t. Before I begin examining Kai's posts, I'll take a stab at providing a high-level description of what Scrum is and isn't.

Scrum is… Scrum is a set of protocols that allow a team of multi-disciplinary of knowledge workers to collaborate together to represent the business in software. Software development is all about understanding and meeting the goals and needs of the business while operating within the constraints (e.g., time, budget) of the stakeholders.

Scrum recognizes (assumes) that these knowledge workers have the greatest expertise and insight about their own work, and as such the Scrum framework supports and fosters open communication, accountability, and cross-functional participation. It defines the mechanisms for those knowledge workers to use so that they can understand, interact, and monitor their work as a team.

The advantage is that Scrum teams don’t have to go through extra time and effort establishing their own protocols for operating. They can use the Scrum framework, incorporating whatever technical practices works best for them. This leads me to what Scrum is not.

Scrum is not… Scrum is not a paint-by-numbers methodology where everything is explicitly and rigidly defined. For example, Scrum does nothing to define technical practices. This is why many industry gurus recommend incorporating XP practices into Scrum.

Succeeding with Scrum requires competent, capable, engaged professionals who are applying more than just technical practices. Because Scrum relies on cross-functional, collaborative teams, these professionals need a blend of both technical and interpersonal skills to succeed. The framework is simple, but solid execution requires disciplined action by capable professionals.

Kai’s blog is an excellent opportunity to play point/counterpoint with respect to Agile and Scrum. Kai has his points, and I will make mine. I’ll leave it to you, the reader, to determine what is right for you.

I'll delve into Kai's post in my future posts on this blog, responding to them individually, in the order that Kai posts them. I invite you to share your experiences and thoughts!

Good Enough Software: An Agile Definition

April 2, 2010

I recently examined the Agile Triangle, promoting an Alternative Agile Triangle as a model to reflect the spirit of Agile development. (I also rather quickly revised it.)

In an effort to keep up with the times, I think that we should update the traditional concept of “good enough” software. Actually, the conventional definition is just fine when it relates to non-Agile software projects. What we need is a revised definition for Agile projects.

The term “good enough” was coined by James Bach of Satisfice, Inc., and it relates to software quality, where it is okay to ship with bugs as long as you ship with the right bugs. James’ point is that building bug-free software is prohibitively expensive, and that as long as the benefit provided by the software outweighs any problems, you have achieved your primary objective in building the software.

As far as Agile software projects are concerned, they specifically focus on delivering with quality; James Bach’s “good enough” software definition applies to sequential software projects that have a quality-assurance cycle at the end of the project – where time is constrained and the poor QA folks always get short-changed.

Agile projects don’t work like this.

Good enough in Agile is really about good enough design.

Good design in Agile translates to meeting the needs for the features that are being implemented right now. This does NOT mean that you should throw good design principles out the window! The software design should reflect what is needed to support the features being implemented, but only what is needed, not what you might need later.

We all know that requirements will change, yet all too often software design attempts to reach too far into the future and anticipate change. This leads to two problems.

  1. Implementing too much foundational code that supports a big design up front makes the software more complex. This in turn makes the software more difficult to understand and more costly to maintain going forward.
  2. You will end up wasting time and money developing and testing things that won’t be needed. A design can degrade over time because the requirements dictate changes in some way that the original design did not anticipate.
From my experience, there are some common responses involving the big design approach that is faced with new functionality that is a poor fit for the existing design.

The first is to react by continuing to work strictly within the bounds of the existing design, even if the design is proving to be a burden. A more extreme example occurs when human nature really kicks in, and those who have invested a great deal of thought and time into creating a design become wedded to it and attempt to keep it alive much longer than they should. Changes become delayed until it becomes so costly and difficult that it is painfully clear to everyone that the design must change.

On the other side, there are those who weren't a part of the original design process in the first place, but are faced with updating the software in some way. The deciding factor for these individuals is how quickly and easily the design allows them to make a change. If the design is constraining to the point where working within the bounds of the design takes significantly more time and effort than working around it, the design will not be followed.(At least not without a fair amount of arguing.)

Agile is about embracing and dealing with change. And we all know that change is constant in software projects. Requirements change due to business priorities shifting, or because what we thought we understood really wasn’t quite right.

Agile design should be a small investment up front. The team starts with the simplest design possible, develops and maintains an inventory of unit tests and acceptance tests, and continually evolves and improves the design each and every iteration – keeping the design appropriate for the feature(s) developed for that iteration.

From a software development perspective, be good enough with the design, but be great in the other dimensions of software development. Like writing solid, maintainable code that is tested thoroughly and delivered with quality.

But wait, there's more!

Good enough applies to the business end of the deal as well. Our management team recently read and discussed a book Stand Back and Deliver: Accelerating Business Agility by Pollyanna Pixton, Niel Nickolaisen, Todd Little, and Kent McDonald. The book described what is known as the Purpose Alignment Model.

The Purpose Alignment Model is a tool to help you to examine your business processes and activities in two dimensions: Mission Critical and Market Differentiation. These dimensions are split into quadrants: Who Cares, Parnter, Parity, and Differentiating.
Focusing specifically on Differentitating and Parity, the objective is to understand what truly differentiates your company in the marketplace from those activities that don't really provide competitive advantage.

Parity activities are important because they are mission critical. You shouldn't under-invest in them because they are your baseline; you won't, however, gain any advantage in the marketplace by doing them better than the competition.

Good enough business value is appropriate for non-differentiating, parity activities.

When it comes to Parity activities, do them well, but don't go the extra mile. The investment won't be worth it. Find those few, key Differentiating activities and excel at those to maximize the return on your investment.

Photo by kanu101