Don’t Just Change the Rules, Change the Game

Several studies have shown superior software development success rates when using an agile approach like Scrum or Kanban versus a waterfall approach. Does using a waterfall approach to develop software cause many projects to fail? Conversely, does using an agile approach cause projects to succeed?

I wish it was that simple. Ultimately people cause projects to succeed or fail. People are drawn to people like themselves. People are drawn to environments and cultures they prefer. What characteristics do you look for in the people you hire?

Waterfall approaches to software development are prescriptive. They use command-and-control, phases, gates, documents and approvals to get things done. What kind of people, do you suppose, are attracted to those techniques?

Agile approaches are collaborative. They use teamwork, self-organization, conversations, visuals and feedback to get things done. What kind of people, do you suppose, are attracted to those techniques?

Real Change Takes Time

I’m not a psychologist or sociologist so I’m not going to attempt a deep dive into these ideas. My point is that if you want to improve your software development results, you need to take a hard look at the messages you’re sending and the people you’re attracting.

Why is this so important? If you decide to change your development approach, you’ll need to change your people too. How are you going to do that? It won’t happen in a sprint or two. It will likely take a year or more to completely transition from one approach to another.

In a large organization, you’ll have multiple development teams. Are they all going to transition at once? If so, it will be a huge undertaking. If not, how will interteam dependencies be managed when one team is using Scrum and the other is using waterfall? Their deliverables will not be aligned.

Adopting agile software development is not simply a matter of changing the rules — you need to change the entire game. What would you do if you wanted a basketball team to play ice hockey? How about a soccer (football) team converting to basketball? It would be a colossal transition requiring plenty of training and conditioning. Some players would not be able to adapt. New players would need to be recruited.

That’s what you can expect when going from a traditional, prescriptive, software development approach to Scrum or Kanban. You can make it work if you’re willing to invest the time and effort. Do you have the time?

photo credit: fchmksfkcb via photopin cc

Writers Can Teach Us Something About Writing Software

In this post, I’m sharing a technique for writing a software module with you. I’m assuming that we are implementing a user story and that the acceptance criteria are clear. The story has been divided into a set of tasks and the task durations are known.

It’s an approach that works well for me though your mileage may vary. I strongly urge you to refine and tune the approach to your needs and most importantly, to your work style.

If you’ve ever had to write a report, proposal or even a specification, you may have heard advice like the following:

1. Establish a time interval, say 10-15 minutes and set a timer.
2. Work on the outline.
3. Get your major thoughts written down.
4. Don’t think too much, don’t analyze, just write.
5. If you get stuck on an item, skip it.
6. When the timer expires, go back and organize what you wrote into sections or chapters.
7. Reset your timer for another 10-15 minutes.
8. Write a section until the timer expires.
9. Forget about grammar and spelling, just write.
10. Go back to step 7 and repeat for each section.
11. Now go back and do some editing for grammar and spelling.
12. Make additional passes as needed until the document is complete.

What does this have to do with writing software?

Of course, writing software, in any computer language, is more complex than writing a report, proposal or specification. It’s not necessarily more difficult. It’s more disciplined. There are many more rules to follow and external dependencies to worry about.

Despite the added complexity, you can follow a structured approach like the one above. Let’s say you’re implementing a user story. You’ve likely broken it down into a set of tasks. You should have a rough idea of how long each task will take. Many developers will approach the story implementation serially. That is, they’ll work through the task list sequentially.

I do it differently. I iterate over the list of tasks. Here’s a basic approach that you should customize for your situation.

1. Establish a time interval, say 25% of the total estimated story implementation time, and set a timer.
2. Create a skeleton of the code (there may be 2 skeletons — one for test code and one for the story).
3. Get the major sections of the code defined.
4. Don’t think too much, don’t analyze, just create the structure.
5. If you get stuck on a section, skip it.
6. When the timer expires, go back and review what you wrote. Note any areas that need more thought.
7. Reset your timer for 25% of the story time divided by the number of code sections you have.
8. Write a section of code until the timer expires.
9. Forget about covering every detail (e.g. error conditions), just write.
10. Go back to step 7 and repeat for each section.
11. Now go back and do some editing, testing and debugging.
12. Make additional passes as needed until the code is complete.

The approach will vary depending on the situation. For example, if I’m unsure about how something might work or if it can even be done in the manner I’m thinking, I’ll make a first pass targeting the area I have questions about. Once I get that ironed out, I’ll build out the rest of the code as described above.

There you have it — a simple iterative technique for writing software modules. Give it a try.

photo credit: MaryLouiseEklund via photopin cc

Binary Choices are Better When Choosing Software Features

In the world of agile software development, there’s a lot of emphasis on things like story estimates, daily standups and team retrospectives. Those things are important but there’s a serious problem that none of them address — feature set. What features should the software have in the next release?

Waterfall development practitioners tend to include everything they can in their requirements specifications — if anyone requests it, put it on the list. Is it any wonder that those software projects take many months or even years to deliver anything of value?

Agile development practitioners talk about minimums — minimum viable product (MVP) or minimum marketable features (MMF). Both concepts appear reasonable but a critically important question is left unanswered. How is the minimum determined?

Try a Simpler Approach

The simplistic answer is that it’s up to the product owner. Someone has to have the final say, right? Feature requests come from many sources including software developers, product managers, marketing experts, senior managers, and customers. Every one of them has a unique perspective and different needs. The product owner can help sort it all out but it’s never easy.

Let’s not forget the adage that people often don’t know what they want until they see it. The PO may spend many hours deriving MVP or MMF only to find out later that customers (the only opinions that really matter) either disagree with the choices or changed their minds.

I suggest approaching feature prioritization as an iterative process. Don’t devise elaborate priority matrices or scoring systems. They are confusing and subject to manipulation. Instead, take all the features of interest and let the sponsors, stakeholders and end-user representatives classify them using just two categories like:

• Vital
• Non-Vital

Let everyone know that only features marked vital have any chance of making the next release. In the unlikely event that the vital feature list is short enough after one pass, you’re done. If not, you’ll need to repeat the process using the vitals only. If the list is still too long, do it again.

If you get stuck, that is, everything left is vital but there’s too much to do, let everyone know that the PO will make the final decision. Once the list is final, there is still one thing left do to.

The development team needs an opportunity to review the final list and look for inter-dependencies. For example, vital feature ‘A’ may require that non-vital feature ‘Z’ be implemented. Don’t skip this step!

photo credit: Pete Reed via photopin cc

Faster Business Is Better Business When You Need to Change

Can you get your software to market faster by following agile software development principles from Scrum, XP, Kanban or Lean? That’s a complex question that generates controversy no matter how I answer it. I’m okay with controversy so my answer is yes — if you give the team time to mature.

Regardless of what you do or how you do it, doing it faster is often a good idea. The logic applies to any endeavor. Going faster can make you better — just don’t go so fast that you lose control. Here’s why you should go faster.

1. Faster highlights weaknesses in the current process.

When you have to go faster, you’ll question the process you’re being asked to follow. You’ll want to know why tasks are being done in particular ways. Hey, you’ll want to know why some tasks are being at all!

2. Faster exposes bottlenecks.

This is a Kanban principle, right? Minimize work-in-progress. Work will quickly pile up behind people and workflows that can’t keep up. This will force the team to take corrective action to empty the queues.

3. Faster tests the team’s skill levels.

Those who are good at what they do will rise to the challenge. They’ll find ways to work smarter and get more done in less time. Those that aren’t so good, will fall behind.

4. Faster forces focus.

The best way to get more done in less time is to focus. Eliminate the distractions and the busy work. Concentrate on the really important stuff and get it done. You can go back and fill out the paperwork later.

5. Faster makes you think.

The team will question everything in a tireless search for better performance — processes, roles, tools, features and rules are all fair game. Going faster means no sacred cows.

Faster Doesn’t Mean Risky

Senior managers often create a sense of urgency around corporate initiatives. They deliberately stress their organizations and observe how they react. The stress highlights bureaucratic bottlenecks and often generates new ideas and better team performance.

Try going faster. Some will argue that more mistakes will occur. So what? Fix the mistakes and keep improving. You’ll likely still be ahead of where you would have been had you gone more slowly.

Be smart. Take prudent risks. If something gets seriously messed up, stop and evaluate. Maybe you pushed the accelerator too hard. You may need to slow down a little — but only temporarily. Faster business is better business. Give it a try.

photo credit: ATOMIC Hot Links via photopin cc

Hire the Best People By Focusing on What Matters

In my post “Don’t Just Prioritize User Needs, Prioritize the Process Too”, I discussed the need to prioritize the elements and artifacts of the software development process. In this post, I’m turning my attention to the hiring process.

When your team needs to bring another developer on board, what do you look for? If yours is like most teams, you compile a list of technical skills something like this:

• PHP
• Javascript
• Eclipse
• Spring framework
• etc.

You may add some non-technical skills to the list like this:

• Good communication skills
• Team player
• Works independently
• etc.

And just for good measure, you might add…

• Walks on water and doesn’t leave foot prints

(Okay, maybe that last one is slightly exaggerated!)

These lists of job requirements are often lengthy and at times contradictory (such as “works independently” and “team player”). You need to ask yourself a critical question — “What really matters?”.

I can’t give you a direct answer to that question because the answer depends upon your situation. I’ve hired many people over the years (and, sadly, fired a few). Here’s what I’ve learned.

• Focus on what really matters.
• Highly specific technical skills don’t matter. (For example, someone who knows several computer languages can readily learn a new one.)
• Getting along with people, even difficult ones, really matters.
• Knowing how many stuffed animals fit in a Volkswagen Beetle doesn’t matter.
• Ability to learn new things really matters.
• Writing elegant and eloquent specifications doesn’t matter (unless you’re a big consulting firm).
• Being able to convey an idea to a group really matters.
• Solving problems doesn’t matter (that’s a team activity).
• Identifying problems before they ruin your day really matters.

Who should you hire for your team? It depends on your company culture and your work environment. If your company favors top-down, command-and-control, you need to hire people who are good at following procedures. If your company favors distributed, self-organizing teams, you need people who work well in an open, team setting.

Bottom line: Focus on the soft skills. People who are smart, open-minded, team players will learn whatever technical skills you need. The opposite is not true — people with great technical skills and poor soft skills are unlikely to change. Firing them won’t be pleasant.

photo credit: NoJuan via photopin cc

Change Is Good, Upheaval Is Not

You want your software development team to switch from using a waterfall approach to using an agile approach like Scrum, Kanban, Lean or XP. Should you do it gradually or go cold turkey (all at once)?

Before you answer that question there are a few things to consider. Let’s walk through an example. This will be a rather extreme case to get you to think about how complex this transition can be.

For this example, we have a strong software development team. They have a good track record. There are no pressing problems to solve. The motivation for changing the development approach is to try something new and see what effect it has.

Management identifies a new product. It’s not a desktop application that has been the company’s strength. It’s a web-based application taking the company in a new direction. This is a great time to try a new development approach, right?

Here is a list of the major things that will need to change in adopting the new approach and building the new application. Let’s assume they’ve decided to adopt Scrum.

• Approach – From Waterfall to Scrum
• Language – From C to PHP and Javascript
• Tools – From desktop software build tools to browser- and server-based tools
• Office Layout – From distributed cubes to cohabited open space
• Work Style – From individual efforts to team efforts
• Control Style – From tasks assigned by a manager to self-organizing workflow
• Alignment – From isolated work efforts to collaboration with business people
• Documentation – From formal, lengthy specifications to informal, brief stories
• Meetings – From formal status and review meetings to informal daily standups
• Deployments – From two (QA and production) to many (after each sprint)

I could go on but you get the idea. A lot is changing — in fact, everything is changing. Will this team be successful?

Maybe but not likely — too much is changing too fast. For this team to succeed, here’s what needs to happen.

1. Training – The team won’t know where to begin. Scrum training and web-based application development training are essential.
2. Coaching – Even with training, they will make rookie mistakes. Direct assistance from someone who has experience with Scrum and web-based software development is needed (not necessarily one person).
3. Time to fail – The team cannot estimate tasks with any precision. There are too many unknowns. They need time to experiment and mature.

If the management team is willing to put money and time into this effort, the team will succeed. Unfortunately, senior managers tend to be impatient and cheap. They want instant results. Problems can always be fixed later — if there is a “later“.

If you decide to make such drastic changes, tread carefully. If money and time are not on your side, consider changing one or two things such as the language and the tools. Once the team is comfortable, change one or two more and keep at it.

Lastly, have good reasons for changing. Simply wanting to “try something new” is not a good reason.

photo credit: HikingArtist.com via photopin cc

Open Source, Agile Development and Social Media Have Something In Common

Open source software, agile development techniques and social media tools are three of my favorite things. They have one thing in common that binds them together — they help people collaborate.

All three provide mechanisms people can use to interact and cooperate. In fact, the more we do so, the better the results. That’s how crowdsourcing works — many hands, many minds, better results! Think about it.

Open Source Software

Open source projects existed before agile development and social media. The popular open source projects like the Apache HTTP Server, LibreOffice, Linux and Mozilla’s Firefox are great because lots of people contribute. Many ideas, opinions and contributions make the software better. It can get cantankerous at times but that’s okay. Reasonable people can disagree — sometimes strongly — and still work together to achieve a better result.

Agile Development Techniques

Agile software development came along to address the process issues around building software. It takes a lot of skills, tools and techniques to build great software. But more than anything else, it takes people who interact and collaborate. We can debate Scrum vs. Kanban vs. XP vs. Lean for weeks. None of those approaches will work without good people who are willing to work together and accept compromises. It’s not about the process. It’s about the people.

Social Media Tools

Smartphones have given us the ability to communicate in new ways. The simple phone call is from the last century. Facebook, Google+, Instagram, Pinterest, Twitter and similar tools have changed our lives. They give us new ways to interact with others — even people we’ve never met. Suddenly, anyone can be heard and acknowledged anywhere in the world by simply posting a message or picture through one of these services. It’s amazing and addictive.

Collaboration Is Key

When we collaborate, we get more done in less time with higher quality. The collaboration must be genuine, however. If the opinions of managers carry more weight than those of others, collaboration is crushed — command and control take over.

If you dislike the concept of open source software and you hate social media tools, you aren’t going to like agile software development either! It’s time to change.

photo credit: Will Lion via photopin cc

Don’t Just Prioritize User Needs, Prioritize the Process Too

Many software development teams go to great lengths to prioritize requirements, features or user stories. (I hope your team does.) It’s a valuable exercise if people take the time to truly evaluate the importance of each request they make or receive.

Do you want to improve your software development process? Apply the same logic to the various elements of your process — prioritize them. Not every aspect of the software development process is equally important. Nor should every artifact be used on every project.

Here are three categories I’ll use to prioritize process elements:

• Strategic
• Important
• Non-essential

As for the elements of the process to prioritize, that’s pretty much up to you to decide. Here are some ideas to get you started:

• Product vision
• Project goals
• High-level software requirements or user epic backlog
• Detailed software requirements or user story backlog
• Specifications and other documentation
• Process diagrams
• Architecture diagrams
• Source code
• Test scripts/code
• Build scripts
• Deployment scripts
• Defect tracking
• Change management
• Status meetings
• Metrics

Now think about this.

What elements of your software development process are Strategic? Important? Non-essential? Here are my definitions. Feel free to re-word to your liking.

Strategic – Any part of the process that is critical to the success of the project. (If you claim that everything is strategic, go to your office. Do not pass the team room. Do not collect your paycheck!)

Strategic process elements are vital to project teams. Teams simply cannot function without them. Think long and hard about what you label strategic. Good project teams can operate with very little guidance. Poor or inexperienced teams may need much more.

Important – Important elements help teams do better. While teams can get by without them, these elements offer things like time savings or improved quality.

For example, automating the deployment process might be important to a team that does frequent deployments but not so much to one that deploys infrequently.

Non-essential – Whatever is left is non-essential. These elements are useful either to the team or to external participants but don’t add much value. I’m not equating non-essential with wasteful. (I suppose wasteful might be a fourth category but I’m hoping you’re better than that.)

For example, tracking metrics might be considered non-essential but it can be a useful tool for improving team performance.

What’s it to you?

I encourage you to go through this exercise. Start with your core team. Do it again with your stakeholders and possibly a third time with your suppliers (internal or external groups you depend upon). You won’t get the same results each time but that’s okay. You’ll develop a list of what really matters and what doesn’t.

Focus on the strategic elements. Do all of them to the best of your ability. Make sure they are complete, comprehensive and thoroughly vetted. They should be part of every project you do.

If any important element is not providing the value expected by the team, eliminate it. Do the remaining important elements well. They should be complete but not necessarily comprehensive or elegant. You might skip them for some projects.

As for the non-essential elements, consider trashing them all. You may want to keep a few around for job satisfaction or team morale reasons. There may be a few that can be improved to the point where they become important (or even strategic).

Focus on what really matters.

photo credit: jakuza via photopin cc

Software Projects Fail for the Wrong Reasons

I’d like to discuss failure — specifically, software development projects that fail. Has it ever happened to a project team you were on? If so, it was probably not for the reason you think.

Before we can examine this further, we need to agree on what constitutes failure. I’ll offer my definitions and you can add yours in the comments if you like.

What is failure?

• The project never finishes. It’s canceled before the team considers it done.
• The budget is exceeded by more than 20%. (Why 20%? It’s a number that feels like failure to me. You might use a different number.)
• The team misses a critical deadline AND ‘must have’ features are not working. (You did prioritize features, right?)
• The team delivers working software but the stakeholders and business users are unhappy with the result.
• The project just drags on. There’s no budget, timeline or definitive requirements — there’s also no definition of done.

I’m sure that anyone who has been involved in software development for more than a few years has experienced one or more of these situations. If you haven’t yet, you will– and it won’t be pretty.

Why do software projects fail?

The reasons for failing projects are as varied as the projects themselves. I don’t want to dwell on information that is available elsewhere so I’ll try to offer a different perspective.

1. It’s widely perceived that lack of management oversight and control leads to project failure. I disagree. I believe that projects often have too many managers and too many controls. The focus is on managing the process when it should be on getting stuff done.
2. Lack of people management is another widely perceived failure point. Wrong again. If the company has hired good people, they know what they need to do and how to do it. Get out of the way and let them do their jobs. Give them some running room and some time to accomplish something. (Oh — and fire the non-performers and troublemakers.)
3. Poorly defined requirements is a real problem but not for the reason you might think. The stakeholders and end users know what they want. Pay attention to them. Problems develop because we don’t spend enough time talking through what’s wanted, establishing common goals, and determining what really matters. (Lengthy requirements specifications can’t solve that problem.)
4. Contrary to popular opinion, projects don’t fail due to lack of time, money or people. They fail because expectations are not managed well. People become locked into their favorite solution or approach and are unwilling to accept a different idea. Spend more time leading and less time controlling.
5. Lack of process, governance or change control are also often cited as failure reasons. Sorry. Those are invalid reasons too. There is either too much of those things, stifling the project team, or they are being improperly applied resulting in poor decisions. Keep it simple.

Would you like to succeed more and fail less?

• Stop managing so much and start delivering results.
• People are more important than process. Respect them.
• Documentation is a tool not a result. Don’t abuse it.
• Protect relationships not ideas.
• Change is good. Be open to changing your plans.

photo credit: Ruin Raider via photopin cc

It’s Not About the ‘How’. It’s About the ‘What’.

Software development experts, myself included, get caught up in methodology battles. I like Scrum. You like waterfall. My approach is more responsive than yours. Your approach is more disciplined than mine.

But, are we losing sight of ‘what’ really matters? The approaches we follow are the ‘how’ of building software systems. My goal (and I hope yours also) is to build better software so that our respective businesses can be successful. That’s the ‘what’ — build better software for our businesses.

If you and your team are not satisfied with the results you’re getting, you need to let go of the ‘how’ and focus on the ‘what’. In other words, if you’re unhappy with your team’s results, your approach isn’t working — so change it.

• What is wrong with the software you’re delivering?
• What makes it inferior to competitive products?
• What causes it to fall short of expectations?
• What issues are business users reporting?
• What internal goals are being missed?

Once you know ‘what’ is going wrong, you can turn your attention to the development approach to understand ‘how’ these issues came to be. You may need a completely different approach or some changes to your existing one but, either way, something needs to change.

Arguing about Scrum vs. XP vs. standard waterfall vs. iterative waterfall is a semantic debate. Instead, identify the tactics within your current process that work and those that don’t. Preserve the tactics that work and eliminate the ones that don’t.

• Don’t treat anything as sacred and unchangeable.
• Don’t start changing things simply because they’re easy.
• Don’t draw conclusions without hard data to back them up.

Here’s an example of a really bad ‘improvement’ idea. (I’ve witnessed this several times over the years.) A software system is widely perceived as buggy. It’s hard to use; it crashes; etc. The proposed solution is to do more testing. If you can identify more bugs before the software ships, you’re ahead, right?

– Wrong! –

If the software is buggy, there’s a fundamental problem with your team’s approach to specifying, building and testing it. Your entire process from front to back is suspect. That elephant is too big to eat in one sitting.

Accept that the software will be buggy for a while. You can make incremental improvements but you won’t be able to fix everything in a release or two.

Get to the core issues and fix them. Until you’re willing and ready to do so, a new software development approach won’t help, whether it’s agile or not.

photo credit: dhaun via photopin cc