Last year, I’ve watched the talk Fred Wilson gave at the annual Future of Web Apps Miami conference in February 2010.  I’ve stumbled upon it today and treated myself with another watch. This is so inspiring to me that I thought I would share it here. If you have 30 minutes during the day, treat yourself with a really great piece!

The full transcript is available here but here is the gist of it:

• Speed – Speed is the most important feature. If your application is slow, people won’t use it.
• Instant Utility – The application should be instantly useful to its user, not after lengthy configuration.
• Software is Media – Your application should have a personality and a voice people can connect to.
• Less is more – Do one thing really well when you launch. Then you can grow.
• Make it Programmable – Others should be able to build, connect or add value to your application. Think read/write API’s.
• Make it Personal – Users and programmers should be able to personalize their application.
• RESTful – Everything in the application has a URL, and ideally, a very clean and comprehensible URL.
• Discoverabilty – Your application needs to be built from the ground up to be discovered and optimized for social media and search.
• Clean – Make your application visually simple. Embrace the KISS principle to your design.
• Playful – You can turn anything in your application into a game. Anything.

Here is the video

The 10 Golden Principles of Successful Web Apps from Carsonified on Vimeo.

Here are the associated slides

Related posts:

1. What apps are in every developer toolkit?
2. Google outage: A broken cloud !
3. Musings on the Future of Data and Predictive Analytics
4. Innovation at Google
5. Grand Central Dispatch – Future of thread programming?

I’ve just finished watching Patrick Colepand QCon Keynote about innovation and thought I would share it with everyone interested by innovation. In 40 minutes you will learn about the first three principles of the eXtreme innovation approach based on the Pretotyping Manifesto: Innovators Beat Ideas, Pretotypes Beat Productypes, and Data Beats Opinion. Excellent keynote with some great and practical ideas! As always Patrick delivers!

The keynote video and slides can be found here.

AND this post gives me the opportunity to show you my last low-tech gadget: The Boogie Board. Can’t surf with it but it can grab some thoughts I might have during the day Nah, it’s not an iPad. Heck, I can’t even connect this thing to my Mac! And this is why it is so special And my kids can borrow it … Sometime.

Related posts:

1. A week in the Cloud ! EuroCloud + Innovation Cloud Summit. Let’s meet !
2. Is Google Page Speed Service a threat to the Internet neutrality?
3. Google outage: A broken cloud !
4. Google launches an open source programming language
5. Google Page Speed Service – The death of the Web Performance Optimization consultant?

I’ve always wanted to write a post about an important aspect of performance testing: Budgeting your hardware environment for Performance Testing. While managing a QA organization at Experian, it’s been one of the least enjoyable part of my job. Managing and growing people, sure ! Anytime ! Managing a large hardware environment? mmm .. Not so much. But it’s necessary to build it and manage it seriously if you want to run proper performance testing. The fact that I had to manage a large hardware budget during an economic downturn was actually a good thing as I had to be creative to find alternative and I became pretty damn good at rolling on the floor to get what I need from our finance guy …

There are multiple problems you face when you handle a large hardware lab dedicated to performance testing:

• It’s godamn expensive! – I should work in the hardware business. amazing margins ! Lock-in ! 3 years and you can throw it away. Damn …
• You NEVER know how much you need – You never know what type of customers your going to have to test for next. You have pretty good results with one set of hardware and then you have a large financial institution asking your performance results on the latest and greatest IBM Box. They don’t want to buy your software (nor the hardware) before knowing what to expect. Extrapolation of results? BLACK MAGIC at best. You end up in very uncomfortable situation …
• You NEVER have enough – If your QA organization start doing performance testing, and doing a good job at it, you will never have enough hardware. Maybe the thing is to never start (and unfortunately a lot of organization decide not to invest in performance testing). You start doing performance testing for one product, two … Doing a good job, need more hardware … Budget cycle come. It’s tight … You need to prioritize amongst all the products you’re responsible for. Sales and marketing scream at you because they don’t get numbers or figures they need for pre-sales. People above you shift the strategy (with good reasons) and you have to re-prioritize all your efforts, capacity … In any case, you NEVER have enough hardware to cover everything you want to cover. It’s an interesting excerise to be able to predict, plan … And can get frustrating because you want to do so much more.
• It’s NEVER utilized 100% -A box dedicated to performance testing is never utilized 100%. NEVER. Especially the largest one. So you think you’re smart and you’re going to put in place a server planning process where you can use spare cycle for something else. Functional testing for example ! Not a bad idea all together but can lead to major nightmares especially if you’re using this box for hard commitment. My recommendation is to never plan these box as part of resources available for testing (functionally) the critical path of a major software release. NEVER.
• Everyone outside your organization want to use your environment - You’ve done a good job building a reasonable environment, getting some good results out of it, good feedback from customers … You can be sure that some organization with the same kind of need would want to use it at some point. You’re nice, we’re all a big family ! Sure why not ! Go ahead ! We have our server planning process, you can use it during spare cycle. Ooopss … they end up using it for a major delivery, for a customer you can’t say no to, hard commitment etc. You’re stuck. There is a customer down the line and there is nothing you can do … So you start playing tough. People throw rocks at you Seriously, my recommendation is to help other organization to get ready for the unexpected, sit with them to understand their need and show them their option. If you’ve been there, done a good job, share your knowledge to help. “Give a man a fish and you have fed him for today. Teach a man to fish and you have fed him for a lifetime” (an alternative: “Give a man a fish and you have fed him for today. Teach a man to fish and you can sell him fishing equipment” )

Cloud Computing change the game of course as you don’t need to know how much you need as you can have all you need (theoretically), you can bring it up and down as needed, it’s wayyyyy cheaper and other organization can quickly create their own environment. Perfect world !! But … What do you do with your existing hardware? After all, it’s pretty powerful, would be good to be able to use it as part of your new environment as added power to simulate virtual users, deploy your tests …

Guess what ??

YOU CAN !!

<shameless plug>
You’ve got “bare metal”? Private clouds? (vCloud? Eucalyptus?) Using EC2? Azure? IBM Cloud? SHAKE IT REALLY WELL !! You’ve got a seamless Performance Testing platform !! Well, you’ve got it if you’re using our latest product SOASTA CloudTest PRO !! It brings you the WORLD’s LARGEST TEST PLATFORM ! Cherry on the cake, it integrate with uTest community of 34,000 testers !! Now, that’s what I call innovation !!!
</shameless plug>

Building and managing a hardware environment dedicated to performance testing is critical and might not be fun everyday. But in 2011, you actually have plenty of new options to help you in your task and make the whole process a bit more enjoyable !

Related posts:

1. Performance Testing – When will they learn?
2. Hot Software and Performance Testing Links – Week of March 28th
3. Hot Software and Performance Testing Links – Week of April 4th
4. Hot Software and Performance Testing Links – Week of April 11th
5. Hot Software and Performance Testing Links – Week of April 18th

Every now and then there are discussion about the future of Software Testing. Lately I’ve seen a post from Lanette Cream (The future of testing is wide open) and Jeff Goldsmith from SauceLabs (The Future of Testing). Trends are around Agile Testing, Automation, Continuous testing, Crowd Testing and last but not least: Cloud Testing. It matches the results of the poll I’ve created a while back. If you’re passionate about Software Testing, you’re following all these trends and probably implement some of the new innovation within your team. I know I did while building my organization at Experian Decision Analytics:

• We’ve invested in Selenium to run our functional and some performance testing for customers.
• Built various homegrown framework to run continuous automated testing.
• Start using Amazon EC2 to run scalability testing for some of our web application.
• Adapt our testing process to accommodate for SCRUM.

These initiatives made a huge difference in the quality of our products and I think changed the way QA was perceived within the broader Experian Organization. Best of all, I really think it made a difference for the people working for me who had an opportunity to work with the latest innovation in their field. I’ve always tried to keep people excited about their job and Software Testing in general and one way to do it is open up their horizon and make sure they have ample opportunity to make a difference. This said, influencing Software Testing within an organization is one thing. Influencing the whole industry is a complete different ball game. If the company you work for is not a pure player, it might be a bit tough, frustrating and much slower than what you’d want, especially if you’re very passionate and want to make a real difference! I’m one of these people who wants to make a difference during their career. Not only to the company I’m working for but also to the broader industry.
That’s reason number #1 I’m joining SOASTA: To have an opportunity to revolutionize Software Testing (or at least part of it ! )

During my various interaction with customers while working at IBM and Experian, I’ve always been struck by the challenges encountered by Performance Engineering team:

• Challenge to reproduce like-to-like customer scenario.
• Challenge to simulate realistic and flexible loads at a reasonable cost.
• Challenge to deploy and maintain a load grid/lab.
• Challenge to generate a geographically spread load.
• And for me the biggest challenge of all: How in hell can I make sense of all the data received during tests (we’re talking Terabytes of performance data received from all application and hardware layers !) and provide valuable aggregated information allowing me to take actions. Oh and by the way, I’d like these information to be available in real-time during production performance test. Yup, real-time analytic on a live environment! Testing in a lab, while important for extracting some type of results, cannot answer questions about production performance or capacity with a high degree of accuracy and confidence.

All these challenges come from the following observation: The most common test tool in use today for web application testing was never designed to tackle these type of challenges. You have a tool today used by thousand of customers which is, from technology to licensing, completely inapt to answer requirement for web sites with a significant presence. Yes, I’m talking about LoadRunner of course. It makes customers believe that testing with a few thousand users is good enough in today’s world. It makes customer believe that analyzing production performance data, 20 minutes after the test is good enough. It makes customers believe that we’re still in a world of expensive Enterprise License Agreements when the reality is Software-as-a-Service and On-Demand. LoadRunner was relevant 15 years ago, it’s not anymore. As discussed in a previous post, I was forced to splurge a significant amount of money to get my organization some LoadRunner licenses for the sole reason to be credible in front of our customers. That’s all they know today and if you’re not using LoadRunner, you don’t do Performance Testing. Period. It made me sick frankly. LoadRunner is not a bad tool all together but it doesn’t meet the challenges of increasing complexity and can’t scale up to the real-world traffic levels applications are seeing and it’s definitely not cost effective !
That’s reason number #2 I’m joining SOASTA: To have an opportunity to offer to all customers in the world a real alternative to Loadrunner. I want to help them get the most out of their web applications which is sometime their only source of revenue. I want to help them provide their customers the best online user experience. I want to provide them confidence about their online operation. And when they come up with a critical online offer, I want them to avoid the AT&T syndrome !

I’ve been working within Engineering teams all my career and I think I have a reasonable understanding on how to build good software But building the software is only one part of the whole Software Business. There is a large side of that business that I’d never been directly involved in: Marketing, Sales, Market Research, developing channels, finding resellers, building partnership with ISV, building a brand, intelligence gathering on competition, generate leads, handling customer account etc. If one day I want to run a business (either mine or someone’s else) I better start getting myself involved in these activities! Do I have the required experience? Hell no! But you’ve got to start somewhere. And as Steve Blank said “Nothing I couldn’t fix. I took the job!”. I believe I make up my lack of experience by enough business acumen, domain expertise and a whole lot of passion! And a real will to help customers with what I think is the best for them.
That’s reason number #3 I’m joining SOASTA in a Business Development role: Broaden my experience and prepare myself to run a business during the next cycle of my career.

Last but not the least. The Startup part. I’ve started my professional career in the US in 1998. Right in the middle of the Internet bubble. Startup were everywhere and something struck me the most: Constant innovation and business agility like never before! I was working for IBM at the time and frankly I was a bit jealous. I was learning quite a bit and will never regret that time! It brought me a very solid foundation in engineering and management. But I’ve always been intrigued by startups: How can so few people build such innovative products/services? How can they adapt so quickly to a very dynamic economic environment? When you work for a large company for a while, at some point you wish it could go faster. You’re looking for snap decision, agility at all level of the organization, dynamic budgeting, making daily impact instead of spending a long time influencing a slow moving organization, bottom-up approach where nothing happen unless you make it happen (versus demand-driven initiatives). Working in large company can become very comfortable and you always have to challenge yourself to get yourself outside of your comfort zone. Working in a startup always put yourself outside of this comfort zone because you have to do so much, so fast, sometime outside of your domain of expertise (large company provides very comfortable silos). At this stage of my career, this is what I’m looking for!
That’s reason number #4 I’m joining SOASTA: To work in a very dynamic environment, get out daily out of my comfort zone to experience things I’ve never done before !

Last week, I’ve joined SOASTA as Vice President Business Development Europe for all the above reasons. They’re game changers, a growing startup, they have a strong customer base and best of all, they’ve realized that LoadRunner is no longer relevant! I’m returning from a trip at SOASTA HQ in Mountain View where I had a hell of a time with a FANTASTIC team! I’m going to have the time of my life !

I will of course continue to maintain this blog! Maybe broadening the topics, maybe not What do you think?

Related posts:

1. Software Testing Revolution with SOASTA CloudTest Lite
2. Future UIs will bring challenges to Software Testing!
3. Building high performing Software Testing team – 90 days plan (part 1)
4. Thanks to Game Changers, Software Testing is flying high !
5. SOASTA is hiring the BEST performance engineers in Europe

I’ve started my career as a typical Software Engineer, messing up with C++ and Java code on B2B software (good time !). During that same time, I had the opportunity to see Lou Gerstner on stage as he was visiting our IBM campus. It was right in the middle of the e-Business period and Lou was here to explain us what e-Business was about and what it meant for us. It was one hour which changed my life. I was so impressed by the message, the clarity, the energy, the motivation. I knew from that point on that this was something I wanted to do: Being able to have this type of impact on people. being able to share a vision, drive a business, etc. I guess I would have had the same conclusion if I had the opportunity to see Jack Welsh on a stage. He’s also one of my role model.

Setting a target is the easy part, hitting it requires a bit more work ! Especially when you’re a software engineer and you want to become someone like Gerstner. There is not one way to reach this type of objectives and I could have chosen a lot of different way. I was in IBM, looked like it was a good opportunity to learn and experience management so I stuck with it.

I had my first management role about 10 years ago. And boy didn’t I know anything at that time! Between the project pressure and the learning process, I was a bit overwhelmed. I hadn’t received formal training yet and at that time and was looking for some clues. I was fortunate enough to have my manager close by (pretty much next door) and who was very hands-on on the day to day activities of his team. I thought that if that guy was at that position, he was probably doing something right (If you’re fortunate enough, that’s usually the case). So I started observing him, picking up what I thought was good practices, tried to understand the impact he had with some of the behaviors he was demonstrating. The overall team was fairly successful, so he became a good first model. Stepping back, there is one thing he taught me which stands up from the rest: learn as early as possible to manage the emotional bank accounts you have with people you work with.

The term was coined by Stephen Covey while he was giving course on organizational behavior. He also wrote about it in his acclaimed best seller, The seven habits of highly effective people, In a nutshell, Covey tells us that we’re keeping an emotional bank account with everyone we have a relationship with. It is true for the one you love, your spouse, children, family, your friends but also your co-workers and your employees. In a sense, this account represent the level of trust and confidence we have with people.

Any account we have with people will start at a neutral level. As we make deposits in this account, the level of trust and confidence go higher, the relationship grows. If we start making withdrawal from the account, the relationship and the trust suffer. The goal is to have a positive account with people at all time, deposit often so that the relationship will have a greater tolerance to mistakes we might make.

Covey describes 6 major ways of making deposit into all your emotional bank accounts you have with people.

Understand the individual

With employees or co-workers, you need to be able to listen in order to understand what’s important to them, their aspiration, what make them happy. Being able to listen is a very good way to make large deposit in their emotional bank account. Listening is not as easy as it sounds! You need to put yourself in their shoes, understand their thought process, empathize. Remove yourself from the picture. It’s all about them.Listening to people is a good way to understand them. Being there, visible and observing is also another way. I encourage you during the day to walk around the office to observe, touch base with people, try to get the temperature, encourage, make small personal connection, laugh ! It shows people that you’re here and that you care.

Keep commitments

Breaking a promise is one of the largest withdrawal you can make so you better do what you promise to people. You basically need to walk the talk so that everything that comes out from your mouth means something to people.

Clarify expectations

If you want to avoid major withdrawal from people emotional bank account, you want to make sure that expectations are clear. You need to invest time and effort to make sure roles and goals are clear. Some people needs general direction. Some needs greater detail. But in any case, you need to make sure people understand what you expect from them.

Remember the little attention

In a way, this is an area where you can make the largest deposit over time but it is the most forgotten. Smiling, thanking people, small encouragement, kind words etc. These are all small things we should all do as individual. It shows that we care, that we’re aware of others. All these deposits are small but numerous. You can really load an account with these. Think about it as the long tail of emotional bank accounts ! (I’m currently reading the Long Tail … ! )

Show personal integrity

You could do perfectly all the previous points, if you don’t demonstrate integrity your accounts are doomed. Since they represent trust and the strength of a relationship, if you lack integrity your balance will become overdrawn. Don’t talk behind people, don’t criticizes or complain (be constructive), don’t be rude or aggressive, don’t use people mistakes as weapon, don’t hold grudges, don’t take offense too quickly, forgive, be loyal etc. Be whole and complete and people will trust and respect you.

Apologize with sincerity

Being a good person every day is difficult. We make mistakes. Sometime we’re going to offend someone, break a  promise, forget to thank someone, we’re going to be angry, not clear enough etc. We’re human, we screw up, and it’s ok as long as we’re able to recognize our mistakes and apology. Sometime, an apology completely offset a withdrawal and makes it a deposit in an account !

All these concepts are kind of obvious when managing a relationship but applying them requires awareness and effort. Integrating them into your management best practices is definitely a good investment !

Related posts:

1. Performance Testing – When will they learn?
2. Avoid bankruptcy ! Manage your technical debt.
3. Design and usability – A lot to learn from the best
4. A good way to learn sorting algorithms!
5. Jack Welch: Straight from the Gut

Damn ! I just realized that my latest article is almost 1 month old ! This is unacceptable for my trusted readers and as I spend a night in London I decided to share one of my latest read. I did read during the past months but for once, I indulged myself with some great science-fiction books I had in my stack: The forever war from Joe Hadelman (always trust a classic. This is an awesome read !), the Ophiuchi Hotline from John Varley and The Currents of Space from the man himself, Isaac Asimov (I’m a huge fan …).

But I finally took some time 2 days ago to pick up my copy of “Behind the Cloud: The untold story of how salesforce.com went from idea to billion-dollar company and revoluzioned and infustry” from Marc Benioff, Salesforce.com CEO, and I actually couldn’t stop reading it ! I’ve just finished it on the plane to London and I have to say that I had a blast !

I’ve always been interested about Salesforce.com as I was reading a lot of articles about the agile transformation they made some years ago. As my organization is going throught such transformation I always been impressed and inspired by what they did. By picking up this book, I wanted to understand the bigger picture and how Marc Benioff pulled it off 10 years ago. He was the first one to have this vision around Saas and then Paas. With the strong emergence of cloud computing the past few years, I wanted to understand why this guy got it right way ahead of everybody else.

The story is a bit different from the Google and Facebook story. Marc was already a successful executive at Oracle when he built the company. He seeded the company with $6 millions which he had saved from working at Oracle and various successful technology investment he made. That’s pretty impressive if you ask me and it does help implement a great idea in the first place. The actual great idea is actually priceless.

The book is divided into playbooks and gave me some great insights into the whole process. I’m not at this stage into a startup mode (I’m working for Experian Decision Analytics, part of the Experian group, a 15k+ people company. Not what I would call a startup!) but there are some really nice ideas which can be applied to the corporate world. I’m a strong believer that it doesn’t matter if you work for a large company or a very small one. Entrepreneurship spirit can and should be encouraged in either one of them.

The playbooks are the following

The startup playbook: How to turn a simple idea into a high-growth company

This playbook really apply to startup but can also be applied to new products your company is building. I mean, do the following ring a bell whether you work in a startup or in a large company?

• Have a big dream.
• Work only on what is important.
• Listen to your prospective customers.
• Defy convention.
• Hire the best players you know.
• Take risk.
• Think bigger.

From my perspective, these plays are a given in any size company.

The marketing playbook: How to cut through the noise and pitch the bigger picture
The events playbook: How to use events to build buzz and drive business

I combine both playbooks as they go along very well. I’m not, by far, the marketing specialist. But reading about it is really appealing. When you work in software development, you’re proud about what you design and build. But who really care if you’re not able to market it? To go against your competitor? To tell a great story about what you’ve built? To be innovative to separate yourself from the pack? In these 2 playbooks, there are some great advices for any startup to build up their brand. Some can without a doubt be applied to larger company.

The sales playbook: How to energize your customer into a million-member sales team

This was an interesting part of the book, but nothing really new under the sun. I don’t think Benioff really revolutionized the sales process but applied best practices to engage customers, make them Salesforce’s partners and grow the seeds. I’m not a sales expert but from my perspective what I read was sales by the book.

The technology playbook: How to develop products users love

I consider myself as technology driven so you can bet that I was particularly interested by this chapter. But more than technology, this part is all about innovation and users. It reminds us to  have the courage to pursue innovation, to set a strong (and simple) foundation (can you spell KISS?), to reuse as much as possible (Can you say open-source?), to transcend technical paradigm, and most important of all in my opinion: Harness customers’ ideas.

The corporate philanthropy playbook: How to make your company about more than just the bottom line

This part is perfectly placed within the book and remind us all than a company is more than revenue and profit but also about what it can give back to the community. I was actually astonished by what Salesforce.com, a fairly young company, is able to bring to the community. This is a great example of corporate citizenship.

The global playbook: How to launch your product and introduce your model to new markets

This is one of the best part I would say. It tells you how Salesforce.com was able to scale globally without overspending, to adapt to different market (either through partnership or by replicating what they did in the US), how they’ve handled some IP dispute (especially in Australia) and how not to use a seagull approach (Swooping in, messing up the place, and flying away) but commit yourself fully to your new reach.

The finance playbook: How to raise capital, create a return, and never sell your soul

There are some great concepts Benioff reminds us in this part:

• Everything takes twice as long and cost twice as much as you’d expect.
• “Revenue is vanity; profit is sanity” only apply to well established company. Not startup (duh !)
• Be innovative and edgy in everything you do. Except when it comes to your finance. This is a very interesting part giving some details around the IPO process and why they chose to go to the NYSE vs the NASDAQ (“We need the credibility and the panache of the NYSE brand; it’s traditional, old-line, well established; it’s the antithesis of salesforce.com“)

The leadership playbook: How to create alignment, the key to organizational success

I was very eager to read about this part as this is maybe my top priority in my current position. I’m always open to new idea s !

I have to say that I’m not disappointed with what Bernioff has to share with us as leadership was a key foundation to his success (how else could it be?)

He shares with us what he’s used to formalized his management process. He’s called it V2MOM which stands for Vision, Values, Methods, Obstacles and Measures. This is something he had used to guide every discussion at salesforce.com. From 1999 to today ! As an example, here is what V2MOM looked like back in 1999:

Vision (What do you want?)

• Rapidly create a world-class internet company/site for Sales Force Automation

Values (what’s important about it?)

• World-class Organization
• Time to market
• Functional
• Usability (Amazon quality)
• Value-added partnerships

Methods (how do you get it?)

• Hire the team
• Finalize product specification and technical architecture
• Rapidly develop the product specification to beta and production stages
• Build partnerships with big e-commerce, content, and hosting companies
• build a launch plan
• Develop an exit strategy; IPO/acquisition

Obstacles (what might stand in the way?)

• Developers (I did chuckle with that one )
• Product manager/Business development person

Measures (How will you know when you have it?)

• Prototype is state-of-the-art
• High-quality functional system
• Partnerships are online and integrated
• Salesforce.com is regarded as leader and visionary
• We are all rich

Benioff rewrites and communicate the V2MOM every 6 months.

The rest of the chapter reminds us about some great concepts to implement when building a great leadership team:,

• Build a recruiting culture: Hire a HR manager right away. Hiring is a top priority. That’s true in a startup and in a large company.
• Use aggressive interviews: 360-degree interviews, have your candidate presents so you can check how they perform on the fly, how they handle curve balls.
• Make sure you hire people who fit the culture you’re trying to grow. Typically at Salesforce.com they had trouble hiring people coming from the client-server world.
• Make sure everyone in the company understands the importance of Mahalo: Mahalo is the Hawaiian spirit of gratitude and praise. I can’t emphasize enough the importance of telling someone “Thank You” in any corporation, large or small. I’ve been astonished in my career by some people not understanding the value of such a simple concept. This is particularly important in a tough economy when monetary rewards  are a bit more difficult to give.

“Behind the Cloud: The untold story of how salesforce.com went from idea to billion-dollar company and revoluzioned and infustry” from Marc Benioff is a fantastic read I recommend everyone to read ! Whether you work for a small startup or a very large company !

Related posts:

1. Jack Welch: Straight from the Gut
2. The Art of War – Sun Tzu
3. Founders at Work: Stories of Startups’ Early Days
4. Richard Branson: Losing my virginity
5. A week in the Cloud ! EuroCloud + Innovation Cloud Summit. Let’s meet !

• Drive a 90 days tactical plan.
• Run a deep organizational analysis and provide recommendation.
• Build a strategic plan.

There are 4 key area to focus on during these first 90 days. In this first part, I’ll focus on the learning stage.

Homework before you start your new job
Generally, there is always a gap between the day you sign your hiring contract and your actual first day. You will still be involved with your previous job or responsibility but all information you can gather about your new company will prove a key advantage as you start.

• Ask your new boss or HR about any documentation they might be able to give you about the products (user guide, case studies etc.), about the development process (covering testing of course).
• Get some information about the company itself, revenue figures, key executives, activities (optimally, you should get these information BEFORE you sign the contract, but it might be easier to get additional details after you’ve been hired). Learn the history of the company, how they had grown ie. organically or through acquisition (this is important if you’re responsible for multiple line of products)
• Try to do a self-assessment of your strengths and weaknesses. You’re starting with a clean sheet with this new company but people will judge you very quickly. Think about what went well and what could be improved based on your past experience. Jot down a few initiatives and improvement you can make in your new job. It can be anything from communication improvement, better listening skills, punctuality etc.
• If you feel you have a technical gap, try to fix it. If the product is Java based, try to read as much as possible about the latest and greatest Java test tools, technique. You don’t have to become an expert (would be useful though) but at least be prepared so you can have informed discussion with your new team.
• Try to understand what development process is used in the new company. If you’re not comfortable with the process they’re using (could be waterfall, SCRUM, XP, RUP etc.) document yourself as much as possible. Don’t wait until you start your new job.
• If you’re not familiar about the business domain, document yourself as much as possible. I was personally not the expert in origination, customer management, collection or Fraud. I had no idea about scorecards and credit bureau. It’s not rocket science, but you have to make the effort to get comfortable with how the products are used by your customers and the related specific business jargon.

In summary, try to be as much informed as possible before day 1. A new job can be overwhelming, the more prepared you are, the better.

Product knowledge
This is true for any level of management. Hands-on experience will be more difficult as you’re higher in the hierarchy (and usually responsible for a growing number of products) but you should do everything possible to get a real experience of the product you’re going to care for.
If your product is well documented, you can do a lot yourself. If this is not the case, make sure you try to get as much information without impacting too much people around you.
Try to get a feel about the stability of the product, its usability, strengths and what you would consider weaknesses. If you find bugs (you will) try to report them using the proper process so you can experience it. Take note. Don’t necessarily communicate about your findings and avoid early judgment. Your note will get useful as you talk about the products to other people within the organization.
Before understanding how the product is tested, try to think about how you’d test it and what are the critical paths. From experience, early thoughts are usually the right ones.

Priority
This is one of the most difficult part of the learning curve. You will usually get as many opinion as there are stakeholders and they all have their own perception of the quality of the products and will try to convince you to focus on certain priority. Get information from:

• Development team
  They will usually think the product is the greatest ever but if you start digging a bit you might discover some important shortfall on their end ie. Lack of unit test, manual build process (error prone by essence), no static analysis, no code review, no documented code (hardly maintainable), maybe lack of specific skills etc. A good team will cover these important activities which build quality upfront but discussing with developers (not necessarily the most senior one) will help you paint an objective picture which will give you a sense of the quality of what you’ll be responsible to test. You should also try to understand how they perceive the test team and how well the relationship is going.
• Project managers
  Important to discuss the timings of releases and their history. What’s a major release? A hotfix ? A Service pack ? Try to understand the historical timing ie. How many hotfix a months? Fixed service pack timing? How acurate are the sizings? You want to understand how much your team has on its plate.
• Support managers
  If there is a good support team, you should be able to dig into historical statistics around defects and most importantly their type. Understand the volume of defects (requiring change of code) going out to customer and their type ie. functional problem, usability, performance. Is there a trend? Are there obvious and critical problem which should get fixed right away. How many hot production problem? Try to assess the efficiency of the support team ie. Is support a good shield for development and QA? How much help can you expect from them ?
• Service or delivery
  If your products are customized and delivered by a service team, you can gather quite a bit of important information by talking to delivery people. They’re using your product on a daily basis and should be able to provide useful feedback. They’re in direct contact with customers so they should be able to give you another angle about the perceived quality of the products.
• Product manager
  They own the roadmap and have the best view about business requirement. They can give you a good view about the future of the product and the component which will become increasingly important. They’re usually in direct contact with customers and should be able to give you some good informed feedback.
• Customers
  Hopefully (or not, it’s a double edge sword), you might have access to end users. Depending on the size of your customer base, it might be easy to identify clearly area of focus. If the base is large, it’s a bit more difficult as you can’t talk to each customers and they all will have different problem. Informal discussion with customers will help you identify trend and recurrent type of issue.
• Senior management
  They’ve hired you and will have an opinion about the quality of the product. They might give you advice regarding priorities but most importantly, they expect you to be in charge and present them a strong strategy.
• Sales
  They should be able to give you visibility on revenue figures per products and customers which should help you understand priority from a financial perspective. They should tell you how they think your organization can help them. Not only can your organization help build a product of better quality but there is a lot of information you can provide them to give confidence to the customers (visibility on process, test strategy, performance figures, benchmark etc.)
• Existing testing team
  It’s your team. They should be honest with you and let you know where they feel the team should focus from a product perspective.

Talking to all important organization and stakeholders will help you understand how the quality of the product is perceived, what are the most important component of the product (critical path), relationship between development/QA/Support etc. Additionally, discussion should help you identifying high visibility issues, critical decisions which can’t be postponed, quick win that can be accomplished and gain management support.

Current level of testing and the associated process
That’s the fun part if you passionate about testing (and hopefully you are ! If this is not the case, start to wonder why you’ve accepted this position !). This is where you will be able to take a good look at what you’ve inherited if you start with an existing team in place. Depending on where you stand in the hierarchy, you might be able to experience the process and be involved in the actual testing. It’s the best way to get the most objective view. If you’re responsible for a set of products, make sure you still try to be as close as possible from the actual testing to make your own judgment. Having only discussion brings a large level of subjectivity which could be a derailing factor for your mission.

There are key take-away to get as quickly as possible:

• Current responsibility
  You need to understand quickly the current testing responsibility of your team. If you identify any potential gap, is there another team taking care of it? Responsibility could includes: Functional testing, performance, benchmark, stress, localization, compliance, usability, accessibility, regression, installation, recovery, BVT, security etc. All these type of tests don’t necessarily apply to your product but you need to make sure that you identify any gap which could impact the quality of the software.
• Current test approach
  How is the current software being tested? White Box, Black box, mostly through the UI (if any), API level, mostly ad-hoc, exploratory, keyword-driven, manually, automatically, risk based etc. You need to quickly decide if the current approach is appropriate or if another approach would be more efficient. Again, hands-on experience with the product and the process will help you make a good judgement.
• Current functional coverage
  How much of the software the current approach cover? How deep does it go? Is it mostly at a unit level, component level? Are there any business scenario (end-to-end) being performed? Does the software integrate with other products? Is it being tested? This coverage is sometime a bit difficult as there is a large layer of subjectivity. Code coverage helps to some extent but doesn’t really assess the relevance of your tests.
• Level of automation
  How much of the current testing is automated? How fast is the current test team being able to provide feedback to the development team on any given build? How much does it cost to maintain the automation framework, testcases and relevant data? What’s the ROI?
• Tooling
  Are the current tools used the best one for the job? Automation tools, test case management, performance testing tools etc. What is the approach taken? Commercial, open source, home grown? Why? What is the associated cost? Can the current tools allow you to scale and pick up additional responsibility or scope?
• Testing environment
  Is there a proper environment to perform required testing? Is it scalable? How well is it managed? Are you dependent on other team to maintain it? Is it efficient?
• Data
  Is there a dependency on specific test data? Do you need to generate them? Do we need to get them from customers?
• Information coming out of testing
  What type of reporting is expected from the test team? Who are the stakeholders? What value does this documentation currently provides? How is the information generated? Is it efficient?

Organizational analysis
If you end up with an existing team, this is a critical exercise. If you have the luxury to create a team from scratch, you can refer to the next part of this series (Plan and organize).

I’ve said it before and I say it again: People are key. They should be your priority #1. In the first 90 days, you should be able to:

• Identify if there are any unclear roles and responsibilities leading to a dysfunctional structure. Identify if a clear career path framework is in place.
• Identify high and low performers. Try to get an objective opinion through discussions, observations, past performance records etc.
• Level of relationship with the other organization, especially how well developers and testers get along.
• Understand what drives your people.
• Assess the technical level of your people. Do you have people with development background, IT background, business etc.  Is there a technical gap with developers?
• What is the training situation? Are there any formal training? Development plan for strong and low performer?
• What is level of passion within the organization? Do people breathe testing?
• Understand if there is a lack of QA alignment with business.

During this learning period, there is a lot of listening and observing to do. It’s not so much what you do but how you do it which will be important.

Words of wisdom

• Avoid politics
  This is pretty much true even after your 90 first days but is particularly true at the beginning of your new job. Getting caught in internal politic or turf battles doesn’t bring you anywhere and your initial knowledge won’t allow you to get any win. Stay open. Don’t buddy up with everybody but treats everyone as equals with openness (not intimacy). Don’t align too quickly with certain individuals.
• Be independent
  Your company might give you an orientation to the company and organize something formal for you. Don’t bet on it and design your orientation program yourself. Be visible, try to meet a lot of people, network, socialize to some extent.
• Understand the corporate culture
  The more you understand the corporate culture, the more successful you’ll be. Don’t try to fight it but understand as much as possible to navigate smoothly. How does people communicate? Meeting, email? Who should be invited? Is hierarchy important? What are the office policies toward lunch, hours, time off, telecommuting? If you work in a foreign country, try to understand as much as possible the national culture, what are the do and don’t?
• Be tactful
  Don’t rush to judgment. Try to understand how some area could be improved in the most constructive way. Involved others. Get their opinion.
  
• Find the right work-life balance
  This is true in general but particularly in a new job where you have a lot on your plate and so much energy to do well. Try to balance your life and set the right precedent. If you work 18 hours a day during the first few months in your new job and if you scale down, it could be seen as a decrease of commitment or enthusiasm.

The learning phase in a new job is a critical one. It’s a good one since you learn so much and a lot is new. Doing it in the right way will help you build a strong tactical plan and strategic vision as well as organize your team to match your plan. We’ll see how to achieve this goal in the next part of this series.

Related posts:

1. Building high performing Software Testing team – Part 1 – Organizational climate
2. Thanks to Game Changers, Software Testing is flying high !
3. Jumping into the future of Software Testing – The reasons I’m joining SOASTA
4. Cloud Testing days in London – Join me!
5. Founders at Work: Stories of Startups’ Early Days

The first foundation of any high performing organization is its organizational climate. You can have the best brain in the world, the best technical people, if you don’t provide them with the right climate to operate, you’re doomed. This is true for any organization, not only software testing. It takes on-going effort to setup and maintain the appropriate climate and should be, in my mind, your priority #1. Research has demonstrated that a significant percentage of the variance in measured business results can be accounted for by an organizational climate. Let’s trust the experts

An organization’s climate is a complex mix of norms, values, expectations, policies and procedures. The climate represents employees’ perception of “the way things are done here” — The way it feels to work here  Studies have identified the following 6 dimensions that most impact business results, performance, job satisfaction and propensity to leave:

Clarity
This is the most important dimension in my mind and within a software testing organization there are two important sub-dimension:

Mission and direction
The degree to which people know that there is an overall organizational vision and clear plans to reach it. Whatever your vision is for your software testing organization (and there are not a silver bullet vision. I’ll share mine on another part of this series), it needs to be communicated to your people and to other organizations. You need to provide your team with a vision they can relate to on their daily activities. You also need to provide your plan and initiatives you’ll drive with them to implement this vision. They need to understand that this is not a bubble of air and that you have a plan with clear milestone. They need to be regularly updated on progress. They need to feel their organization is moving in the right direction.

Organization and expectation
The extent to which the organization has an understood structure and job expectations and clear roles. When you’ve setup your vision and plan, people needs to understand how they fit within this vision, what is expected from them at the current level they’re in, what would be their responsibilities to implement the plan. They need to understand that these expectations relate to the larger goal and vision of the organization.

Standards
Your team needs to understand what you expect from them as far as performance. You should be setting challenging but obtainable goals one and measure them regularly. The right level should bring excellence within your organization. Within a software testing team organization, standards should be set not only on what people do ie. Influence quality across the whole development cycle, provide the right level of feedback to other organization, improve turn around of this feedback (hint, hint .. automation ! to be developed on a later part), stay one step ahead of development but also from a behaviorial stand-point ie. Team work, communication, initiative, reaching that extra mile etc.
Your goal as a leader is not only to make sure you set the right level of standards but also encourages and help performance improvement from people.

Responsibility
A climate which is strong on responsibility should empowers people to take initiative, make decisions and get things done without a lot of management scrutiny. Autonomy is key. Additionally, people should be accountable for their decisions, own these decisions and understand the risk. Ownership and risk taking are key.

Flexibility
You should encourage a climate which minimize unnecessary procedures, policies and formalities. These should not interfere with your team work but on the contrary help them with their work. As part of a software testing team, you’re usually part of a larger development organization and there are some rules you don’t have control over. Your goal as a leader is to work with other organization, give them visibility on your own requirement and find an acceptable balance so that policies don’t interfere with your team innovation. Studies shows that unnecessary bureaucracy is responsible for lack of inovation in a lot of large software company. This is tough one to crack.

Rewards
You need to encourage a clear link between performance and reward. It can be financial remuneration, recognition and praise, additional responsibilities. Everyone has different preferences for how we like to be rewarded. These preference needs to be understood so that reward can be given appropriately. Recognition and praise should definitely outweigh threats and criticism.

Team commitment
If you take care about all the previous dimension, you shouldn’t have a problem with that one. Managers might want to build team commitment through team building activities (and they have their place) but the key lies with the previous five factors. Give your organization a clear vision, setup clear standards of excellence, encourage responsibility and ownership, reward and recognize people achievement and you should get 150% of your people.

When the organization’s climate is not what you desire, it it best to work on improving one or two climate dimension at a time. Other things being equal, working on climate dimensions in the the following order may prove most effective: Clarity->Standards->Responsibility->Flexibility->Rewards->Team commitment.

As I said in the introduction, this part on organization climate can be applied to any given organization and is not specific to software testing team. This is really management/leadership 101 but it’s always good to be reminded once in a while about these basic principles. In subsequent part, I will refer back to these dimension and give specific example on what I did to manage these important factors.

Related posts:

1. Building high performing Software Testing team – 90 days plan (part 1)
2. Thanks to Game Changers, Software Testing is flying high !
3. Jumping into the future of Software Testing – The reasons I’m joining SOASTA
4. Behind the cloud is a great read !
5. Learn to manage your emotional bank accounts and build trust

When transitioning your organization to scrum, you need to realize the management and hierarchical implication. A scrum team is not managed but manages itself and that’s the beauty of it. You don’t have development leads, test leads within a scrum team. You have developers and testers all working in the same direction to deliver what they have committed to deliver to their stakeholders. The ScrumMaster is not the manager of this team. He is a facilitator, helping the team focusing on what they do best (hopefully developing great softwares !), helping the team organizes itself, dealing with external issues, giving visibility on progress to stakeholders, setting the pace etc.
In a sense, introducing scrum shift the lines and makes the hierarchy a bit flatter which might be disrupting at first. This is why, having external training might be a good idea if your development organization hierarchy is deep or if politics might get in the way. The term “ScrumMaster” gives a sense of rank which doesn’t exist but could be perceived as such.I’ve always found the term poorly chosen. Having a third-party helping you during your transition might ease the friction and put everyone at the same level.

Related posts:

1. State of the economy is helping Agile development adoption
2. Software quality metrics dashboard
3. QA is always the bottleneck. What do we do about it ?
4. uTest.com – Can crowdsourced testing help my organization ?
5. Avoid bankruptcy ! Manage your technical debt.

I finally had a chance to finish reading Richard Branson’s biography: Losing my virginity.

If you’re looking for insights, tips or advice you might be disappointed. Branson is simply telling his story, his success and failures, what drives him and how he approaches business decision (quite simply actually with a lot of instinct). It’s up to you to discover what to make of his story. I might read his other book “screw it, let’s do it !” which summarizes quite nicely his life and the decision he had to make.

Related posts:

1. The Art of War – Sun Tzu
2. Jack Welch: Straight from the Gut
3. Behind the cloud is a great read !
4. Founders at Work: Stories of Startups’ Early Days
5. Brilliant, Crazy, Cocky: How the Top 1% of Entrepreneurs Profit from Global Chaos