The Mobile OS Wars Are a Good Thing

The smartphone/tablet OS wars are exciting. There are five mainstream choices and one dark horse.

• Apple iOS
• Google Android
• HP webOS
• Intel MeeGo
• Microsoft Windows Phone
• RIM QNX

It’s great to have serious competition in any market. Without it, stagnation results. Just look at how far desktop Windows has come in the last decade. Compare Windows XP to Windows 7. Vastly different, aren’t they? Yeah, right!

There will be a lot more momentum in the mobile OS space due to the competition. Only the most agile companies will be major forces. Here’s my take on the competitive landscape.

Apple iOS – Used on the iPhone and iPad. The clear market leader in mindshare if not marketshare. Apple is the company to beat…for now.

The problem: iOS is completely closed and proprietary. It also desperately needs to have Steve Jobs fully engaged in it’s future growth.

Google Android – Used on a variety of mobile smartphones and soon tablets. Google is looking more and more like the Microsoft of mobile. They have established a strong position.

The problem: Google’s hardware partners will try to prevent Google from becoming too powerful. This will make it difficult for Google to take Android in the direction they want to go.

HP webOS – Used on what were Palm devices. Palm was a great company in PDAs. HP has the engineering skill and market recognition to turn Palm into a smartphone and tablet success.

The problem: HP has had limited success with small, mobile devices. They have relied on Intel and Microsoft to lead the way on larger systems. Can they blaze their own trail?

Intel MeeGo – Still in the lab. Intel needs to have a strong presence in mobile devices. Their future depends on it now that traditional PCs are a shrinking market. MeeGo is open and could be Android compatible.

The problem: MeeGo has no takers now that Nokia has switched to Windows Phone. Intel wants to be more than a chip company but they have stumbled in several attempts.

Microsoft Windows Phone – Used on some popular smartphones. Microsoft has been in the smartphone space for several years. They have powerhouse potential in any market they enter.

The problem: Microsoft is struggling. They need to abandon the Windows desktop mindset and move in a new direction.

RIM QNX – Still in the lab. RIM bought QNX to replace the aging Blackberry OS. They own the enterprise smartphone space and could leverage that to strengthen their consumer presence.

The problem: QNX is unproven in consumer devices. It is an industrial control OS. The Blackberry OS looks to be on its way out. Time will tell if RIM can hold its enterprise share and attract consumers.

The Bottom Line: I wouldn’t bet against any of these OSs given the strong backing they have. The only sure long-term winner is Apple simply because of their consumer focus. Android will survive because it is open but it may fragment badly.

I think there is room for one more major player. My pick is HP due to their consumer savvy. Intel is the dark horse. They may finally be successful in a non-chip business.

Situations can change overnight as companies fine tune their strategies, enter into partnerships and hire new people. We’ll have to wait and see how this plays out. What do you think?

Manager’s Guide to Agile Development

Get out of the way.

The End.

Explanation

Most middle managers at large enterprises are conditioned to command and control. They are expected to know and understand all the major details of every project they own. They have to be consulted on every “major” decision. (Of course, the definition of what constitutes a “major” decision is often sadly lacking.)

This immediately creates a bottleneck. The manager has to be consulted in advance yet he is likely to be difficult to engage. Hallway conversations are almost impossible as the manager is always on the run. Finding time on his calendar is even more difficult as he is likely double booked much of the time.

When the team finally gets face time with the manager, it could get worse. If the decision is deemed to be too big or too complex, it will have to get escalated to a higher level manager or sent to a committee. Can you spell g-r-i-d-l-o-c-k?

Getting out of the way is hard to do.

The agile approach calls for managers to be supportive. They should advise and assist — not control. The team should make its own decisions to the greatest extent possible. The beauty of short sprints and frequent deliveries is that it is easy to re-direct the team if they wander off course.

The command-and-control mentality is a huge hurdle to the adoption of agile development in big corporations. Even managers who are supportive of agile principles are handcuffed by organizational demands and cultural constraints.

If your team is burdened with a manager that is overly controlling, try compromising along the lines of evaluating sprint deliverables. Perhaps in a single weekly or biweekly discussion, the manager’s questions can be answered and he can make adjustments as needed. (Note: Inviting the manager to the daily stand-ups is likely to be a bad idea.)

If your team has a manager that understands and wants to help but is hampered by corporate dogma, keep an open mind. Strategize together on ways to keep the corporate machine satisfied and away from your project while running the project in the most agile way you can.

It’s not easy being agile in a big, bulky organization but it can be done — if managers get out of the way.

Agile Development Won’t Let You Walk On Water

Some companies switch from waterfall development to some form of agile development in order to reduce costs, shorten schedules, improve quality and mitigate risk. Agile can do all that, right?

Sure, and I can juggle while skipping rope and walking on water! Sometimes, expectations are out of control.

Let’s examine what agile techniques can and cannot do under typical circumstances. There are always exceptions but here is what you can reasonably expect:

• Reduced Costs – No. All else being equal, an agile approach is unlikely to be cheaper than waterfall. Staffing, equipment, etc. will be about the same.
• Shortened Schedules – No, again. The amount of work is about the same. It will not magically take less time just because you are following an agile approach.
• Improved Quality – Yes … if you follow agile principles. Active QA involvement and frequent deliveries to the business will result in a better solution.
• Mitigated Risk – Yes, again. Getting the software running and into user hands early will expose problem areas and force corrective action.

Of course, if you improve quality and mitigate risk, you might reduce costs and shorten schedules. However, those are indirect benefits of agile development. They are also difficult to quantify.

The direct benefits of agile development lie in improved quality and mitigated risk. So keep those expectations under control and stay focused on the core strengths of agile software development.

Agile Projects Need Vision

Does your software project have a vision statement? It’s that document that defines a system and summarizes predicted benefits, risks, goals, scheduled milestones, stakeholders, etc.

If your team doesn’t have a vision statement for the software under development, they lack a basic roadmap to guide them toward the end result. A good vision statement can help prevent a lot of arguments and help mitigate a lot of risks.

How formal the statement should be depends on the organization, its culture and the scope of the software. If you’re developing an enterprise application for a large organization, take my advice and make the vision statement a formal, in-depth document.

James Shore offers a segment from his book, The Art of Agile Development called Vision. It presents a simple and informal approach to vision statements.

Process Impact offers a complete vision and scope document template (Microsoft Word format). It is much more formal and detailed.

Vision statements are often overlooked and that’s too bad. They should be written before or in conjunction with the high-level requirements. Be as formal or informal as needed. Keep it concise and distribute it to senior management.

Treat it as a living document to be fine tuned as the project evolves.

Oh, one more thing — if the vision changes drastically over time, you’re project is in a lot of trouble.

Sponsorship + Momentum = Agile Success

Some agile projects are doomed from the start. They simply cannot get going. The team brainstorms with the business folks, defines requirements, creates mock-ups, conducts feedback sessions — then repeats the process again and again. They have paved the road to nowhere.

How does this happen? How can a team of software engineers and managers spend weeks and months working on a software application and have nothing to show for it?

Being agile is not good enough

Sound ridiculous? It’s not. I was once on the periphery of just such a project. I was not on the project team but I acted as a technical subject matter expert regarding the dataset to be processed by the application.

Requirements were written and tossed. Why? They simply missed the mark. Trying to please everyone often results in pleasing no one. Back to the drawing board.

Requirements were re-written. Mock-ups were created. A software application was written and made it all the way to pilot deployment. Another miss. The application couldn’t attract enterprise commitment. It did too few things well and left out too many others. Tossed again.

Requirements were written for the third time. More mock-ups and a prototype application. More problems achieving enterprise commitment. Everyone gets frustrated. I lost interest.

How does this happen to project teams?

1. No Executive Sponsor. If your software application is intended for enterprise use, you must have an executive sponsor. This must be a business person at the VP level or above who has a vision for the application. Someone with the respect and stature to make decisions and get people moving. Enterprise projects don’t succeed without executive sponsorship.
2. Lack of Momentum. The business doesn’t care about requirements and mock-ups. Those items are artifacts of the development process. The business wants solutions. The development team must move fast to deliver useful software and keep improving it to show progress. That’s the core of agile development.

Agile teams are not immune from organizational dynamics but they know how to move fast. Line up that executive sponsor and go. Don’t look back. Don’t second guess. Don’t make excuses. Just go!

Agile Stories Need Roles Not Users

I’m sure you’ve read that only drug dealers and software developers call their customers ‘users’. When it comes to agile software development, simply calling everyone who will run your software, ‘user’, is a problem.

Agile software requirements are usually captured as stories following a structured format like this:

“As a <user role> I want <goal/desire> so that <benefit/reason>”.

All too often, every story begins with “As a user, I want…”. User! I don’t think there is a corporate job title of “User”. The role of ‘user’ doesn’t convey any information about the business person running the software.

For the software developers to implement what the business community really needs, they have to relate to the job functions being performed. The business team won’t just be ‘using’ the software. They will be following a business process toward achieving an outcome.

The first purpose of stories is to help the development team understand who is running the software. To help figure that out, answer a few questions:

• What is the software user’s job title?
• What is the user’s job function as it relates to the software?
• What responsibilities does the user have that the software will help with?

Don’t just implement stories the way the technical team sees them. Create a mental image of the business person using the software to help the software developers implement the stories the way the business wants.

Agile Solutions Are About Benefits, Not Process

Agile software development and the Scrum process are based upon collaboration — creating a tight union between the technical and business teams.

This appears to be a simple and obvious approach but it turns out to be one of the most difficult aspects of agile and Scrum development. Some agile/Scrum projects fail simply because the business would not actively participate.

What is active business participation?

To be actively engaged, the business must appoint a “Product Owner” (PO). That person must attend the daily stand-up meetings and help the team make decisions.

The PO is a liaison between the technical folks and the business folks. The PO should be empowered to make decisions. For difficult or complex questions, the PO will take the issue to the stakeholders and gain consensus.

It is not an easy role to fill but is critically important to a fast-paced, agile process.

The other critical area of business participation is evaluating the frequent software deliveries by the technical team. As often as every week, the technical team may ask the business users to evaluate the software and provide feedback.

While the PO can perform much of the evaluation, it is important get feedback from multiple end users to ensure that the software does what the business really needs.

Agile development is not agile business

Problems begin when the business team refuses to appoint a PO or they appoint one who is clueless. They may ask that the technical “Business Analyst” represent their interests to avoid having to assign someone.

The business may also fail to actively participate in the software evaluations. Their attitude may be “just let us know when the software is done”.

When these scenarios play out, you end up with a process that is agile for the development team and may result in better software — technically. However, it’s not agile for the business team and the end result may not meet their needs.

Agile is not the problem

Are agile development and the Scrum process to blame? Is something wrong with the whole concept of being agile?

Winning people over and getting them fully engaged are not intellectual problems. They are emotional ones. If the technical team hasn’t fully engaged the business team, it’s because the technical team has failed to create a powerful vision of change.

The business team will always react apprehensively to change. They will question the need for change and resist it. They will also resist taking on more work and responsibility. They have enough work to do — a business to run. They are not in the business of developing software. That’s your job!

Create positive emotion around the new software

To get passed this resistance, you need to create a vision for a new and better way of doing business that is powerful enough to overcome negative attitudes AND generate positive participation.

Sales people will tell you that buyers assess products intellectually but make buying decisions emotionally. This applies to software development as well. You need to create an emotional attachment to the software.

I can hear all the intellectuals (aka, software developers) reading this and thinking “you must be joking”. For us (yes, that includes me) intellectuals, this is a tough concept to grasp and even tougher to execute.

Think about it. Do you make buying decisions based solely on technical details? Be honest. Do you have an emotional attachment to Apple, Linux, Microsoft, Sony, Ford, GM, Google, or some other brand? I’ll bet you do. Marketers depend on it.

Come up with an agile pitch

Do yourself a favor. For your next agile project, spend some time brainstorming all the benefits the business will derive from the end result AND from actively participating in the process. Then, sell them.

Pitch the benefits. Build an emotional attachment to the effort. If you have trouble doing this, find someone on the  business side to help. (You have an executive sponsor, right?) Here are 10 business benefits to get you started:

• Cost Reduction / Avoidance
• Increased Revenue
• Productivity Gains
• Service Level Improvements
• Enhanced Product Quality
• Marketplace Differentiation
• Better / Faster Decision-making
• Faster Customer Issue Resolution
• Competitive Advantage
• Regulatory Compliance

Like it or not, you need to sell the solution. Don’t sell agile; don’t sell Scrum. Sell the solution. Agile software development and the Scrum process are great tools but they can’t do it all. You need to sell the benefits.

Agile Development Teams Take on Debt

Technical debt is a hot topic among agilists. What is it? Does it really matter? Is it a problem? Should you be concerned about it?

Let’s start with a definition of technical debt. It occurs when development teams cut corners to meet deadlines. Let’s be honest, we all take liberties to meet scheduled commitments. When we do, little things remain — let’s say — less than perfect.

Technical debt can occur in many forms:

• Stories left partially unfinished
• Software architecture that is inelegant at best and sloppy at worst
• User interface design that is confusing
• Source code that is inefficient and bloated
• Test cases that are incomplete
• Documentation that is terse and misleading

Okay, so none of these sound like good engineering practice, do they? Regardless, some aspects of technical debt will occur on every project.

Does technical debt really matter in agile software development?

Some debt is okay. Most of us have monetary debt of some kind — education, car, house, credit card, etc. As long as we maintain control and don’t let it grow too large, debt is a good thing. It gives us leverage and helps us enjoy life.

Technical debt is similar. There will always be some. We just need to keep it controlled.

Be aware that some technical debts are more significant than others. For example, if you have a code module that is poorly implemented, you are in debt. If the code module is heavily used, the debt will have to be paid, that is, the code will have to be refactored. However, if the code module is only rarely used, why spend the time to refactor it?

A similar argument can be made about any of the aspects of technical debt listed above. If it’s important, pay off the debt by refactoring, cleaning up or completing the artifact. If it’s not important, ignore the debt or only invest enough time to reduce the debt to a tolerable level.

Stay in control. Take on technical debt during the project in a measured and disciplined manner. Pay it off as needed. Make sense?

Apple’s App Store Is an Old Concept

Apple takes all the credit for inventing the concept of an “app store”. They even want to copyright the name. Copyright aside, Apple did not invent the concept, the open source community did — over a decade ago.

Linux distributions (aka distros) use the concept of ‘packages’. A package can contain any software that runs on a particular Linux distro.

The idea began back in 1998-1999 when Debian and Red Hat recognized the need to give Linux users a way to manage the software on their systems. Debian offered the Advanced Packaging Tool, or APT. Red Hat offered the Red Hat Package Manager subsequently renamed the RPM Package Manager (a recursive name), or just RPM.

These solutions started out as simple command line tools. You had to be technically savvy and you had to know what software you wanted. While the tools were rather crude, they were effective and proved popular.

Technology has advanced a long way in the last decade. APT and RPM have graphical user interfaces today. In fact, there are several to choose from such as the Synaptic Package Manager and Yum.

These graphical tools enable Linux users to search Internet repositories for software using various criteria; display what is currently installed on a system; install, remove, upgrade and downgrade single and multiple packages on a system; find documentation for a package, etc.

Sounds like an app store, right?

The key difference is that most Linux apps (or packages) are freely available. (There are exceptions, of course, and if you want professional support, it will cost you.) In addition, the open-source community doesn’t control the software that is available. It is up to the software developers and the end users to control and influence the contents of the repositories.

Apple’s App Store is a dead end.

Apple’s attempts at total control of its app store are doomed to failure. Independent software developers and big companies alike are getting tired of the unreasonable constraints and changing rules.

As web-based technologies get more sophisticated, software developers will be able to deliver powerful applications directly to end users through browsers. In general, there will not be a need for using specialized tools to create platform-specific applications in most instances.

Apple will have to enhance its iPhone/iPad Safari browser to run these next generation web-apps or risk losing market share to Google’s Android. You won’t need an app store except for software with unique, iPhone/iPad-specific features.

Apple will still prosper. They have much more to offer than a re-packaged software distribution concept they call an app store.

Agile Development Teams Know How to Fail

Do you want your software development team to develop better software faster? Learn to fail fast, often and cheap. Sounds silly doesn’t it? You want to succeed not fail, right? Fail often? What’s up with that?

Agile development advocates take a lot of heat over our efforts to fail fast.

Well, the word ‘fail’ is slightly over the top. It’s not about project failures. It’s about making small mistakes and more importantly, learning from those mistakes to achieve continuous improvement.

The idea comes from lean manufacturing techniques. Achieving continuous improvement means catching mistakes quickly and taking corrective action immediately. The same principle applies to software engineering.

Objective: Learn from mistakes

The theory is that mistakes are going to happen. Clearly, you’ll try to prevent as many as you can but there will always be some mistakes. Don’t go overboard trying to prevent mistakes,though. Trying to achieve perfection can nearly paralyze you.

Once you accept the premise that the software development team is going to make some mistakes, you’ll want to make them as early in the development effort as possible. The earlier the team ‘fails’, the sooner they will learn and improve.

Also consider that early mistakes are less costly to repair than those made later. Mistakes made early in the development cycle leave plenty of time to adjust. Those made later may have to be deferred until a future release.

How do make mistakes sooner rather than later? Identify high risk areas in the development effort and work on those areas as soon as possible.

Accept that many mistakes will be made. Stories, estimates, code, tests, documents, etc. will all contain errors and omissions. Accept it and learn from it all.

Control the perfectionism

Foster a culture that embraces failure. Someone once told me that “Progress is making new mistakes.” The key word is ‘new’. Move fast. Make quick decisions. Be prepared to…

• Fail fast. Learn quickly.
• Fail often. Learn continually.
• Fail cheap. Learn inexpensively.

That’s what agile software development is about.