Hello faithful readers!
I just wanted to say that Maven and Motley will be on hiatus through the month of November 2008. I will be on vacation and Maven and Motley will be coming with me :-). I'll try and get one more post in before I leave, but no promises.
In the meantime, please let me know if there are any topics you'd like to see these two characters cover in upcoming episodes.
All the best, and thanks again for reading!
James.
Summary
Motley: All developers have the same personality type - introverted and logically-minded. A personality test for a developer would be a waste of time.
Maven: Build a diversified team with different personality types; learn what type of personality each person has as everyone is different, and break down communication barriers with this knowledge. A great test is the Insights Discovery profile, which breaks people into cool blue, earth green, sunshine yellow, and fiery red personality types.
______________________________
[Context: Motley hired 3 new developers on the team a few weeks ago and is concerned with the behavior of the new hires in relation to the rest of the team]
Motley: I feel our team is in disarray with 3 new developers that just started on the team. Of course, there is the usual transition period for new team members and an expected time period for the team to get to know the new people, but these guys are a little different than the rest of the team members. I'm not sure what to do about it. Perhaps we made a mistake in our hiring.
Maven: It's tough for a team to take on that many new people in a short time period. However, it may not be so easy to chalk up the difficulties to team transition. How are the new people different?
Motley: Well, the bulk of the team is your stereotypical software developer - very introverted, very logical, do as their told, rely on data to back up an argument, and really doesn't express feelings - characteristics like that. For the new people, we have:
- Morris: Morris is a more senior industry hire who likes to mentor people. Even though he is new to the company, he has jumped right in and started to improve the team. Some of the team members are put off by this, as they feel they know more than he does, at least about how the company works. Additionally, he seems to get upset easier than most. One thing that people do like is that he is taking the time to get to know everyone one-on-one.
- Maverick: Maverick is absolutely take-charge kind of person. He doesn't take "no" for an answer and gets stuff done as soon as possible. He is unusually extroverted for a software developer, and the other people on the team don't know how to deal with him. He makes decisions without hesitation and keeps pushing people to be as productive as possible, sometimes excessively.
- Mavis: One word describes Mavis - "fun". She is already playing jokes on the rest of the team and injecting fun. I love it. However, the rest of the team is a bit taken aback by it and is having a hard time dealing. I've complemented her a couple of times on her work and she seems to eat it up whereas the others on the team dislike public recognition.
Pasted from http://www.insights.com/Files/210_LS_enGB.pdf
Maven: My first observation is that you likely did extremely well with your new hires.
Motley: What gives you that idea? I only gave you a really brief description of each of them. I know you like to pretend your smart - is this another trek into your alternate reality you seem to love so much?
Maven: Always got a dig for me, eh Mot? Your descriptions are enough to know that you have a very diversified team in terms of personalities. The best teams are made up of a wide mix of people - not just your stereotypical developer. In fact, a team of people with all the same personalities likely is not going to optimize their creativity and have as much fun. The trick is for each team member to learn what kind of personality each person has, and cater to their strengths.
Motley: Ok, wise guy. I know you have an answer for everything. Regurgitate all that logic that fills that head of yours and tell me how we can get to know each other very quickly. I do not want to lose years of productivity and morale while everyone learns about each others' habits!
Maven: Well, I just so happen to have a suggestion, as surprising as that may sound. Get everyone on the team to take a personality test.
Motley: I suppose you want us all to go see a psychologist too! Jee whiz, Mave, isn't that a little too "touchy-feely" for a team of developers? They are going to laugh themselves crazy if I suggest that.
Maven: Well, I am totally serious. Sell it to them as a fun couple of hours that they will spend making the overall team more effective. Ask them to humor you and if they do not find it enlightening, you'll buy them drinks after work.
Motley: Great. I am going to go broke.
Maven: Maintain a positive attitude! You have many options with personality tests. My personal favorite is called "Insights Discovery". The test presents you with a set of questions that you will likely feel are completely irrelevant to judging a personality. At least, that is the way I felt. The results, however, astounded me. The personal profile I received nailed my personality, helped me learn about myself, helped me understand others, and helped me manage my interactions with others. By sharing the results with the rest of the team, they now have some strategies with how to more effectively interact with you.
Motley: I have already learned those strategies - humor you by pretending to listen to your banter, give you false complements once in a while to ensure your ego stays high, and make you feel like you are making a difference around here instead of being a useless investment to the company.
Maven: You need to visit "Dr. Feelgood" and take your positive pills. Anyway, I'll ignore your attempt at humor and fill you in. The resulting profile presents four personality types, of which you may be a mix of more than one:
- Cool Blue: A person that is cool blue is introverted, indirect, works in a structured way, focuses on process, fears embarrassment, seeks security in preparation, likes data to back up a claim, is thorough, is precise, wants to be correct, and likes time to think before making a decision. Cool blue is a combination of introversion and thinking. Many developers fall in the blue quadrant
- Earth Green: A person that is earth green is introverted, emotive, has a slow/easy style, focuses on maintaining relationships, likes attention, wants to be liked, and seeks acceptance through conformance. Earth green is the combination of introversion and feeling. Morris sounds like he is in the green quadrant.
- Sunshine Yellow: a person that is sunshine yellow is extraverted, feeling, has a fast and spontaneous style, focuses on relationships, is often sarcastic, likes you to be outgoing, wants to be admired, and makes spontaneous decisions. Sunshine yellow is the combination of extraversion and feeling. Mavis sounds like she is in the yellow quadrant.
- Fiery Red: a person that is fiery red is extraverted, thinking, fast and decisive, focuses on productivity, wants to see results, likes you to be brief and smart, and is usually quick and decisive. Fiery red is a combination extraversion and thinking. Maverick sounds like he is in the red quadrant.
Motley: Isn't calling someone by their color a little prejudiced?
Maven: In this case, no. Learn what color each person is and read the portion of their profile that indicates how they deal with people and how people should deal with them. Based on this information, you can make the team much more effective and understand everyone's behaviors much more thoroughly. James was telling me he did this on a previous team, which helped ensure the team was diversified and helped each team member deal with each other and be more empathetic to behaviors. I think he said he was blue, borderline green, which is actually fairly typical for a developer.
Motley: And I suppose all of this costs money?
Maven: Think of it as a team investment. A really good team investment. I don't know what the specific cost is, but it is well worth it. If cost is a major consideration, there are some free tests that you can do on the Internet that may not be as effective but will still provide some results. I am going to persuade every team I join in the future to do this kind of testing as it can only help, not hinder.
Motley: I'll ask for the funds from the boss, but if he laughs at me and it affects my annual review, I am coming after you...
______________________________
Maven's Pointer: There are may different personality tests out there, and many of them are available for free. One of the most popular personality designations is the Myers-Briggs personality test. After taking the test, you end up with a four-character designation indicating your personality type. A very brief description of the results is as follows:
- Introverted or Extroverted (I or E): E = actively involved and outgoing; I = prefer to be alone
- Intuition or Sensing (N or S): N = pays attentions to impressions and patterns; S = pays attention to physical reality
- Thinking or Feeling (T or F): T = more weight on principles and impersonal facts; F = more weight on personal concerns and the people involved
- Judging or Perceiving (J or P): J = structured and decided lifestyle (planned, orderly); P = more flexible and adaptable lifestyle (spontaneous)
My (James) personality as indicated by Myers-Briggs is INTJ, which actually is fairly typical for a software developer, and in line with the green/blue personality type.
Maven's Resources:
Summary
Motley: Developing international software is really, really hard. We need brand new binaries to ship in other languages.
Maven: Follow these tips when developing for international markets: design for one worldwide binary, ensure the software is globalized, do not build strings at run-time, expand UI labels by 40%, and test with pseudolocalized builds.
______________________________
[Context: Motley is a little shocked that the marketing team has asked the development team to produce a non-English version of the software they just shipped]
Motley: Arrrrrrggggghhhh. I've had it! We spend all this time shipping the first version of our software in English, and now the marketing team wants us to ship a Japanese version to expand our reach. I don't know the first thing about shipping software in languages other than English. It's too hard to do if you don't speak the language. We are going to have to hire a vendor to fully create a new version.
Maven: Calm down, Mot. It's not so bad. If you designed the software correctly from the beginning, shipping in another language really is not that difficult.
Motley: Okay, don't keep me in suspense. How does one "design the software correctly from the beginning?" I have to admit that we were not thinking about shipping an international version, and instead focused on getting the thing done as soon as possible in our default language - English.
Maven: There are various keys to shipping software in multiple languages. The first is to have one worldwide binary.
Motley: How can we ship one binary? If we ship English and Japanese, that will mean two different binaries that we have to build and distribute. Use your head, Mave!
Maven: Actually, no. Ultimately you want one executable for your application that is used regardless of what language is displayed in the UI. The user can potentially set the locale via the Windows control panel to switch languages, which does not change the .EXE that gets launched when the application icon is double-clicked. What does change, however, is what strings are loaded by the executable.
Motley: Ah, of course. That's what I meant. And, hmmmmm…. Fortunately we did use resource files for the UI strings for the most part to make it easier on the user experience people to make sure we developers who don't talk good English get our mistakes fixed.
Maven: Nice play on the grammar, Mot. The other benefit of being able to pass the resource files to user experience people is also being able to pass them to localizers for translation to other languages like Japanese. To do this, however, you need every visible user string in those resource files. Did we do that?
Motley: Well, probably not every string. We'll have to do a scrub of the strings. Shouldn't be a problem though. So that's it?
Maven: Not necessarily. You have to follow a few other rules. Firstly, do not build strings at run-time.
Motley: What exactly does that mean? Let's take a simple example: if I ask the user for their name and I want the software to say "Hello", I have to do something like: "Hello" + name. No real way around that.
Maven: Yes, that type of functionality is often required. However, there are better ways to put strings together. For example, in C# you want to do something like:
string.Format("Hello, {0}", name);
But remember, the string above is actually taken from a resource file. That gives the localizers the opportunity to change the positioning of the token in the string to match the language being translated. Some languages may force different locations of the name in the string. If you build the string in code with the '+' operator, the ordering is compiled in and you have to rebuild (and generate another binary) to change order if another language is "<name>, <hello>" instead of "<hello>, <name>".
Motley: At least the solution is easy. What else do we need to do?
Maven: Another big rule is to expand your UI labels by approximately 30% to 40% in length. In some languages, like German, a typical phrase has many more words/characters than the equivalent English phrase. As a result, just because your UI looks great for English does not mean that text will not be clipped for other languages. Have to be careful there.
Motley: Rules, rules, and more rules. Can't we just abbreviate for the other languages? I am kidding of course.
Maven: Additionally, don't forget that you should not make any assumptions about sort order, date/time formats, currencies, and other international differences. For your software to be truly globalized, it must work with any culture - even when Windows is set to display right-to-left instead of the standard left-to-right.
Motley: One thing at a time. Let's just focus on making v1.1 localizable (translatable to other languages) and globalized (functions correctly in differing cultures). We will likely have to make small modifications to our designs to accommodate this. But here is another question: I don't speak Japanese, so when we have a Japanese version available, how am I supposed to debug it? I want to avoid constantly switching between a Japanese and English build.
Maven: Great question. For initial testing that finds the vast majority of problems, as well as easier debugging, we can create what is called a pseudolocalized build.
Motley: Pseudo-what??
Maven: Pseudolocalized. We take a build that is localizable, and automatically insert some more, well, troublesome characters. We could insert accented 'e' characters to replace the 'e', as well as other characters that are similar to their English counterparts, thus still making phrases readable. In addition, the lengths of the strings are expanded, and each string starts with a delimiter character like '[' and ends with ']'. If you see a string in the UI that does not start and end with those characters, then you have a clipping bug. Pseudo-localized builds really help nail down international problems early in the development cycle.
Here is what a pseudolocalized application could look like:
Motley: Very cool. A lot of it looks like gibberish, but is still English-readable. The UI contains a lot of the characters that can be troublesome given the wrong font choice for the UI. I can definitely see this technique saving lots of bugs prior to check-in, provided the developers can generate a pseudo-localized build on their own.
Maven: Exactly. Since pseudolocalized builds really only require processing of resource files, they are generally easy to generate. The are tools out there that can do it for you, or you can write your own text processor to do simple string expansion and replacement. It's a valuable tool.
Motley: Good tips for a change, Mave. I guess we have some work to do to really make our software internationalized, but I don't feel it will be a lot of work given the choices we have already made. I better get to work!
______________________________
Maven's Pointer: There are lots of other tips to creating good international software, from requirements to development to testing. As a developer, it is little extra work to make your application localizable and globalized. Do this work up front - trust me. I was on a software project that lasted 6 months while we moved strings around. Not exactly fun work. If we had followed the tips above, avoided text in graphics (hard and expensive to translate), and avoided hard-coded user-visible strings in the code, we would have been in great shape to ship in multiple languages. Do it right the first time, and take the very minor hit to the schedule that comes with it.
Maven's Resources:
- Developing International Software, 2nd Edition, by Dr. International, Microsoft Press, ISBN: 0735615837, November 2002.
- NET Internationalization: The Developer's Guide to Building Global Windows and Web Applications, by Guy Smith-Ferrier, Addison-Wesley Professional, ISBN: 0321341384, August 2006.
- Wikipedia entry on Pseudolocalization: http://en.wikipedia.org/wiki/Pseudolocalization
Summary
Motley: I must conform to the wishes of the management team, even if they are wrong. I need permission to modify the organization-wide processes.
Maven: Sometimes it is better to ask for forgiveness than permission. Break the rules if it is best for the team, then say "sorry". Be accountable for results, not processes.
______________________________
[Context: Motley has just surfaced out of a 3 hour meeting that focused on company processes that he feels are unnecessary. Motley is back at his desk, slams his desk drawer in frustration, and lets out a few colorful metaphors. Maven takes note and walks over.]
Maven: What's up, Mot? Did someone throw a laxative in your coffee or something?
Motley: Why you-
<a chase around the office ensues>
Maven: Ok, Ok, I give up. You are in a mood. But seriously, may I do anything to help whatever is bothering you?
Motley: You're lucky I didn't catch you before you gave up or… ah, forget it. You want to know what's bothering me?? Extraneous process. Too much bureaucracy. Inflexibility. Resistance to change. Micro-managing. People telling me the wrong thing to do. That's what's bugging me. Simple fix this time, eh Mave? Good luck.
Maven: Well, let's get into some of the details. How about the first two, since they are likely related - extraneous process and bureaucracy. What's the problem?
Motley: First of all, I am a developer. I develop software. I am paid to be technical. The stuff I just talked about shouldn't even factor into my job. I want to design. I want to write code. I don't want to deal with politics. It's frustrating.
Maven: You are the lead of a team, are you not?
Motley: Yes. So? I still have to conform to the wishes of the management team, even if they are wrong.
Maven: Firstly, even though management may be wrong in your eyes, they may think that they are right. Keep that in mind. Secondly, those non-technical aspects you mentioned come with the job. Not only do you have to be a technical leader on your team, but you also have to deal with all the other stuff around it and shield your team from distractions. It comes with the job. You are good at it, too. I've seen it.
Motley: Don't butter me up, wise guy. You are right that I am good, but save it. Anyway, you know how the company is structured - there is a release management team in place that sets many of the rules. You have to input bug records in a certain way. You have to meet a ton of exit criteria at a milestone. You have to plan your feature set in a certain way. You can only have certain things for lunch on Monday. You know how it is. The ridiculous rules take away your freedom as a feature team.
Maven: Yeah, I hate having tofu on Mondays. Ha! Just kidding. Yes, there are rules in place, and many of them are there for a reason - to ensure the release of the software is on time and of high quality. But-
Motley: I figured I would get the standard answer from you: "Follow the rules. Conform. You have to play nice." Blah, blah, blah.
Maven: Ah, but you didn't let me finish. BUT, you have to understand the "why" of the rules, and if it doesn't make sense to you, break them.
Motley: WHAT?!?! YOU are telling ME to break the rules? Have you been into the glue again?
Maven: Sometimes it is better and easier to ask for forgiveness than permission. Do what you think is right and explain why later if necessary. Where the release management team is falling down is in instituting process across the organization instead of focusing on results. It's the accomplishments of the team that matters, and every team is slightly different. If you need to bend the rules to do what you think is right, then do it.
Motley: But they are going to make me accountable for following the rules!
Maven: Ultimately they are going to make you accountable for the results. That's what matters. You need to be prepared to answer why you broke the rules, but in the end I am sure you will be forgiven. What about the other issues: inflexibility, resistance to change, micro-managing, and people always telling you the wrong thing to do?
Motley: They are all basically the same category, I guess.
The inflexibility comes when the management team wants us to do something specific and won't take no for an answer. For example, we are forced to come up with a detailed long term plan when our team is agile. The important thing for us is to have the right priorities against our work, not predict exactly what features will make it into the final release.
Resistance to change comes in when management views our team as renegades and does not let us operate on our own even though the development model differs from other teams.
Micro-managing comes in when they look over every move we make. For example, they review our bugs even after we have triaged them!
For the wrong thing to do point, it just ties in with forcing actions on us that do not jive with our development model, like the planning above.
They are all related.
Maven: I see. You are right - they are all related and come back to the very same point. Focus on results and do what is best for the team even if your methodology differs from the overall group. Just be prepared to be accountable for the results. I am willing to bet the release managers forgive you if you ship a super high quality product on time. In fact, they will likely want to learn from your team in future releases.
Motley: Wow, Mave. You are quite the renegade. This is not exactly the advice I was expecting from you! I have new found respect! Well, not exactly, but let's pretend. We will definitely become the golden child of the entire organization and other teams will want to be just like us.
Maven: Great. The catch is this: you had better make sure you deliver those results or the release team has more ammunition to use you as a very bad example for other teams to learn from and not follow. That could spell disaster for you as a lead.
Motley: Of course we will deliver. There is never any question.
______________________________
James' Pointer: Sometimes an idea arises that you know is going to make the team more productive and improve morale. Take a recent situation I experienced. In my office area at Microsoft we are very space constrained at the moment, with people double and tripled up in offices and extreme difficultly booking conference rooms. Our team had a great idea to quadruple the leads, free up two offices, and use one for 1:1 meetings, and the other as a non-bookable team room with some extra test hardware in it. We were ecstatic. Then we asked for permission and the administrator shot us down stating that empty offices would not be tolerated and would need to be filled immediately to alleviate our space problems. But they were our offices to begin with and we didn't have to move! In the end, we did manage to get the administrator to agree to a partial move, and we used our ingenuity to perform the full move anyway without telling anyone. We are happier, more collaborative, and more productive. What she doesn't know won't hurt her. I just hope she does not read this write-up. We'll beg for forgiveness if we get caught, but until then we will help ourselves and the business.
Maven's Quotes:
- "It's easier to ask forgiveness than it is to get permission. " -- Grace Hopper
- "Forgiveness does not change the past, but it does enlarge the future." -- Paul Boese
- "Do whatever it takes to get the job done the right way and the best way; then both permission and forgiveness are unnecessary and thus irrelevant." -- Rosa Say
Summary
Motley: A tester's job is to find bugs, so measure them on the amount of bugs they find. More test automation is always better.
Maven: Do not measure testers by the amount of bugs they report. Think of the test team as more a quality assurance team than a quality control team. Too much test automation can be a problem due to brittle test infrastructures, too much time troubleshooting tests, suboptimal investment in tests, and lack of thinking like a user.
______________________________
[Context: Motley has been having issues with another counterpart team in the company]
Motley: I am a little disappointed in our test team. They really haven't generated many bugs in the product as of late. I feel like I have to kick them in the pants to get anything done.
Maven: I always thought we had a great test team. We have a bunch of really smart people, and they have made previous releases great. What is the problem?
Motley: Lately all the bugs are generated either by the development team or by others using the product. We pay the test team to test the product and find issues. If I was the test manager who is measuring them by the number of bugs they find, they would all fail this year's annual review.
Maven: Whoa. Before we explore the real issues of why the test team is not reporting bugs, let's talk about your statement around measuring testers.
Motley: Why? The best way to measure a tester is by the number of bugs they find. You can mine the bug database easily to get the numbers and it makes evaluation of the test team really easy.
Maven: Sorry, bud. Measuring testers by the number of bugs they find is a really dumb thing to do.
Motley: Don't EVER call me "dumb" - <pow>.
Maven: Ouch! Fine. I deserved that, and I apologize. Anyway, just because a tester is not reporting bugs does not mean they are not being productive. Think of the test role less as "quality control" and more as "quality assurance". The best tester can prevent a bug before it happens.
Motley: But they do control quality, and how would they prevent a bug before it happens? Developers hand over the code when they are ready expecting the tester to find all the issues.
Maven: Maybe in the past. Now, particularly with agile teams, testers are involved in the process right from the beginning. They participate in functional specification reviews, contribute to user scenario development, design reviews, code reviews, do private buddy testing, help compute metrics like code coverage, and many other quality-related activities. They do not have a sole test responsibility - they are another member of the team. A good tester helps assure quality by finding issues in all aspects of the development process and helps to improve the team's processes to prevent bugs. The best testers find no bugs in the code because they worked to prevent them right from the beginning. As a result, it makes no sense whatsoever to measure a tester by the amount of bugs they report in the bug database.
Motley: I guess that has some merit. The best tester may actually have a lower bug count than the poor testers. That is kind of an odd way of looking at the performance of a tester, though.
Maven: Odd, but reasonable. The test team should still be testing end-to-end scenarios in the product and reporting test results, however. You are saying that isn't happening? Why?
Motley: I talked to Morgan, the test lead of the multimedia feature. They are focusing all of their time on improving the test automation to ensure we have full coverage. However, the test infrastructure they are using is very unreliable and often reports incorrect results. Another team in the company is responsible for that infrastructure, but because our tests are a little more complicated, Morgan's team ends up troubleshooting the issues. It sucks up so much time that they don't have time to do the tasks that matter, like attend reviews and actually test the product.
Maven: A common problem when teams focus too much on automation.
Motley: What do you mean? Test automation is a good thing. It allows us to re-run tests without human intervention on a regular basis. Without test automation we risk breaking many areas of the product every time we make a change.
Maven: Do not get me wrong - automation can be a great thing. Unit testing is a form of automated testing and something that we have been discussing that absolutely every software developer must be doing. You make a change, you run your tests, and perhaps tests from other teams, to ensure you have not broken any functionality. The more unit tests, the better. The higher the code coverage on those unit tests, the better.
Motley: You are contradicting yourself all over the place Mr. Maven. First you said you can focus too much on automation, and now you are saying more is better. Inquiring minds want to know - which is better?
Maven: More unit tests - better. More scenario-based automated tests - not necessarily better. There is a great value in having a basic test suite that tests the core user scenarios of the product. However, relying too much on automation at the scenario level has disadvantages:
- If the architecture of the test infrastructure is very brittle (i.e. not robust), every time the product changes, major changes in the automated tests may be required. Testers spend more time trying to get the automation to work than adding real value to the product.
- A large focus on automation perpetually puts the test team behind the development team, if that is how your team is organized. If the developers design for testability, as they should, this situation is less of a problem as the testers can start developing automation fairly quickly. If automation is an afterthought, the developers may be on to the next feature before the test team is done, which means the feature isn't "done" according to our definition. It is also a context switch to go back and diagnose and debug issues later as the code is not as fresh.
- If the infrastructure on which the current features are built is expected to change in the next release, often a rewrite of the test automation is required. Should the team spend a large amount of time building automation infrastructure if it will change in the near future? Tough call.
- An automated test cannot think like a user, even if you inject some randomness into the tests. Over-reliance on automation creates some nasty test holes in the product that may only get discovered after shipping.
Motley: And here I thought more automation all the way around is always better. You actually make some good points. I am going to have a chat with the test people and ensure we are focusing on the right things. We should give up some work on automation if it means that we ship the product sooner and we do not cause ourselves any long term harm.
Maven: Sounds great. Let me know how you make out. I'm now going to stick some tissue up my nose to control the bleeding thanks to you.
Motley: Ah, you know you deserved it.
______________________________
Maven's Pointer: At Microsoft, I (James) have worked with a test team that seems to spend more time diagnosing and troubleshooting organization-wide automation infrastructure than it does improving processes, working closely with developers on test plans, and manually testing the product as a user would. Automation is a tool to detect regressions earlier in development, but it should not be used as a crutch. Given that philosophy, limit the amount of time you spend on automation to a reasonable number and pay attention to diminishing returns.
Maven's Double Pointer Indirection: We talked about code coverage in the past. One mistake test teams make is that they demand that they own the code coverage numbers, and that coverage should be measured against the test team's automated tests. Scenario-based test automation is not about testing individual components, modules, methods, and lines of code - it is more about ensuring that a scenario works as it should. Leave code coverage metrics to the developers and measure it with unit tests.
Maven's Resources:
- I.M. Testy's blog, from a guy in the Microsoft Engineering Excellence who has been teaching about testing for a long time.
- Alan Page's Notes and Rants, from another guy in Engineering Excellence who really knows his test material
- How We Test Software at Microsoft, by Page, Johnston and Rollison, Microsoft Press, ISBN: 9780735624252, August 2008.
Motley: James, that slacker, is not in the office again. That guy spends so much time outside of work that it's a wonder we pay him.
Maven: Well, everyone is entitled to a bit of vacation now and then, don't you think?
Motley: If that's what you want to call it.
Maven: Actually, this time around he's off doing a backpacking trip for charity. James is doing a 4 day hike to support Washington's National Park Fund (WNPF). It's a really good cause. We all do lots of hiking and camping in the backcountry in our national parks and generally take trail maintenance, repair, rangers, etc. for granted. Money to support that stuff needs to come from somewhere. James is raising money for the WNPF to help out. Care to give?
Motley: Ummm, I gave at the office.
Maven: Well, if everyone said that then nothing would get done. James will even take care of having Microsoft match whatever funds you donate. In case you change your mind, you can donate at http://www.firstgiving.com/waletzky.
Motley: Ugh. Fine. I can probably part with a few morning lattes. I'll have a donation up there within the hour.
___________________________________
James: No blog entry this week due to a charity event. Back next time. In the meantime, if you feel like donating to the WNPF, please click the link above. Thanks!
Summary
Motley: Use Scrum in my personal relationships? Don't be such a geek.
Maven: You can apply the same lessons as Scrum teaches to your personal relationships - lots of communication, planning, iteration, and retrospectives focusing on continuous improvement. Just translate the really hard stuff (relationships) to the what we geeks understand.
______________________________
[Context: It's Monday. Motley is not a very happy developer after spending the weekend with his girlfriend]
Maven: Hey, Mot. You look a little depressed today. Did you not have a good weekend?
Motley: Personal stuff. Leave me alone.
Maven: Ah, c'mon. Maybe I can help.
Motley: Dude - you write software for a living. You have no personal life. You don't know the first thing about relationships. Ah, crap. I already gave too much away.
Maven: Girl troubles. I see. What's the problem?
Motley: Ok, I'll humor you. I may as well tell someone my problems. It helps to get them off your chest. It's pathetic that I have to resort to you, however. Anyway, I have a great relationship with my girlfriend - usually. We are going through a rough patch. We haven't been communicating as much as we should, expectations are not being set appropriately, and I feel like we keep digressing to old behavior.
Maven: Typical problems in a more mature relationship. I remember you saying you live with her, so I presume it's mature. How about starting with some examples? What's the communication issue?
Motley: Wait a second. You see James listening again hoping for some blog material? Hah. Not getting anything this time. For once we are having a conversation about a topic that has nothing to do with software engineering! Sucker.
Maven: Knowing him he'll turn this into a software engineering topic somehow.
Motley: Anyway, one of the main issues in my relationship centers around chores. She has some responsibilities and so do I. The problem is that she does a poor job at the chores and I have to clean up and finish. It is frustrating.
Maven: It's your fault.
Motley: What do you mean it's my fault?!? She does the chores!
Maven: Have you sat down and communicated expectations you have for the chores? The two of you have not specified the completion criteria for the chores, so there is a misunderstanding of what needs to be done.
Motley: That sounds so robotic, dude. But, fine. I guess if we don't talk about expectations, that leads to issues. I'll have a chat with her about that.
Maven: What are the other problems?
Motley: Still related to chores, when she starts on something, it takes forever to finish it. She just bites off way too much at one time. And by the time it's done, it's too late to be useful. Yeah, yeah - you want an example. Well, she started working on the yard in mid-summer - bought all the plants, and by the time the plants were all in the ground it was fall and they died off shortly thereafter. Definitely not the way I would have done it.
Maven: Have you encouraged her to split the larger tasks in smaller pieces? Instead of doing one big task she could do a bunch of smaller tasks and adjust as needed. If the yard is taking much longer than expected, she could adjust what plants to put in the ground to be more seasonal.
Motley: Probably not a bad suggestion. I'll bring it up. While I am in a whine mode, another thing I am not happy about is that many chores get overlooked. Taking out the garbage is a regular thing - if you don't do it, you miss garbage day and have to put up with a nasty odor for a week. Don't you just love the smell of two week old rotten vegetables?
Maven: Perhaps what you two should do is have a brief discussion at the start of the week to come up with a shared to-do list of tasks you need to accomplish. Think of it as a family meeting or something.
Motley: Have you ever had a relationship? Never mind - I withdraw the question. Your suggestion is way too formal! She will likely laugh in my face.
Maven: It doesn't need to be formal, and it goes back to setting expectations. If you clarify the plan for the week, you will save yourself some stress and headaches later. Write it down so there is no confusion, and then you get the pleasure of checking off the task when it is complete, as we talked about previously in our checklists conversation.
Motley: I am not going to bring it up as a "family meeting", but the concept is reasonable.
Maven: If you do a daily check-in as well, you ensure that things are kept on track for the week. Just bring it up in everyday conversation.
Motley: I am afraid that if we take these suggestions that we will be back to our same old selves at the end of the first week.
Maven: Change is hard. We have talked about that too. When you make up your plan for chores for the next week, think back about the previous week and talk about how you can make the next week better. Scrap the to-do list if it isn't working. Make more time to talk if that's what it takes. Additionally, have a chat about what went well, and continue to do those things.
Motley: I don't know if I can sell all of this to her. I am obviously going to have to rephrase everything that you have just said in a way that she can understand, and not sound so ridiculously formal. All of this thinking sounds familiar though, but I am having a hard time placing it.
Maven: At this point you likely think I am completely off my rocker (crazy), but in a previous relationship my girlfriend and I were seeing a counselor and he recommended everything above. I thought it sounded very familiar to the work environment, and then it hit me like a tire on the side of the head - it's Scrum! Who knew that you could apply Scrum concepts to your personal life. I didn't.
Motley: Scrum. Yeah, I thought that sounded familiar. You just ran over planning, the meaning of "done", doing work iteratively, the daily check-in meeting, updating your backlog, and retrospectives. You are such a geek. You did say "previous relationship" with your girlfriend, so I am assuming this didn't work. Why bother?
Maven: Don't be a wise guy. Apply all the stuff we just talked about to both your relationships and to software engineering and you will be fine. Just remember to apply some right brain thinking when you use it with your girlfriend.
______________________________
Maven's Pointer: Building and maintaining relationships is often hard for techno-geek logic-based beings like software developers. It is amazing how the metaphors that we apply in everyday software development also apply to life in general. The counselor in the story above had no idea whatsoever what "Scrum" was, but he presented all the concepts in his language. Many concepts that we leverage as developers are applicable to other domains and disciplines. You just have to look for it.
Maven's Resources:
- Yeah, right. This topic is pretty far out there. If you find any related resources, be sure and let me know!
Summary
Motley: Features sell a product. When in doubt, add more features!
Maven: These days, software is less about features and more about reliability, fit 'n finish, performance, and usability. Use the Kano model to help you focus on the right scenarios for the user.
______________________________
[Context: Motley is struggling with a common project management problem]
Motley: I am wondering how we are ever going to make any money on this product. We had to make so many cuts to make it to market in a reasonable time that the product is not all that useful, in my opinion. We need more features, and we need them quickly.
Maven: Do you think it's just features that make a product successful and sell lots of copies?
Motley: Well, pretty much. If the software doesn't do what you need it to do, why would you bother buying it? Features trump everything else. For a v1, we should even consider shipping sooner with a few more bugs to get a few more features in.
Maven: Hmmm… you were telling me the other day that you have an iPod Touch, right?
Motley: Why are you wasting my time here? Yes, I have an iPod Touch. Get to the point.
Maven: One more question: why do you have an iPod Touch vs. a Creative Labs Player vs. a Zune? The iPod costs significantly more doesn't it? And don't the other players typically have more memory for the same money, and perhaps include FM tuners?
Motley: That was three questions, wise guy. I chose the iPod Touch after playing with it for a while. It does what I need it to do, it's reliable, and it's extremely well refined and polished. I could flick the list views and pan around for hours. I love watching the acceleration of the list view as you start to flick and slow down as "friction" takes over. They really did a nice job with the interface. I had to have it. It's a really fun device to use.
Maven: So it's more than just features that attracted you to that particular model?
Motley: Well, in this case, yes. I looked at the other MP3 players out there, but I wasn't impressed. They had the same features, but the iPod Touch was just, well, fun. Additionally, one of the other players that shall go unnamed crashed within just a few minutes of use. I was not impressed.
Maven: Does the iPod Touch do everything you want it to do?
Motley: Not necessarily. It would be great if it had a built in GPS, for example, so I could hop on a wi-fi network and get directions from where I am. An FM tuner would be nice for those nights I go to the races (they broadcast the commentary over FM). But seriously, I have to get some work done. Why are you bothering me about all this?
Maven: Let's go back to the software you are working on - you were saying we need more features and should even ship with slightly lower quality to get features in. Does that equate back to your iPod Touch experience?
Motley: Well, errrrr, ummmm…
Maven: That's what I thought. A decade ago, when there was little competition for many software products on the market, features won the war. End users actually put up with an operating system like Windows 95 that blue screened every other day when it was released. It was the best thing out there and the reliability issues were tolerated. Times have changed. Users expect software to "just work". They want it to solve their problems their way with a minimum of fuss. If it meets the majority of their scenarios and does it well, users are generally happy. These days there are always other options if a product does not meet their needs.
Motley: You did mention "their way" above, though. In order to do things their way, you need to make it as configurable as possible and including knobs and buttons allowing them to customize their experience. That takes time to build.
Maven: I would actually argue that too many knobs to twist, turn and pull just ends up confusing the user creating a frustrating experience. Look at the iPod Touch - two buttons. Compare the browser on the iPod Touch to something like Internet Explorer on the desktop - very few configurability options. But, users are happy. In fact, they are ecstatic about the device. It satisfies 80% of the core user scenarios. It may not keep the power users happy, but there are other options out there, including third party software updates that could potentially add some of the knobs and buttons they need.
Motley: There is still a minimum feature set we would need to be successful.
Maven: No argument there. However, that feature set is usually not as large you think it is. Nail the top priority user scenarios extremely well and you will likely be successful.
Motley: Easier said than done.
Maven: Sometimes. You need to really understand the user in order to make good decisions. Here are a few other keys to success:
- Reliability: The user's first experience with the product should be positive. It should "just work". It should be working out-of-the-box within a few minutes. Spend more time during development ensuring it installs easily and doesn't crash vs. adding features. What features are there must be solid.
- Fit 'n Finish: Were the gravity and friction capabilities on the iPod Touch really necessary for a decent user experience? No. Do they set the device apart from competitors? Yes. Do they make the device fun to use? Absolutely. Do they set the bar for interfaces on mobile devices? You bet. Nice icons, nice graphics, and little effects add up to a really positive experience with the device when combined with the other criteria listed here.
- Performance: Waiting sucks. Apple put the right hardware in the iPod Touch to ensure performance would not suffer. I am sure they spent a lot of time tuning the experience to make it snappy. Users will no longer accept sluggish software. Performance actually is a feature.
- Usability: The user interface must be incredibly intuitive such that you do not even need a user's manual. The user should be able to pick up the device and be productive within minutes. An understanding of human psychology is a requirement when developing a good interface.
As another example, how many features of Microsoft Word do you use?
Motley: Out of the 10000? Probably 20.
Maven: Exactly. A few extremely polished features will likely satisfy 80% of your users (see the Pareto Principle, or 80-20 rule). Spend time making an incredible experience for those core features, and add features once the polish is in place. Aim to delight the user.
Motley: Delight the user? That sounds a little "foo-foo" to me. What is "delight the user" supposed to mean?
Maven: Think about the Kano model, which comes from Six Sigma. A diagram illustrating the concept is shown below:
Pasted from <http://www.isixsigma.com/library/content/c030630a.asp>
The lower curve represents the basic needs of the user that must be present in the product for it to stand a chance to be successful. With the iPod Touch example, it better play MP3 files. That is a basic need that the device must fulfill, and if it didn't, it wouldn't sell, at least not as an MP3 player. These features likely won't set you apart from the competition either.
The middle curve represents those features or criteria that you can never have enough of. With the iPod Touch example, more memory, faster performance and better sound quality are always welcomed and can set the product apart from the competition.
The upper curve provides the greatest opportunity to beat competitors, and are those things that truly "delight" the user. With the iPod Touch example, the polished user interface, the flick and pan operations, the automatic playlists, etc. help set it apart from other players and make customers say: "Wow, this is a cool device!" Often these types of "features" are unexpected, but very welcome.
Motley: Interesting model. You are saying that we must met the basic needs, consider performance characteristics, but to really set ourselves apart, we need to consider those things that delight the user. This typically revolves around ideas that really catch the user's attention, and are often the result of polishing existing user experience paradigms and features.
Maven: Exactly. Although polish does not always equate to delighters, it does contribute to a solid user experience - moreso than the addition of several more half-baked features.
______________________________
Maven's Pointer: Although I (James) work for Microsoft, I will gladly give another company kudos for a job well done if it is warranted. I do own an iPod Touch and think it's a fabulous device that other MP3 players cannot keep up with. I have been extremely happy with my purchase, even though I could have gotten a significant discount (relative to other players) on one unnamed player. "It just works" really matters to me - the device and/or software needs to be polished, usable, reliable, performant (is that really a word?), and just do what I need it to do. That's not to say Microsoft doesn't make some fabulous products as well, such as OneNote, Money and Vista (yes, I am happy with Vista). Apple does a set a great example, however, when it comes to building software and devices that consumers love.
Maven's Double Pointer Indirection: There is more to Kano analysis and mentioned here. There is guidance available in some of the resources below on how to ask user positive and negative questions and plotting them on a 2-D table, to determine whether ideas are delighters, performers, or basics.
Maven's Resources:
Summary
Motley: Milestones are useless for agile development. Our feature team can ship at the end of every iteration, so milestones have no value for us.
Maven: Milestones provide a synchronization point across a set of features, helping to ensure the overall product is of high quality. Every milestone has a set of exit criteria that the integrated product must satisfy before moving on.
______________________________
[Context: Motley is analyzing his team's upcoming deliverables and is questioning some of the Cynthesis Software development process]
Motley: Overhead, overhead, overhead. Why is the project manager making our team go through all the hassle of hitting a milestone when we are doing iterative development anyway? We have mini-milestones every time we finish an iteration. We produce a shippable piece of functionality that is ready to go. Milestones are useless for us.
Maven: Actually, milestones have use even in an agile world. You are not the only team contributing functionality to the release, right? There are other teams building features?
Motley: Yeah, so? Some of the other