Great Technology Isn’t Enough For Being Agile

We have a disconnect in the agile community. Agile approaches to software development are not about technology departments like Information Technology, Engineering or Research and Development. Agile development approaches are about customers, knowledge workers, and successful outcomes.

This fundamental concept seems to be difficult for many companies to grasp. Or, maybe many managers and developers prefer to ignore the broad-based, core aspects of being agile and prefer to focus on the easy stuff. It’s much easier to focus on your job and your team’s activities rather than the broader corporate goals.

Whether your team applies the principles of Scrum, Kanban, Lean, XP or some combination of all of them, you’ll need many skills to be successful. In addition to the obvious technical skills, successful teams need active participation from marketing, product management, finance, customer support and security administration teams — at least.

The major concepts behind agile software development aren’t technically oriented. They are people and process oriented. Consider this list of agile principles:

• Value creation
• Shared knowledge and pairing
• Multidisciplinary teams
• Continuous improvement
• Quality results
• Collaboration
• Customer satisfaction
• Change acceptance
• Simple techniques
• Trust and respect
• Self-organizing teams
• Short cycles
• Backlog management
• Daily 15-minute standups
• Minimal work-in-progress
• Definition of done
• …I’m sure you can add others.

The point is that by focusing exclusively on the technical contributors and their skills we also focus on the technical aspects of the solution. Yet customers don’t care how the software was built or what tools and technologies were used. They care about quality results delivered in a timely manner.

Great software delivered late is a poor outcome. Great software delivered far above the expected cost is a poor outcome. Crapware delivered on time and on budget is a poor outcome. Software that meets all the technical and internal goals but doesn’t satisfy customers’ needs is a poor outcome.

Are you following this? Delivering software that everyone (software developers, business community, and customers) believes is great is hard to do. Agile techniques are no guarantee but they’ll improve your odds — if you adopt a comprehensive view of your approach.

photo credit: lumaxart via photopin cc

10 Reasons Why Your Team’s Software Is Crapware

Crappy software. It’s everywhere. There is far more poorly-designed software than well-designed software. So much more, in fact, that we are literally drowning in crapware. It gives all of us in the software business a bad reputation. I hate it.

You’ll find lots of information on how to build better software (just click here). However, tools and techniques can only get you so far. If your company is serious about building the best software in its market segment, change your attitude. Here are a few suggestions.

1. Lower the stress level. I know there are occasional needs to crank it up and push hard to get a project done. However, in some companies, every project is like that. It’s wrong. It generates waste, rework and paranoia. Lighten up. I’ll bet software quality improves and productivity increases too.
2. Cut back on the meetings. Everyone seems to hate meetings and yet they are ubiquitous. Just stop! Cancel them! Move on! Having a meeting must not be your de facto approach to dealing with problems. Meetings should only be held when there is a clear and pressing need. Try walking down the hall and having a one-on-one conversation instead.
3. Reduce the formality. Lighten up. Relax. Make every day, casual Friday. Even Steve Jobs wore jeans and a turtle neck. People should be able to speak freely. Having to carefully select every word and make every detail politically correct wastes time and stifles innovation.
4. Don’t be a pointy-haired boss or a seagull manager. Managers and tech leads do not always know what’s best. That’s worth repeating — managers and tech leads do not always know what’s best! Assembling a collaborative team is the best way to determine the optimal solution to a problem.
5. Make it fast. When developers have to wait for software to load or simple file copy operations to complete, their minds wonder. They’re more likely to pick up the smartphone and check Twitter and Facebook. Invest in high performance systems. They’re worth every penny. Then, identify and eliminate bottlenecks. See how much more gets done.
6. Mix it up. Many companies like dedicated and highly-focused employees. I hope they also like high turnover because that’s what they’ll get. Cross-train and assemble multidisciplinary teams. Everyone will be more satisfied and productive.
7. Offer developers multiple development environments and tools to choose from. Having everyone use identical configurations makes sense. They are easier to maintain and troubleshoot. But at what cost? Forcing developers to use tools they don’t like only slows them down and encourages them to find work-arounds. It’s not worth it. Embrace diversity.
8. Upgrade. Some companies stay with what they know too long. They use a software package until they just can’t use it any more and are forced into upgrading. That’s dumb. Stay current. You don’t need to jump on every new release but you should upgrade at least once a year. (If the vendor isn’t producing new releases at least once a year, find another vendor!)
9. Implement reasonable security constraints. Don’t lock down your environment so tightly that even simple tasks are hard to do. Implement my simple productivity rule; any group that mandates a new process or procedure that reduces productivity, must provide an offsetting productivity improvement. Let them wrestle with that mandate.
10. Ask more open-ended questions. We all need to tell less and listen more. If you’re still wondering why your software is crap, go back to the top of this post and read it again.

photo credit: illuminaut via photopin cc

Some Tips for Guiding, Not Controlling, Software Developers

I like to move fast. I like having the “first mover advantage”. I don’t believe that my team needs to be smarter than yours or better at what we do (though those attributes certainly help). If we can simply move faster, we’ll have the advantage and we’ll be more likely to succeed.

Regrettably, I work with many software managers who don’t see things that way. They believe that success depends upon staying in control. They want all activities to be planned, documented and approved. I get it, but that attitude builds a major barrier.

All that planning, documenting and approving takes time — lots of time. I’ve seen software development projects requiring less than a month of building and testing — that’s 3-4 weeks of writing code and thoroughly testing it. Yet, 6-8 additional weeks are spent planning, prioritizing, documenting, reviewing and approving. So a 3-4 week project takes 9-12 weeks!

You can’t lock down the team and still be agile.

Yeah, I know. I’m exaggerating a bit. We need a few days of planning and documenting even within agile development projects. So my 3-4 weeks is probably more like 4-5 weeks — fine. It’s still about half of the total calendar time actually expended.

I’ll also point out that not all of that 6-8 weeks of administrivia is work time. A significant portion of it is spent waiting — waiting for meetings, waiting for reviews, waiting for approvals, and waiting some more.

Warning: While your big enterprise is waiting, your small competitors are gaining first mover advantage. You may release a better software system but it could be too little, too late. You end up doing the right thing at the wrong time.

You might think that the solution lies in agile software development but it doesn’t — not really. The solution lies in your mindset, your behavior. Software development teams need guidance not controls. They need to be led not directed.

If you put your software developers in lockdown, you’ll spend vast amounts of time managing the lockdown and little time delivering results. If you give the software developers some direction and running room, you’ll spend more time evaluating results and little time issuing directives.

Will mistakes happen? Of course, they will. But the mistakes are more likely to be small, easy to spot and recoverable. The team will come out way ahead of where it would have been with a heavy handed approach. Big design up front often results in big mistakes at end.

Here are a few tips for releasing control and offering guidance instead.

• Keep deliverable cycles short. (Team deliverables should be no more than 4 weeks though I prefer 1-2 weeks. Individual deliverables should be no more than 5 days and 1-2 days is better).
• Use whatever metrics you like to track activities over time but mix them up. (Metrics are notoriously easy to game. Once people learn the system, they also learn how to use it to their advantage. Mix up your metrics.)
• Trash the long, fancy document templates. Reward people who can get to the point and convey an idea quickly.
• Offer samples. If there’s a document, code snippet, diagram, etc. that you really like, display it as a guideline and let the team try to improve upon it.
• Set high quality standards and don’t compromise. Set firm deadlines and hold them. Reduce scope to hit target dates and/or budget constraints.

Let the deliverables and the results drive the team’s progress.  They’ll get more done in less time with better quality.

photo credit: mallix via photopin cc

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.