Book Review: Reinvent Your Enterprise Through Better Knowledge Work

May 28, 2010

Reinvent Your Enterprise by Jack Bergstrand. Copyright © Brand Velocity, Inc.

As a manager seeking to improve my game in managing software developers, I’ve taken the stance that software development is knowledge work. I therefore keep an eye out for useful information about managing knowledge workers, not just software developers. The book, Reinvent Your Enterprise Through Better Knowledge Work appealed to me on that basis.

Jack Bergstrand makes some solid observations about the need for productively managing knowledge work. One being that the half-life of knowledge continues to get shorter. This places demands on knowledge workers to learn faster, interact better, and produce better and more accelerated results. (This struck a chord with me, since we’re always looking to produce “better software, faster,” and the rate of technological change has been significant during my career.)

And while this wasn’t a software development book, another observation was spot-on: Knowledge work is how individuals and groups use ideas, expertise, information, and relationships to get things done. It includes tasks such as brainstorming, analysis, project management, and personal coaching.

These activities are exactly what we’re doing with our Agile/Scrum development process. We want individuals to collaborate and share ideas and expertise.

Bergstrand notes that knowledge work actually needs to be managed better than manual work because there are so many ways for it to go off track and become unproductive:
  • Too many meetings that produce too few decisions and actions
  • Competing internal priorities with no mechanism for resolution
  • Studies that are completed and put on the shelf
  • Projects that get started but are never finished
  • Projects that get started but are not finished on time
  • Projects that never get started but get talked about every year
  • High executive turnover that causes frequent changes in direction
A few thoughts/recommendations Bergstrand puts forth:

A system to manage knowledge work requires both a shared framework (shared mental model) and an explicit process. The framework is needed to get everyone on the same page. The process helps people manage their knowledge work more productively and sustainably. The model needs to simplify while also being robust enough so that knowledge work tasks can productively self-organize and the architecture in a variety of situations and under various conditions.

It is usually productive to write off underperforming products, operations, and orientations at the same time an organization is moving forward with new things. This can help establish new standards of performance.

Organizational hierarchies produce known problems, but it is not productive to be anti-hierarchy. Working without a clear organizational structure is the most unproductive situation of all.

Overall, this book was well-written, and provided me with an excellent, generic perspective on managing knowledge work, but less so on managing knowledge workers themselves.

Ten Behaviors Required for Effective Teamwork

May 25, 2010

High-performance business teamwork demands a great deal from individuals. If you want a high-performance team, it needs to be staffed with competent people who have clarity in terms of direction, understands what needs to be done, and are capable of performing that work.

As a team member, what are the characteristics required of you to be perceived as a valued, contributing and positive force on that team? Be…
  1. Engaged. Demonstrate a willingness and desire to advance the team’s goals by proactively seeking to add value to the work that the team is performing. Don’t wait for someone to assign tasks to you, be a self-starter. Seek to understand the objectives of the team and volunteer to take on tasks that are within your ability to perform; and don’t shy away from tasks that may stretch you a bit.

  2. Action-oriented. Have a bias for accomplishing work that provides value, avoiding the "analysis paralysis" trap. This does not mean taking hasty action, such as bypassing research and planning. Both can add value, but seek to understand what you need and how much is really required. There is no such thing as perfect information or a perfect plan, and you should move forward when you have sufficient information; seek advice from those with experience to help define “sufficient” for your situation.

  3. Committed. Make a commitment to delivering value by a certain date. Through engagement, action and commitment you will become a contributing team member.  This includes making sure that the team as a whole is pulling together to meet its overall commitments. If you are confused about what constitutes value to your team, by all means ask the question!

  4. Accountable. Hold yourself personally accountable for meeting your commitments and hold others to meeting their commitments. If there are problems, inquire about what is causing a problem – but keep the discussion depersonalized. Accountability is expressed as “I will…” and not, “I’ll try…”

  5. Collaborative. You need to be someone who is both a good listener and willing to speak your mind. Engaged team members understand the work, form opinions and voice their opinions. It is not in the best interest of the team to have a select few (or one) forming opinions and driving direction. Keep in mind that when there are multiple opinions in play, others may have different perspectives based on their experiences and understanding. There very well may be aspects all of the opinions that should be considered.

  6. Adaptable. The business world is a dynamic, fluid world, and the needs and dynamics of one team will likely be different than other teams. Be prepared for changes in priorities and be coachable – you may need to adapt your personal style for the good of the team.

  7. Supportive. Teams are comprised of individuals with complementary skills, and there will be times when individuals will be operating outside of their comfort zone. Support people by providing assistance in the form of guidance and coaching, but do not cross the line into carrying someone else’s load (this disrupts accountability). Be supportive of the team in general as well, including its goals and methods. Bad-mouthing the team to others will come back to haunt you, and demonstrates a lack of commitment to the team. If something is making you uncomfortable, talk to the team about it, and in necessary, find a way to remove yourself from the team.

  8. Transparent. Be open about any issues and the progress of your work, particularly when you are working on a task independently.  Your teammates cannot support you if they have no visibility into your work, and you will deny yourself the opportunity for valuable input from others.

  9. Honest. Be truthful and sincere, and by all means keep your word!

  10. Trusting. To be a good teammate, you must be able to trust those on your team to “play their positions.” If all team members have the above behaviors, there is no reason not to trust them. If there are problems, talk about them in an open, honest, no-personal way. Explore why there is a breakdown and what can be done about it.
You might notice a couple of typical “behaviors” missing from this list: Leadership and continuous learning.

Leadership is a quality that is spread throughout the behaviors; leadership emerges to the degree in which someone is committed, collaborative, etc. Leadership can also take other forms, such as possessing and sharing deep domain knowledge or (more than likely) a combination of both knowledge and behavior.

Continuous learning/improvement is a trait that can and should be embraced by both individuals and teams. Individuals should have something to contribute to a team, and continuing to learning more about your profession will increase the value of your contributions to a team. Personal and professional growth exhibits engagement in your chosen profession. In addition, teams should never be satisfied with their status quo, but should always be asking, “How can we operate better?”

Avoid Being Anchored by Your Own Opinion

May 21, 2010

Have you ever developed a passion for an idea as a result of considerable time and effort expended in research and thought on your part? Did your research and thinking lead you to a firm, unshakeable conclusion? Does your routine research and understanding of your profession provide you with solid opinions about how things should be done? Does your hard-earned insight occasionally blind you to alternative ways of thinking?

Guilty as charged.

You might work very hard at keeping current and forming opinions on various topics, but others will not have your perspective. And they won’t enjoy dealing with someone that they perceive to be so opinionated that alternatives aren’t at least explored and considered.

It is always good to keep an open mind and explore options, particlularly during the decision-making process. There is a common problem with us humans, and that is to focus too heavily on one piece of information during our decision-making process. This is known as anchoring.

If you place too much importance on one aspect, the anchor becomes “set,” and you will find it difficult to mentally shift away from your perception. This becomes more difficult when emotions are engaged – you feel excited and energized because you’ve had that inspirational flash of insight, and before you realize it, you’ve dropped your anchor and your ship isn’t going to be moved, at least not easily.

There is a difficult balance to maintain here. Productive workplaces are filled with people who have strong opinions. You certainly don’t want to have a bunch of people walking around without opinions – talk about a real lack of engagement! The trick is to adopt Paul Saffo’s mantra of having “strong opinions, weakly held.”

Paul’s advice: “Allow your intuition to guide you to a conclusion, no matter how imperfect – this is the ‘strong opinion’ part. Then – and this is the ‘weakly held’ part – prove yourself wrong. Engage in creative doubt.”

Strong opinions are healthy, and we should all develop the best possible reasoning and evidence to support that reasoning. Just don’t too attached to what you believe, because that attachment will undermine your ability to acknowledge additional evidence that is in conflict with your opinion.

Optimism Isn’t Just for Developers

May 18, 2010

“Developers are overly optimistic.” When it comes to software project scheduling, that’s one refrain that I’ve heard almost once too often. The reality is that developers aren’t the only ones who are optimistic about work estimates.

A recent study by social psychologist Dr. Mario Weick shows that people who are in charge – those who set policy and decide on courses of action – make time predictions that are inaccurate and overly optimistic. Why?

“The more people focus on what they want to achieve, the more they tend to neglect impediments, previous experiences and task subcomponents that are not readily apparent,” Dr. Weick explains. “Power tends to increase people's focus on intended outcomes. Although this can be beneficial, in the context of time planning we reasoned that power would lead to greater error in forecasts.”

It isn’t because people have greater faith in their abilities or that they see things through rose-colored glasses, either. “…Power affects what people focus on when they plan the future,” Dr. Weick says, “and this seems to be the root of the greater bias in powerful individuals' time predictions.'

The problem with planning and estimating doesn’t end with developers or those in charge. People in general tend to underestimate task-completion times. It’s known as the planning fallacy. A study conducted in 1994 involving demonstrated that the students did a terrible job of estimating how long it would take for them to finish their senior theses.

When it comes to software projects, estimates are regarded as poor, and industry evidence supports this. The Standish Group’s periodic Chaos Report is a widely quoted source. The statistics appear grim:
  • Average cost overrun: 45%
  • Schedule overrun: 63%
  • Actual functionality delivered: 67%
While there are plenty of skeptics regarding the Chaos Report figures, no one doubts that there are challenges with software project estimation. My quick list of planning and estimating issues with software projects:
  • Because trying to predict an end date at the beginning of the project is begging for trouble. There is too much uncertainty involved.
  • Mistaking estimates for commitments. An estimate is supposed to be an approximation and not a precise figure.
  • Software development is a people-intensive endeavor, and people introduce a high degree of variability into the equation. The complex interactions and dynamics of the personalities involved cannot be captured in an estimate.
  • Everything isn’t known by everyone up front. There is a great deal of learning going on throughout the course of the project. 
  • Developers Everyone tends to be overly optimistic.

Managing Today’s Employee

May 14, 2010

My boss and I were talking to a few developers after a team stand-up one morning, discussing the deadline pressure of a customer deliverable and the impact that some unforeseen issues were having. Since we were both developers prior to becoming managers, my boss offered our programming talents to help the team.

This offer was met with immediate laughter.

Part of this was because there were some newer employees on the team and they had never even looked at any of our code, let alone witnessing us actually programming. They also recognized that our organization has everyone stretched in one way or another, and that we were filling other roles besides traditional management. (I’m also quite sure that to some people, the visual of managers doing “real work” is a great source of amusement.)

Even though the thought of managers doing the work of those who report to them is humorous, managers are the ones who evaluate the performance of those very same employees – and no one laughs at that. The reality is that the programmers who report to me do spend far more time coding than I realistically can, unless I find away to give up sleep.

While I have spent countless hours in the past designing and coding, these days my challenge is keeping conversant and up-to-date on technology, methodologies, improving my management game, and yes – keeping up with the various projects that we have in flight and my staff’s participation and performance relative to those projects. And just for fun, I’m also acting as a product manager for the products produced in our office.

This means that my staff understands more about their work than I do. They’re the ones immersed in it day in and day out. I can keep my fingers on the pulse, but I can’t know the nitty-gritty details. How do you manage individuals who by rights should know more than you do about their work?

For a start, maybe they don’t know more than you. Maybe they are just out of college, lacking in real-world experience. For the purposes of this discussion, let’s assume that they’ve got a several years under their belts.

A natural starting place is to talk with them about the work that performing right now.

You’ll discover if they are really enjoying what they are doing, or if there are problems lurking under the surface. The conversation shouldn’t end there, however. It’s similar to what you do when you interview people for a position. During an interview, you talk about what a candidate can do, but you also to talk about how they go about their work, right?

When I interview people, I want to understand that people have the demonstrated ability to accomplish the type of work that I am expecting of the position that I’m hiring for. This will include assessing their technical knowledge and ability. In addition, I want to determine the candidate:
  • Is a self-starter
  • Has demonstrated a desire and willingness to learn and grow 
  • Has critical thinking skills
  • Has the interpersonal and communication skills required to be a collaborative, team player.
  • Has the willingness to be a team player
  • Has confidence in their abilities and their ability to adapt to changing circumstances
  • Has the motivation and desire to produce high-quality work
These characteristics are highly desirable during the interview process, and they shouldn’t be overlooked once someone is through the door. The day-to-day management of knowledge workers like developers can and should be about how they are approaching their work, not just what they are doing.

Are your employees continuing to learn and grow? How are they planning on approaching the work that they are facing? Are they struggling in certain facets of their work? Is something de-motivating them, causing a slip in the output and quality of their work? Do they seem enthused about their current assignment? Are there – or do they anticipate – difficulties with those on their team?

Keep these characteristics in mind as you observe your employees throughout the day. Having a meaningful dialog about the work that they are going to perform will add real value in their eyes, because you are helping them to be successful by partnering with them before the fact instead of judging them after the fact.

Don’t Plan on Working the Plan

May 11, 2010

A good plan, violently executed now, is better than a perfect plan next week.George S. Patton

George Patton was a master at leading armies into battle and emerging victorious. He invested a significant amount of time and energy over a period of years in researching, experimenting, and refining his understanding of men and tanks in combat. He understood the value of planning, and he always sought to anticipate the enemy’s reaction to his moves.

As the quote above indicates, Patton also understood that to delay too long – waiting for perfect information – could cost battles and lives. He put effort into planning, but he was fully prepared to take action when the timing dictated that he should. And he didn’t always end up working the plan that he thought that he would at the outset.

A common quote in business is, “Plan the work, and work the plan.” As Patton understood and as many software projects have repeatedly proven,the problem is that all too often, plans don’t work out as we expect.

The military expends plenty of time and effort in the planning process. When it comes to execution, however, the military has uncovered some basic truths about the planning process that are invaluable with respect to business, particularly as the complexity of business continues to increase.

As Colonel Tom Kolditz noted in the book Made to Stick, “You might start off trying to fight your plan, but the enemy gets a vote. Unpredictable things happen.”

No battle plan survives contact with the enemy. – Helmuth von Moltke

This doesn’t mean that you shouldn’t plan. To the contrary, the act of planning forces people to think through the issues, to consider what could go wrong (risks) and to consider contingencies. And most importantly, if you are going to lead your army (or division, unit, squad, whatever the case may be), you need to have a direction.

Plans are of little importance, but planning is essential. – Winston Churchill

Plans are nothing; planning is everything.Dwight D. Eisenhower

Planning is a discipline that helps you to think about the terrain, check your compass, and to start out in the right direction. You will likely need to make adjustments once you are on your way, but at least you will be able to make informed decisions about those adjustments.

General Patton understood this; he was continually on the move during a battle, assessing where things could/would go wrong and helping to make corrections. He had an uncanny knack of anticipating where the bottlenecks would emerge and arrived on the scene to help keep things moving.

Patton, through his constant study and experience, developed a keen insight into the art of war that enabled him to not only plan well, but gave him the ability to anticipate problems and make those fast, critical adjustments that were necessary to win a battle.

Like war, business these days is continuing to change at ever-increasing rates, and it is growing in complexity. And with the economy in uncertain territory along with this, we all could use a better map and a good compass.

A fool with a plan can beat a genius with no plan. – T. Boone Pickens

And as Patton understood, waiting for perfect information can be costly. By the time you have perfect information the opportunity will have likely passed. So how does an organization deal with greater complexity and rapidly changing conditions using imperfect information?

Through something called Commander’s Intent.

Joint Publication 1-02, Department of Defense Dictionary of Military and Associated Terms, gives the following definition of Commander’s Intent:

A concise expression of the purpose of the operation and the desired end state. It may also include the commander's assessment of the adversary commander's intent and an assessment of where and how much risk is acceptable during the operation.

The Commander’s Intent is a statement written in plain English, and easily remembered. It can’t afford to be long, nor can it attempt to anticipate every possible scenario. If the Commander’s Intent is too detailed, it runs the risk of quickly becoming obsolete.

At higher levels, the Commander’s Intent is more abstract than it is at the lower levels. The objective, however, remains the same. “You can lose the ability to execute the original plan," Colonel Tom Kolditz says, "but you never lose the responsibility of executing the intent.”

It all boils down to this: The plan isn’t the strategy, the intent is the strategy. Tactics – the plan – help you get there. During the execution phase, you will most likely need to change your tactics to adapt to changing circumstances.

Don’t plan on working the plan… as you initially laid it out. But be sure to communicate your intent, set the boundaries, and let your staff take responsibility for executing the spirit and intent. And be there to help navigate through obstacles. Proper execution of strategy requires leadership throughout the process.

The Real Problem with Scrum

May 7, 2010

Since I’ve spent a few posts refuting Kai Gilb’s issues with Scrum, I thought that I would take a stab at articulating the real problem with Scrum. Most of what Kai has complained about Scrum to date doesn't look like a problem with Scrum to me at all.

The lightweight nature of Scrum makes it broadly applicable, but since it is new to many organizations, experience and true understanding is lacking. The implementation of the deceptively simple framework of Scrum can trip you up.

As Scrum adoption increases, we’ll hear more about Scrum failures. It will fail to improve the delivery of software projects, costing organizations significant time and effort to adopt a new approach only to end up (at best) where they were before they started using Scrum.

Today, many of the problems that organizations experience with Scrum are that they have a ScrumBut problem. The “We’re doing Scrum, but…”
  • We don’t have a product owner.
  • We don’t have a product backlog.
  • We don’t bother with daily standup meetings.
  • We’re not doing ... some fundamental activity that is and should be a part of the Scrum process.
As Jurgen Appelo noted in a recent blog post, Some Day Kanban Will Fail 75% of the Time, that there are those who state that “at least 75 percent of Scrum implementations fail.” Jurgen makes the excellent point that this failure rate includes those who are “doing Scrum, but...”

I call this a basic blocking and tackling problem. Despite the fact that Scrum is a lightweight framework that is not complex, teams and organizations skimp on implementing the basic mechanics.

The Scrum community is doing a great job of highlighting the ScrumBut problem, and I feel that organizations will get the message that they should implement the entire Scrum framework if they expect success with Scrum. The next big issue will be that a great many organizations won’t realize any significant gains from the experience.

Sure, the workers will enjoy their jobs more because they have more control over their workday, but there will be one BIG question lurking, and it is the same one we ask ourselves at my company; “Are we producing better software, faster?” And while having a happier workforce is a victory, can you – and should you – ask for more?

Yes. Because this is where real, meaningful change takes place. It is also where the true value of Scrum is realized.

Scrum is not just another process to create software. The standard activities of requirements management, software design, software construction, and testing should NOT be handled as sequential activities. The key to raising productivity and aligning development with the business using Scrum is to establish true collaboration.

Shared knowledge, shared understanding, and constant, high-bandwidth communication should improve productivity and align the development team with the business. For example, there should not be a situation where the team reviews a User Story and then the developers go off to design and build something while QA writes a detailed test plan and waits for development to provide that feature in a build, with no customer (or proxy) involvement. That is a operating sequentially, using Scrum as a “mini-waterfall” process.

Instead, teams should review the User Story together with the product owner, who represents the business (unless an actual customer is involved as a part of a customer team). Furthermore, this should be a vertical, testable slice of functionality delivered, and not a horizontal, “data access layer” (or some other tier). There should be constant communication, shared design, pair programming, and talking about issues or questions that arise.

In the end, there is a certain flow and rhythm that is established with truly collaborative teams that is virtually impossible for a sequential process to beat. This is more difficult to achieve than it appears, but the potential exists. For many organizations, this autonomous, collaborative approach is also a very different work model, and the correct, successful adoption of Scrum is hampered because there is little available in terms of ScrumHow manuals to guide implementations.

If you were to ask me – based on what I know and have researched to date – for a good, single source of information that talks about Scrum from someone highly experienced with the common pitfalls and challenges, I would pick Mike Cohn’s book Succeeding with Agile: Software Development Using Scrum.

I recently read this book and I really appreciated the depth of Mike’s experience, and I found the information that he presented both uncannily accurate and very useful. I feel that it is one of the best ScrumHow manuals available today, going well beyond the basic blocking and tackling of Scrum.

A second book on Agile development that focuses greater attention on the technical practices along with giving you another great perspective of Agile development is The Art of Agile Development by Shane Warden and James Shore.

The wealth of information contained in these two books is extraordinary, and well worth your time to read if you are heading down the Agile/Scrum path.

We Won’t be Managing White-Collar Factory Workers for Much Longer

May 4, 2010

In my last post, I warned of the dangers of being a “white-collar factory worker.” This is a follow-up post to discuss the same problem from another perspective: managing difference-makers and “factory workers.”

For people who are the difference makers, Dan Pink’s advice holds very true: “Traditional management is about compliance. If you want engagement, self-direction works better.”

I feel that there is another major problem in today’s workplace, one that places management in a difficult dichotomy. Even if you are a manager who embraces self-direction, the entire workforce is not prepared to be managed this way.

I’ll admit that there are those in leadership positions aren’t fully prepared to manage truly self-directed workers, and there are situations such as venture capitalists who want inexpensive off-shoring incorporated into business plans.

However, employees play a role here, too. I have friends that work in the trades as non-union workers, and they’ve told me that they’ve been astounded when they’ve worked side-by-side with union workers in certain jobs. They’ve literally been told to stop getting as much done in a day as they can, because they were making the union workers look bad. On those jobs, my friends said that they were able to breeze through the day operating at what they considered half-pace.

On the white-collar side of the fence, there are those employees who have learned the compliance game all too well. They don’t seek to operate outside the bounds of their job. They push any and all responsibility up the chain. They demand that their manager clearly define the boundaries of their job, their role, and the processes that they should be following.

In addition, there are those who don’t seek to extend themselves professionally. Pawel Brodzinski recently noted the lack of initiative on the part of many individuals when it comes to professional development in a recent post, People Don’t Want to Learn.

Managers these days are increasingly straddling a line between those who demand self-direction and those who demand direction, with all the various degrees in between these two extremes. And by the way, we’re using one HR system with a standardized annual review process.

I don’t believe that this will be sustainable or desirable in the long term. Continually raising the productivity bar will require that more time and energy applied to the more creative, high-return aspects of business. We’re running out of people bandwidth to continually organize and structure everyone’s day. People will need to understand the general direction and be a part of helping the organization get there by applying their skills and abilities as the strategic direction dictates.

My advice is that ultimately, you’re in a very bad place if you want someone else to fully define and orchestrate your day. If you expect a manager to explicitly define and organize your work, don't expect top dollar for the work. And increasingly so, don't expect medium-sized bucks for that work, either.

If your job can distilled down into a well-defined, repeatable process, your job is in danger of being commoditized. Translation: you will receive lower pay or your job will be moved off-shore, where it can be performed by someone else for far less pay. This might not happen tomorrow, but the potential exists. Follow the advice offered by Seth Godin, and strive to become indispensable, through things like:
  • Providing a unique interface between members of the organization.
  • Delivering unique creativity
  • Managing a situation or organization of great complexity
  • Leading customers
  • Inspiring staff
  • Providing deep domain knowledge
  • Possessing a unique talent
Be a professional, and keep developing yourself as a professional. The best defense is a good offense!