If Your Users Lack Personas, You Might Be a Drug Dealer

You’ve likely seen the line that says ‘Only drug dealers and software developers call their customers users’. It’s funny but also carries an important message.

You see, drug dealers don’t care about their customers. All they care about is the money. Some software developers exhibit a similar characteristic in that all they care about is the technology.

Creating really good software requires more than good technology, minimal defects, and decent performance. The software has to behave in a manner consistent with the person running it; let’s call him or her the ‘client’. The only way to achieve such a result is to get inside the head of the client.

That’s where personas fit in.

Whether you’re doing waterfall or agile software development, User Stories and Use Cases are great tools for elaborating on client activities and behaviors. They allow us to describe client actions in ways that software developers can dissect and turn into executable code. But there’s a step missing!

We need to know a few things about our clients before we dive into their behaviors. Here’s a simple example. Let’s say I have the following user story:

As a user, I want to send Twitter messages so that I can participate in its global community.

Simple right? Now what if I told you that the ‘user’ has severe arthritis and cannot type or use a touchscreen? That changes everything.

Here’s an even simpler example:

As a user, I want to generate an inventory aging report and export it to Excel so that I can manage inventory levels and costs.

You might think that this report will be run monthly by a finance staff member. What if I told you that the user is a highly-impatient, senior executive who runs this report hourly and uses it to adjust product pricing dynamically?

Get the point? It’s critically important to know your clients.

There are many aspects to knowing a client. Here are a few ideas to ponder. Determine which are important to your situation and create personas around them.

• How much on-the-job experience does the client have? Or, how savvy is she as a consumer or buyer?
• What are the client’s job responsibilities? Or, where does he fit within his household?
• What does a typical day (or evening) look like for the client?
• What is the client’s attitude toward technology and computers?
• What tasks does the client perform that are the most critical or repetitive?
• What is the client’s personality like (e.g. mellow and even-tempered versus impatient and hot-headed)?
• Does the client sit still and complete a task in one place or is the client highly mobile, starting and pausing tasks often?
• Does the client have any physical limitations affecting mobility, sight, hearing, etc.?
• Is English the preferred language of the client?
• Does the client abide by the same rules and regulations as other clients (e.g. state and national laws vary widely)?

You get the idea. Develop a small number of client personas for your next project. Give them names so the software development team can relate to them. How many you will need depends upon the nature and complexity of your software.

When you write user stories or use cases, direct them at one of the personas you’ve defined. Then go one step further. Apply a different persona and ask the team, “How does this change the client behaviors?”.

How to Capture Non-Functional Requirements

Non-Functional Requirements (NFRs) can be difficult to define and track. We often treat them as after-thoughts and only near the end of the project.

We usually focus on functional requirements. These represent system behaviors. They define what a system is supposed to do and how the inputs and outputs will appear.

NFRs are more varied. They define characteristics of systems rather than behaviors. Here are a few of the more common types of NFRs:

• Availability (e.g. 24x7x365)
• Capacity (planned)
• Compliance (legal and/or regulatory)
• Efficiency (resource consumption)
• Interoperability (inter-system data exchanges)
• Performance (response time)
• Portability (cross-system functionality)
• Resource usage (processor, memory, disk space, network bandwidth, etc.)
• Scalability (user count and data volume growth)
• Security (e.g. login, encryption)

Traditional business requirements documents have a section devoted to NFRs. They may even be captured in a separate document. Either way, it can be a bit awkward in that the business often doesn’t specify NFRs. They tend to focus on what a system must do making the implied assumption that the system will be able to handle the workload thrown at it in a secure and robust manner.

Agile software development teams often have a difficult time with NFRs too. How should they be captured? What do they look like? Here are a few ideas.

Capture NFRs as user stories. While most NFRs don’t fit nicely into the story metaphor, capturing them this way makes them highly visible and easy to manage. They are just like any other requirement. An NFR story might read something like…

As an impatient and over-worked data analyst, I want to process 10,000 records in under 60 seconds so I can get more done in less time.

As a claims adjuster handling sensitive information, I want my data to be password protected and encrypted so that I meet compliance obligations.

As a marketing executive, I want the software to operate in Windows, OSX and Ubuntu so that the company maximizes its revenue potential.

Capture NFRs as technical stories. These stories are different from user stories in that they don’t originate from the business community. Thus, they don’t have the visibility and discussion associated with user stories. There is nothing wrong with this approach though I’d argue that sacrificing visibility and discussion does not lead to positive outcomes.

Capture NFRs in the acceptance criteria for each story. This is a little more work in that it forces the team to think about NFRs while implementing each story. This may make some of the acceptance criteria repetitive. In addition, some NFRs may be difficult to test story by story. It may be best to only reference an NFR in the acceptance criteria if it is essential to the implementation of the story.

Write a Non-Functional Requirements Specification. Such a document would serve as an umbrella or wrapper over the project. This could work but using two methods for capturing requirements might be confusing. There will always be gray areas. For example, if I want to run the software on a touchscreen, is that functional or non-functional? It’s both because of the many issues and nuances introduced.

There really isn’t a right-way or wrong-way to define NFRs. Pick an approach or a combination of approaches that works for your team. The most important point is conditioning the software development team and the business community to recognize the importance of NFRs and document them.

5 Steps to Disciplined Problem Solving

Hurricane Irene spun through New England this weekend. It was a tropical storm by the time it arrived but still wrecked havoc. Many people had to make adjustments or completely change their plans. Many businesses had to close and those that stayed open suffered losses.

Similarly, unexpected events can wreck havoc on software development projects. When (not if) your project gets into trouble, here are a few ideas to guide you:

1. Focus on solving the problem. There will be plenty of time to identify the cause and assign blame later. All of your attention and energy needs to be directed at finding and implementing a solution as quickly as possible.
2. Challenge all assumptions. Test the validity of the facts, theories, beliefs and assumptions being articulated. Don’t blindly accept anything as true unless it can substantiated. You need to know that the team is focused on solving the right problem in the right way.
3. Preserve a positive outlook. It’s okay to disagree. Do it without being disagreeable. Maintaining positive relationships with those around you is important. Once the problem is solved, and it will be, you’ll need to continue working with the team. Keep in mind, and remind others, that no one created the problem intentionally.
4. Turn your attention to preventing future occurrences. Once the problem is solved, consider small adjustments or additional monitoring that may help avoid a repeat event.
5. Assess how decisions are made by the team. Now that the problem is solved and avoidable, seek out a root cause. How did the situation that allowed the problem to occur develop? What could have been done differently?

You can’t prevent every problem but you can solve them by following a disciplined process. Perhaps more importantly, you can learn from the experience and stay agile.

IT Certifications Have Value in the Right Situations

Businesses are always looking for an edge. Job seekers are always looking for a differentiator. Both often view IT certifications as a way to get better results. Yet the subject of information technology certifications is controversial.

Some strongly believe that someone with a certification is better at what they do than someone without. Others are equally sure that certifications are meaningless. There are valid arguments on both sides.

Some certifications have value while others are not worth your attention. It is important to know what a particular certification means and what value it has in a particular situation.

Is it relevant?

Ultimately, the relevance of the certification is what really matters. A certification in security audits is of little value to a team needing a web developer. Make sure you understand what a particular certification means in terms of job skills.

Deploying and maintaining technology products is complex. The pitfalls are many and the skills required are varied. Technology professionals must constantly learn new techniques to keep up with an ever changing industry. Certifications are one way to do this.

There are many choices.

Many certifications are issued by vendors that sell the underlying products. For example, Cisco, HP, IBM, Microsoft and Oracle have many certification types and levels. It makes good sense for vendors to attract and train skilled professionals thus unleashing a small army of evangelists.

Other certifications are issued by organizations that champion a technology or capability. For example, CompTIA (information technology), ISACA (information security) and PMI (project management) offer multiple types of certifications.

It’s important to note that certifications represent a revenue opportunity. The firms that offer training programs, books, manuals and examinations have much to gain. The fees for attaining a certification amount to hundreds, and sometimes thousands, of dollars.

If you decide to obtain certification or are looking to hire certified professionals, do your homework. Be sure the organization offering the exams is well known and respected.

There are certifications that are popular and in demand. Here is a short list of major certifications (there are far more than I can list here and I apologize in advance to the many I’ve excluded):

• Microsoft offers over a dozen certifications. There is a list here.
• Cisco offers even more. Take a look.
• Security certifications are offered by CompTIA and ISACA.
• The Project Management Institute offers a Project Management Professional certification.
• There are also certifications in Scrum through the The Scrum Alliance (and others) and Lean Six Sigma through Six Sigma (and others).

So, are certifications worth it? A certification can’t hurt even if it is in an area that is not closely related to the work being done now. Certification shows that the person holding it is willing to put in the effort required to learn the material and pass the exam.

Employers can use certifications as a way to motivate and reward staff members. They keep the team fresh and trained on the latest best practices. The way to make this work effectively is give people time to study during work hours and, of course, to pick up the tab for the exam and required study materials.

How much certifications help in hiring or career development is an open question. Be sure that the job and the certification are aligned. When they aren’t, certifications get a bad reputation and only the training firm comes out ahead. Do you have anything to add?

Don’t Let Mindless Complexity Ruin Your Project

To be more agile, you need to keep it simple.

Many of us have a tendency to make things too complicated. In an effort to cover every angle or get all the facts on the table, we overwhelm the reader or listener with too much information. This creates confusion, causes mental fatigue, and leads to poor decisions.

Complexity is not inherently bad. For example, running a $10M project is fundamentally more complex than running a $1M project. Problems develop when we keep adding complexity to deal with new issues that arise, but the new complexity doesn’t add any value.

Complexity breeds complexity.

Internal complexity increases whenever we add new products or services, hire new people, introduce new processes, start strategic initiatives, add layers of management, or add new data sources. There are also external forces that increase complexity in the form of new markets, new competitors, regulatory changes, and economic swings.

IT complexity is also part of the problem. Complex technology restrains businesses by making it difficult to add or remove systems within the infrastructure. It is often a challenge to change existing systems as there is a cascade effect that ripples across the entire enterprise every time any system is upgraded or replaced.

Technology should be making it easier for businesses to manage change. Instead, we often make it more difficult.

Justify it. Reduce it. Get rid of it.

Think about these issues within the context of your next project. As software systems get larger, we need more management, more documentation, more risk analysis, more design models, more test code, more memory, more storage, more bandwidth — more, more, and more. Don’t keep piling on mindless complexity.

When changing a business process, ask “How can we do this faster and simpler?”. Business processes are often overly complex with so many checks and balances that everything slows to a crawl including decision-making. Justify every step in the process and look for ways to eliminate each one.

When adding a new function to a software system, ask “What can this new function replace or make obsolete?”. Simply appending more code and more options to the software without a value justification will only create support problems.

When adding new artifacts to the software development process, ask “Who will use this artifact? What value will that person derive?”. Use the answers to decide how much formality the artifact requires, if it’s needed at all.

When incorporating new policies or procedures into your software development process, ask “Why are these needed? What value do they add?”. Everything you add creates more work. Work is costly. Justify it.

When finding the solution to a problem, ask “Are we solving the right problem? What is the simplest solution that will work?”. Always lean toward the simplest solution to every problem. You can always expand the solution later (assuming you’ve followed good design practices).

Every business wants to be more agile. So stop adding mindless complexity.

Hate Scrum? Re-Define it!

I have a theme going this week on this blog. I’ve been touching on reasons why software developers dislike agile development and Scrum in particular. But wait there’s more!

Some software engineers dislike having to deliver “production-ready” code at the end of each sprint. I can understand why. I often race through a code module (or a blog post) trying to lay a good foundation but not concerned about the details. Considerable refactoring may be needed to get the module to what I would consider to be “production-ready” (that is, completely “done”).

If you have to stop and refactor during every sprint, you might get frustrated. You’re anxious to get all of the planned functionality built out before spending lots of time on finishing touches. Delivering code that is incomplete is not satisfying and you know that building out the entire module will take multiple stories and several sprints.

Scrum doesn’t constrain us. We constrain ourselves.

I believe that Scrum offers a lot of control over the above scenario. For example, what does “production-ready” mean? There is no standard definition. Also, what exactly do you need to deliver at the end of sprint? There is no standard definition for that either.

The point is that the Scrum Master, Product Owner, and the development team have wide latitude to define what is acceptable or production-ready and what is not. Nothing inherent in Scrum requires that your source code be clean and complete at the end of every sprint. (I think it should be clean and complete at the end of a release but that’s a separate issue.)

Here’s some guidance for making Scrum more livable.

• Each story must have acceptance criteria. Focus the criteria on the functionality of the code from a business perspective, not the implementation. Leave yourself some latitude in how you solve the business problems.
• Keep stories small and limited in scope. Basic functionality, advanced functions, error handling, refactoring, and even documentation can be covered in separate stories. You’ll get a sense of accomplishment from each story even though there is more to do.
• “Production-ready” means the software implements stories as intended or defined and is free of serious defects (anything that may cause crashes or data loss to the best of the team’s knowledge). It does not mean that the software contains all the features and functions desired by anyone that may use it. Nor does it mean that the software will trap every user error condition or be as responsive as it could.

At times we blame the software development process for problems that we create. The developers, testers, stakeholders and managers need to feel comfortable with the process and the deliverables.

If you’re having trouble meeting sprint goals, maybe the goals need to change.

Scrum Stand-Ups: Information Sharing Not Status Reporting

Yesterday’s post (Scrum Does Not Take Control Away From Developers) made me consider another reason why some software developers simply don’t like Scrum. I think it comes down to too much reporting.

Doing Scrum properly requires daily stand-ups to share information. The team congregates for 15 minutes and quickly synchronizes — at least that’s what should happen. Too often the stand-up turns into a status meeting. You know the drill — Let’s go around the room and have everyone report on their tasks.

When that happens, everyone feels the pressure. There will always be someone who is good at spin. That person will ramble on about all the tasks he completed and all the issues he resolved. This pressures everyone else to offer the same kind of monologue to avoid looking bad in front of the group (and their manager who is often in attendance).

These stand-up sessions give Scrum a bad reputation. The stand-up is NOT a status meeting. If management wants a status meeting, management should schedule a status meeting. The Scrum Master and the Product Owner can report for the entire team.

The daily Scrum stand-up must be tightly focused.

1. What have you “done” since the last stand-up? – Share with the team what you completed since yesterday’s stand-up. This is simply to let everyone know what artifacts are ready for others to use. If nothing you worked on met the team’s “done” criteria, fine, say so and move on.
2. What will be “done” before the next stand-up? – Again, just let everyone know what’s coming. If you don’t expect anything to meet “done” criteria before the next stand-up, say so. (No one should care about all the detailed activities you spent time on. They expect you to work hard.)
3. Did you encounter problems or issues not previously discussed? – Finally, simply let everyone know about problems and issues that they may encounter and should be aware of. (If you had to take your dog to the vet and lost some time, that’s your personal problem. The team doesn’t need to know. Deal with it.)

The last question may generate considerable discussion. Team members will often jump into problem solving mode as they try to help. The Scrum Master needs to squelch this. A quick suggestion or an offer to assist after the stand-up is fine. A detailed discussion of the issue is not.

A common occurrence is for a software developer to realize that a story will take much longer to implement than planned. The story may have been under-estimated or new information may have been uncovered. Either way, this is not a topic of discussion for the daily stand-up. Take it offline and either return the story to the backlog, divide it into multiple stories, or finish it at the expense of one or more other stories for this sprint.

Scrum stand-ups are designed to promote teamwork. If yours aren’t doing that, stop. Your team has a serious problem. Conduct an immediate retrospective focused on the daily stand-ups. This can’t wait. Do it now.

Scrum Does Not Take Control Away From Developers

There is a small and vocal percentage of software developers who dislike almost any form of structured process around their work. Process is often viewed as a euphemism for control, specifically, management control.

If you take the time to carefully read the Agile Manifesto and to understand the basic elements of Scrum, you’ll see that developing better software is about empowering software teams. High-performance teams need the ability to structure their day-to-day activities and self-correct as new information is received.

Managers retain a critically important role focused on strategic goals, long-term planning, and operating environments. Everyone must actively participate to achieve successful outcomes.

I believe that agile techniques add considerable value to software development and I have the experience to back that up. Let me explain how I approach implementing a new software module using agile techniques.

Yes, I still write software. Not as much as I did many years ago but I still like getting my hands dirty. Currently, I work with the Salesforce.com Apex language (Java-like) and the associated Visualforce page description framework.

Here’s how it works…

At the outset, I like to get some aspect of the new software module running as quickly as possible. I find it much easier and more efficient when I see the code producing results that I can then build upon and extend. There are surely developers that like to write lots of code and start debugging it once an entire module or set of modules is written. That has never worked for me but if you are really, really, good at writing code, it might work for you.

Once I have something running successfully, I know I’m on the right track — my initial assumptions are correct and my approach should work. If I’m dealing with user interface issues, I’ll solicit feedback from the user community immediately even though the UI is simply a framework. I don’t want to spend a lot of time creating a nice-looking user experience only to be told they don’t like it. [This initial result could be called a 'story'. It may even be more than one.]

Now, I like to dive in and tackle the most difficult part of the problem along with the test cases that will be needed. I want to know early on if I can reach my ultimate goal or not. In the case of Salesforce.com, governor limits are a huge issue. I need to know that I can deliver the results I want without exceeding limits such as the number of records returned or the time required.

To recap, there are three things that I believe should be done as early as practical on any project:

• Test assumptions
• Solicit user feedback
• Solve the most difficult challenges

Once these elements are handled, I’m ready to build out the final solution. The UI (if any) can be beautified, error processing can be extended, performance can be optimized, etc. [All of these efforts can be covered in individual stories.]

That’s my approach. It’s iterative, interactive and agile. It’s also lean with minimal overhead.

I should also point out that I have a strong, positive relationship with my manager and with the user community. It helps a lot! So what do you think?

Here’s How Corporate IT Can Adjust to Tablet Computers

Tablet computers are disruptive and are invading every company. It started with the Apple iPad and has blossomed into many choices. Every major vendor has announced at least one tablet device including Acer, Dell, HP, Lenovo, Motorola, RIM, Samsung and Toshiba.

Those tablets offer a variety of operating systems including Android, iOS, QNX, WebOS (or not) and Windows. IT departments must adjust to the idea of managing and supporting a variety of end-user mobile devices. It will no longer be a Microsoft-dominated IT world. Tablets are a game changer.

Enterprise IT needs to find ways to co-exist with consumer tablets and their short life cycles. That means giving up some control to the end users and the vendors. It sounds foreboding but is not, because vendors are eager to work with businesses and sell more tablets.

Banning tablets is not an option. Neither is imposing so many restrictions that they are all but unusable.

Several factors are driving this transition.

Apple has long been viewed as a consumer electronics company. They position themselves as consumer-friendly and attract buyers of all ages. Once someone acquires an Apple device for personal use, they often want to use it at work.

Consumers have become more technology savvy. They are buying many types of electronic gadgets and loading up on intelligent home appliances and tools. In the process, they are becoming more dependent on technology than ever before and see the value in it.

Finally, the pace of innovation is accelerating. Historically, it’s taken enterprise IT departments many months to review, approve and deploy new equipment. At today’s hypersonic innovation pace, the equipment could be nearing or past its end of life before it’s deployed.

Here is a short list of items to consider.

Usage Policies. Define acceptable and unacceptable tablet usage. Define and enforce good security practices for tablets, including strong passwords and device certificates.

Remote Erasure. Software is available that can remotely erase the contents of tablet devices if they are lost or stolen. Find the right software for the devices you want to support and make sure your users understand that any personal information saved on the device will also be erased.

Encryption. Tools exist to encrypt tablet data making it almost impossible to decipher. It is a good idea to encrypt any information that leaves the enterprise infrastructure whether stored on a laptop, smartphone or tablet.

Cloud Storage. If you feel uncomfortable storing any enterprise data on a mobile device, you may want to save all data to a network server using a cloud-based service or your own systems. This will force users to have a network connection, either Wi-Fi or 3G, in order to access corporate information.

App Delivery. If your firm develops its own tablet applications, you will need a mechanism for delivering the software similar to Apple’s App Store. For the iPad, this can be done wirelessly without using a PC or iTunes. Other vendors offer similar solutions.

App Availability. You may be tempted to restrict the third-party apps users can load onto their tablets. However, you will likely see productivity advantages to letting users load whatever they want. Tablets are a new world that users need to explore and experiment within to get maximum value.

Support. This leads to the question of how much support you want to provide. Will employees be allowed to use their own tablets at work or must the tablets be company provided? Will corporate email, calendar and messaging features be supported? Are the devices for general-purpose use or for specialized apps only?

The more open the platform, the more likely it will be that employees will use the devices heavily and get maximum value from them. There are many productivity advantages to be had but it will take some creativity and experimentation to draw them out. Be open minded.

Consider allowing employees to load some personal apps on the tablet and store some personal data. You may find that if tablets are used for personal information, employees are more likely to take good care of them. Loss, theft and damage will occur but can be minimized.

Launch a pilot program.

Before making final decisions, start with a pilot program. Include a mix of user segments such as executives, managers, sales, support, technical and administrative personnel. You will need to get feedback from all types of user groups in order to determine the best approach for a full-scale rollout.

Tablets offer the promise of major advances in productivity for some users. You owe it to yourself and your company to find out who those users are and help them succeed.

How Software Projects Seize Defeat from the Jaws of Victory

Here’s what happens. I’m sure you’ve seen it before. A software project starts with lots of enthusiasm. The team is assembled. A kickoff meeting is held. New relationships are formed. Everyone is energized.

The team is focused on solving a business problem. There is a sense of urgency and a commitment to deliver. The team is at its peak of performance. It doesn’t get any better than this!

The project gets off to a great start. There are no unusual or unexpected problems. Then, usually about one-quarter to one-third of the way through the project, the energy and enthusiasm are greatly diminished. The team has delivered documents, charts, graphs, maybe even some executable code, but nothing to get excited about. The project has become routine — dull.

The project is stuck in a trough of tranquility. Work is getting done and artifacts are being delivered but it’s just not exciting.

Then it gets worse.

The project team becomes complacent. They start to arrive late for meetings or miss them entirely. They miss deadlines by a day or two. They don’t communicate as often or as clearly as they should.

In the worst case (and this happens far too often), there is a crisis on another project and management decides to pull someone from your project team to assist. Hey, things are going so well on your project that you can afford to help out, right?

This scenario is one of the critical problems with a strict linear (a.k.a. waterfall) development approach — analysis, requirements, design, code, test, deploy, user acceptance. By the time the team delivers anything functional, everyone has lost their enthusiasm and worse, they have lost sight of the original project goals. This is how defeat is seized from the jaws of victory.

Any iterative approach — modified waterfall (such as the Unified Process or a spiral model) or agile (such as Scrum, XP, Kanban, Lean, etc.) — that delivers working software early and often will help keep the development team and the stakeholders interested and engaged.

When people are delivering results and receiving targeted feedback, they are motivated to do more. The team will learn faster and the stakeholders will provide better feedback sooner. No approach to software development is perfect but iterative approaches have proven benefits.

Minimize the analysis, planning and designing. Maximize the delivery of functional software. Your thoughts?