The Curse of Recurrence and Habit

Some habits are good. Others are productivity killers.

Here’s one example. Someone schedules a meeting. That’s bad enough, right? And the person decides to make it a recurring meeting — every week for as far into the future as anyone can imagine. Then it gets worse. Week after week, zombies (sorry, I meant people) arrive at the meeting wondering why they have to attend and hoping it gets cancelled. It becomes a habit and it just goes on and on.

Here’s another example. Each week a report is generated and distributed to thousands (okay, maybe just a few dozen people). Some dutifully look at it each week while others simply ignore it. Few remember the original purpose for the report. They merely recall that they are supposed to look at it each week. Now it’s a habit.

Habits are hard to break.

Crazy, right? It is and it also happens all the time in companies around the world. People get into a habit — a recurring event — and they just do it. Those recurring meetings are particularly nasty. Often, attendees will multitask. They bring a laptop to the meeting so they can be doing something else. Or, they call in even though their offices are just down the hall.

Multitasking? Really? Why not just cancel the meeting? Call a meeting when needed and only if needed. Before calling a meeting ask yourself if a one-on-one conversation is all that’s required. You can inform everyone else via email. If you believe that every decision needs to be a group decision, don’t bother, your project is doomed.

As for that weekly report distribution, kill it. Automate the process such that information is tracked and automatically presented in a dashboard for anyone who cares. Send out an email reminder if you must. (Pull people to the information. Don’t push the information to them! If the information has no pull, why bother?)

The curse strikes agile development teams too.

The same effect happens with daily stand-up meetings and retrospectives. They become so routine — boring — that no one pays attention. Teamwork deteriorates into individual contributors touting their efforts. Continuous improvement deteriorates into self-preservation. That’s the curse of recurrence and habit.

I’m a proponent of both daily stand-ups and retrospectives when they’re done right. You know the drill. There are plenty of references on this website and others on running proper stand-ups and retrospectives. Therein lies a hidden danger — the curse.

If those meetings become too prim and proper — too structured and routine — new and innovative thinking gets cast aside. Everyone learns the drill. They arrive. They participate as required. They leave — and get back to work. “Get back to work”, as if the meeting is not considered “work”.

• If the team shows up and everyone always stands or sits in the same place, you’re cursed.
• If everyone speaks in the same order every time, you’re cursed.
• If everyone uses the same words and phrases time after time, you’re cursed.
• If people are continually late for the meeting or distracted during it, you’re cursed.
• If the results of the meetings are always the same, you’re cursed.

Variety and variation will break the curse. Employ various techniques and styles to make the meetings interesting. Always start on time. Always end on time. Mix up the agenda and the format. Have different people run the meetings each time. Ask unexpected questions. Present a problem and brainstorm solutions. Watch the attendees. If any of them look bored, ask what can be done to improve the sessions. Take the advice. Experiment.

Stay agile. Don’t let the curse of recurrence and habit destroy your productivity.

photo credit: Rev. Bombasticos (ClintJCL) via photopin cc

You Don’t Need to Be Better. You Need to Execute Better.

Companies don’t need to be better than their competition, they need to execute better. You don’t need to be better than your coworker, you need perform better. Your team doesn’t need to be better than another team, it needs to do better.

Make sense? Simple, right? Not at all.

When we use the term “better”, we’re implying that someone or some entity is superior in some way to others like themselves. The other person or entity may be smarter, stronger, tougher, faster or cooler. I’m arguing that you don’t need to be any of those things to be better. (They all help, but none are mandatory for success.)

The one thing all of us must do to be better is execute reliably and consistently. Forget the excuses. Focus on execution. There will always be someone who is smarter, stronger or better looking. It doesn’t matter. You need to execute better than that person.

We see it all the time in sports. The best team (statistically) doesn’t always win. The fastest race car doesn’t always cross the finish line first.

In business, the company with the best product doesn’t always capture the biggest market share. The product using the best technology doesn’t always sell the most units.

The principles of agile software development and Scrum in particular support the concept of executing better. Amazing results are achieved with teamwork and collaboration among technical and business people. Here’s what you need to do:

• Tell others what you’ll do, and do it (even if you don’t want to).
• Deliver on your commitments (even if it hurts).
• Treat others with respect and dignity (even if you don’t mean it).

That’s it. Make sense? Simple, right?

photo credit: jot.punkt via photopin cc

How to Do Less and Deliver More

Have you ever had a manager ask you to “do more”? Or maybe he skipped the politeness and just told you to “do more”? It usually happens after you’ve indicated that you have too much to do — too many projects, too many tasks, and not enough time. Rather than offer help, all the manager gives you is “do more”.

It’s happened to me. I was once in a management job where an ordinary week was 55-60 hours long. If something out of the ordinary happened, it quickly became a 70-80 hour work week. Whenever I requested assistance, all I got was “do more”. Not surprisingly, the company eventually filed for bankruptcy. Luckily, I got out of there before that happened.

If you find yourself in a similar position, here are a few suggestions.

• Start by reviewing all the stuff you need to get done. Ask yourself what can be delegated to someone else or skipped entirely. Discuss your ideas with your team and your manager. Be as specific as you can be. You’ll get some push-back so be ready.
• When you’re feeling overwhelmed, describe the problem to your manager in detail. Be specific about what’s causing the issue and what assistance you need to get the job done.
• If additional staffing, either permanent or temporary, will help, say so. Offer specifics about the required skills and the length of time they’ll be needed.
• If more or better equipment and tools are needed, speak up. Do some research into what’s available and what value it will add.
• If you’re overwhelmed by administrative tasks, offer ideas for reducing or eliminating them. Even temporarily skipping some routine drudgery might free enough time to give you some breathing room.
• If you’re not getting the support you need from other team members, be specific about what you need and who should provide it.
• Be clear about any management interventions that cause delays. For example, preparing fancy status reports, attending routine status meetings, incessant requests for status updates, preparing documentation simply because the “process police” require it; these can be huge time sinks. Offer specific ideas for how these artifacts can be reduced or eliminated.
• Ask about priorities. What REALLY matters? The answer is likely to be something like ‘everything matters’. If so, point out that the team needs to focus in order to be most productive. Offer the manager an opportunity to guide the team or risk losing control of them.
• Make it clear that if you don’t get what you need, projects will be delivered late and/or quality will suffer. You’ll do your best, of course, but being stressed-out and over-worked will have a negative impact.

The major theme in these ideas is specifics — be as clear and precise as you can. If none of the above work, your manager is likely more interested in protecting herself than helping you. My best advice in that situation is find another job — you’ll be less stressed and more energized.

photo credit: net_efekt via photopin cc

Technical Debt Isn’t the Only Type of Debt You Need to Avoid

Technical debt is a frequent topic in blogs covering agile software development. But it’s not the only type of debt incurred by software development teams. There’s no shortage of ways for software developers to dig deep holes for themselves.

This post explores other forms of debt that lie in wait for the unsuspecting development team. You may knowingly choose to incur short-term debt with the intent to pay it off before it gets too large. Alternatively, you may choose to avoid any indebtedness so you’ll never have to deal with repayment issues. It’s up to you.

If you decide to take on some debt to meet a critical deadline or satisfy a business need, document it and keep track of it. If the product or service you’re supporting is short lived, the debt won’t matter. If you find yourself adding many new features and upgrades, the debt will likely have to be paid off eventually.

Some of the following debt types are subsets of technical debt (i.e. defect, performance and size) while others represent different types of debt (i.e. backlog, competitive, learning, testing and useability). Some are more sinister than others but they are all formidable challenges.

Software Development Debt Types

Backlog debt – The story backlog just keeps growing. The team does a reasonably good job of delivering completed stories but they arrive at an even faster rate.

Recommendation: Either expand the software development team (this may require adding another team) or push back on the product owner and the stakeholders encouraging them to focus on what really matters in the software.

Competitive debt – Your company’s competition gets new products and services to market faster than you and grows its market share.

Recommendation: Your team is too slow. You need to crank it up. Consider adding more (and better) people. Avoid seeking perfection in the product or service. Make sure the software is “good enough” and move on.

Defect debt – The bug count keeps increasing despite the team’s best efforts to fix bugs.

Recommendation: Your team is sloppy. Make good engineering practices a priority. Focus on preventing defects using pair programming, code reviews, test-driven development and related techniques.

Learning debt – New technologies and tools are appearing yet the team continues to use what it knows and lacks the skills it needs to adopt new ones.

Recommendation: Allocate time for training, learning and experimenting. Just do it. Identify technologies and tools that will benefit the company. Make a strong argument for acquiring the skills and push for them.

Performance debt – The software system’s response time keeps increasing. It takes longer and longer to perform routine tasks.

Recommendation: This is similar to defect debt in that good engineering practices will help. Set performance goals, include them in acceptance criteria, and incorporate performance testing into the development process.

Size debt – Memory usage keeps increasing. The software’s footprint keeps growing and as it does, load times get longer.

Recommendation: Memory handling problems can be vexing. They creep up on you and get out of control. Be vigilant. Monitor memory usage during test runs. Identify memory hogging areas of the code and improve them.

Testing debt – The percentage of the system not regression tested keeps increasing. QA has their hands full keeping up with new features.

Recommendation: It’s only natural to focus on testing new features and functions. However, regression testing is almost as important. Hire good testing talent and invest in automated testing tools.

Usability debt – The software becomes more complex and difficult to use. Feature creep produces so many options that many users are overwhelmed.

Recommendation: Usability is often driven by the software developers. Yet, what makes perfect sense to them may be unintelligible to the average consumer or business person. At a minimum, conduct periodic usability reviews and make implementing the feedback a priority.

photo credit: StockMonkeys.com via photopin cc

If You Develop Software in Iterations, Are You Agile?

Let’s say your team deploys a new software release every four weeks. (I’m a big fan of short release cycles. In fact, I think four weeks is too long but let’s try that.) On the surface, the team appears to be using an agile development approach. But let’s stir the pot a little.

What if I tell you that the team spends the first week of each cycle planning and designing? They have a rule stating that the content of the next release must be finalized during the first week. Change requests are allowed but usually deferred until the next cycle. They spend part of the first week documenting and designing the changes. (Hmmm, this “agile” approach is starting to show some wrinkles.)

The team implements the features that made the cut during weeks two and three. The developers perform unit tests and fix the defects they discover. Toward the end of week three, they package the software and deliver it to the quality assurance team. (At least, that’s how the process is supposed to work. At times, development runs late and spills over into week four.)

During week four (or what’s left of it), SQA tests the software and reports defects. If time allows, developers fix the defects and send another build to SQA for testing. If time doesn’t allow, the known defects are noted in the release notes and SQA testing spills over into the next cycle (or simply stops). Defects found beyond week four may not get fixed in the next cycle if they miss the week one planning window.

Iterative, yes. Agile, no!

I try to stay away from dogma. For example, ‘to be agile you must have daily standup meetings’ (the team has to stand or it doesn’t count). Or, ‘you can’t be agile if you use sprint zero, hardening sprints or any other technique that doesn’t focus on completing user stories’.

But there is one principle that I steadfastly maintain — to be agile, the business, development and SQA teams must collaborate. (In an ideal world, there would only be one team and collaboration would be simpler. The world is not ideal. Get over it.)

True collaboration must happen every day, not every fourth week. SQA should be testing new builds daily (you are doing daily builds, right?). The business should be actively involved in the development process daily (you told them they must be engaged in the effort, right?).

Iterative waterfall techniques work in some environments. If you absolutely, positively must use waterfall, please iterate. However, if you want to be agile, you must collaborate. There is no substitute.

photo credit: jaygoldman via photopin cc

Management By Proxy and Agile Development Don’t Mix

Following the rules isn’t good enough.

Do you manage by proxy or are you being managed by proxy? It works like this. A manager or management team defines lots of rules — you must do this — you cannot do that. Been there? Some of the rules are sensible like those related to timely response and quality control. Others, not so much, like those that call for filling out forms or submitting requests for every issue no matter how small or insignificant.

The manage-by-proxy manager simply monitors compliance. His first response to any question is “Did you follow proper procedure?”. If your answer is no, you’re told to go back and follow the procedure. If your answer is yes, you’re told what the next step is according to the procedure.

I’m calling this “management by proxy”. The proxy is the procedure. That’s a management job you gotta love. Just pull out the rule book, find the appropriate entry and read it. The rule book manages the team not the manager.

To my shock and awe, some employees actually like this approach. They know exactly what they need to do (and not do). They believe that as long as they follow the rules they have nothing to fear — even if something goes wrong. Disaster may strike but as long as you followed the rules, you’re protected.

Those who create need more.

The approach works in many situations where people are performing jobs that demand accurate repetition — the same work must be performed in the same manner repeatedly. The end results are well known. The number of things that can go wrong is constrained. Makes sense, right?

Enterprise software development is different. The end result is often envisioned but not known. The number of failure types is difficult to quantify. Management by proxy is often attempted but rarely works. You’d need a rule book the size of a multi-volume encyclopedia.

Agile self-organizing teams and rule books are hard to mix. We all need to “know the rules”, of course. Yet, one of the best kept secrets to successful agile development is letting the team figure out the rules as they go. And, empowering them to change the rules as needed.

Skip the Encyclopedia

If you’re a manager with a background in management by proxy, learn to let go. That will only happen if you have respect for your team. Be open-minded and transparent. Be willing to accept small failures as learning opportunities.

If you’re a developer accustomed to management by proxy, learn to rely on your teammates. The best agile teams show mutual respect and help each other. They swarm to the aid of any team member in trouble.

Rule books don’t create great software. People do.

photo credit: two instincts via photopin cc

You Want to Change Your Software Development Approach, But How?

If your team follows a traditional, legacy approach to software development and wants to convert to an agile approach, how should you go about it? Let’s say you want to convert from a waterfall approach that uses a strict command-and-control model to Scrum that uses a self-organizing team model. How would you get from here to there?

There are many ways to undertake this change. None of them are quick or simple. Small organizations are more likely to succeed than big ones simply because they have less invested in the status quo. Big organizations have much to protect and preserve.

Here are two extreme examples of how you might proceed:

1. Dump everything you’re doing now and adopt all new techniques. Don’t consider anything sacred or untouchable. Change everything.
2. Change one thing, try it out, let it settle, then change something else. Approach the switch slowly and deliberately.

Which option is better? Which option will produce the better outcome? It’s up to you.

Advantages of #1

• Gets all the pain and discomfort out in the open immediately. Lets everyone know what’s going to change.
• Allows the team to focus in building competence with the new approach. There’s nothing to preserve.

Disadvantages of #1

• Causes maximum disruption which might jeopardize a product or service release.
• People may get confused and frustrated increasing the odds of the new approach failing completely.

Advantages of #2

• Minimizes the pain and discomfort making the transition manageable.
• Allows the team to focus on just one aspect of the new approach at a time building expertise as they go.

Disadvantages of #2

• Spreads out the pain and discomfort over a long period of time creating a difficult work environment.
• Increases the odds that the new approach will never be fully implemented.

If you select #1, be ready for plenty of turmoil. Offer lots of support, training and coaching. Be willing to accept some small failures and some employee turnover.

If you select #2, be vigilant. Keep pushing new ideas and new techniques. Do not accept “good enough”. Keep marching toward the final goal.

Getting Stuff Done Leads to Happier and More Productive People

I have good days and not-so-good days. I’ll bet you do too. My good days are the ones that leave me feeling a sense of accomplishment. That happens when I get something done — finished, not just “worked on”. My bad days are the ones that leave me wondering what I did all day.

You see, it’s not simply a matter of being busy. I have a lengthy backlog of work — more than I will likely ever finish because it seems to arrive faster than I can finish it. I’m always busy but I crave more. I need to be done. I need to finish stuff.

If you’re like me in this regard, and I suspect you are, your job satisfaction and productivity have a direct relationship to how much work you get done — that’s finished, acabado, fini, finito, fertig, consumandam. How often do you hear people bragging about what they spent time on? Rarely, right? They brag about what they accomplished. What they completed. What they got done!

We all need more good days. People are energized by finishing. We derive job satisfaction from finishing a major task — accomplishing something of value. All of us should be finishing something significant every day — every single day.

Another Reason Why Waterfall Doesn’t Work

That’s a huge problem for software developers in traditional development organizations. They are forced to spend days, sometimes weeks, working on documents and diagrams. After all that work, they’re forced to wait for some bureaucratic approval process to complete — it’s hurry up and wait all over again. Or, they may be forced to summarize the documentation in a PowerPoint presentation and deliver it to a committee. As each day passes, ‘just shoot me now’ becomes more and more appealing.

Productivity declines. Output volume shrinks. Quality suffers. Managers are oblivious because people appear to be busy as progress is being recorded in weekly status reports.

Management 101

The secret to better morale, improved productivity, and superior results is unbelievably simple. Let your teams finish something. Note the word ‘finish’. I didn’t say “do something”. I said “finish something”! Stop creating busy work. Dump the approval cycles. Remove the impediments.

In addition, when your team needs something from you such as an approval or an upgraded development tool, make it happen. You’re putting a lot of pressure on the team and some of that pressure will push back on you. It’s only fair that you respond quickly.

Improving morale isn’t brain surgery. It’s common sense. To create more good days define simpler accomplishments, remove impediments and get out of the way.

photo credit: jayneandd via photopin cc

Fail, Learn, Assess and Try Again

I don’t know about you but I hate to fail. I’m not kidding. I REALLY hate failure. And that is one of the scariest aspects of agile software development. To succeed, you have to be willing to tolerate failure. In fact, if you’re not experiencing any failures, you’re not pushing yourself or your team hard enough.

Understand that I’m not referring to monumental failures. No one wants to see their million dollar product launch fail. (I don’t even want to see my $1,000 project fail.) That’s why agile principles encourage us to fail fast. Those quick failures tend to be small and relatively inexpensive. They are learning opportunities that help us avoid the big failures — the catastrophes.

Take a chance. Try an experiment. If you’re unsure about an approach or a technique, give a try. Run a test. If it fails, you haven’t invested much time or money so there’s little waste and no harm. It’s a lot better than spending days writing, reviewing and revising documents hoping that you haven’t missed anything.

Use Real Data

One area where you have to be extra vigilant lies in the data set used for your tests. You may get a favorable trial result using limited or artificial data inputs. When the software is deployed to a production environment with 1,000 times more data and many more boundary conditions, what worked in development may crash and burn.

I’ve seen this happen many times over the years. Software that responds instantly in development slows to a crawl in production. Or the software handles the artificial data set cleanly but when presented with real business data, numerous failure points are exposed.

Develop and test with real business data if you can. If time and money don’t allow for replicating the business data in development, do a trial production deployment. Be absolutely certain that you can back out whatever changes you make and restore the prior state quickly. It’s also a good idea to instrument the software. In other words, add extra logging and tracking functions so that you have good information for analysis in the event the trial fails.

If things go smoothly, you can re-deploy without the logging and tracking functions or, better still, simply turn off the logging via a configuration parameter.

Failure doesn’t have to threaten your career or bankrupt the company. Take prudent risks. When things don’t turn out as you hoped, learn, assess and try again. That’s agile!

photo credit: Honda News via photopin cc

The Simplest Way To Get More Done Is To Do Less

Software developers, testers, analysts and managers are known to be detail oriented. We need to know exactly what needs to be done so we can devise and implement software algorithms. We need answers to detailed questions so we can make the right implementation decisions.

Meanwhile, business people don’t always have all the answers. This is particularly true for new business initiatives. These are often experimental. They represent learning opportunities. If the business teams had all the answers, would they need high-caliber (that is, expensive) software people?

Business Really Matters

I work with multiple business groups. They often ask for new data elements or new software algorithms. Sometimes they know exactly what they want and what they’ll do with the information. Other times, they only have a rough idea. The actions they’ll take after seeing the results depend on the results they see. The analysis will, in turn, generate new requests for the software team.

These situations are more common than not. Running a business is not an exact science. It demands flexibility and rapid responsiveness. Whenever I direct questions to the business stakeholders and receive answers that are vague or general, I work with the development team to assure that the software can flex with the business.

For example, if someone tells me that are interested in data elements within a broad range of values, I’ll make sure the range can be changed by simply editing configuration parameters. If someone gives me a list of data elements, I’ll make sure the list can be changed by updating a configuration table.

Does your team seek out ways to do less?

Part of being agile is designing software for change. These types of configuration changes should be normal operating procedure. They aren’t technical changes and don’t require change management or backlog grooming.

Take a look at your backlog. Look for ways to combine stories or eliminate the need for some of them entirely. Doing less is a perfectly valid way to deliver more. The alternative is to slow down the business and that’s a dreadful outcome.

photo credit: Brett Jordan via photopin cc