I am adventurous when it comes to e-commerce, mobile wallets, social sign-in and all things that support digital marketing. I’ve had to be as I am responsible for pushing these industries forward. As consumers we love to take advantage of free email, instant messaging apps and news. And as marketers and business owners we welcome this barter system established to offer such services in exchange for the ability to provide advertising to such consumers, which is increasingly more targeted and hopefully more relevant to each individual.
Behind the scenes my own little fears sometimes drive me to use my American Express credit card for a purchase with a retailer I don’t know well, I almost never use my debit card as I’m not sure it’s really as well covered from fraud as my other credit cards are, and I have a specific email account I use for websites just in case they trade it or sell it. So, while adventurous, I still worry about too many of my preferences getting out, wonder how it could impact my ability to get a life insurance policy at some point in the future, or worse yet how data about me and my lifestyle could impact my ability to stay employed. But, I fundamentally believe that it is human nature to barter. The only true currency is trading goods and services of like value, … and sometimes, this may require a few participants to complete the transaction.
“A few years ago, users of Internet services began to realize that when an online service is free, you’re not the customer. You’re the product. But at Apple, we believe a great customer experience shouldn’t come at the expense of your privacy.” – Tim Cook
As Apple Pay was announced this month I smiled with enthusiasm. Many mornings I grab a bagel and coffee at my neighborhood café that uses Square. I rarely have cash and being able to just walk over with my mobile phone and the Square Wallet app is refreshing. I still have to find my keys so that I can get back into my apartment, but even that step could be eliminated if I were to get a wireless door lock.
Recently I joined Intel to drive product strategy for solutions enabling retailers to create the next revolution in the shopping experience leveraging the Internet of Things. I envision experiences where the physical store knows who I am, finds my favorite store associate who then is reminded of all my tastes and preferences, and is able to help me find what I was looking for or simply didn’t know I needed. The purchase event will of course be frictionless. As I investigate the details of how the store will detect me, how applications will look up who I am and pull back incredibly detailed information, and expose it to devices in the store such as a tablet laying on a counter or a digital sign near the dressing room, it’s become chillingly obvious that my traditional application development architectures are inadequate.
As I think about hackers carefully placing their own beacons and sensors in the store calling the same APIs as the retailers business application or simply monitoring this data as it’s passed around the room, I see now that as mobile application developers we have to begin to understand how to know our environment, challenge that it is secure and verify that only our own apps are engaged with such personal and sensitive insights of our customers. I challenge every developer to learn more about gateways that can monitor your physical space, tokenization systems that can minimize the actual storage and transfer of sensitive data and ultimately keep in mind that your customer is whispering a secret into your ear and none of us wants to be known as someone that can’t keep a secret.
With all the doomsday prepper shows and natural disasters that seem to hit our planet from all directions setting back communities into distressed chaos, I certainly wonder what it would be like if all hell broke loose. For full disclosure, I am the author’s son and supporting editor of this book. This is an art of passion and not a commercial enterprise, so please forgive minor editing mistakes. We did the best we could and look forward to making corrections based on readers feedback. If you have any, please visit our facebook page facebook.com/montanaalliance and we’ll make the correction (great part about a Kindle book).
Now, all of that said, I thought this book was quite the adventure. I had a hard time getting into it at first, wondering to myself, “is this plausible?” Then I realized it doesn’t matter. Between Japan’s Tōhoku earthquake and tsunami and Hurricane Sandy in the US, it’s clear that there are many things that could set us back a bit. What was more engaging was imaging what it would be like. Living in San Francisco, we’re all told how we should be prepared for “the big one”, have extra water on hand, food, and other supplies. But what happens if “the event” makes it such that our electricity production and manufacturing abilities are minimized to the point where we’re back to hunting and gathering? That was when I got hooked on the storyline. It’s set years later, outlining the challenges and creativity of different groups of people all learning how to survive where canned goods eventually are no good and even bicycle tires have rotted. What kinds of communities will form? How will you interact with your skilled neighbor? Do you trade with him or direct him at gun point? This is where I think this storyline takes off. There is the obvious hippy camp that gives a socialist structure a try and communal living a focused strategy, and of course you have to have the crazy dictator who ceases control of weapons and thugs that will help him to power. What’s more interesting is how you’re mind wanders from supporting one group to another, questioning what alliance you will actually make. If you’re looking for an escape, and want to challenge your idea of what prepared means, take a read. Let us know if you would join the Montana Alliance!
I’ve made an assumption all this time that the thumbs up/down would indicate to Pandora that for a given station, I don’t like a particular song. Not necessarily that I don’t like that song entirely, rather that it’s not appropriate for the sound I want the station to play.
Here’s an example…
I could create a station for Bon Jovi and it could be all over the place. Alternatively, I could create a station for You Give Love a Bad Name, and occasionally it might through in a ballad. But, maybe I only want high energy Bon Jovi type music, so in this case, I thumbs down all those ballads.
Now, I’m kind of a ballad guy, so in another station I might create it based on Bed of Roses, and in this case, if you start playing Living on a Prayer, I’m going to thumbs down it. Not because I don’t like that song, but because I don’t want it in this station.
I can’t find anything in the Help section that would let me know if you actually do this. To be honest, it’s the basis for my subscription and the reason I love Pandora. So, if you don’t, please start working on it..and oh, don’t let me know.
If you do, then I’d love to have this validated!
I have been contracted to help with the optimization of the site http://www.virtualpbx.com/. In light of recent Google updates the site’s link profile needs to be cleaned up, so we would like to request that you please remove the links to our site located here: http://darinarcher.com/blog/2007/09/ http://darinarcher.com/blog/mobile_web/ http://darinarcher.com/blog/mobile_web/mobile_work_phone_that_switches_to_personal_phone.htm
Due do the Google Penguin update these links are negatively impacting both of our sites by creating an unnatural link. Please know that your site’s integrity and business practices are not in question, it is just that the existence of the link itself causes Google to establish a relationship between our sites that looks unnatural.
If you have any questions about the request above, please contact at Virtual PBX. He can be reached at .
Thank you for your consideration, @removethislink.com
I think this is a real shame. I get that there is a significant amount of SEO spam out there, but the fact that I received this email, given my intent in my blog post… well, shame on Google. This sure feels evil and controlling and against the culture, purpose and value of the Internet.
Online technology has forever changed the game for commerce.
Customers expect compelling, personalized, and consistent experiences across devices and channels that spark sustained conversations and turn visitors into buyers. This experience-driven commerce is the main driver for conversion and sales.
Adobe Experience Manager integrates with e-commerce platforms, such as hybris, to provide a unified environment for creating and managing product, website, and campaign content — optimizing the entire customer experience from initial touch to checkout.
View my on-demand webinar and white paper to understand:
The relationship between experience-driven commerce, conversion, and repeat business
Technology best practices, such as personalization, social sharing, and rich content
Strategies to build agile, customer-centric experiences across multiple channels and mobile devices
The power of personal experience is critical to a successful brand and commerce strategy. Is your business prepared?
General musings on relevant trends affecting today’s eCommerce platform providers:
1-click and the paradigm of the cart – Apple & Amazon have reprogramed our expectations of eCommerce. In the beginning the analog chosen was the shopping cart. This made particular sense for online retailers selling a diverse selection of goods. However, most eCommerce sites today focus on a particular product catalogue and the act of going through a shopping cart checkout experience simply diminishes conversion. For example, if I go to Burton to buy a snowboard, I’m not putting multiple boards in my cart. If I want to buy a digital camera from Cannon’s website, I’m likely only getting one. And even if I go to REI.com to pick up a replacement pair of sunglasses lost over the weekend, my goal is likely “in and out”. Now, this doesn’t mean that the “window shopper” doesn’t exist or that there aren’t many retailers looking to get you to add as many items to your “basket” as possible, but the act of shopping should support the “buy now” phenomenon popularized by Amazon’s 1-Click, Apple’s licensed use of it for iTunes and the Mac App Store, along with eBay’s “Buy it Now”. Many companies selling online are finding that their existing platform is “stuck” in the paradigm of the shopping cart and cannot even support simple concepts like a “single page checkout”. Note: This is the main reason why Adobe.com did not implement ATG.
Mobile – Best Buy is struggling because it became the showcase for products to be purchased on Amazon later. Many savvy shoppers across all demographics are using their mobile phones to quickly price check items and do product research and lookup customer reviews. In these moments, some companies are supporting these requirements and others are losing the customer to a Google search that can often end with a 1-Click purchase of the same product in store bought from Amazon, which might even come with same day availability.
Product management. / multi-channel – Customers expect that companies with both eCommerce and “brick and mortar” presences to sell the same products and have access to the same inventory. These systems grew up under different corporate owners and thus are different databases all together. Companies now aspire to have one master product catalogue that can have all information (PIM) managed centrally and enable pricing and inventory to be pushed out to physical stores, online site(s), and partner marketplaces (e.g., eBay, Amazon)
Order management. / multi-channel – customers assume that if they buy online, they can return in the store. This requires centralized order management and visibility of all orders across the enterprise. Again, two systems today.
Relevance & Retargeting – customers expect companies to know their shopping behavior and even their browsing behavior. Amazon has popularized “recommendations” and leads customers to expect more relevant, targeted content. This includes carrying this insight forward to marketing campaigns such as emails, SEM and display ads. Sites that tie these insights together best and incorporate them effectively in their marketing spend, convert higher and sell more online. Today, companies have to use a plethora of disparate solutions to build these campaigns and often miss the pattern that would “push the customer over the edge” to buy.
Subscriptions – Beyond music, movies and games, more and more companies are finding ways to offer their products and services under a recurring order model. From shaving blades to organic produce, companies want to be able to bill for products and services on a recurring basis. This is not inherent in most eCommerce solutions and requires companies to support two billing solutions and two order management approaches.
Flash Sales – Social, email campaigns, mobile SMS (text messages), native mobile apps, and the website(s) itself are all vehicles used to inspire quick conversion and/or ‘dump inventory’ that needs to be moved. Popularized by Woot & One Kings Lane, future platforms not only need to enable this by channel, but also enable “1-click purchase” and automate based on business rules (e.g., If product X expires on September 16th, 2012, and there is > than 20% of inventory within 30 days of expiration, deploy flash sale to “mobile app”, Facebook page and Amazon.)
Social – While “social” receives tremendous amount of mindshare, company after company finds the results to be marginal at best. “It’s like trying to sell to someone talking to their friend at a bar”. While this may change over time, the key tenants above of enabling a product catalogue to be pushed out to different marketplaces and “flash sale sites”, is the same capability that can be leveraged by a Facebook page or whichever “social site” becomes the next standard (e.g., pinterest, Google +, yet to be invented).
Thirty-five percent of IT departments follow agile delivery methods, according to Forrester. No, they’re not just following iterative methods and calling it agile, but a little over twenty percent are and only thirteen percent are still following a waterfall method, including the famed CMM. These thirty-five percent are adopting a working style that empowers our highly skilled and highly paid technology professionals to solve business problems creatively and autonomously in self-managing, self-organizing, accountable teams. Beyond IT, product development at software companies all over the world have also begun to abandon the barriers of innovation and speed moving to Scrum teams that consist of people from product manager to test engineer.
Continuing to manage projects following a waterfall method invites failure and inconsistent customer satisfaction. In fact, Dr. Winston W. Royce, who sent us all on the waterfall course explicitly stated, “I believe in this concept, but … [it] is risky and invites failure.” Too bad we’ve spent the last fifty years holding tight to the belief that we can manage software development with a project plan that presumes it can predict how long it will take us to elicit requirements and design a solution that meets the customer needs.
At this point you’re probably thinking, “Yeah, it’s easy for our R&D and IT teams to follow agile as they don’t have an external client to deal with.” But, we believe you can and here’s how.
Why should a professional services organization adopt Agile?
Several years ago Darin was mentoring a young consultant who was ambitious and eager to make her mark on the world but had become disillusioned quickly after her brief project experience. She couldn’t understand how so much time was spent on planning, discussing what should be done, and ruminating on how it would be done, then when she had started the actual work, she found that team after team would fall behind schedule and reduce scope or cut quality to meet deadlines. Sound familiar? She shared a great metaphor outlining how the project was progressing:
“We started the project getting the client really excited about what we were going to deliver. It was a Lexus. It was going to solve all their problems and get them there in style. Once the project began however, during requirements gathering we realized that we wouldn’t be able to build the Lexus in the first release given the timeline that was committed to. We would be able to build a Toyota Camry though, and it was pretty much the same thing as the two shared the same frame, body, engine and other parts. They’d just have to let go of a few bells and whistles, and if they did, we’d be right on plan. On it went through the software delivery life-cycle where at each stage it seemed necessary to reset expectations and continue to downgrade. By the time testing began we were now only committing to a Toyota Corolla. When UAT began, we realized that Release 1.0 was not going to work and that it would now only consist of the frame and body, and the engine wouldn’t be put in until Release 1.1, when we’d be able to do a soft launch.”
All too often we work with our clients enthusiastically espousing how our software solution is going to radically transform how they do business. What we don’t admit is that it’s difficult to change a company’s processes, gain buy-in from diverse stakeholders and more often than not our systems are not as flexible as we need them to be.
An agile approach follows an empirical process model that requires frequent inspection and adaptation, recognizing that software development is not like stamping out toys on an assembly line. Rather than spend a client’s money and time planning, you begin the work focusing on the highest priority items that will deliver business value. When those items are delivered, you move on to the next group of prioritized items. The outcome is that you deliver the Lexus in Release 1.0.
How do you convince a client?
Professional services organizations, consultancies, law firms, ad agencies, and any other services business have one thing in common – the contract. We call them work orders, statements of work, services contract, work request, etc. It’s our way of comforting a client given what we are selling is intangible. It’s not an invoice that comes after the work has been done. That would be all we needed if they were buying a hard-good from us as they’d be able to see it, touch it and say, “I want two hundred.” No, it’s not easy to convince a client to trust that we’re going to deliver on a promise given none of the work can be seen and in most cases understood. So, we draft a piece of paper that attempts to illustrate what we jointly agree the services will be. And when it comes to software, we’re asking them to imagine something they’ve never seen and then sign on the dotted line to indicate they understand it well enough to commit to a long engagement. Let’s be real, all you’re selling at this point is your reputation as both parties know that the piece of paper doesn’t even come close to defining what they’re going to get from the engagement.
An agile approach however only requires the client to hold their breath for one sprint at a time. You will continue to take time during the sales process to educate them on your approach. You’ll walk them how you will take a backlog of work and following their prioritization deliver work in small increments that demonstrate the software working, not provide hundred page specifications that they have to then envision what the software will look like, but real working code. This is dramatically different. This is a new commitment. This says, “I’m going to focus your money and energy on getting you up and running so we can solve those business challenges we convinced you our software solves.”
Still not convinced? Ask them to sign up for two sprints. If your software is a large, traditional implementation then your sprints are probably going to be thirty days each. This means you’re only asking them to hold their breath for thirty days and will only require an investment of a small portion of the engagement. If they don’t see results and feel engaged more than on any other project they’ve had, then let them terminate the agreement for convenience. We’re convinced that if you follow agile methods, you’ll demonstrate value in the first sprint and they’ll be hooked. They’ll be hooked because they’re going to see a level of transparency they’ve never had before and the data will be real. They’ll be hooked because you’re going to deliver working code after the first sprint. No, not Visio diagrams, HTML mock-ups or wire frames, but real, working software.
Practically speaking, you should break the work up into two engagements. The first is your Discovery Phase. During this short engagement you should have pre-packaged questionnaires, process flows and a vanilla version of your system to demonstrate. The exercise then would be to walk through your system similar to how you would in a detailed RFP life-cycle, but the focus would be to identify the areas that may need customizations to meet the client’s needs and gather the basic information that you need to understand what the effort will be to configure your system. We’re making the assumption that it’s packaged software (a.k.a., Commercial off the Shelf [COTS]) and so you should know what areas you have to setup and configure. We have seen many companies use a lengthy questionnaire that can be completed by the client themselves, to gather the key insights to allow the team to estimate the engagement. These details now become the backlog. Once you have this you can facilitate a prioritization with the client such that you finish the phase knowing what the work is you team needs to do and have something to estimate.
Estimating the Work
As with other areas of this article, we expect you to have read about agile and Scrum, and in this case we would recommend that you dive deeper into the books on estimating with agile. But, we do want to provide some highlights around the approach. Estimating software implementation efforts is hard. No methodology in the world can predict what your client’s demands and dreams will be once they become more familiar with your software. The difference between agile methods and traditional waterfall methods is agile approaches don’t pretend they can. Estimating following an agile approach is composed of two main processes. The first is when you are estimating backlog items and the second is when you’re estimating throughput of completing a grouping of backlog items.
Following the workshops and questionnaires of the Discovery Phase, you’ll have a backlog of items that represent specific configuration tasks and customizations. Each of these needs to be estimated for not only the “dev time”, but all the time related to completing the task from further requirements gathering, to integration testing and deployment. Teams use a method of comparison to something they know and use a metaphor such as “t-shirt sizes” to keep them focused on referencing something they know versus the new subject material. An example is when they look at a backlog item that requires them to setup the login screen. They may see that there are no changes to the software and thus be able to flag that item as Extra Small. In another case, they may be looking at an item that is typically a couple days of work, but in this case there are a number of customizations. So, what might normally be flagged as Medium or Large may now be increased in t-shirt size. The t-shirt sizes do represent time and thus later can be converted to hours or days. It will still remain difficult to estimate the throughput and so teams are best served using a comparative method that references past experiences with similar clients. Once the project begins however, estimating the completion time becomes increasingly accurate as you inspect actual burn-down of the backlog and the velocity of work completed. This becomes valuable when the client makes a request for something new in the middle of the project.
Regardless of what methodology you’re using today, your team should have a list of tasks or deliverables that if checked off as delivered mean your system is setup. Use this list to keep track of estimates and “actual” from client to client and estimating will become easier and easier for your team during the fast paced sales process.
Statement of Work
Well, we still need a contract. And yes, introducing a new methodology is likely going to be difficult – at least until everyone wakes up and starts challenging waterfall contracts more. Until then, we propose a few modifications to your contract to help alleviate client concerns. The first is to define Scrum and agile in the document itself. Include an overview of the process, your client’s involvement and highlight the level of transparency provided with this approach. We used illustrations to show how the sprints work pointing out that they get to have a formal review of working software at the conclusion of each sprint. Emphasize that they will also be able to control the prioritization and change direction as you go – something you won’t find in a waterfall based contract. Include the backlog and each item’s estimate. This should be translated to engineering hours or days, whichever is most relevant to your efforts.
A key selling point to agile is that it is much more flexible to change. Rather than scare everyone into the stone tablets that are typical requirements of waterfall engagements that require senior councils to approve any change once the project has begun and typically a major “sign-off” of a change order or revised contract, agile methods allow the client to add, modify and remove items from the backlog as they go. So, if they get into the project and having seen demonstrated working software after a few sprints realize that your solution is amazing and they just want to get using it and no longer are caught up on all their customizations, those items are simply de-prioritized and not executed on. Now, you’ve probably been wondering at this point, “yeah, this sounds all fine and good, but my client has to get approval for a budget and there isn’t all this infinite flexibility!” You’re right, which is why we propose introducing contingency. Yes, we still need contingency. The difference here is that we’re only going to use it if the client approves it versus adding in an arbitrary number to each waterfall phase because we know we never get through it like we predict. In this case we create a bucket for “refundable contingency” that gives the client some flexibility later to change the prioritization of a backlog item and/or add new scope once they’ve become more educated on our system. The best way to use this is to keep the client focused on using the software as intended and minimize customizations. When in the heat of the moment you can say, “we can definitely add a new backlog item to the next sprint that will allow for that customization if you approve us decrementing the refundable contingency bucket.” So, the client gets a contract with one number, which is really made up of what you believe the work to be plus a bucket of refundable contingency so that they can make their budget ask with some room. Can you always get this? No, but it’s worth a try and a lot easier to get approval for when they don’t just think contingency is being added to each scope item. Remember Parkinson’s Law: “Work expands so as to fill the time available for its completion.”
Again, if they’re not ready to sign up for the whole engagement, ask them to sign up for two sprints, then prove it.
Staffing & Training
Agile teams require deeper skills and competency than most managers are ready to recognize. They also require more multi-discipline resources that are comfortable doing different tasks. In a scrum team, the whole team commits to delivering the scope of a sprint, how they get there is up to them. The majority of coding tasks will be done by the developers and the majority of testing tasks will be done by the test engineer, but you need test engineers that can jump in and help coding if the team falls behind and developers that test their code. Additionally, you need to continue to invest in their skills. Every company should be doing this anyway, but let’s face it, most don’t invest in their human resources. We spend tons of money upgrading computers, changing out old furniture, upgrading plants and equipment, but rarely have the same focus on our people. Agile teams require deeper expertise and thus need more investment. The benefit is that you accomplish significantly more output with significantly less people. You’ll find scrum teams of seven to nine people that can outperform a forty person team from the top system integrator in the world. So, if you’re team uses a scripting language to configure your software, or have to code in Java typically or just use your proprietary configuration tools, make sure they are experts in these skills and invest in this over time.
Staffing an agile team requires breaking down boundaries between disciplines. It means a team must work together, even though team members may have reporting relationships that go up to different executives in your company. This becomes very difficult for most managers as they begin to worry about where they fit into this new world, which is unfortunate because if they were doing their jobs they’d realize their value is not in trying to control the flow of information or who works on what, rather they’d focus on improving the talents of their team by designing training programs for them, coaching them in their day to day work and finding new ways to share their skills across other teams so that everyone begins to build some multi-discipline experience. This is a huge job and if done right can produce truly high performing teams.
The other key to staffing an agile team is to create a new working environment for these teams. The cube farms and closed door offices don’t inspire creativity, innovation or collaboration. You need open work spaces, sometimes called “team rooms” where each team member can see one another, work together and collaborate on the commitments of each sprint. This doesn’t mean throw everyone in bullpens and save a ton of money on office space. You still need private areas and people need quiet places.
And most importantly, get everyone trained on the agile methods you’re adopting. If you choose Scrum as your project management framework, which is becoming the standard, then get everyone trained. Even if they won’t always play the role of scrum master, they all should be able to step into it and now how the process works. For those that will play a more traditional role of business analyst or client engagement roles, get them trained in what is called the product owner role, this role manages the backlog and helps the various stakeholders of a project to define their requirements. Engineers should also get training on software test automation tools as this is a critical pillar of agile delivery teams.
Project Tracking & Governance
Most people think agile is a free for all. They think it means developers get to just begin coding without requirements defined and no documentation. What most don’t realize is that agile methods actually have more planning and with more team members than any other method. And yes:
* You still need a project work plan; the architecture of it is just changed,
* You still need to track what everyone is working on and assigned to,
* You still get to track estimates and actuals,
* You still get to keep track of deliverables and milestones,
* You will have amazing status reports, and
* You still have change control.
Project plans are your backlog. You can pre-arrange the backlog items into buckets that you believe will be future sprints to allow you to forecast roughly when the engagement might finish. This also allows you to illustrate to the client the order that might be followed. These tasks though should be deliverable-based rather than activities-based. This allows you to demonstrate “earned value” rather than simplified metric of percent complete. The real value of agile in project tracking is the level of transparency provided. Prior to each sprint, a sprint backlog is created that is a decomposed group of backlog items that are made up of smaller tasks or work items. Each day the team then marks off only those that are complete, not partially complete, but 100% ready for deployment. This allows the team to provide a “burn-down chart”, daily illustrating progress. This along with standard impediment logs (a.k.a., issues log) can be aggregated to provide a daily status report. each backlog item has an effort estimate and during the sprint planning meeting, team members assign themselves to each item and so you also have visibility into who’s working on what.
Within a given sprint the rule is that you don’t introduce change. This is typically not met with too much resistance as the client only has to leave the team alone for a max of 30 days. Any changes proposed are converted into backlog items and then prioritized against everything remaining. If the team is completing items ahead of plan, then you may be able to absorb the new backlog item. If the new or modified item introduces more effort than originally planned, you would then remind the client of their refundable contingency and ask if it’s important enough to decrement that budget. This activity alone often gets them thinking more about business value of their ideas than any other approach you’ve used in the past. It puts the onus on them to make the call.
Quality Assurance (Testing)
Testing typically makes up most of the effort of any project. Many project managers like to pretend that testing will be some percent of development and most executives believe it should be less effort as we all want more features, less overhead. The reality is testing often takes almost twice as much effort as development and breaks schedules because of two reasons. The first is that developers in the waterfall approach get trapped in the telephone game and have to make guesses at what the client wanted and focus on meeting schedule milestones over validating assumptions and thus cut corners when it comes to the quality of their work. It will all get caught in testing, right? Secondly, when the project does decide to move to the test phase(s) of the project, the team typically has planned for manual testing that takes a significant number of resources and hours to repeat tests over and over after each bug is resolved. To become an agile team requires the team to validate their assumptions often with their client through daily check-ins and formal sprint review meetings and requires a team to automate their tests so that they can be run daily and constantly to continually verify the system works as expected.
This will require test engineers that have deeper technical skills and can build tests in the various automation tools. This also requires a better understanding of how the code actually works so that they create efficient tests rather than only black box tests because they don’t know that executing the four different scenarios is actually just executing the same function in the code four times.
The goals of an agile team are not to produce documentation and test cases and scripts, but rather to demonstrate working code that is potentially shippable after each sprint. This requires test driven development and automated tests to be built in the beginning. It also means a lot less overhead in your test management efforts as the team is more focused on making the system work then showing how the dev team missed requirements and/or have bugs.
How do I get started?
Don’t try to do this on your own. Get a coach and some practitioners to join your team. Supplement the teams with people that have done this before and get everyone trained up on the basics. You should also show your commitment by getting trained yourself. Unfortunately there is no “dipping your toe in” when it comes to agile. As a professional services organization this makes it difficult to begin. If you have an existing client that has follow-on project work, find a way to get one of those projects following this new approach. If you have a project that has stalled out or is failing, stop what they’re doing, create a backlog of what’s left and begin getting it back on track one sprint at a time. And however you start, don’t forget to employee the basic agile engineering practices out of the gate such as continuous integration and automated testing. This is your foundation.
This article was co-authored by Will Yen, VP, Interactive Marketing & Director of Consulting, Kenny & Company.
Recommended Reading: Succeeding with Agile: Software Development Using Scrum
by Mike Cohn Agile Project Management with Scrum (Microsoft Professional)
by Ken Schwaber Agile Estimating and Planning
by Mike Cohn
 “Managing the Development of Large Software Systems”, Dr. Winston W.Royce, University of Maryland, 1970 Originally published at PSVillage on February 16, 2011
I recently purchased a Motorola Droid XAndroidsmartphone from Verizon Wireless after having been an iPhone owner for a little over two years. I made the switch for a few reasons, the two primary being a.) AT&T’s network sucks and b.) upgrading to iOS 4.0 on my iPhone 3G rendered it useless due to performance issues. Before I go into my reasons, I’ll openly admit that I’m an Apple addict and have been since I was in middle school. I love almost all things Apple and dreamed of the day the iPhone would be built. In the beginning I had many complaints, but over time either adjusted to its deficiencies or Apple resolved them with new capabilities. That said, I began my journey with an android phone with as much openness I could and to be honest was a little excited to make the switch and see what it was all about.
Android User Experience is Clumsy
One of the immediate challenges with the Android ecosystem of hardware vendors is that they are all making modifications to the user interface and in some cases almost entirely changing the experience. This is unfortunate as it means the evolution of improving the operating system and user experience will be disjointed and slowed as each group will do their own thing thus dividing the total potential resources that could be focused on making it better.
The first major issue I had with my phone was typing. The keyboard and touchscreen that comes with the Droid X responded poorly to my input. I find the auto-correction to be much less accurate than what I became accustom to with the iPhone and found my ability to type simple emails and text messages tedious and slow. I have been really disappointed by this as it seems we had made large strides in the phone world with tiny thumb keyboards becoming increasingly accurate and predicting what we intended to type and automatically correcting any fat finger mistakes we may make without us taking pause or correcting words ourselves. I have learned to be slower on keys such as the “space bar” and reach further out to hit the letter more directly, but I shouldn’t have to make these adjustments. Regardless, I still can’t type as fast as I could on an iPhone.
Browser double tap and zoom – When you double tap on a content area within a web page from the browser, the zoom often crops the text in a such a way that you have to scroll left and right and misses the mark. The Safari browser elegantly determines the content area you’re trying to focus in on and accurately zooms in without trying to reformat it.
Notification count on app – The notifications window is a neat idea to be able to see everything and not have everything distract you with a pop-up as it does on the iPhone, but the implementation misses two critical features. The first is that I need to be able to see the notification and choose to not make it go away. For example, if I accidently touch the item it clears that notification, even if I haven’t read the SMS. Second, nothing on the application icon itself tells me that there is something needing my attention.
SMS app still alerts me when I’m in it? That’s just silly.
How did we go backward in basic PDA Functions? – The calendar application is missing the description field so if I click into an entry to know what the agenda is prior to walking into the meeting, I don’t’ have access. (Calendar missing description http://www.youtube.com/watch?v=eeTdJSzdVfQ). Task managed in Microsoft Outlook are not sync’d.
Flick scrolling selection wheels –I’m sure this is one of those items that is simply missed as Apple has the patent, but it’s really annoying that I can’t just flick the hours forward or backward in the clock application to change my alarm. This simple slot machine type interface is so much easier than pushing a “+” or “-“ button.
Passcode unlock – Why do I have to click the check mark?
Using the physical key to get into application menu’s feels wrong (Droid X specific)
Favorites in Phone (Contacts) can’t be sorted?
Whoa battery life – Everyone gives the iPhone a hard time for not having “multi-tasking”, but other than listening to Pandora (now possible with iOS 4.0 API’s) I’d challenge anyone to show me that they can get in and out of things faster on a Droid. All I seem to get is applications that stay open and drain my batter. Yes, I realize I can get the Kill Apps app, but this should be more elegantly handled by the operating system (hear Fryo solves).
iTunes integration – My life is in iTunes and iPhoto. Not being able to connect to these easily is very annoying (I blame you apple). So, I will eventually switch my photo album to Adobe’s Lightroom, which gives much better control of where the photos are kept as well as more capability, but I still haven’t figured out what to do with my music.
Lack of apps – The first night I sat back on my couch with both my iPhone and new Droid X, the first thing I did was referenced my iPhone and opened the Android Marketplace to add all my apps…most were not there.
Android Marketplace needs sub-categories
What I like
The browser doesn’t refresh constantly when I return to it or hit the back button.
Snooze is great on calendar notifications, but I should be able to set the snooze time
Calendar widget is great at a glance
Calendar allows me to decline a meeting later that I already accepted and send a note with it (iPhone just sent the decline without allowing me to add a message)
Overall it feels like an immature operating system that is being pushed out haphazardly and has had very little attention to the customer experience. That said, it’s young and has a lot of supporters so probably by the time this gets posted to my blog, much of my complaints will be solved. More importantly it’s an open platform that can be expanded on much more than the iPhone so I expect great things. Oh, and it’s nice to be able to watch hulu.com.
Most online transactions finish with an automatically generated email summarizing what you just did. This can be as simple as a note letting you know you changed your password, which in turn also would alert someone that didn’t that someone else did, and it can be as complex as summarizing a large product purchase that details when a service may be provisioned and or products shipped (e.g., a cell phone). If you get this right, you have a happy customer that just did business with you in the most profitable way we’ve found to date. If you get it wrong, you erode your margins from customer service requests and most often take a hit to your brand from bad publicity due to your frustrated customer sharing their troubles via Twitter, Facebook, Yelp and the like. Now, your seemingly great direct channel business becomes a nightmare.
How do we minimize the negative publicity, maximize our margins and potentially even create some free marketing from happy evangelizing customers?
Think end-to-end and have cross-department teams define, craft and implement everything together. This includes everyone from the user experience designer to the folks in finance.
Recently I purchased a couple of complex product/service combos online. Having just moved, I ordered cable from Comcast for my new apartment. Additionally, to have a phone that could make calls and see the full web, I switched to an Android phone from Verizon Wireless. In both of these cases I had a pretty good online experience and a fulfillment process that worked out reasonably well. Though, had I been a different kind of customer, I can see where there are some friction points in each company’s end-to-end eCommerce processes that could create trouble for them.
Comcast.com starts off seemingly organized. The main navigation provides for quick access to specific content around the primary categories of interest for either a prospective customer or returning customer: Learn, Shop, Programming, Customers, About. Everything else around this navigation is trying to sell you, which is what it should be doing. It’s trying to get me to convert to their service by enticing me with insight into all the great programming they have and incredible deals that are presented in such a way that not only provide the traditional call to action, but also create a sense of urgency. The rub is when I go into the next level of detail.
“Learn” does its job by providing me basic details on what they’re offering, so I’ll skip over it and speak to “Programming” for a moment as that was my next place to investigate as a prospective customer. Having experienced AT&T’s U-Verse for a year, I became accustom to having every television channel known to man. Having also decided that I wanted to spend less on TV in the new apartment, I wanted to dive into the programming packages to see which ones on the cheaper side still included specific channels that both me and my fiancée watched regularly. Armed with knowing what channels I wanted to make sure I had, I clicked “Programming” then “Channel Lineup”. Now, I understand that this might change depending on my region, and that Comcast wants to begin capturing insight about me as a customer, but I do get annoyed having to provide my address so early on. Following this was where I about lost it. The list that is displayed, with a drop down filter menu, was unmanageable and terrible at allowing me to compare different packages to see what channels I would get. I had to open multiple windows and Alt-Tab back and forth to see what was in each and then keep track of the specific channels I was looking for on a notepad. This small trivial issue is where not getting it right opens you up to the publicity/marketing challenges. During this visit a customer may tweet about this sloppy experience or tell their friends on Facebook how difficult it is, at which point someone may respond directing them to explore the competitor. If this happens, then that one day where everyone (employees responsible for the site) was in a meeting and gave no attention to this page or just assigned it out to someone to build without thinking of the user flow, the revenue already began to erode.
Once I decided I was going with Comcast and what package I would order, I switched to the “Shop” menu and dived into the bundles knowing that I wanted Internet as well as TV service. This was a clean experience that gave a good summary of each “package”. The missing elements were being able to compare packages and find other critical details such as whether HD was included or if I would get a DVR. Not finding this information (again a spot for a marketing issue), I decided to start the buying process making the assumption that it would come eventually. At this point, the whole process fell apart. Not only was it unclear whether or not I needed to add these extra items, but I ultimately had to start a chat session to complete the transaction. No, really, my “eCommerce” experience was finished with a person. The real irony was that when I was having trouble getting my questions answered and getting through some network issues, I tried calling in and the call center person I talked to said they couldn’t help me with online orders, and if I ordered from them they wouldn’t be able to offer me the same discounts. Really?! Ok, so now I’m forced into an online purchase process that interacts with a human (higher cost) and I’m only allowed to chat with them?! This was where I almost decided to go with DirecTV (if they had a better Internet offering I would have).
After it was all said and done, I had a technician installation scheduled with a set-top box on order and service provisioning kicked off. Great, now I can setup my online bill pay and be done with it, right? I go to email…nothing. There aren’t any emails summarizing what I did (think $$$ if I call back in for help), and it took me almost an hour to navigate around the site and figure out how to get to my account details, learn what my login was (took me calling customer service) and setup my bill pay. It was a terrible finish. Oh, but they probably covered the costs of this experience by charging me that technician install rate and a start-up fee. And cable companies wonder why we give them a hard time.
Verizon wireless, as with any telephone company selling online, has a complex eCommerce challenge as they not only have to try and explain their overly confusing service plans they invent to try and increase ARPU, but also have to get you to pick a phone and then provision a number of systems in their back-end to allow that phone to have the right phone number, be able to make calls, receive voice mail, SMS, access the internet, etc. It’s not easy. That said, you’d think they’d be the experts on end-to-end process thinking as they have so much to get right. For the most part, they did pretty well. Verizon’s site explains their plans well, allows you to compare service plans and phones and ultimately add things to your cart in such a way that you are really clear on what you’re buying and what you may be missing [they do a great job of showing you all the little add-on features (think up-sell)]. The piece they missed? Well, for one they didn’t summarize my order in the email or give a link back to the store to see the details, but best of all they didn’t think through the shipping delay for my new Android phone and had a pretty empty status of, “Your order has been processed and will be shipped based on inventory availability and shipping method. You will receive shipment notification and tracking details via email.” The other missing piece was lack of instruction on how to create my online account. It was fairly easy to figure it out online, but having that be part of the order summary (or better yet, in the order flow), would have made it easier and Verizon would likely increase the percentage of customers that a.) setup automatic bill-pay and b.) become more of a self-serve customer.
Most eCommerce sites focus on the conversion and order check-out process. Only the best consider the end-to-end customer experience. So, get the process flow diagrams going or pin up the butcher paper and map out your customer processes!
Almost two years ago now, I joined a small enterprise software company that has a product for the Property & Casualty Insurance market that supports selling, administering, billing and supporting insurance products such as automobile, homeowners, and commercial liability. This software system, as with many, requires setup and customization to enable it to support each individual insurance companies products and operating model, for example where they might use captive versus independent agents, or centralized billing and claims departments versus field or branch offices supporting customers. Ultimately, each new customer requires an implementation team to setup the system to support their business lifecycle from sales (agents) to billing to customer service when an insured reports a claim. When I joined, I inherited a number of challenges affecting the professional services organizations ability to understand what work was in flight, it’s progress, and whether or not it was even approved work whereby its costs could be recovered from the customer. There were monthly write-offs due to confusion between project teams and customers paying the bills and a dedicated resource responsible for running around and asking folks what they were working on. Having come from a fairly well organized consulting company that had explicitly defined processes around contract management, staffing, billing, etc., I knew that I needed to put in all the basics.
A few years prior I had led a software selection project for a large company that wanted to take advantage of an enterprise project management tool. During this project I became aware of many offerings on the market and had seen the idea of “Professional Services Automation” begin to be championed by several vendors. This lead me to dream big as I expected there would be great solutions to how I wanted to run this business. Services Resource Planning (SRP) really is about supporting the end-to-end business process. Fortunately, I was able to step back and think about how to put the pieces together. Specifically, at ISCS, I have new customers that need a project team to setup our product for them and have existing customers with ongoing service requests and product issues. Ultimately, I needed real-time visibility into all of this work, but more specifically need to be able to answer these questions:
What new service opportunities exist (i.e., projects)?
What issues are my customers having?
What are people working on?
Are they working on the right things?
Are we billing for their work? How much?
Did we bill for the work?
What are the margins of my projects?
What are the margins of my maintenance agreements?
What are my margins by customer, by the whole department?
With answers to these questions I can then make decisions on staffing, training, recruiting, and goodwill.
More importantly, with this level of insight and transparency, I can better manage internal and customer expectations and plan for a more probable future rather than executive intuition.
It was also very important to me that both our customers and employees could see all of the cogs in the wheel and where things are at in the assembly line.
To support this vision I needed a multitude of capabilities that if not yet found in one system, needed to integrate with others to provide end-to-end business process support. In a smaller company with staff focused on customers, I didn’t want to have a large IT investment in either software, hardware or administration. Similar to how my company enables our customers to run our system in the cloud with my team working in the background to make sure everything works behind the scenes, I wanted tools that were also managed by someone else so that I could focus on running my business rather than keeping operational applications running. I choose OpenAir as the heart of my Professional Services Automation vision and Salesforce Sales and Service Clouds to enable a SRP style operating model, and we already had QuickBooks, which is used by most small businesses. OpenAir supported my SRP vision Day 1 with pre-built connectors to Salesforce.com and QuickBooks. Beyond just opportunity management, project delivery, and financials, I also wanted human capital management, as Mike defined it, supported as well to give me a complete picture of the Services Supply Chain. Having capabilities such as resource booking, skill tracking, availability are key components to streamlining and creating an efficient process for allocating the right resources at the right time to deliver customer value.
Specifically, the tools needed to support project work and customer support, both with unique yet similar operating processes. Let me begin by walking through how I’ve leveraged these tools to meet my vision in supporting project work.
Every project begins as an Opportunity, creating visibility into current and future demand just like a factory manager would have to plan for the manufacturing of its widgets. Managing services opportunities in the same sales system as our product sales, all of us on the management team have greater visibility into all potential revenue without waiting for financial reports that are after the fact. Sold and lost project opportunities are tracked not only by title and forecasted revenue, the focus of most CRM tools, but also by resource costs whether it be time or expenses as each become a Project in OpenAir. The Project is the heart of the operation. All resources track time to a project, whether it be internal facing or customer facing inclusive of expenses.
If the project opportunity is lost, then business development costs are captured to reflect true profitability. If the project opportunity is won, then the project kicks off! The great thing about OpenAir is its ability to marry actual work efforts, captured in individual timesheets, to the original plan. The really exciting capability we use is something I call “Democratized Estimates”. As resources keep track of time spent on a task, they are also asked to provide feedback as to how much effort they believe is remaining on that task. This is then aggregated and gives a more accurate picture of how a project is progressing. Both our employees and our customers have access to this information. I also use OpenAir’s resource bookings module to match up active and potential projects with current staff to allow me to better plan for when I need to increase capacity whether it be by recruiting more FTE’s or leveraging partner resources to deliver the work. And of course all this service needs to be billed and fees collected from our customer. Again, the project is the heart. Opportunities have a corresponding contract that defines the fees and planned effort. We capture this data in the Salesforce Opportunity record as I have illustrated. This data is then passed to the project, which tracks it as budget in dollars and hours, two existing OpenAir fields. Following the billing rules defined by the contract or Statement of Work, OpenAir’s billing function then processes time spent and its associated fee rules (e.g., rate card based, task based, or fixed fee) to calculate the billing amount, which maps to the invoice. These charges are gathered and processed monthly, rolled up and packaged into an Invoice that is passed along to QuickBooks, our financial accounting system of record along with expenses reported. Customers now have a complete view from what was expected per the original contract to what is invoiced, which provide task level detail and charges that map directly to the project plan. This provides exceptional visibility into the profitability of project work, but for those of us that are responsible for additional support activities, that may be managed in a traditional case management system, one needs data from the cost of that effort as well to see true profitability across a customer on the whole services operation.
Our customer support team uses Salesforce.com’s Service Cloud to track and manage customer issues along with small service requests. These cases are visible to our customers through an online customer portal and are managed by the same lifecycle of project work. Each maintenance agreement sold with our product is expected to provide budget for continued support to our customers following a successful implementation of our product AND of course this revenue drives R&D, sales and marketing, and of course provide profits. The main question is, “are we charging enough for these maintenance contracts to enable further product innovation, allow us to grow the business AND support the customer?” Or alternatively, “Are we charging too much?”
To answer these questions requires time and expense accounting to support each customer. We begin again with an Opportunity in Salesforce representing a year of the contract, which then gets a corresponding project in OpenAir, which creates a container for us to track our time against. Cases are pushed into OpenAir as tasks within the “maintenance” project to allow for this accounting. This approach also allows us to combine billable work requests as they come accross as cases with a type that is recognized by OpenAir’s billing rules as something that needs to be charged for. You may be wondering why we’d break up the maintenance contract as separate opportunities given they’re typically a multi-year deal. Well, we found that if we were going to keep adding cases as tasks within that project that over time it would become too unmanageable, so we decided to close it out at the end of the year and create a new one representing the subsequent years value. Having costs tracked against cases and rolled up against the project, which contains the budget allocation from the maintenance agreement, we can then produce management reports illustrating the profitability of each contract. This data is not only available to us in OpenAir’s reporting, but is also pushed back to some extent into Salesforce so that we can leverage it’s powerful Analytics capabilities and aggregate with forecasted sales data. As with project work, any charges and time spent on support cases can be pushed into the invoice for increased transparency showing some work with $0 and other effort having charges, which will have the Case ID allowing the customer to review back in the customer portal. Hopefully, my team made sure to get the customers approval before doing the work, something I haven’t figured out how to automate yet.
We had all of this live in a couple of months and immediately received feedback from customers that they felt more comfortable with what we were working on even though our billings went up on account of better tracking of billable work. From their perspective they had better insight on the status of their requests and in real-time, everyone knew who was working on what, and we nearly eliminated the monthly dance of explaining the invoice and negotiating write-offs. The new operating model and tools have enabled us to reduce overhead on project staffing, project setup and the billing process. But most importantly, leveraging the decision sciences of ERP we are able to make more insightful business decisions on real operational data.