Tuesday, May 19, 2015

This is NOT the End.

This is not the last sprint. There will be more after this. You don't have to have everything this week, and it's more important to deliver than to have every possible feature crammed in. Also, there isn't a good reason to not retrospect or plan if we're going to keep working.

This is not the last test.  There are cases not covered yet, and the solution isn't complete. That's fine. We can write another test and then add the code to cover it. Working incrementally means we often have work in some in-between stage. Let's just get this test working, and then write the next. Programming, says Michael Feathers, is the art of doing just one thing at a time.

This is not the last change. We could try to cram it in like it is an unexpected interruption and a special occasion, but it's not. Changes continue until the last user deletes the last version of the software from the last machine where it is installed. Probably better that we make changes like this easier to implement and easier to fit into the schedule.

This is not the final refactoring. As much as we'd like to pretend that the code can be finished once and for all, it's just not true. This is not the last change, and not the last sprint, so the design will have to continue to evolve. If one refactoring makes it temporarily worse, that's okay. Sometimes it's like cleaning the garage in that you have to make it a bigger mess before you can get it cleaned up. So, code goes through stages and steps and evolution. It's okay.

This is not the last project we'll do. This is not the time to stop learning. There are plenty more where this came from. Even if some aspects of this project are awful, it won't last as long as you and I do. Even if it is great, there are still things to learn. We can't act as if all of the future depends on this one, because it doesn't.

You are not the last person who can take on work. You have competent colleagues, all competent to various degrees and in different areas, but there is a lot of overlap. You don't have to always say yes, or promise that you will personally do all the work. You can share work assignments, and you can defer to others. Take care of each other and yourself.

This isn't the only day.  Tomorrow will have new work, and new problems, and priorities. We don't have to have everything perfected and perfectly buttoned up today. We can lean from today and pay it forward as long as there is still a tomorrow. There has always been a tomorrow for almost everybody almost everyday. Forgive what it is, but use some of it to make tomorrow great.

This isn't the only job. As much as we might want this gig to go on forever, odds are it won't. After 36 years I've outlived so many companies I worked for, but the people there are now in other jobs and so am I. The people and the skills you are blessed with and develop are so important. Your longevity in this field depends entirely on the number of people who want to work with you. Be kind. Be helpful.

This isn't the only thing we'll have to learn. The need to learn is relentlessly ongoing. We might as well get used to the idea and embrace the dreadful constancy of it, so that it becomes instead a kind of never ending adventure. We need to love learning, and keep learning, and keep shoveling out room for our curiosity. We can afford to have the next big lesson come only to find us unreceptive. Open up, it's okay.

The whole world is still incredibly incomplete and moving. This is not the end.

Friday, May 8, 2015

The Company: Can we talk about it?

We talk a lot about changing cultures. There's a lot of inspirational, humanistic content in agile conferences and forums and books and blogs. We tell our success tales in front of rooms of people in both corporate gigs and public conferences, and even as some are applauding, we see people crossing arms and lowering their gaze and some even blushing or flushing.

Inspirational stories are great, but not everyone is getting inspired. Some are getting frustrated, depressed, or even offended. The stories don't ring true to everyone, these storytellers seem to see the world through rose-colored glasses.

There is an elephant in this room.

In most software organizations the overt goal is to produce and release valuable code to customers, as early and often as possible. However, if you ignore what you hear and look at what people actually do, the organization is not fully focused on delivering valuable code.

In fact, many of the things they do seem to be focused on preventing the release of code. In The Systems Bible John Gall noted "systems oppose their own best function."

The real primary goal in most organizations?  To preserve and enhance your position within the organization.

I know that it is not very politically wise to talk about this, but can we?  After all, most software organizations can tolerate defects, late releases, and even product failures. But you can get fired for asking the wrong questions or criticizing key policies, or overstepping your authority or even as a result of someone else's play to acquire the influence that you currently enjoy.

Nobody wants to get fired. Most of us can survive it, and might even land a more lucrative job elsewhere (provided we don't get that dreaded negative reference) but it's a given that we want to keep our job and maybe only leave it through promotion.

Not everyone wants promotion, but everyone wants to gather more respect, autonomy, and compensation. To do that, we have to preserve our place in the hierarchy, and improve it if we can.

It's not really a negative thing, but if we try to ignore it then we can't take advantage of it.

I suspect it can become a positive force in our world. For instance, at Industrial Logic we have been creating an organizational directive to call out hazards and risks so that we can resolve them.

To be a good Anzeneer is to call out latent conditions that harbor risks and hazards to our members and customers.  Our place in the world now is to create more safety. The culture is open to questioning habits and policies and choices.

Maybe your covert primary goal can become overt, and actually work in everyone's favor at your company.

Can you talk about it?

Saturday, April 18, 2015

Bonus for Productivity?

The Whole Idea Is A Little Insulting

Scholtes' /The Leader's Handbook/ says that motivation through reward is insulting -- it assumes that you have been withholding effort all this time, waiting for someone to offer you an incentive to actually do your work.

Hadn't really thought much about it before.

But yes, it does assume you have effort on tap that you're not applying to your work.
And yes, it is a little insulting.
And yes, you could intentionally hold back until offered another bribe (but just enough not to be punished).

Everyone wants a little more money, but P. Scholtes notes that it's out of alignment with the idea of humanitarian management who realize that the employees are their greatest asset.

Not Only That, But It Doesn't Work

Likewise, Daniel Pink reports that rewards for knowledge workers tend to have the opposite effect of that intended. It might not be a good idea for programmers and managers in non-manual-labor fields.

Pink does mention that the system works great for physical labor.

Then How Do We Reward Team Members? 

At Industrial Logic, we have bonuses.

We have a health-n-safety bonus which we spend making our lives better. Some pay gym memberships. Others buy standing desks or treadmills or bicycles to help them keep fit.  It's not guaranteed every year, and the amount reflects profitability or generosity instead of performance.

We also sometimes have a profitability bonus, split evenly across the board, to celebrate another great year. We don't count on them, but they've been helpful to us as well.

The bonuses don't buy loyalty or effort. They're congratulatory and helpful rather than transactional.

Do you have any stories to share about your great (or awful) bonus system?

What do you feel about what Pink and Scholtes have to say about knowledge workers and bonus programs?

Friday, April 17, 2015

Too Many Developers?

My friend and colleague Curtis Cooley recently blogged "You Might Have Too Many Developers."

Overall, I agree that smaller teams move more quickly and swarm more effectively on task than large ones seem to, and that there is definite overhead with large groups.

You already know some developers are more effective than others. 
What if you could find 1000 within the 2000 that collectively are twice as effective as the other 1000?
Joel Spolsky has claimed the best programmers can be as much as 10 times more effective than the worst programmers.

The argument continues describing how many developers are much better than others, and are better in a smaller group than they can be when they are encumbered by less competent programmers.

I also agree that smaller teams of more expert programmers make sense on many levels and represent a savings in frustration, cost, and time.  

As Red Adair would say: "If you think it's expensive to hire a professional to do the job, wait until you hire an amateur."

Mythic "better people"

I don't think that Curtis is wrong. I have seen teams with too many programmers, staffed hurriedly with warm bodies or with badly-defined HR requirements and biases towards archaic styles of work and project management.

Bad requirements build bad code, and bad human requirements tend to build staff badly.

I've seen managers repeatedly hire and fire for the same position, complaining "why can't I find the people who can do what I want them to do?"  Should we consider that either we're hiring from the wrong requirements, or we are asking for things that people cannot do?

There's an old saying about marriages that "If it's more than two, it might be you." I suspect this applies also to revolving door positions in a company.

Sadly, a lot of these revolving door positions exist when we are looking for unicorn developers -- magic omni-competent people who have hyper-productivity and efficiency installed in their DNA. People who never say no, never complain, and always deliver just the right thing on their first try and are never a problem to manage.

They are "better people." Programmers on staff, are, by comparison "not very good people" -- evidenced by the fact that we want more stuff than they can deliver. We're already frustrated with the system we have, and the answer must be "better people."

Deming has offered us the sound bite that 94% of our problems involve the system, and only about 6% of them are attributable to individuals.  That's harder to see when the work is largely invisible, as is the case with knowledge workers, instead of physical laborers.

It's just easier to see progress when work is motion and products are physical. All sympathy for that problem, but it goes wrong when we try to make management easier by treating knowledge work as if it were physical work.  Sometimes we want people who can do great information-type work as if it were great physical-type work, and who make management and measurement easy. Such is the nature of bad HR requirements.

Not recognizing the information-nature of the work makes industrial-age management a really bad system for managing software development, and "a bad system will beat a good person every time" Deming would quip.

Bad Systems?

Size may be the symptom of organizational dysfunction.

It may be that the organization isn't dealing with people well, and so it must have many of them. If it is only 10% effective,  it certainly feels as though the organization needs 10x as many people.

An organization's system may involve too much process around getting permission to do work, too many cycles through finished-work approval processes (reviews, QC, expenses, time reports). All of these can prevent quick feedback and learning. Without feedback and learning the productivity of programming is significantly limited.

The system may have strangled productivity so much that all the work being done is treated as a one-off rush job.

Perhaps the code base has been rushed so much that it has started to take its revenge in the form of immutable code and multiplying defects. There are always consequences for deferring crucial tasks indefinitely.

There might be a planning problem at hand, where the organization is trying to do large things in a single step. Without small steps (story slicing) and continuous delivery, there is no chance to exercise options. Instead the problem seems to be all about "going faster." Perhaps cutting scope is smarter and less expensive than adding headcount.

Or possibly you have evolved the system to work with 2000 developers during a rapid growth period only to find out now that you can't operate your current system as-is with only 200 or 20.  You will need a whole new (simpler) way of working to get back to being productive in small numbers.

Good Systems?

But maybe you have great people that you've worked very hard to gather and train and educate and you have given them reason to believe that you are looking out for their interests. 

Perhaps there are many of them because you've had such a great growth in the market place and having more experts (and a steady stream of new thought leaders) has kept you operational and cutting-edge. 

Maybe you are an extremely good organization with a great culture and your success has blessed you with fairly deep pockets. 

Maybe you are just looking for a way to continue operating, produce results well, and not break your commitment to the people who look up to you. 

You just don't want to let go of the people you have, and they don't want to go either. Maybe a lot of these people have shown leadership interest and potentially, and have earned jobs in management.

You want to preserve your organization because you have taken responsibility for the well-being of your chosen tribe.  Good for you. I see nothing wrong with that. I do recognize that it leaves you with some difficult questions and issues. I want to help.

Maybe the question isn't so much about how few people you really need, but how to maintain a humane, productive, innovative culture and introduce products now that you have the critical mass to take on many projects at once.

It may be that un-encumbering people by using a more lean or agile process will free up resources to do more creative and innovative work -- along the line of Google's famous 20% time. 

Curtis didn't say that you have too many people. He only suggested that you might

Monday, April 13, 2015

Individual Work Assignments: Neither Agile Nor Team

I managed to set off a small avalanche of retweets, agreement, and absolute angst in the past few weeks, when something I'd said sometime last year appeared as a quote in a lovely frame (thank you so much Agile Fortune!).

Here is the image for your enjoyment:

It seems that maybe I've touched on something that people are thinking about, and possibly on a point of contention in many organizations. 

Most traditional managements have a focus on resource loading and utilization. What we are learning about people who do knowledge work (for instance, software development) is that utilization of resources is exactly the wrong idea. 

Let's explore what I had in mind when I wrote the tweet:

What is a Team anyway?

For now, let's put the whole "agile" thing aside entirely. It doesn't matter if you're agile or not. I can pick that back up in a few paragraphs. For now concentrate on the concept of team.

To team (the verb) is "come together as a team to achieve a common goal."

A team is "a group of people who work together" (MW).

C.Avery says "the task is the reason for the team" -- a team is a temporary organization created to complete a specified goal, and their alignment is a defining characteristic. They're not an arbitrary assemblage of persons.

In many organizations, what they call a team is "people who report to the same manager, but who never share any work items, who have separate areas of responsibility, and who avoid communicating with each other so that they don't interrupt the other person's task."

A team is different from a group of individuals in qualitative and quantitative ways. One can sit in a single status meeting and tell the difference.

A group of individuals all have "their own work" and are responsible for clearing "their own plate."

They may have handoffs between experts, but they work alone, and minimize conversation and interaction.

They may be stack-ranked, so they often feel they are in competition and frequently their goals are in competition.

Groups of individuals all maintain separate areas of responsibility and separate sets of skills. As a result, a very turbulent work flow results with less-expert developers waiting on experts to (solo) complete parts of tasks. While they wait, they take on extra tasks (to stay busy) and soon there are many tasks in progress, few finished, and developers become overwhelmed.

The individual style of work is great for defined processes (assembly lines, etc) but for knowledge work, it seems to suffer more drawbacks than group work.

A team works together to accomplish goals.

A team uses interaction to complete work quickly and well, and to share knowledge and skill to build group competence ("watch the baton, not the runners").

They are in profound cooperation, and do not compete against each other. This is one of the reasons that Deming referred to performance appraisals as one of the Seven Deadly Diseases of Management (referenced also by Esther Derby's excellent article).

The work of an individual in a group cannot be assessed apart from the work of his peers.

In fact, individual assignments are considered an anti-pattern.

Teams are powerful, self-directed, and hard to "rank and yank." Individual awards and punishments don't apply. 

They're not as easy to manage as a set of individual drones who do as they're told, and whose work is solitary and easy to appraise. They're not under managerial control. But they get a load of work done and they learn and improve quickly.

What about that Agile stuff? 

In the tweet I am not saying that you cannot be a team unless you are agile.

I'm saying that you cannot be truly agile unless you become truly a team. 

Agile methods require us to start and complete work in very small increments, and to keep the code in a running state that is open to modification.

Consider two different situations at the end of a project:
  • 100% of the work is 70% done
  • 70% of the work is 100% done.
The former is an unmitigated disaster.
The latter is a workable situation and a qualified success.

Agile teams apply the maximum number of people to work on the smallest number of tasks, in order to bring each to completion soonest. This focus ("watch the baton, not the runners" in Lean parlance) makes it possible for us to have the most work completed and deliver it soonest.

Delivering high-quality, high-value code as soon as possible is the agile way. It's not something you can do well with a dozen people who don't talk to each other and don't sit near each other, and don't converse or participate together.  

Without teaming, necessary code hygiene will be abandoned as individuals rush the maximum number of stories to done. The primary value of teams in agile organizations may be to slow the rush and ensure work is done well. Without this care, work becomes increasingly difficult to complete through the life of the project, which is frequently observed and misdiagnosed as "teams slowing down." 

If you are working incrementally and evolving your code base, then you have to be more strict about the quality of the code, not less. Any unmanageable changes come back to haunt you very quickly, and any untested code can be broken at any time by any number of people.

Without the teaming, I'm not sure that any agile method can be successful. .

Without teaming, is it a team at all?

Monday, March 30, 2015

Can Scrum Teams Have Managers.

"Is it safe to say PM has to acquire new skills to make himself fit in the scrum process? " 
This question was asked in a scrum forum on Linked In, and many interesting and valuable answers were given.

It is pasted here verbatim because I want my answers to this question to come home with me, and to be available to my clients, peers, and colleagues.

The fear of "working without management" or "losing my management job" is pretty fierce in larger organizations, and I think it can be a misplaced or imaginary fear.

This answer was specifically pointed to people in a Scrum-specific forum, but information here applies generally in any number of organizational change contexts. Even in our migration to Anzeneering, we have seen/felt the powers permission and support.

On to my answers:

Strictly, yes. The biggest is not telling individuals what to do. It's hard for the individuals at first too. It's easier, once accustomed to command-n-control ("masters n minions") to continue the habits that keep things harmonious in the previous project. 

But let's leave strictly for a moment. Managers tend to be stewards of the 4 Ts (Time, Talent, Target, Treasury). They have influence on budget, can hire/rent/fire/shuffle people, can help communicate or coordinate scope changes across organizations (not just scrum teams), and have a certain budget to manage. These are not "part of" the scrum framework, but with these a manager of an organization composed of scrum teams can have a great deal of impact and influence -- hopefully for the better. 

In addition, someone who was a manager has two extra super-powers: Perspective and Permission. Sometimes these are as effective as the 4 Ts. People need to know how an organization is navigated and how to serve it (yes, in addition to serving the customer). 

And people tend to not do things that they do not feel the permission to do. Lacking a sense of permission, people keep their tools, practices, and quality exactly as they have always been. It is safer, organizationally, to work within the permission you have. 

The ugly fact of larger companies is that delivery of valuable software is a secondary concern. The primary concern on most peoples minds, most of the time, is their position and longevity in the organization. Becoming brave and blazing a path is fine for contractors, but it can get you fired out of a job you want to keep. Likewise, we can stay in the job even if we have late deliveries, bugs, and problems provided we work within the system. 

It is not something we are comfortable to talk about publicly, but it's true nonetheless.  Managers control empowerment.

In a larger org, the manager has a very important transitionary role and a very important supportive role, even if he does not have an official place INSIDE the scrum framework.

Your agreements, disagreements, amplifications, and puns welcome in the comments section. 

Friday, March 6, 2015

QCon London: Taking back development (Take Agile Back).

Ruud Wijnands and I just completed QCon London. I have a few new contacts, a few new stories, and we were able to present "Take Agile Back" -- a talk in three parts:

  • Take Back Agile: "If this is agile, take it back."
  • Take Back Agile: "Give me my agile back."
  • Take Back Agile: "... to your team." 
The point was not to shore up the defenses and protect the whole velocity/timebox/points/meetings nightmare, but to remind people that there were reasons that XP (and scrum) worked, and to return our thoughts to the experiments that resulted in a successful, productive, social process that got stuff done.

There are underpinnings to consider.

Safety (anzeneering) is one. It has to be safe to experiment in order to do things more intensely. We see people repeat some practices, but deny the right to modify the system via experiments and validated learning. This is a mistake. We need to find our own "two questions" and focus on never stockpiling our pain.

Permission is a key type of safety. Ruud and I both talked about finding permission, and how our mental impersonators (your "inner forbidding boss") need re-calibrating. We discussed the context shift developers need in order to get permission, and how trust and permission can be obtained in a transactional way. 

But most of all, it starts with concern for our value:effort ratio. This relates to the lean concept of "perfection" (absolute value with zero waste) and Ruud explained that it can be addressed with the accumulation of small improvements (see 2-Second Lean for more details). 

There was about an hour's worth of stuff, so I'm not going to use up this space with a recap.

However, I got a story from a developer in my elevator ride from the interview I had with Ben Linders on Friday: His team started to estimate the time it would take to clean up the code in order to implement a feature. He said it was the moment that everything changed for the better. They didn't ask permisison, they just included it in the estimate instead of estimating the time to type the new feature's code onto the pile of rotting code that they already had.

This story resonated with me. If you are that developer, please contact me so I can write more about your journey. I've seen this before, and I would love to hear more.