Your Data in the Cloud Is at Risk

Many firms are touting the benefits of “cloud computing”. It’s particularly beneficial for mobile users. If you could store everything in the cloud, your information would be accessible from anywhere using any device. That’s Nirvana!

This approach would also make mobile devices cheaper. If they don’t have to store anything locally, they can do without hard drives and large amounts of flash memory. Do you realize that the single costliest component of many portable devices is the flash memory?

As consumers and businesses flock to mobile computing, the emphasis on cloud computing will grow exponentially. Yet, the key weakness in the cloud computing vision is reliability. A few noteworthy examples include:

• Google just experienced a Gmail failure resulting in thousands of their users temporarily losing all their emails. It impacted a small percentage of users but if you were one of them, that statistic means little.
• Microsoft’s Danger subsidiary lost Sidekick user data in 2009. It was likely one of the worst embarrassments in the company’s history.
• Facebook experienced a major outage last year as millions of its users were unable to access the site for several hours.
• Amazon Europe suffered a brief outage during the Christmas season last year — the worst possible time of year for any retailer to have connectivity issues.
• Twitter has a famous “fail whale” that shows up periodically instead of user tweets. The problem is better than it was two years ago but still occurs far too often.

For some, these failures are merely inconvenient. They simply try again later. For others, appointments are missed, deals are forfeited and opportunities are lost. Not every situation is resolved with a simple “try again later”.

What can you do? Not much. If you have information stored in the cloud that you really need and depend upon, back it up. Backup tools exist for every major cloud-based application. For example, Gmail can be backed up with an email client application like Mozilla’s Thunderbird.

One other tip, save a local copy of critical information on your smartphone, tablet or laptop. For example, many cloud services will allow you to store a local copy of a file, note, image, etc. at least temporarily. Also, you can copy and paste information into a local text file or document so that it is readily available with or without the cloud.

Don’t be caught without your critical information. Sooner or later you will be impacted by an outage.

User Stories: Focus on the Problem Not the Solution

Much has been written about creating user stories. There is a good User Story introduction on WikiPedia and Mike Cohn has written a well-known book on the subject called User Stories Applied: For Agile Software Development.

Despite all the literature, agile development teams often struggle with writing good stories. In this post, I’d like to draw attention to the issue of user stories that propose an implementation or solution rather than stating a problem, need or want.

This is a easy trap for software developers to fall into. In fact, anyone who has a good understanding of how software works might fall into these lines of thinking. Let’s consider the following examples.

1. As an expert buyer, I want the database to be indexed by part number so that I may quickly find the product I need.

The expert buyer is suggesting a solution to the problem of rapid information retrieval. There are many ways to design data stores. Indexing represents a means of finding information and there are many others. The implementation should be left to the developers.

2. As a financial analyst, I want the system to recognize interest functions such as NPV and IRR so that I don’t have to enter complex formulas.

Most financial analysts use Microsoft Excel to perform complex calculations. Excel contains Net Present Value and Internal Rate of Return functions. While those functions serve Excel well, there may be better ways of solving this analyst’s problem if he would clearly articulate it to the team.

3. As an experienced web designer, I want the software to support Cascading Style Sheets to make page formatting simpler.

CSS helps make webpage formatting clean and consistent. While CSS is a major component of good webpage design, it is not the simplest tool to master. It would be better to challenge the software developers to hide the complexity of CSS and present a simple user interface to the designer.

In each case above, we really want to know what the user is trying to accomplish. Then, we can determine the optimal way to help him or her get it done.

So the next time someone hands you a user story that suggests how to solve a problem, ask why. What is the user trying to do and why is he trying to do it? Be agile from the outset.

Solutions Are All Around You, Not High in the Sky

I sat in a meeting one day with a group of managers and engineers discussing how we might solve a vexing customer problem. We started out trying to articulate a problem statement because you can’t solve a problem unless you can agree on what it is.

I presented a simple problem description which I hoped would lead to an equally simple solution.

One of the managers suggested we “step back” and develop a better understanding of what was happening. Fine. Questions were asked and answers offered. Then someone else suggested we “step back” and take a broader view. Okay.

Round we went until finally yet another person suggested that we “step back”. I think that’s when I lost it. I said that if we stepped back any further we’d lose sight of the customer!

It’s fine to take a broad view of a problem. People often refer to the 50,000 foot view or some such metaphor. That’s okay as long as everyone realizes that the solution is at ground level and can only be implemented by people with their feet on the ground. From far away, you’ll miss too many details.

That’s what makes agile development so powerful. It’s grounded. People actually do stuff. They don’t spend vast amounts of time studying and analyzing. Competition moves so fast today that by the time the analysis is complete, it’s outdated. Time to re-evaluate. Nothing ever gets done!

From an agile perspective, the goal is to study and analyze enough to rough out an approach and be able to intelligently try a few things. Learn and repeat.

Yes, assumptions will be proven wrong and mistakes will be made but the learning experiences will be priceless. A good agile team will pick up speed as they go because they will get smarter and make fewer invalid assumptions.

As for the customer problem I referenced above, it really was a simple problem with a simple solution. It just took getting everyone’s feet on the ground.

Problem: Enterprise Change Control vs. Agile Project Metrics

For agile to be truly successful, we have to use it successfully on projects in enterprise companies. Start-ups, small shops, even small groups flying under the radar at big firms are all great but they can’t be characterized as enterprise adoption. So what will it take?

I wish there was a simple answer or at least a sequence of steps to follow. There’s not. But, there is one element that is common to many enterprises and must be dealt with. That element is enterprise change management.

Big companies have committees that control (some would say prevent) change. They go by names like Change Control Board, Project Management Office, Change Police, etc. (sorry, that last one isn’t real…I think). They may seem to be in the business of blocking change but their goal is (or should be) to help prioritize projects, optimize resource usage and enforce consistent policies across projects.

Managing priorities and resources is fine. It’s the ‘consistent policies’ part that is the problem.

From an enterprise reporting perspective, consistency makes sense. How can you compare completely different, unrelated projects? You have them report standard (i.e. traditional) metrics in standard formats.

Of course, agile projects don’t rely on traditional metrics. We don’t estimate with lines of code or function points. We don’t plan with hundreds of pages in requirements documents and functional specifications. We don’t have old style milestones like code complete and starting SQA.

Like it or not, we have to find a way to work with the enterprise change folks. Fighting them will only result in your project getting roadblocked.

We have to identify what really matters to them. What information do they absolutely need to do their jobs? The answer will be different from enterprise to enterprise. Once you know what they need, find a way to deliver it to them while maintaining as much agility as you can.

Negotiate. Try to arrive at metrics that you can reasonably deliver AND are meaningful to the enterprise.

Do not attempt to use both waterfall and an agile approach like Scrum so you can report waterfall metrics while developing with Scrum. You’ll be asking for trouble. It may work but it will be costly and counter-productive.

Eventually, as agile gains traction and broad support, this problem will work itself out. The enterprise change folks will identify agile metrics. They will either define a standard set of metrics across all projects or operate with two metric sets, one for traditional projects and one for agile projects.

It will be their choice and our gain.

Self-Organizing Team or Self-Destructive Team?

Agile teams must be self-organizing. You hear it all the time. Self-organizing. What does that mean?

If you’re a paranoid manager, it means that the team plans to run wild and do whatever they want, however they want. That’s not self-organized, it’s anarchy.

If you’re a crazed product stakeholder, it means the team is going to build it their way. You’ll be lucky if anyone pays any attention to you. That’s not self-organized either, it’s bankruptcy court.

If you’re an insecure team member, it means you will not receive any direction. You’ll be on your own and will take the blame for everything that goes wrong. Nope, not self-organized. Self-destructive.

Teams can self-organize when given clear goals and guidelines. This takes leadership not management. If you want your team to self-organize, try answering the following questions about them:

• Is the team respectful and trusting of one another?
• Do they exhibit internal leadership?
• Do they actively seek feedback internally and externally using it to self-correct?
• Are they focused on team goals not person achievements?
• Does the team have the skills they need to be successful?

Now try answering the following questions about the organization:

• Do rules exist for building, testing and releasing software?
• Are the business stakeholders actively engaged in the project?
• Is management willing to “hold on loosely” and give the team some running room?

Being self-organized is not easy. It requires a strong team and a good support structure around them. Many companies lack that support structure. Does yours?

Time for the Daily Status…er…Scrum Meeting

The daily Scrum meeting is often referred to as a status meeting. Even the Wikipedia definition includes the phrase “…a project status meeting…”. I don’t know about you, but when I get invited to a “status meeting”, I cringe. They are usually mundane and boring.

Many people bring a laptop, tablet or smartphone to status meetings so they can entertain themselves and stay awake. (I’m sure you and I have never done that.)

Now the agile software development team hears that they must attend daily status…er…Scrum meetings. Oh, but they are stand-up meetings and only last 15 minutes. (Right, 15 minutes of their lives that they’ll never get back.)

Okay, In general, the way project status meetings are run varies widely. Many will bore you to tears but some are run well and actually impart useful information. Within the broad definition of “status meeting”, I have to admit that the daily Scrum meeting qualifies.

If you’re a Scrum Master, your job is too prevent boredom. The primary purpose of the daily Scrum meeting is to align the development team. The developers need to share information and sync up.

I wrote a post last November about the three questions to ask each developer at the Scrum meeting. It is called “It’s Not What You Did, It’s What You Finished” but there is more to it.

It’s fine to ask what was done and what will be done but it’s more important for everyone to understand what’s happening and why. As everyone cycles through the famous three questions, get them to include information that addresses the following supplementary questions:

• What impediments did you overcome and how? (This will help others who face the same issues.)
• What did you learn? (This could be technical, organizational, or business information that may help others.)

These additional questions won’t result in answers from everyone, everyday. You want the team to keep these questions in mind and address them as needed.

The team needs to stay aligned. They need to synchronize. They have to share information. That’s what the daily Scrum meeting is about. It is not just another boring status meeting.

Oh! And no laptops, tablets or smartphones allowed.

Calling It Agile Doesn’t Make It Agile

Here’s a common scenario. A company’s software development process isn’t working real well. The software is often late, incomplete and buggy. (I’ll bet you’ve heard that story before.)

Anyway, management decides to try a new approach. ‘Agile’ is a hot buzzword so they decide to give agile software development a try. A few development folks are sent to training to become the company’s agile experts. Management can’t wait to see how much better the software team will perform now that they are ‘agile’.

Good intentions are not enough.

They (the software development team) cannot be agile alone. Why is this such a difficult concept to grasp? Agile is not a software development methodology or framework like the Unified Process, Prince2 or Crystal Clear. You can be agile but you can’t implement agile.

Most companies just don’t seem to grasp how important sales, marketing, finance, human resources, and their customers are to the software development process. Software developers cannot develop high-quality software in a vacuum.

Software teams can never be agile on their own.

Multidisciplinary product teams can be agile. Internal application development teams can be agile. Even teams developing infrastructure software like operating systems and servers can be agile. The key element is the active participation of business and/or customer groups.

If your company wants to experiment with short iterations, frequent builds, and integrated quality assurance testing, great! Go for it. There are many ways to improve upon waterfall. Just don’t call it agile.

Code Standards: An Overlooked Need

Do you have code standards for your software development teams? Most companies don’t. They go to great lengths to produce all kinds of document templates yet coders are allowed to do whatever they please. Odd.

The reason document templates are widely used is simply to promote standardization. For example, when you pick up a project vision statement written by someone in Company X you know what to expect. There are standard sections and a common approach to laying out the project goals, costs, etc.

If a standard template didn’t exist, those vision statements would be all over the lot. You’d might have trouble finding the information you want. Even worse, comparing two or more projects would be much more difficult.

Of course, we can’t produce a common set of templates for all the code a development team will write. It’s just not practical. Yet, there are simple guidelines that can make code more readable and less costly to support.

Start out slowly. Keep the guidelines minimalist. You want consistency in the code. Seek consensus on the team and don’t be too picky. I’ve seen teams argue about tabs versus spaces. Those details are not important. The code must be maintainable by anyone on the team. That is the number one goal.

When establishing guidelines, here are some things to consider:

• File naming, layouts and directory structures
• Build conventions and make files
• Declarations and initializations
• Variable naming conventions
• Internal error handling and assert usage
• Error reporting and logging
• Event processing, logging and audit trails
• UI conventions
• Comments
• Language-specific guidelines

You don’t need to cover all these areas. Decide what’s important to your team (and your business). Obtain consensus and put a process in place to spot check compliance. In the long run, everyone will be better off.

Teamwork Is Hard; Agile or Not

Teamwork is hard. To be good at any agile discipline from Scrum to XP to TDD to Kanban, etc., you need teamwork and lots of it.

Many people think that if they are communicating, they are working as a team. Yet communicating is only the first step toward building a team. You can be a great communicator but a terrible team member.

Teamwork takes more…a lot more. You’ll need to:

• Connect – top performing teams get along. They work and play together. Sure, they disagree and argue but they also have fun.
• Cooperate – good team members help each other out. They pitch in as needed and do whatever is required to get the job done.
• Coordinate – just like top athletes, top teams are coordinated. They are able to synchronize activities and balance workloads.
• Collaborate – the best teams share everything and operate seamlessly. They are able to share knowledge not just information and use it to generate new ideas.

If this sounds like it is hard to do, it is. Teams need constant encouragement and rewards. They need to know that they have autonomy and flexibility. Perhaps most important, each team member must recognize that his or her success is dependent upon the success of the team.

Managers, Product Owners and Scrum Masters are all accountable for teamwork and team productivity. No one I know ever said that being agile is easy. It’s not.

Brainstorm with the team both collectively and individually. Find out what is important to them and how they like to work. Do everything you can to create a safe, comfortable and fun work environment. You may be amazed at the resulting productivity improvement.

Note: If you want to read more about collaboration and software tools that can help, check out Failure to Collaborate Can Trigger Team Turmoil.

Can Agile Teams Be Too Fast?

I worked on a project where the software development team provided rapid response to user requests. We’d meet with the business team leaders every week. Often, they would ask for a change or a new feature and it would be delivered before the next meeting.

Of course, some requests were larger or in a few cases could not be done. But overall, we delivered fast and often.

We had a close knit team. We prioritized stories weekly. The quality of service was outstanding.

There was a downside, however. The business team leaders came to expect this level of service. As a result, they would often fail to think through the consequences of the change they were requesting. They adopted the attitude that if a change didn’t work quite right or didn’t meet their needs, it could quickly be changed again.

Our rapid-response, agile process was too successful.

Product owners and business users need to think through the business processes impacted by a software change to fully understand it’s effects. If they don’t, they end up creating more work (actually re-work). The user community gets frustrated with changes on top of changes. The developers get frustrated having to change what they just changed.

It’s not just about making software changes. It’s also about the impact those changes have on business processes and the people that follow them. Fast and responsive are good agile traits. Adding “business analysis” to the mix makes agile better.