Progressive Development

Motley says: “Agile doesn't change testing - developers can just throw code 'over the wall' to the test team”

2011-04-13T06:56:00Z

Summary

Motley: Developers should just throw the completed code "over the wall" to the test team when they are done. There is nothing different with testing in an agile world vs. a waterfall world.

Maven: Testing in an agile world is a completely different way of thinking about testing. "Testing" becomes more quality assurance, with testers involved in a development iteration from the start. The team rallies around test-first strategies, and deals with any bug and test debt before the interest becomes too high.

______________________________

[Context: Motley is used to a waterfall style of software development where developers write code and pass it to a test team to validate once the code is complete. Now that Motley's team has taken an agile approach to software development, he is a little confused how the test team fits in, and if their role actually changes or stays the same.]

Motley: We have been practicing agile development for a couple months now and the testers on the team are a still confused as to what they should be doing. I don't see what the problem is - I tell them to just wait until I have something to check-in near the end of the iteration and then they can have at it. While they are testing I go on to the next task.

Maven: So you throw it "over the wall" to the test team once the code is finished.

Motley: Basically, yeah. Got a problem with that?

Maven: Maybe that "worked" in a waterfall world, but that model is not in line with agile principles. Agile brings about a new way of thinking about delivering software. Developers no longer "throw it over the wall" to the testers when the code for a user story is checked-in. Testing becomes more of a forethought than an afterthought, with quality built in at all stages of development.

Motley: How so? There is nothing to test until I finish the code! You're a little slow today, Mave.

Maven: Au contraire, mon ami. As we discussed previously, with agile we break up larger features into small vertical slices of functionality that deliver real end user value. The team is involved in setting exit criteria, or "done" definitions, for those slices and each piece gets implemented one at a time. The testers are involved from the beginning of the sprint-

Motley: But there is nothing to test until the code is written!

Maven: Agile presents us with a new way to think about testing. In a company like ours that has a tester career model, we need to adjust our thinking of what a tester is from a quality control view - where testers validate the functionality that the devs wrote, complete with running test passes and filing bugs - to a quality assurance view - where testers help prevent bugs from occurring in the first place. We treat testers as fellow engineers with a focus on test practices, but they should also be capable of writing production code when required, and devs should also be capable of developing test automation and pitching in to validate tasks. Testing is more of a team responsibility, and everyone's focus is high quality sooner in the cycle/iteration vs. testing in quality late in the cycle/iteration. The development of a slice of functionality is no longer phased, with an implementation and test phase. Instead, the testers work in lockstep with the developers, even thinking through and writing tests before any code is written.

Motley: I am still confused - what exactly do they do before any code is written?

Maven: On a good agile team, every engineer is "test-infected". Testing actually becomes a primary focus for the team, with everyone (including developers) pitching in as required. Driving testability helps drive a good design and helps promote solid engineering practices, such as ensuring unit tests are checked-in with every change to product code. All that said, there can still be a specific test role if warranted. Testers help with requirements brainstorming, design brainstorming, prototyping, technical investigation, and automation infrastructure design. Perhaps most importantly, however, is the creation of acceptance tests as soon as a story is defined for an iteration.

Motley: How can a tester create an acceptance test when there is nothing yet to test?

Maven: In the same manor as a developer could write tests before code. Remember our discussion on Test-Driven Development (TDD)? Think of this as Acceptance Test-Driven Development. Ideally tests are written in some form that can eventually be executed, such as in code or using a tool like Fitnesse, which allows even customers to write executable tests. However, writing tests using plain English in a team notebook can also be just as valuable. The tests help drive the overall design giving the developers check-in criteria. Let's leave ATDD for another discussion.

Motley: It still seems like testers would be idle while I write the code.

Maven: Not really. Testers can help with other activities in addition to those I already mentioned, such as writing unit tests, developing further acceptance tests (it can be more than one per story), participating in code reviews, doing private buddy testing prior to finalizing the code, developing integration tests, and even writing product code as any other engineer on the team. The important concept here is that the team marches towards the same goal - the completion of a particular story. There are plenty of parallel and collaborative activities involved in story development, and the team should not go on until a story has met the exit criteria. Once the code is checked-in, there is very little validation that should be done by the testers because most of it was done up front.

Motley: There still needs to be some level of integration testing. The individual story may be functionally complete, but we typically have to put the developed components together with other pieces.

Maven: True, and a very astute point. The unit tests should do the validation of the individual components, but components still need to be glued together. Testers can validate the integration and file bugs as they come across them. Another difference with agile is that developers do not start working on new functionality at this point - their first priority is addressing all of the issues found during integration, preferably as they come up. Bugs are a sign of not being done. The team - not just the developers - but the team, should be embarrassed when bugs are found post-check-in. Whereas with waterfall you may have a big "stabilization"/bug fix stage at the end, with agile you fix the bugs before declaring victory on a story. Bugs are debt, and should be dealt with before new features are added.

Motley: But it still may happen that a story may be coded but not necessarily completely validated before the end of an iteration. What then?

Maven: Yes, it happens. In that case, the team rallies around getting the story done before moving on. The task is inserted into the next sprint, and you do not get credit for finishing the task in the previous sprint (and thus you do not demo it). The team takes care of any test debt before moving on.

Motley: What about building up the set of automation infrastructure? Testers often get behind on that early.

Maven: If automation infrastructure is important to the team, then everyone pitches in to get it done quickly - including the developers. However, test infrastructure should be built in the same fashion as product code - incrementally with vertical slices. Don't build a huge amount of infrastructure and add tests later. Build enough infrastructure to support your first few tests, and then continue to add-on and refactor from there. Remember, testers are engineers just like the developers, and there is no reason both roles cannot work the same way.

Motley: I am skeptical, but I guess this change of thinking could work.

Maven: It can absolutely work! Of course, there are caveats. First, keeping work in small chunks as opposed to big changes helps this model. Second, for the team to succeed it requires time to focus on the task at hand. Randomizing the test team with, for example, test passes for other simultaneous releases will build up test debt and destroy this model. Third, some testing has to occur closer to the tail end of the iteration or even cycle, such as end-to-end integration testing, performance testing, and stress testing. Once again, the team rallies around those test goals and everyone focuses on completion of those tasks.

Motley: There is always a catch, isn't there?

Maven: Those are minor caveats. The important concept is to act as a team fulfilling the same goals. The team builds one story at a time, fully completes them according to a "done" definition, integrates as they go, and minimizes debt as much as possible. The product is always of shippable quality at the end of an iteration (with occasional exceptions - be pragmatic). In order to be successful, it really requires a test-first line of thinking, but let's hit on that in more detail next time.

______________________________

James' Pointer: At Microsoft, the Software Development Engineer in Test, or SDET, is an important role. The best SDETs help hammer out bugs before they even hit the source control system. In fact, in my opinion, the best teams have testers that report very few bugs because they practiced quality assurance instead of quality control. Measuring an SDET by the number of bugs they report is obviously wrong in this model. The SDET career model is also not directly aligned to agile, but we make it work. Agile tends to blur the lines between the Software Development Engineer (SDE) role and the SDET role. Perhaps in the future, engineers become more generalized, with some taking on a test role and others a development role, but all being capable of switching depending on team need.

James' Double Pointer Indirection: Using this kind of model, where test is involved up-front, typically produces fewer features in a given time period. The core reason is that features are developed to a "done" state that is far stricter than with a typical waterfall team. However, you save time in the long run because you avoid the lengthy bug tail. Think of it as "slowing down to go fast", a common theme in my everyday activities at Microsoft.

Maven's Resources:

A selection of articles around agile testing: http://www.exampler.com/testing-com/agile/

Decent book that describes what it is like to be a tester in an agile environment:
http://www.amazon.com/Agile-Testing-Practical-Guide-Testers/dp/0321534468

Very good magazine that gives several perspectives on testing in an agile world:
http://www.testingexperience.com/testingexperience03_09.pdf

Motley says: “Just build the features, and they will come. Who needs a goal?”

2011-03-01T15:35:00Z

Summary

	Motley: A successful development iteration does not need a goal. Just deliver some features and call it good.
	Maven: A goal provides clarification on what the team is building during a development iteration. Goals provide rallying points for the team, as well as focus. Iteration goals aid in decision making for deciding what to build during planning.

______________________________

Motley: Well, Mave, another successful 3-week development iteration. We delivered some great stuff - of shippable quality - and are off on and running on the next one.

Maven: That's great! What does "successful" mean for your iterations?

Motley: We finished the work we set out to do, of course. We had very few bugs reported by the test team, so I would call that a success.

Maven: Was there a theme for the iteration? How did you determine what work items to include during your iteration planning?

Motley: Just a mish-mash of work - no real theme. Why do we need one, anyway? As long as we make progress on the software, that's all that matters.

Maven: Having a team goal for the iteration allows the team to rally around a common theme. It also allows you to decide on features to work on during planning and more quickly build complete segments of the product. Instead of finishing very small pieces that do not add up to any real functionality, you get the team working on just a few small pieces, with everyone pitching in to complete those by the end of the iteration.

Motley: What are you suggesting? We pick a goal during iteration planning and all march toward it like ants?

Maven: Exactly. It also facilitates shielding the team from distractions as there are no problems turning away any requests that do not fit within the goal.

Motley: What makes an effective iteration goal?

Maven: A user scenario, or set of user scenarios can make effective iteration goals. Pick a couple of end-to-end scenarios that add real user value and deliver one or more features that satisfy those goals. If your team uses user stories (Ed: more on that in a future article), pick a couple from the top of your product backlog and deliver those.

Another common iteration goal is centered around bug fixing, particularly while you are in the integration phase on the glide path to shipping. A good way to specify a iteration goal is to commit the team to fixing a certain number of bugs by the end of the iteration. If we compute the number of hours (after load factor applied) available to the team of developers in the iteration and divide by the average of 5 hours per bug, we can commit to a certain number. Scale accordingly depending on how much time is being spent specifically on bug fixing. For example, if iteration planning tells us we have a team velocity of 400 team hours per iteration, and we spend 5 out of 8 hours in a day on real work we have 250 hours for the team. Given an average of 5 hours per bug, we commit to fixing 50 bugs in the iteration.

Motley: I thought doing a bug fixing "sprint" is not recommended???

Maven: Some teams do them, some don't, as we have discussed in the past. Using the formality of a Scrum sprint is not a necessity, but having a target number of bugs to fix in a certain duration pushes the team, allows you to track progress, and gives you a target to hit. Having a clear goal motivates the team to hit it versus saying "Ok, guys, go fix bugs."

Motley: Fair enough. We will put a goal in place for our next iteration based on our product backlog.

______________________________

Maven's Pointer: You may ask: "What if the backlog items, however, don't align to one particular goal?" I have rarely found that to be the case. My teams have had iteration goals that encompass 2-3 related user stories, and even had iterations focusing on engineering improvements. It typically is not difficult to find commonality. If you are struggling, ask yourself whether you are really building a small enough chunk of functionality that adds user value.

Maven's Resources:

None this time

Motley says: “Planning Poker? I bet my estimates are better than yours!”

2011-02-23T06:16:00Z

Summary

	Motley: Wideband Delphi is overkill for smaller tasks. I would never invite a bunch of people to an estimation session to estimate a 20 hour task.
	Maven: Planning Poker is a lighter variant of Wideband Delphi that provides similar benefits to Wideband Delphi but more efficiently.

______________________________

[Context: Maven and Motley are having a continuing conversation around estimation techniques]

Motley: As I was saying, Wideband Delphi (WBD) is definitely overkill for smaller tasks. I don't want to get a bunch of people in a room for an arranged meeting and go through an interactive exercise for a small 20-hour task!

Maven: I agree with you.

Motley: What?!? Seriously??

Maven: As shocking as that sounds, yes. One technique we can leverage for smaller tasks is Planning Poker. It follows the same basic recipe that WBD does, except that the process is more lightweight and meant for quicker estimation.

Motley: I get the same benefits as Wideband Delphi but it's more lightweight and quicker? Sold! Forget the WBD stuff - why didn't you tell me about Planning Poker sooner??? I'd love to put my card playing skills to the test!

Maven: Hold on! Don't jump to conclusions. WBD is the recommended technique early in a project where there are many unknowns and you are estimating larger tasks for the purposes of overall scheduling. Tracking the team decisions also allows you to go back and justify your initial estimates and refine specific pieces as you remove variability from the project. Still much value there. Use Planning Poker for smaller tasks with fewer unknowns.

Motley: Well quit beating around the bush - what's the technique already??!?

Maven: Ok, ok. Patience is not one of your virtues! Anyway, first you need to get some people together for the Planning Poker session. Usually in a session like this you'll have a set of work items that you want to estimate. Each person comes with a set of cards that are used for estimation. The content of those cards is some sequence of numbers in hours. A good sequence to use is 1, 2, 4, 8, 16, 32, and 64. My team usually throws in 48 as well. Other sequences I have seen used include 1, 2, 3, 5, 8, 13, 21, 34, and 55. Know what sequence that is?

Motley: I know, I know! It's the-

Maven: Ah, let's leave it to the others to tell us. [Ed: Let us know in a comment below]

Motley: So what's the point of the cards? Just because someone called it Planning Poker I bet!

Maven: The cards constrain the estimates to keep things moving. Here is the overall process:

The originator of the work item gives the group a very brief overview of the work involved. A sentence or two description is usually sufficient.
Take a small amount of time (30 seconds to 1 minute) to think over the assumptions that go into the task. No need to write them down - just keep them in your head.
Pull out the card that most accurately represents your estimate. Keep it upside down until everyone is ready.
Everyone shows their cards at the same time.
1. If the numbers are identical or very close, the group decides on the number and moves to the next task.
2. If the numbers differ, a discussion ensues focusing on the owners of the outlying estimates. Why are the estimates different? As with WBD, make some team decisions about assumptions. Do the process again with each person once again showing a card corresponding to their estimate and continue the process until the numbers converge.

Motley: Some differences I noticed: estimates are no longer anonymous, estimates are fixed, and we don't capture team assumptions in writing. In addition, just because everyone shows the same number does not mean they have the same assumptions about the task! This technique, although quicker, is flawed!

Maven: Estimates are not anonymous as the tasks are much smaller, so variance is not as large and participants can still go with their gut with little pressure. Yes, estimates are fixed as a guideline, but if half the group chooses 8 and half chooses 16, a compromise of 12 is certainly valid. We don't capture team assumptions in writing to keep things efficient, and because the tasks are such fine granularity anyway. Your last point is certainly valid, however. There is a risk that assumptions differ but numbers are the same. That's a risk our team is usually willing to take for efficiency, and because the penalty on small tasks like this is not large. Often we have a small conversation even if the numbers are the same to ensure we are on the same page.

Motley: Sounds pretty cool. I'd be willing to give it a shot in our next planning meeting. Since the technique has "Poker" in the name, I vote that everyone contributes $5 to a central pot and we track everyone's initial estimates. At the end of the iteration we see how many people were within 10% of the actual number and the one with the most accurate estimates wins the pot!

Maven: Ugh. Whatever suits your fancy, Mr. "My main value in life is money." Just promise me you won't start making "Royal Flush" jokes.

Motley: Well, there once was this king who ate Mexican food the night before and had some really bad gas the next day-

Maven: Enough! I'm going to, errrr, write some code. Remember to use WBD and Planning Poker as necessary. The collaborative technique will improve the accuracy of your estimates - money back guarantee!

______________________________

Maven's Pointer: Don't go crazy creating fancy cards. On the Xbox team, during every sprint planning session we use index cards with hand-written numbers on them. You can also use Post-It notes or whatever else is handy to create cards on-the-fly. Planning Poker is a great agile technique that you can use to estimate the work in your monthly or weekly iterations.

Maven's Resources:

Agile Estimating and Planning, by Mike Cohn, Prentice Hall PTR, ISBN: 0131479415, November 2005.
http://www.planningpoker.com - a free online tool that your team can use for a planning poker session. No need to create cards! Also great for a session among distributed teams.

Motley says: “Story points? Is that the new name for sports highlights?”

2010-11-01T03:15:00Z

Summary

	Motley: Story points provide no value over using plain units of time for estimates. Who would want to use an abstract unitless measurement for estimates anyway? Makes no sense.
	Maven: Story points are a unitless measure for the relative amount of work involved in completing a work item. Story points are an abstract concept that allows you to determine iteration velocity without being biased by time measurements.

______________________________

[Context: Motley has been asked to provide estimates for his team's work items using a new type of "unit" that he is not familiar. He is confused by the request, as he is used to providing estimates in units of time, like hours.]

Motley: With this new project coming up, I was asked by the management team to provide estimates in something called "story points". Is that a new name for sports highlights?

Maven: Presumably you have never used "story points" for estimates?

Motley: No. What ever happened to good old fashioned "hours"? The team wants to be agile, so they are using this new thing. From what I understand, it boils down to 1 story point = 1 day of work anyway.

Maven: If that's the case, then why bother with story points? You may as well just use "days" as the unit of your estimates.

Motley: Thanks, Mave! It's nice to have you agree with me for a change!

Maven: But let's get back to story points. What the team is mandating is a complete misuse of story points. The idea comes from agile software development and is used by teams that are often inaccurate with their estimates. A story point is a unitless measure that represents the amount of effort to implement a work item, which is typically used with the agile concept of a "user story". We can talk about "user stories" later.

Motley: I'll push your question back to you - why bother? Why not deal in something with units that is more concrete?

Maven: It helps get you out of the mind frame that estimates need to be in units of time. Other valid ways to estimate are by complexity, effort (the classical way) or size, how much risk or unknown project variance there is, or some other means that is pertinent to your team. By getting away from time, it allows you to quit thinking about buffers and time effort and instead combine other types of measures. Approaching estimates from different axes can yield more accurate results.

Motley: Weird. So if I say that a task is a "5", what the heck does that mean?

Maven: Perhaps the biggest problem with story points is getting started. Until you have some development iterations under your belt using story points, it's difficult to predict exactly how many points a task will take. The important thing to remember is that story points convey relative measurements and not absolute.

Motley: Relative vs. absolute - what are you talking about, Mave?

Maven: With hours, you give an estimate in absolute terms. The number is, for example, the number of ideal hours it will take to complete the work item. That is an absolute number that can be assigned mutually exclusive of all other work items. Of course, for scheduling you typically have to apply some "fudge factors" like accounting for distractions, such as meetings and working with other teams on unrelated tasks, which can get more complicated. In the end, you may come up with calendar time representing the length of the task.

Motley: But you digress - back to story points please.

Maven: Ah, yes. Story points are generally more relative. One technique is to list off the work items you want to achieve in a given iteration (say, 2 weeks). Then, using whatever metric you want, such as complexity, assign a number to each work item relative to the others. For example, if I have work items A, B, and C, and C is larger and more complex than A and B and as a result will take longer, then I might assign values of A=3, B=3, and C=8.

Motley: What good does that do? Those numbers are meaningless!

Maven: At the outset they may seem meaningless, but after a couple of iterations, you'll start to get an idea of how many story points worth of work you can accomplish in a given timeframe, and you'll get much better at predicting how much work you can get done, which is the point of all this estimation stuff in the first place.

Motley: Any guidance on what kinds of numbers should be used? Why did you pick 3's and 8's, for example?

Maven: The numbers are somewhat arbitrary, but if you fold in an estimation technique like Planning Poker, you end up with a series like 1, 2, 4, 8, … or the Fibonacci sequence like 1, 2, 3, 5, 8, 13, … You could also use general decimal numbers, but the estimates are rarely that granular. Using a sequence like this plays well with Planning Poker.

Motley: Still seems kind of ridiculous, but we could give it a go. How do we get started? How do we determine how many story points we can deliver in an iteration? I know - we could look at Marvin's team and see what they delivered and use that as our basis. I think they started using story points for estimates last iteration.

Maven: I would not recommend looking at Marvin's results. Story points are an arbitrary measure whose exact definition is up to the team. By being consistent with estimation within the team, you can get a consistent idea from iteration to iteration how much work you can deliver. Marvin's team, however, would have their own definition and just because they deliver 40 story point does not mean your team will. You may deliver 90, but still get the same amount of work done. The idea is to measure your team's velocity and get an idea of how much you can deliver per iteration given your story point definition.

Motley: Still not sure I like this. What really is the benefit over hours?

Maven: Story points get you to think more abstractly than just how many hours work items take. Remember: it is okay to use hours if you decide to do that in the end, but don't call them story points. They are different. You can use hours to compute a load factor and make your estimates better per our Scrum conversations and that is fine. Just pick a model and go with it.

Motley: Ok, we'll give it a shot. Sounds tough to get started but we can try it.

Maven: It IS tough to get started because you don't have a definition for the points yet. Just stack rank the work items and mark a fairly well-understood work item of mid-size/mid-complexity/mid-effort/etc. work item as something like 5, and then compare all other work items to that one assigning higher or lower.

______________________________

Maven's Pointer: Sometimes the abstraction of story points is just not worth the pain it will cause a team, particularly when they are just getting started with Scrum. Stick with hours in that case, but don't fool yourself in calling them story points with a direct mapping back to hours or days. That is even more abstract. If you do use hours, remember that no one is 100% on task every work day (e.g. in an 8 hour day, you will likely get 4-6 hours of on-task work done). Compute a load factor to create realistic calendar time. With story points this "buffer" is basically built in, with the assumption that you generally have similar distractions from iteration to iteration.

Maven's Resources:

Interesting article that recommends story points for the product backlog, but not for sprint work items: http://blog.mountaingoatsoftware.com/why-i-dont-use-story-points-for-sprint-planning

A debate on hours vs. story points: http://agile101.net/2009/08/24/sprint-planning-hours-or-story-points-that-is-the-question/

Motley says: “Kinect is where he’s at”

2010-06-15T05:41:00Z

Motley: Man, I have not seen that James guy around in months. I think he must have left us.

Maven: No, don’t give up hope. It’s true he hasn’t been too active here, but he’s got a side gig.

Motley: Side gig? Eavesdropping on us and reiterating our conversations to the world is not enough of a job for him?

Maven: From what I hear, he’s been working to change the world on something called “Project Natal”. Something to do with the Xbox.

Motley: Ah, I saw the announcement of that product today. It’s no longer called “Natal” but now called “Kinect”. That is some really cool technology! You stand up in front of a camera and interact with an Xbox using nothing but your body. Truly ground-breaking.

Maven: Cool! Can’t wait to play with that. When is it supposed to be out?

Motley: November 2010. Just in time for Santa to bring me one for Christmas.

Maven: Um, as long as you are a good boy, and that is always questionable.

Motley: Enough, wise guy. Anyway, I am sure he’ll be back when the pressure is off building that thing. It is some complicated machinery I am sure. Can’t wait to see him again so he can fill us in on all the details of Kinect.

James' Pointer: Yes, it’s true – I joined the Xbox team at Microsoft in November 2009, and that’s when things went a bit quiet around here. I just haven’t had the time for many tech extra curricular activities. I am hoping that will change in the next couple of months.

In the meantime, check out the truly awesome Kinect product that will be out for this holiday season. It is an add-on camera for your Xbox 360 that brings a groundbreaking natural user interface paradigm to our living room. Just get up and start moving.

Check out the USA Today for an overview of Kinect: http://www.usatoday.com/tech/gaming/2010-06-14-vidgame14_ST_N.htm
First impressions from GameSpot: http://e3.gamespot.com/story/6265559/gut-reactions-microsoft-e3-press-conference?tag=top_stories;story;1

Motley says: “To prepare for an interview, just make sure you can code on a whiteboard (Part 2)”

2009-10-30T05:29:00Z

Summary

[This entry is a follow-up to "To prepare for an interview, just make sure you can code on a whiteboard". A few of the important messages are repeated and clarifications are provided to make a complete package.]

Motley: I thought I could rely on natural coding ability for my interview. I was wrong.

Maven:

YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

______________________________

[Context: Motley, er… Mary, has just had an interview with another company and did not receive a job offer. He is discussing strategies with Maven around what went wrong.]

Motley: <bumps into Maven in the hallway with no apology>

Maven: Hey! What's up, Mot? You don't seem to be your normal bright and cheery self.

Motley: Ah, nothing. I, err… I mean Mary, just got some bad news. She interviewed at another company and did not get an offer. She thought the interview went well, and she is obviously brilliant and has a lot to offer to the company. She is confused why an offer was not made.

Maven: Hmmm… "Mary". Let's cut to the chase. YOU interviewed somewhere else, didn't you?

Motley: Shhhh… keep your voice down. Fine. Guilty. Yes, it was me. I am not serious about taking another job, but a friend of mine wanted me to visit the company he works for, and I thought it would be good interview practice. It was good practice, but it is a blow to the ego not to be successful since I know I am good. I guess I stink at being interviewed.

Maven: Well, if you have a few minutes, let's chat about the job search and interview process for a software developer. Firstly, you did the right thing by leveraging your people network in finding a position. That approach improves your odds of success, and can lead you to open positions that are not widely advertised.

Motley: Yeah, in this particular case I knew another developer at the company. He put me in touch with their HR person, and they were willing to create a position if things worked out.

Maven: Excellent! That is a great way to find opportunities. Next, I recommend you do a fair amount of due diligence to find out if the company is a good match prior to committing to interview. Interview them as much as possible. No sense wasting time in an interview if you feel like it is not a good match. Additionally, do an informational interview with the hiring manager. This session is typically one hour in duration and gives you a chance to ask questions, and the manager a chance to find out more about you. You may determine after this hour that the position is not worthy of follow-up, which saves your time and theirs. After the informational, talk to a few other people in the company across various roles if they allow it. Will you effectively collaborate with these people? Do they share your values? If the answers are yes and they invite you for an interview, go for it.

Motley: Since I already knew someone in the company, I really did not do much more research, but it is a good point.

Maven: Did you prepare for the interview?

Motley: I read the couple of books you pointed me to previously, but that's about all. Some questions did take me by surprise, such as where I see myself 3 years from now.

Maven: It is extremely important to prepare for an interview. Although you do not know exactly what questions they will ask you, you can hypothesize at the types of questions you will receive. For example, it is common practice in a developer interview to ask about your previous experience, pose a design problem, ask open-ended questions about your views, present a couple of whiteboard coding questions, and learn more about your personality. You should be prepared to answer these types of questions.

Motley: I focused more on coding, and practicing some different types of problems.

Maven: That's great! You need to go further, however. Know your strengths and weaknesses. Know where you are going with your career. Know something about the problem domain of the company. Know about the company itself. Know the org structure. Play with the product if possible. Come up with ways to improve the product and/or team given limited knowledge. Know the characteristics of a good UI design, if you are applying for that kind of position.

Motley: That is a lot to do to prepare for an interview! I don't have that kind of time!

Maven: You have time when you make time. These things are important to successfully securing a position, so make it a priority. Plus, don't just waste the effort - make notes. I use OneNote to track all my potential interview answers and over time build up a collection that I continually review and refine.

Motley: Is that "all" for preparation? <sarcasm>

Maven: You can always do more. Ask the people around you for the types of questions they like to ask in an interview - that will give you an idea of the kinds of problems you may be asked. Another important piece of preparation is to ensure you have good questions prepared for the interviewers. You are interested in the position, so show it by finding out more. Interviewers love thoughtful questions. Write them down so you do not forget them in the heat of the moment. Ask about company and product direction, team culture, and current challenges.

Motley: Wow - interview preparation is going to be a big investment!

Maven: Do you want the job or don't you? No need to answer. One other thing I like to do load up my favorite Internet search engine and type in the names of the people interviewing me (if known). I do a bit of background checking on them, which does two things: (a) gives me a clue on the types of questions they may ask; and (b) gives me some topics for chit-chat at the beginning of the interview.

Motley: We talked previously about that, and no, I didn't do it. In this case I did know who the interviewers were ahead of time, so talking about background would have been a great conversation starter. I should have done that.

Maven: Now, the interview itself. How did you handle it?

Motley: In a nutshell, I walked in, sat down, waited for them to start asking questions, jumped up to the whiteboard to solve the programming problems, and left.

Maven: I am obviously missing some details on what happened, but I'll try to build on your experience. First, grab yourself a cup of room temperature water for the interview (room temperature water is better for the vocal chords), as you will do lots of talking. Be on time or early. When greeted, use a firm hand shake, look the interviewer in the eye, and introduce yourself. Then I like to take a look around the office for items of interest (e.g. a picture of the family) or leverage some of my background info and start with some small talk.

Motley: Is there really any point to the idle chit-chat? Seems like a waste of time.

Maven: On the contrary. Some small talk sets the tone for the interview and can get both the interviewer and you smiling and in positive spirits. Remember that you never get a second chance to make a first impression. Use it wisely. It also helps you drive the beginning of the interview and ensure positivity is flowing.

Motley: Fine. So I get past the chit-chat and into the core questions. Any advice, Dr. Phil?

Maven: Oh, please don't call me that! Let's take a common scenario in an interview - you are asked a technical question. First thing that I like to do is practice active listening - repeat the problem back to the interviewer. This practice accomplishes a couple of things: (a) you ensure you understand the problem; and (b) it gives your brain more time to process your approach. Follow this with thinking of clarifying questions, and start writing your assumptions on the whiteboard. Whatever you do, always think out loud. The probability is very high that the interviewer does not necessarily care that you come up with a concrete correct answer. Instead, they generally want to see your thought process. Do you ask the right questions? Do you make the right assumptions? Do you stick with the first solution that comes to mind? Additionally, don't ramble - get to the point.

Motley: Repeat the problem, ask clarifying questions, write down assumptions, and think out loud. I cannot say I did all of those things in my interview, so something to work on.

Maven: Right. When solving the problem, there are a few strategies to help you think creatively:

Can you break assumptions on the input? For example, would preprocessing and having a sorted input make the solution easier?
Look at the problem in reverse. Does starting at the result and moving backwards help? Does processing the input in reverse order help?

Know your data structures. For example, perhaps a less-used data structure like a trie is the best suited to your problem.

Understand "Big O" notation. Many interviewers like to ask about the performance of your algorithm, and "Big O" notation is a standard descriptor.
If asked about a well known algorithm, state that you would look it up and refer to the write-up to code it. You may not get away with this, but give it is worth a shot.

If you get stuck, do not be afraid to ask for your help. You would do that on the job, wouldn't you?

Motley: Decent tips. Anything special about coding problems?

Maven: There are a few things special tips when doing coding problems. Important tips are to design the solution and drive the solution with tests:

Continue to think out loud - don't go dark. Remember, the interview wants to see how you think.

Avoid jumping into coding - think through the problem and do a design if necessary.
Solve the easy problem first. Do not prematurely optimize. Do not forget boundary conditions.

Start with an API signature for your function and clarify with the interviewer that it looks reasonable.

My personal preference is to drive the solution with tests, and take a Test-Driven Development approach. Start with the most basic inputs and generate the right output. Then create more tests and continue to refine.
Talk about your best coding practices, but do not necessarily do them on the whiteboard. For example, state that you would assert at a particular point, or that you would add a comment header to the function, or that you would normally catch a particular error condition (like out-of-memory).

Motley: Wow, there is a lot to it. I usually just jump right into coding and come up with an answer.

Maven: You can do that, but you miss the opportunity to prove your value in other ways. Interviewers want you to put thought into a problem, just as you would on the job. Other small tips include maintain eye contact as much as possible to show confidence, and avoid getting flustered - take deep breaths and think through the problem. Remember: you are not going to write your best code on the whiteboard - it is about how you think.

Motley: Okay, I've solved the problem and now I am done, right?

Maven: Uh, no. You need to finish up by concluding and following-up. Ask those questions you prepared in advance. Then thank the interviewer, and ask what the next step is. Also, after you leave I recommend immediately sending an e-mail to those on your interview loop thanking them for their time and stating that you enjoyed meeting everyone. They made a big investment our of their day in interviewing you - the least you could do is thank them. Be as polite as possible . If they turn you down for one position they may call you back later with another opportunity if they like you. And as a friend of mine, I.M. Wright says, "Don't be a jerk." Being nice can pay dividends later.

Motley: Wow, that is a lot of information for one basic interview. Now I have to try and leverage it.

Maven: You like math, right? Here is the formula for for interview success:

YourNetwork + DueDiligence + Preparation + SmallTalk + ClarifyingQuestions + ThinkOutLoud + ThinkCreatively + Design + DriveWithTests + ConcludeAndFollowUp = Job Offer!

You have to factor in natural talent and ability, but let us assume you have that covered.

Motley: Do you always have to put such a geeky spin on things? It gets old.

______________________________

James' Pointer: Having just gone through a set of interviews at Microsoft, I sat down and thought about some of the things that helped make me be successful at the interview loops. The formula above is what I came up with. Different things work for different people, but these are some techniques that I have tried and seem to have worked. I would be interested in hearing your formula, and best practices for being successful at interviews.

BTW, I am transitioning over to a new development role on the Xbox team, and am very excited with the new opportunity!

Maven's Resources:

None this time.

Motley says: "What's wrong with mixing Scrum and Waterfall? You get a nice 'Scrummerfall'!"

2009-08-25T17:45:00Z

Summary

	Motley: An effective modification to Scrum is to do a requirements sprint, followed by a design sprint, implementation sprint, test sprint, and stabilization sprint. It has the benefits of Scrum and has commonality with our older processes, which makes the developers happier.
	Maven: Scrummerfall, or mixing traditional Waterfall with Scrum, is less effective than Scrum itself. Deliver real business value with each sprint for early and frequent feedback, and improve collaboration amongst team members as no one is left blocking and waiting for others to finish their tasks.

______________________________

[Context: Motley and his team of able developers have been brainstorming ways to improve their Scrum process, and he is about to upset Maven with the details of his "improvements"]

Motley: Hey, Mave. Where have you been hiding lately? I haven't seen you around the office much.

Maven: Summer time is busy time. I had softball to play, a week of karate class with my sensei's sensei, and a couple of backpacking trips. I've been taking my vacation in small chunks.

Motley: I thought you were just slacking off, as usual.

Maven: Funny guy. This year I've had lots of small vacations instead of one big one. It really doesn't allow you to recharge enough, but I do like the variety.

Motley: Ok, enough about your relatively boring personal life. I'm thinking of making some changes to our Scrum process. With our next milestone fast approaching, the team really wants to transform Scrum into something more effective.

Maven: That's great! A key tenet of agile development is frequent introspection and continuous improvement. Glad to hear it.

Motley: Yeah. The team is thinking of having a requirements sprint, followed by a design sprint, followed by an implementation sprint, followed by a test sprint, followed by a stabilization sprint. Because the company wants to see these document deliverables as early on as possible, it might make more sense to get these done in sequence like this. The team also likes it because it is more similar to our old process.

Maven: I take it back - that's not so great.

Motley: What's the problem? The changes sound reasonable to me.

Maven: What you are proposing can be referred to (depending on the circle) as "Scrummerfall" or "WaterScrum". I'll call it "Scrummerfall", as I like that term better. In essence, you are proposing to combine two methodologies that typically do not work well together. With the proposal, you are basically doing Waterfall development, with more frequent check-ins (more akin to the way Waterfall was supposed to be, but typically is not). You lose the benefits of being an agile team.

Motley: How is it really different? We obviously still preserve the core of Scrum, including the daily stand-up meetings, planning, burndown chart, retrospectives, continuous improvements, and all the other pieces.

Maven: The proposed process is fraught with issues. In fact, you are no longer an agile team - you are back to waterfall, like it or not. Remember our previous chats on agile development? This process would break many of those principles. For example:

Scrummerfall abandons the idea of vertical slices, or delivering end-to-end functionality in short iterations of 2-4 weeks. Your deliverable at the end of a "sprint" in this model is a document, such as a requirements specification. Does that add real customer value that you can solicit meaningful feedback on? In my experience, it is hard for a user or fellow engineer to provide real valuable feedback on something that is not real (i.e. there is no working software, only a description of what that software will do).
Scrummerfall loses the benefits of the improved collaboration that Scrum provides. Sure, you can still have your daily stand-up meeting, but the feeling of marching toward a common goal is somewhat lost. What are the developers doing while the "Requirements Sprint" is happening? What is the test team doing while the "Design Sprint" is happening? Scrummerfall just doesn't work in a truly collaborative way vs. delivering real business value at the end of a sprint. Additionally, it forces you into doing too much up-front work with requirements and design, leading to overthinking the problem.
Scrummerfall violates the "working software over comprehensive documentation" piece of the agile manifesto. Don't get me wrong - documentation is necessary even with agile teams. Here, however, you tend to generate much more of it, which often falls into the waste (i.e. wasted effort) category, and we want to eliminate waste.
Scrummerfall makes change harder. If you get to implementation and test and realize something is amiss, you have a bunch of rework to do, including potentially large adjustments to design and documentation. Don't forget, with agile, we want to embrace change.

The team needs to deliver working software every sprint for early and often feedback. Yes, you can apply some of the practices of the Scrum methodology that contribute to team success, but Scrummerfall violates the fundamental principles of agile, which put you back in a Waterfall world.

Motley: But we still only need to plan for short iterations instead of long term crystal ball-like planning, which is a benefit and better than pure Waterfall.

Maven: Scrummerfall forces the team into a longer-term detailed planning phase because the end date of specific functionality in working software is important to the management team. You'll be predicting the future farther in advance for each feature instead of delivering features in just a few weeks. Of course, if you have a management team that wants crystal clear concrete delivery dates for all functionality up front, then you have less leeway here and have to do up front planning anyway to increase their confidence and minimize risk (even though that may be a fallacy anyway).

Motley: What about bugs? I don't want the team to be distracted with a bunch of bug fixes while we are doing feature development. We need that stabilization sprint at the end once everything is complete to fix all our bugs.

Maven: Don't forget - agile thinks about bugs differently. Instead of leaving bugs until the very end of the cycle, address them in the next sprint after a small end-to-end scenario is implemented. Bugs are a sign that the feature developed in the iteration is not done. Address the bugs as soon as possible, as they lead to increased technical debt (plus potential bug postponement, forgetting context of the bug, fixes growing more complicated, etc.) if they hang around. Avoid leaving them until a stabilization sprint at the very end. As we discussed previously, it is okay to have a quality sprint where you just focus on bugs as your iteration goal - it is more about when you fix the bugs.

Motley: Although I think the proposed process can work, I see some of your points. Small iterations of complete functionality, focused shorter-term planning, better collaboration and efficiency of team members, and less emphasis on documentation.

Maven: I actually agree with you - the proposed process can work. But, you are either an agile team or you are not. Mixing the two models can confuse people and actually make team effectiveness worse. With small chunks of deliverable software, you can get the test team private builds quickly to hammer on, and the test team does not fall behind as quickly. Because the team is marching to a common goal, the constant collaboration leads to priority adjustments and work breakdown to help others succeed (e.g. dev can build stubs and the test team can start to write test automation).

Motley: Ok, ok. I'll have a meeting with the team to discuss putting the brakes on this proposed change. They might be a little upset.

Maven: There is no one right way to build software. The idea here is to set the team up for greater success than it would have had otherwise. Other factors can get in the way of putting in your own completely customized process, but that is a topic for another day.

______________________________

Maven's Pointer: Brad Wilson, a blogger on the "Agile Programmer" site defines Scrummerfall as:

Scrummerfall. n. The practice of combining Scrum and Waterfall so as to ensure failure at a much faster rate than you had with Waterfall alone.

Interesting definition. His description of Scrummerfall is slightly different than above. It involves embedded Waterfall within each sprint in a one-two-one pattern - one week of design, two weeks of implementation, one week of test. Although, in my opinion, this situation is not nearly as bad as full requirements, design, implementation and test sprints, it is still somewhat outside the spirit of Scrum unless you parallelize the tasks and help each other succeed.

Maven's Resources:

Scrummerfall - Mixing Scrum with Traditional Software Methods, blog by Mitch Lacey, http://blogs.msdn.com/mitchl/archive/2006/08/18/706897.aspx

Motley says: "Where has James been hiding?"

2009-07-14T16:07:00Z

Motley: Where has that lazy piece of work, James, been hiding?

Maven: I was just wondering that myself. I have not seen him in a few weeks. Let me check his Facebook page - that should clue us in.

Motley: It figures that he would update Facebook before talking to us. What is this world coming to?

Maven: It is an electronic universe, Mot. Ah, yes, says here James went on vacation for a while and then did a Mission trip to New Orleans to help rebuild after Hurricane Katrina. Sounds like he has been too busy to talk to us! He's also got quite a few updates in Facebook around summer stuff that has taken him away from the computer and friends.

Motley: He's just lazy. That's what I think.

Maven: Give him a break. I'm sure he'll be back shortly. Hmmmm… here is an interesting update. He wrote an article for the Shaping Software (http://www.shapingsoftware.com) blog on Lessons Learned in Software (http://shapingsoftware.com/2009/07/06/lessons-in-software-from-james-waletzky/). Looks like it might be an interesting read. I bet he summarizes a few key points from interactions with us! I have to surf over and give it a read.

Motley: I've got better things to do, like clean my ears.

______________________________

James' Pointer: Sorry I haven't been around much lately. Life has been busy, as Maven eludes to. Between work and home life I haven't had much time to breathe. Check out the article above for some of my recent writing, on J.D. Meier's most excellent blog (http://www.shapingsoftware.com).

Stay tuned for more upcoming adventures with Maven and Motley.

Motley says: “Slow down to go fast? Do I look like a tortoise?”

2009-04-22T08:23:00Z

Summary

	Motley: There is no harm shortcutting a few steps of development to meet a deadline. Some up-front check-in steps just take too much time.
	Maven: Slow down to go fast. Obey check-in checklists or you will pay for it later in the development cycle. Pre-check-in tasks such as code reviews, unit testing, static analysis, and buddy builds of various flavors must not be avoided.

______________________________

[Context: The code check-in deadline is approaching. Motley has code that is in progress and he is hurrying to get his change in prior to the build snap]

Maven: Hey, Mot. How's it-

Motley: Quiet! I have to get this code checked-in by the end of the day to meet the deadline. I don't have time to chat and need to rush to get this code in.

Maven: Whoa - maybe we should chat. Please just give me a few minutes here - it won't affect anything in the bigger scheme of things. What do you mean you have to "rush"?

Motley: The daily build starts at 6pm and it's 5:35pm. I only have 25 minutes to get the code checked-in so I have to take a few shortcuts.

Maven: I cannot stand the word "shortcut". Care to clarify?

Motley: It doesn't really matter what you can and cannot stand. But since you asked, I am going to skip writing unit tests for this last class, I am going to forgo code review because my code is always perfect anyway, and I am going to skip running FxCop just this once.

Maven: Have you ever heard the phrase, "Pay me now, or pay me more later"? What you are doing is akin to racking up credit card debt. On the outside it looks like a $5000 purchase, but in the long run it is going to cost you a lot more in interest if you do not pay off the debt as soon as the bill comes due.

Motley: Oh, no. More Maven analogies. I can do without those. And by the way, Boyz II Men called - they want their shirt back.

Maven: Always insulting my clothes! This blue and pink sweater combo isn't that bad, is it? Anyway, taking shortcuts now when the code is cheap to fix pays off in the long run and leads to quicker ship cycles and shorter bug-fix cycles later in the development cycle.

Motley: How so? Bugs are bugs, I need to fix them anyway.

Maven: It's much cheaper to fix bugs now than later. Fixing them later usually involves someone else creating and maintaining bugs in a bug database, fixing them when the code is no longer in context and fresh in your memory, and the tendency to bolt-on fixes and shortcut fixes. Additionally, if the test team does not find an issue, the cost of fixing it post-release is large due to the overhead in working with the customer, the bug getting back to the product group, deploying the fix, the negative press, and other factors. If you find an issue that modifies the design later, you may have to change a lot of code possibly destabilizing the product.

Motley: Yeah, yeah - the cost of change curve. I know it.

Maven: Then you know that you shouldn't rush your development. Would you rather fix bugs later when they are more expensive or now when they are cheap without the overhead of a post-check-in bug? Leaving bugs until later forces long "stabilization" periods on the team, which, in my opinion, are evil and can be avoided by a diligent team.

It is well worth pushing back on the deadline to ensure that you can adhere to the following code check-in checklist:

Unit tests. We have talked about unit testing at length in other discussions. This is the number one quality-driven developer technique. You must have a set of unit tests in place that exercise all of your new code and you can check-in when all the tests pass. This items should be bolded on a checklist.
Code coverage. Hand-in-hand with unit testing is code coverage. Aim for 70%+ code coverage for all of your code. More important than the coverage number is the feedback you receive from the coverage tool regarding source lines that were missed in testing so that you can add new tests.
Debug and retail builds. A debug build is generally different than a retail build, particularly when you make use of debug-time primitives such as assertions. You need to build both flavors to ensure the build succeeds either way. Broken builds are not tolerable as they block the entire team. In fact, do a clean build (vs. incremental build) to be safe.
Static analysis. A static analysis tool like FxCop finds bugs for you. Per the cost of change discussion, why not fix them now instead of later when it is more expensive? Why risk security defects escaping your defenses and being released into the wild where hackers and customers will find them?
Reliability tools. Running a tool like AppVerifier is more relevant to C++ applications. Running this tool is a must prior to check-in as it will help identify heap corruptions, improper use of handles, and misuse of critical sections. Additionally, for native code it will point out memory leaks.
Warning level. Crank up the compiler to generate warnings at level 4 (or whatever is highest for your compiler) to ensure that you have addressed all possible compiler-identified issues. Get into the habit of perpetually building at the highest warning level. Get clean and stay clean.
Other tools. Run any other organization-wide tools such as a copyright header checker, XML documentation checker, or coding style checker (e.g. Source Analysis) prior to check-in. You don't want to be the grunt fixing a ton of these issues later. Trust me on this one.
Code reviews. All code should be at least peer-reviewed, with larger changes (e.g. new features) being put through a code inspection. Having at least one other pair of eyes look at your code is likely to find many issues before even the test team gets their hands on the code.
Change list description. Include complete descriptions for check-in change lists, including how you tested the code, why the change was made, how you built, possible regressions, and other risks.
Buddy build. To ensure you did not forget to add a file to your change list and to protect against other bad assumptions, package up your change and pass it to a buddy for her to build. Most source control systems allow you to package up a change list for distribution. If you have a continuous integration system that builds changes before check-in, this is less necessary.

Motley: You cannot possibly be serious! If I do all that now there is no way I would ever make the deadline, let alone make a check-in.

Maven: All of the above is necessary, particularly in a large, quality-focused organization. We want to exterminate bugs before they are even checked-in. The checklist above helps with that.

Motley: Can you say "Sloooooooooooooowwwwww"? I knew you could.

Maven: Get in touch with your inner tortoise. I heard that in a TED talk on Slowing Down in a World Built for Speed by Carl Honore. Going a little slower up front will save time in the overall development cycle, and I would claim that you ship sooner as a result. Of course, that was not the specific theme of the talk, but the lesson can be applied here. Also, be pragmatic. Perhaps you avoid a step or two for small bug fixes.

Motley: One thing I do not quite buy is the lack of long stabilization periods at the end of the development cycle. We still need to put all the pieces together!

Maven: Ultimately we want to avoid long stabilization cycles and instead be stable when you check-in. A tail of the development cycle needs to be dedicated to integration and overall acceptance test validation, but is not the same thing as "stabilization". We talked about this before in our discussion on developer testing.

Motley: So you are telling me that I need to pay my boss a visit as soon as possible to tell him that I am going to miss the deadline? He is going to kill me.

Maven: Well, seeing as you only have 5 minutes to the build snap-

Motley: <POW>. You deserved that shot in the nose for wasting all my time and missing the build snap!

Maven: Ouch! Okay, I deserved that. But seriously, your boss is a reasonable person and will understand. Firstly, you are communicating bad news as soon as possible (well, not really, but let's pretend), which all managers appreciate. Secondly, present it such that you are focused on quality and want to avoid taking shortcuts, and that you feel this course of action is best for the product. I will bet you lunch that he understands.

Motley: There are some days where I wish I stayed in bed...

______________________________

James' Pointer: The checklist items I mention above are from a real team in at Microsoft in Windows Mobile. Quality is our #1 value as a team. We want solid check-ins that adhere to the checklist to ensure we don't have a long tail of bugs later. Yes, it is a lot of work but ultimately saves time in the long run. Slow down. Don't rush. Nail the checklist on every check-in. You will thank yourself later. Okay, maybe not, but you should.

James' Double Pointer Indirection: A good developer knows how much work goes into each and every check-in and factors these things into their estimates. These things take time.

James' Triple Pointer Indirection: "Slow down to go fast" is real advice in car racing circles. Intuitively it does not make a lot of sense. However, if I go into the corner too fast I have to brake to avoid the wall and then take a lot of time and gas to come back up to speed exiting the corner. If I slow down on entry, roll through the corner and smoothly apply the accelerator on exit, I actually go faster even though I slowed down entering the corner.

Maven's Resources:

TED (http://www.ted.com): A great web site of some of the world's best speakers. There are talks on a multitude of topics. You are guaranteed to find something of interest.
AppVerifier (http://msdn.microsoft.com/en-us/library/ms220948.aspx): A mandatory tool for C++ developers on the Microsoft Windows platform.
Source Analysis (http://code.msdn.microsoft.com/sourceanalysis): A customizable tool that validates coding standards and is a good complement to FxCop.

Motley says: “"Vertical Slices"? Sounds like something you do to salami”

2009-03-27T16:41:00Z

Summary

	Motley: Build an application according to architectural layers, from the bottom-up.
	Maven: Build an application using vertical slices. Build just enough UI coupled with underlying layers such as an object and data model, to satisfy a user scenario. Deliver customer and business value at the end of every sprint to ensure feedback early and often.

[Context: Motley thought he was doing iterative development the right way, but his boss has been all over him for not delivering tangible results]

Motley: I'm telling you, I can't win! We have been doing iterative development with the Scrum agile development model and my boss is still screaming at me that he is not seeing anything tangible coming out of it. I keep telling him that it will take a few sprints for us to show real value.

Maven: Have you forgotten one of the key aspects of agile development? Working software sooner. Agile teams should concentrate on delivering customer and business value at the end of every sprint. Get something real into the customers' hands quickly so that they can provide feedback early and often.

Motley: It takes time to get something real! We have to do a bit of infrastructure work first, and then build on that.

Maven: Ah, have you heard of "vertical slices", my boy??

Motley: You call me "your boy" one more time, I'll turn your shirt inside out with you still in it. "Vertical Slices"? Sounds like something you do to salami. I'm not going to bother asking what you mean by this because I know you'll tell me anyway.

Maven: Correct, my- friend. Vertical slices help deliver customer and business value at the end of every development iteration. Instead of developing one large feature requiring multiple iterations to see results, we break the work into usable pieces. Take a typical, but simplified, architecture:

One approach to development would be to first build the data layer (the lowest level of infrastructure), then build the object model on top of it, and then finally end with the UI. This is pretty common practice.

Motley: What's wrong with that? I need the lowest levels to build the middle and upper tier. You HAVE to agree with that! And besides, I am delivering business and customer value if I build the data layer and deliver that piece of software in one iteration.

Maven: Does the customer really care that you have a "data layer"? I think not. There is nothing for the customer to tangibly see until you have built the UI in later iterations. Additionally, once the customer does see the UI a couple months later and they can provide feedback, you risk having to do a lot of rework in the infrastructure if the customer wants changes. Even a small UI change can render various APIs in lower layers useless.

Motley: But I still need a data layer (in this architecture) to build the entire application.

Maven: Yes, but chunk up the work. Avoid building from the ground up starting from data to object model to UI. Instead take a vertical slice of the overall architecture and deliver a user scenario (user story). You build "just enough" of the data layer, object model, and UI to satisfy the user scenario. You get real working software sooner upon which the user is capable of delivering feedback. The focus switches from delivering technology to delivering real user value.

Motley: Flaw. Should I say it louder? FLAW. Putting software together in a piecewise fashion is going to lead to a bunch of spaghetti without a real architecture. This will never work.

Maven: Don't be such a pessimist! Or is it a cynic? I can never keep those two words straight. Anyway, you still need to have a vision for the product architecture. This agile type of approach does not preclude planning the entire system. It says that you plan the architecture at a high-level (components, interactions) and then build it in vertical pieces that span all layers. I still want a holistic architecture plan in place to guide development across several iterations. I just don't go into tremendous detail around exactly what the specific component APIs will look like (for example).

Additionally, I avoid building a full horizontal layer that may contain a bunch of code that will not ever get used, or get thrown away, once I get feedback.

Motley: Well, I may have to take some shortcuts to implement scenario #1 and then redo some work in the first slice to implement scenario #2. I just wasted effort! As we all know, eliminating waste is a key agile principle.

Maven: Well, it's actually a lean-

Motley: Yeah, yeah - a lean principle. Don't nitpick and respond to my comment.

Maven: It is true that sometimes you may have to refactor some code in the first slice to start adding to it in the second slice. That's fine - you have good unit tests in place that make refactoring easier. You may also have rework based on user feedback. This is all fine in that the rework for one small iteration is typically far less than major changes that could be forced by late feedback. Additionally, developing in vertical slices does not preclude you from using proven design principles. Design to accommodate change so that making changes later is easier. Although you don't want to anticipate future changes in successive slices and build functionality that may never get used later, you want to make your design easy to change and extend.

Motley: So I build a small snippet of the UI and just enough infrastructure to make that UI go. I am going to be left with some incomplete functionality by the end of the sprint.

Maven: Yes, but that's okay. It is usually enough to get going with feedback and validate your overall direction and approach. The customer can much more easily grasp a demo of working software than pictures in documents. Give them something they can touch.

Motley: And from the engineering side, we have some fairly incomplete layers at the end of every sprint.

Maven: Yes, sort of. You have layers of minimal complexity that support only the core scenarios. This helps keep the design and code simple. Think of this as adhering to YAGNI, or "You Ain't Gonna Need It". The gist of that principle is that you avoid implementing stuff until you actually need it, and you never try to anticipate future change. You avoid wasting time creating that functionality, testing it, debugging it, supporting it, and you keep things simple. You build enough to support the scenario. Over time your layers emerge.

Motley: I guess that makes sense. We end up incrementally building the product over time with tangible functionality and integrating features piecewise. I would have to try it before being convinced.

Maven: Absolutely. It takes some practice to chunk up the work into vertical slices, but if you focus on user scenarios/user stories instead of building technology, you'll end up on the right side of the fence.

______________________________

Maven's Pointer: A good way to help yourself think in vertical slices is to formulate your product backlog in terms of user stories. The basic way to think of a user story is to phrase your product backlog item as "As a <user type>, I want to do <task> to accomplish <goal>". We'll talk about this more later.

Maven's Double Pointer Indirection: On my team at Microsoft, we try to break up work into vertical slices as much as possible. Take an address bar in a web browser. Instead of building the data providers that provide auto-suggest functionality and then tacking the UI on top of it, we try to build a basic UI with one suggestion (maybe even hard-coded) and then incrementally tack on from there. Okay - it doesn't always work out that way in terms of work chunks, but that's our goal.

Maven's Resources:

YAGNI, "You Ain't Gonna Need It" - http://en.wikipedia.org/wiki/You_Ain't_Gonna_Need_It
Iterative and Incremental Development (IID), by Robert Martin, http://www.objectmentor.com/resources/articles/IIDII.pdf

Motley says: “Branches are for trees, not source code”

2009-03-03T19:08:00Z

Summary

	Motley: Branches are too complicated. The last thing we need is a copy of the code that has to be maintained in two or more places!
	Maven: Branches are source code copies with a tie back to a mainline set of code that allow for easy integration between copy and original set (and vice versa). Branches bring a level of isolation from mainline as well as keep the quality of mainline (and the daily builds) high.

______________________________

[Context: The company has been having lots of trouble with build breaks in mainline of late. General quality of the product mid-way through the development cycle is lower than expected]

Motley: Somebody is going to get crazy glue stuck to their cup! The quality of our daily builds has been crap lately. Too many people checking in lousy code. Too may conflicts. Not enough time to get our mainline build stable and of high quality before the next check-in goes in. Something has to be done.

Maven: Crazy glue? Ouch. If some moron did that to me I would pay them back big time - when they least expect it. Anyway, I agree with you - having a daily build of poor quality slows down everyone. The key is to isolate all the feature teams from one another giving them freedom to check-in yet keep the main build high quality.

Motley: Thanks for stating the obvious, Mave. Your haircut sucks. Now I stated the obvious too.

Maven: I thought I fixed that crooked sideburn! Ugh. There is a good way to accomplish this isolation. If you have a good source control system (like we do) such as Perforce or CVS, you can leverage a branch.

Motley: Branches are for trees. What do they have to do with source code? Should I start working outside in the shade?

Maven: Think of a branch as a more-involved copy of a collection of source code.

Motley: Why would I want to make a copy? Copies are fraught with problems, such as keeping multiple copies synchronized. And to think, I was expecting a good idea from you. Although pigs don't fly quite yet.

Maven: The digs keep coming! A branch is more than a copy. When you branch a source tree, you still maintain the tie to the original source code. Think of it like the trunk that a tree branch is connected to. You can bring forward changes in mainline to your branch, and bring back changes in your branch to mainline relatively easily. You can even work on the same source files in both places and merge the changes together in either direction.

Motley: And how would I do that? Keep them tied together, I mean.

Maven: You bring code forward to your branch from mainline and back to mainline from your branch through an integration, or more specifically, a forward integration (FI) and reverse integration (RI) respectively. Here is an example of a tree structure I used in a previous role.

Mainline: The main source code depot where daily builds take place from

Feature Branches: As many of these as necessary to support isolated feature teams

Feature Sub-branches: Use only as necessary (e.g. a developer making major changes as part of a feature team)

Motley: That looks more complicated your morning routine! Do the benefits of a structure like that really outweigh the costs of doing all those integrations?

Maven: As the consultant always says, "it depends". For a small overall team where not too many people are checking in to mainline, perhaps the structure is too much overhead. However, for larger teams, branches bring a level of isolation allowing features teams the freedom to do what they need to get the job done. In addition, a central build team could maintain mainline and have a very high quality bar for check-ins to mainline. Teams are only allowed to reverse integrate into mainline when they meet that bar.

Motley: And what does that bar typically involve?

Maven: It depends on the team. For us, we may have a quality gate in place that mandates the following when an RI is done:

All changes must have been code reviewed
All changes must have been gone through a test pass
Test automation is in place for new features (if applicable)
New features have been stress and performance tested
No memory leaks have been detected by our tools
FxCop has been run and is violation-free on all changed code
Unit tests have been executed and pass at 100%

You can basically go as thorough as you like. As you move up the branch hierarchy, the criteria to check-in gets lighter and lighter so as not to slow down the team. RI operations get stricter and stricter as you get closer to mainline.

Motley: Should every team have its own branch?

Maven: Teams making changes to an isolated part of the code base with relatively few check-ins may not need a branch. Teams working on radical and risky changes or in common parts of the code base would likely benefit from a branch. Keep in mind, though, that the more levels of branching you have, the more overhead there is for integration operations. I recommend trying to stick to 1-2 levels of branching at most.

Motley: What about builds? We lose the advantage of having a central build team generate a daily build?

Maven: Yes, that can be true. Hopefully you can take their infrastructure on a couple of machines that your feature team owns and duplicate the build there so that you have your own daily build and verification going for your feature. For small features, this may not be necessary. For large features, it is a huge benefit as you nail down problems quicker. If a build break happens due to a bad check-in, you catch it long before you hit mainline. As a result, you block fewer people. Everyone wins!

Motley: Ok, Einstein. I have a you now. What if feature team A is working on some changes that feature team B needs to make further progress? You cannot go across branches. Hah!

Maven: You have several options:

Feature team A can pack up the changes and pass them to Feature team B. Most source control systems support packing up a change list for distribution.
You can do what's called a baseless merge. I don't recommend doing this as it loses your source history. Essentially you do an integration across branches but lose the tie to mainline. Yuck.
You can RI the changes of note to mainline with a test pass and then FI them up into Feature team B's branch. This doesn't work as well if the changes are in progress and not fully baked.

Motley: I can think of another problem - my work in my branch can get out-of-date with what is going on with other teams. That may cause problems later.

Maven: True. The onus is on the feature team to ensure it FIs on a regular basis to keep up. Additionally, teams should not "go dark" from mainline for too long. Regular RIs to mainline should be happening, say, at the end of each sprint. For feature teams practicing Scrum, the code at the end of each sprint should be of shippable quality and can be RId back to mainline.

Motley: Also, merging in conflicting changes could be a real pain!

Maven: Yes, but not if you have the right tools. A good merge tool automatically merges isolated changes in the same file (the majority case), and allows you to easily resolve conflicting changes.

Motley: You seem to have an answer for everything. Let me see if I understand this branching thing:

Branching helps keep mainline quality high
A feature teams considers a branch to isolate its changes
Branching provides more freedom for check-ins
Quality gates are more strict the closer your branch is to mainline
Branching ensures you don't lose ties to the original source code via integrations
A good tool makes integrations and merges relatively painless

Maven: Nice summary. Why don't you go approach our beloved development manager and propose that our team undertake a branching model?

Motley: I think I'll do just that.

______________________________

James' Pointer: I am always amazed at how little discussion there is around source code branching. Branches are an incredibly useful software tool employed all over Microsoft for the reasons discussed above. Branches are particularly useful when you are an agile team in a large waterfall-based organization. They give you that level of isolation needed to follow your own effective processes yet still merge your changes in with mainline on a regular basis. Our team would be much less efficient without branches.

Maven's Resources:

Wikipedia definition of branching: http://en.wikipedia.org/wiki/Branching_(software)
(Tool) Beyond Compare: http://www.scootersoftware.com/moreinfo.php
(Tool) Araxis Merge: http://www.araxis.com/merge/
(Paper) Streamed Lines: Branching Patterns for Parallel Software Development, by Appleton et al, 1998, http://www.hillside.net/plop/plop98/final_submissions/P37.pdf

This paper has many good branching tips embedded within it.

Maven and Motley have Faces!

2009-02-23T20:59:00Z

Thanks to the brilliant work of a coworker and friend, Fred Chao, Maven and Motley now have faces! You can see them in the title bar of the blog and in the about page. Thanks, Fred!

Motley:

Maven:

Motley says: "Tell it like it is, no matter how many bodies you leave behind"

2009-02-17T18:52:00Z

Summary

Motley: Tell like it is. We have a business to run and getting straight to the point is most efficient.

Maven: Interpersonal skills help you ascend the career ladder. Don't be a jerk. Some tips include avoid interruption, ask questions, use more "I" vs. "You" statements, understand the person you are speaking to, use the right tone, and be constructive with a focus on principles.

______________________________

[Context: Motley has been sitting at his desk working in silence all morning with a long look on his face]

Maven: Why are you so quiet today, Mot? Here it is noon and I haven't heard from you. Everything okay?

Motley: Mind your own business.

Maven: Ah, come on. Maybe I can help! I promise to keep our conversation confidential if it is something private.

Motley: Fine. I need someone to scream at. I got a stern talking to from my boss this morning about how I treated Marvin on the setup team. We were in a code review and he was doing some really stupid things, so I told it like it is and let him have it. He should have known better. I am not sorry I reamed him out.

Maven: Ouch. What did your boss say?

Motley: Not much, other than that he heard about the incident and didn't want it happening again. I don't think I would have done anything different, though. Marvin needed to be taught a lesson. Sloppy code is inexcusable.

Maven: Perhaps you didn't deliver the message in the right way.

Motley: Take off, Mave. It needed to be done.

Maven: Sounds like it was a good opportunity for teaching, but you don't want to leave bodies in your wake. Technical skills are very important for software developers, but don't overlook the importance of soft skills, particularly interpersonal skills. If the rest of the company doesn't want to work with you, I guarantee that you are destined for failure no matter how smart or technical you are.

Motley: When are you going to stop talking?

Maven: You just made my case for me. I just happen to be more tolerant of others than many other people are. Not everyone is going to be as forgiving, however.

Motley: So I see, based on my manager having a word with me this morning. What do you propose?

Maven: The number 1 tip I ever received from a previous (extraordinary) manager was "Don't be a jerk." This tip is pretty generic, but it sure does ring true. There are various behaviors associated with jerks-

Motley: Like making fun of that hideous shirt you are wearing?

Maven: Yes, that would be one. Interrupting people mid-sentence is another one. Let your teammates finish their thoughts before you interject. Sounds easy, but I worked at a previous company where this was a rampant problem. I have worked with many jerks in the past, and it stunts career growth. It is not always a fixable problem, but I have faith in you, Mot. You are smarter than the average bear - errr… I mean developer.

Motley: True. You just buttered me up, so I presume that is the opposite of being a jerk, yes?

Maven: Not if I was lying because I had another motive, but I digress. Are you interested in a few more tips that will help you graduate from "jerkdom"?

Motley: You little- I am. Yes, I am interesting in improving.

Maven: Very good. Here are a few good tips that I have learned throughout my career. Firstly, instead of making direct statements like "Marvin, there is a race condition in this code. Fix it.", ask a question like "Marvin, is there a race condition here?" Asking questions is far less confrontational, like we talked about in a previous discussion on code reviews. This technique is good to use in reviews, conversations with teammates, general e-mails and various other types of communication. Plus, you may not be correct in your statement and asking a question covers your own butt too.

Motley: Sounds like a reasonable tip. You mean I should ask questions instead of making direct statements?

Maven: Hehe. Way to throw that in that question. You even practiced active listening, or repeating back what you were told to help with understanding and absorption. Kudos, Mot! Another big tip I learned was to use more "I" statements instead of "You" statements. For example, which one would you rather hear:

Motley, you messed up there and forgot to check the incoming pointer for null.
Motley, I think the incoming pointer needs to be checked for null.

Motley: The second one of course. The first statement made it personal and accused me of making a mistake. The second one was less harsh and concentrated on sound coding principles instead of making it about my screw-up.

Maven: Exactly. You are a quick learner! Of course, I just complemented you, so "you" in that case is a good thing.

Motley: Spare me the compliments. Any more tips?

Maven: Using "we" statements also help pass credit and convey a team style of thinking. Another tip: remember a while back when we talked about interacting with other personality types? Understand the personality type of the person you are speaking to - the other person's motivations and trigger points. If you are dealing with a red personality type, then you can likely get straight to the point and not worry about feelings. With a green personality type, however, I encourage you to use some of the techniques we are talking about and apply them more strongly to this type of person.

Motley: But I don't always know the type of personality the other person possesses!

Maven: True, but understanding the color wheel will help you make a pretty good guess, particularly for the co-workers you work closest with. Using the right tone and body language can also help. If you take the advice I have given but apply it with a sarcastic tone, apathetic tone and/or body language that makes it look like you really don't care (e.g. waving off the other person), then you have undone all that you have worked for in the interaction. Maintain a positive tone whenever possible.

Motley: Hmmm… I guess I should avoid insulting your chin cleft under my breath then, right?

Maven: Yes, that would help. I have already heard quite a few of those insults, but I am sure that does not surprise you. As a quick summary, a best practice is to be constructive and focus on principles vs. personalizing the problem.

Motley: I guess I should also ask for feedback occasionally to ensure I am doing a good job with these new found best practices? How am I doing?

Maven: I have seen a quick improvement in the last few minutes. Let's see how you do over the next few weeks and we'll have another feedback session then. In the meantime, do not hesitate to ask your manager and your peers for feedback as well. Your boss seems to be tuned in to interpersonal issues, so I am sure she will notice your forward progress.

Motley: Thanks, Mave! It was a pleasure speaking with you today.

Maven: Um, remember what I said about body language? Your sincerity was in the toilet with that statement. You will do better though...

______________________________

Maven's Pointer: Although this topic is not specifically a "software developer" technical topic, it is important nonetheless. I have seen people drive their careers into the ground due to their lack of interpersonal skills. These skills are almost as important as technical skills in most companies. I say "almost" because you are not going to hire a software developer just because he is a nice guy. Training in the technical field and knowledge of your company's chosen programming language are obviously important. A jerk, however, is not going to move up the career ladder nearly as fast as someone that the rest of the team loves to work with, and is more likely to lose his job.

Maven's Resources:

None this time.

Motley says: "To be a lead developer, all you need is technological know-how"

2009-01-30T18:57:00Z

Summary

Motley: To be a lead developer, technical skills are absolutely the most important. Everything else is secondary, tertiary, and whatever word comes next.

Maven: A lead developer must lead from several different perspectives, including people, process, and technology. To properly balance technology and people, build a great team, learn to delegate, and break up your responsibilities.

______________________________

[Context: Maven and Motley are hanging out at lunch debating on what it takes to be a good lead developer]

Motley: No, no, no - you're wrong. The absolute most important skill that a lead developer possesses is technical skills. Everything else is far down the priority list. If I cannot make technical decisions then I am worthless.

Maven: Well, I partially agree-

Motley: You can't agree! You just said technical skills were not most important!

Maven: Let me finish, please. Remember to practice "seek first to understand, then to be understood" instead of "listening to respond", but I digress.

Motley: Blah, blah, blah. Get on with it.

Maven: The phrase "lead developer" means different things to different people. If you are leading a small team of 3-4 developers, then I agree with you, a lead can focus more on the technical aspects of the job, although not completely at the expense of some other areas. However, if you lead a team of 10 developers, that typically does not leave much time for technical stuff and you will spend more time managing people. Note that I am using the term "lead" and "manager" here together - my definition of a "lead developer" assumes that you have direct reports in the organizational structure, and thus, have management duties.

Motley: I can see job responsibilities varying by size of team, but I still think technical stuff is the most important. The phrase "lead developer" still has the term "developer" in it after all.

Maven: True, and you are still expected to be solid technically, but there are other aspects to development, as you know. A lead developer must lead from several different perspectives, including people, process, and, of course, technology. You are a key decision maker in your role and you represent the business, but not at the expense of the people. People issues often have to come first. You are the one expected to grow their careers after all.

Motley: I admit I have other responsibilities than technology. But my team of 10 people is doing pretty well. I don't have to focus on managing a whole lot. I can concentrate on writing code.

Maven: Who mentors your people? Who grows their careers? Who manages the dependencies of your team? Can you possibly attend all technical meetings? Who handles recruiting new people? Who attends upper management meetings? Who reviews all the designs? Who triages the bugs? Perhaps you could do all of that, but you would work a very long day and probably a do a half-ass job at everything.

Motley: I just find that a lot of that stuff takes care of itself. My boss, however, has been screaming at me a bit more lately, I must admit. But I just love the technical stuff and would rather spend time on that!

Maven: Loving technology is great, but you have to balance your tasks on technology lead vs. management. You have a job to do that involves both axes of leading and management. If you don't enjoy both pieces, then why are you a lead? Companies these days have growth paths for individual contributor developers so as not to force them into management.

Motley: I do like the other stuff, but I like the technical stuff more.

Maven: That's fine. You just have to balance technology and people. In order to do that, there are a few keys:

Delegate: You cannot do everything. Delegate tasks when necessary and fully trust the person you are delegating to. Additionally, do not just delegate the work associated with the task - you should delegate ownership of that task. Make the person completely accountable for finishing it.
Build a great team: Surround yourself with highly diversified good people. As a lead with a reasonable-sized team, you likely need to give up some of the technical stuff. To compensate, ensure you have one or two senior technical gurus on your team to delegate decisions to.
Break up your responsibilities. Perhaps ask for another lead at your level of the organization so that you can have a smaller team allowing you to focus on technology more.

Motley: Not bad, Mave. Good suggestions overall. Perhaps what I can do is concentrate on making the key decisions, focus more on design, and give myself some smaller development tasks that are off the critical path of the project to keep my skills fresh.

Maven: Now you're talking! That will free up some of your time for managing careers in addition to the product, mentoring, reviewing the work of the team, refining and enhancing team processes, managing relationships between your team and other teams in the company, and overall making the team a well oiled machine. Of course, we have been mostly talking about management here and less about leading. We should follow up this conversations one of these days and expand on that. We could also talk a lot more about being a good manager.

Motley: I will be a better dev lead tomorrow. Glad I came up with some refinements to my working style.

Maven: Do you think I had something to do with your refinements in this conversation?

Motley: Not a chance.

Maven: Figures.

______________________________

Maven's Pointer: As a lead developer at Microsoft, I spend far less time in the source code than I have in the past. Let me clarify - I am in the source code quite a bit, just not contributing new code. Instead, I have chosen to focus more on design issues and code reviews when I find the time. However, if I had far fewer than 10 reports, that would allow me to be closer to the code and even be a contributing developer, although not at the expense of the people I need to help grow. Different people have differing opinions on exactly what the role of a lead developer is, and truthfully, it really depends on the specific situation. However, most "leads" are also managers, and caring about your people and removing distractions from their everyday work is a high priority. Let me know if you want to discuss leading and managing more, in the context of developers of course.

Maven's Resources:

Managing Humans: Biting and Humorous Tales of a Software Engineering Manager, by Michael Lopp, Apress, ISBN: 159059844X, June 2007.
Hard Code: Lead, Follow, or Get out of the Way, by I.M. Wright (a.k.a Eric Brechner), http://blogs.msdn.com/eric_brechner/archive/2007/12/01/lead-follow-or-get-out-of-the-way.aspx

Point for Maven - Wideband Delphi Estimation works!

2009-01-06T18:54:00Z

Summary

Motley: I admit it - Wideband Delphi works! It helped us generate fairly accurate estimates for longer-term planning and the documentation of our assumptions kept everyone on the same page and provided rationale for our numbers.

Maven: Um, what Motley said.

______________________________

[Context: For the past few months, Motley and his team have been using the Wideband Delphi process for their estimates. Over the winter holidays, Motley got curious about the effectiveness of the technique]

Maven: Hey, Mot. Happy New Year, and welcome back to the office! Did you have a good holiday season?

Motley: Yeah, it was a good break. Although most of the time was spent with family and friends, I did do a bit of an analysis of some previous estimation data.

Maven: You have me curious - what's up?

Motley: A few months ago you gave the team some pretty good advice, I must admit. We used Wideband Delphi Estimation as you talked about before to estimate some key features for the product. The team used Scrum and gathered a bunch of data on how long it actually took us to implement the features, and I thought I would show it to you.

Maven: Sweet! Glad you were able to put it to use and see some positive results. Don't keep me in suspense!

Motley: Hold your horses, Mr. Impatient. First, a bit of background. This feature team was responsible for developing a feature with a bunch of subcomponents. We used Wideband Delphi to estimate all of the subcomponents early on in the project when we really did not know a whole lot about what we were estimating. Wideband Delphi was perfect for this exercise due to the large amount of project variability at the beginning.

Maven: How many people were involved with the feature team?

Motley: There was one program manager (PM), two developers, and two testers for the majority of the project to this point. That's not relevant for this analysis, however, as all work was estimated for one developer and computed the hours across all developers.

Maven: Makes sense. Any more background?

Motley: Yeah. One thing I would recommend to everyone is to have whoever is responsible for the initial high-level requirements put together a short 2-3 page document that describes the feature at a basic level, including some mock screenshots if necessary. It doesn't have to be highly detailed but should provide a high-level idea of what we will be building. Think of user stories, but to a slightly lower level of detail (but not much). Then distribute the doc to everyone involved in the estimation session to prepare. Have the author of the short document give an overview just prior to following the Wideband Delphi process to set context.

Maven: Great suggestion. Who did you invite to the session?

Motley: We invited the PM, the two developers, one tester and one senior developer from another team. One thing that worked really well was having that expert external to the feature team to help bring another perspective.

Maven: Okay - let's see the data already!

Motley: Hmmm… maybe I should make you wait a little longer. I love seeing you squirm.

Maven: You really are a mean person.

Motley: Just the way I like it! Fine. Fine. Here are a couple of graphs of the data I gathered:

Maven: Not bad data, Mot! Looks like many of your estimates were fairly close to the actual work on inspection. How do you explain the estimate for feature 6, which was quite far off?

Motley: That's easy - what we thought we were going to build at the beginning of the iteration actually turned out to be quite different. We did the estimate fairly early in the project and made some key assumptions, but later we discovered a couple of those assumptions were not valid. As a result, when we planned the iteration, we revisited our assumptions and realized we had more work than we thought we did. Don't forget - I am comparing our original estimates at the start of the project to our actual numbers. Secondarily, a dependency that we relied upon for that feature was late on their deliverable, so we did a bit of extra work to mitigate that.

Maven: Sounds reasonable. What about intuition - do you feel that Wideband Delphi gave you increased accuracy in your estimates.

Motley: Overall, gut feel is that Wideband Delphi gave us greater accuracy than we would have gotten had we left the estimate up to one developer. Everyone was happy with the process and has committed to keep using it.

Maven: As we talked about in the past, Wideband Delphi helps the team get on the same page at the start of the project. Did you observe that?

Motley: Wideband Delphi really helped us get on the same page with assumptions and come up with an initial direction people were happy with. Even though some of our assumptions changed later in the project, for long-term planning purposes at the start of the project, the data was accurate enough for the release management team to make reasonable predictions.

Maven: So you would use Wideband Delphi again?

Motley: Absolutely. You hit a home run with that one, Mave.

______________________________

Maven's Pointer: Our team at Microsoft uses Wideband Delphi consistently for early-project planning. When the management team forces us to come up with estimates that help define the milestone plan for the next 3 months, we use Wideband Delphi to generate not only fairly accurate numbers but also document the rationale behind the numbers. Even though detailed planning and scheduling for the next 3-6 months is fraught with peril - a realization agile teams come to - to be an agile team in a waterfall organization you must periodically give in to the will of the release management team.

Maven's Resources:

Agile Estimating and Planning, by Mike Cohn, Prentice Hall PTR, ISBN: 0131479415, November 2005.

Happy New Year from Maven and Motley!

2009-01-04T20:57:00Z

Hello all,

Happy New Year! Hope you had an enjoyable and restful holiday season with your friends and family.

Maven and Motley are back from their extended hibernation. I was out of town for the majority of November and a good chunk of December, so that left little time for spying and reporting on the antics of these two characters. 2009 should bring them back to life.

With other projects on-the-go and my day job being busy, I likely won't keep up a regular publishing schedule with the blog, and will instead just post as I write articles. Publication frequency will likely be lower than previously, but we'll see what happens.

In the meantime, if you get a chance, drop me a line via the comments (to start) and let me know:

Your development goals for 2009. I am curious to know how my fellow software engineers are moving their careers forward. Perhaps I may be able to help or suggest a place to look for info.
A hot topic that you have been debating with someone. Perhaps we turn it into a Progressive Development blog post!
Any other suggested topics you may have

Thanks, and all the best in 2009!

James.

Maven and Motley on hiatus through November

2008-10-18T03:07:00Z

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.

Motley says: "ALL developers are the same - introverted and logical. No exceptions."

2008-10-15T16:49:00Z

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:

Insights Discovery training (red/green/yellow/blue personality type), http://www.insights.com/LearningSolutions/LearningSystems/Discovery.aspx
Myers-Briggs, http://www.myersbriggs.org/

Motley says: "Developing international software is really, really hard. We need a brand new version."

2008-09-16T18:11:00Z

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

Motley says: "I must conform to the wishes of the management team, even if they are wrong"

2008-09-03T07:10:00Z

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-

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

http://www.sayleadershipcoaching.com/talkingstory/2008/06/get-permission.html

Motley says: "More test automation is always better"

2008-08-19T18:01:00Z

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 says: "James is slacking off, yet again"

2008-08-05T18:11:00Z

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!

Motley says: "Use Scrum in my personal relationships?!? Don't be such a geek."

2008-07-22T17:59:00Z

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!

Motley says: "Features sell a product. When in doubt, add more features!"

2008-07-08T16:55:00Z

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:

http://www.isixsigma.com/library/content/c030630a.asp
http://learnsigma.com/kano-model/
George et. al, The Lean Six Sigma Pocket Toolbook: A Quick Reference Guide to 100 Tools for Improving Quality and Speed, McGraw-Hill, ISBN: 0071441190, August 2004.

Motley says: "Milestones are useless for agile development"

2008-06-24T17:55:00Z

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 teams are doing agile as well so they likely have the same questions as we do. For the others not doing agile, well, they need to wise up and get with the program.

Maven: It's not so easy to change a company, as we discussed in previous conversations on change management. At some point you need to bring all the feature teams together and make sure everyone is synchronized. That's one of the primary purposes of a milestone. It is a checkpoint that all teams have in common with a set of exit criteria. A milestone brings everyone together to ensure all teams can integrate their features and come together to create a product. Milestones may not be technically necessary if there is one small team developing a release. You can ship at the end of every iteration, at least in theory. However, when many teams are involved in creating a large product, you need to periodically bring everyone together.

Motley: Milestones just seem too process-heavy. Why not just sync-up on an as-needed basis?

Maven: Don't forget - milestones also have use to people outside the company.

Motley: Why should anyone outside our development group care about our internal milestones? Perhaps your girlfriend needs to know so she can expect you to work some overtime around the end of a milestone, but other than that, I can't think of any reason.

Maven: With any significantly-sized product, Cynthesis typically ships technical previews, does integrated product demos for customers, and ships beta releases. Typically these interim releases prior to ship align with milestones to ensure product quality is high. Because each small feature team may have their own iteration schedule with their sprints, the milestones provide that date where sprints can align.

Motley: Fine. I can accept all that. It still seems process heavy though. You mentioned the phrase "exit criteria". That phrase has "formal process" stamped all over it. Pepto Bismol is my exit criteria after eating bad seafood.

Maven: Ah, dude, that really wasn't necessary.

Motley: I know, but potty humor is always fun anyway <laugh>.

Maven: Back to business. Yes, "exit criteria" is one of the more formal-sounding software engineering phrases, but it does have use. At the end of any given milestone there is typically a checklist of quality criteria that each team and the overall product has to satisfy before the milestone is considered done. Think of it as a team-wide definition of that ever-so-important definition of "done".

Motley: Ah, so it's a fancy phrase meaning that once we put all the pieces together that they all work well together. That would include overall performance, end-to-end integrated scenario testing, stress testing over time, lack of cross-product memory leaks, general usability and consistency across features, consistency of documentation, how it works with the rest of the system, and other general product health issues.

Maven: Exactly! We put all the pieces of the puzzle together and hopefully it produces a beautiful picture. Without that checkpoint you could ship a product with puzzle pieces that don't match creating a jumbled mess.

Motley: I see. Makes sense. One thing that I would encourage the project managers to do, however, is not make those exit criteria too strict and that we focus on the right things.

Maven: That's a very astute observation, Mot. I worked in one company where the exit criteria list was pages and pages long. After about the first third in priority order, the rest just created needless overhead and diminishing returns. It felt like the project managers were micromanaging the feature teams. Instead of speeding up the development process, it slowed everybody down, in my opinion.

Motley: Ouch. I guess we should consider ourselves lucky here at Cynthesis. I can put up with a reasonable list of exit criteria, but you don't want to know what I do when someone tries to micromanage me.

Maven: Imagine nag nails for every little thing like high priority bugs you haven't updated in the bug database for a few hours, or nag mails because the project manager thinks you haven't triaged your bugs but your process is different than other teams, or people screaming at you because bugs are not assigned to a specific individual person and are instead on a bug backlog. I'll stop ranting now, but just know that these things can be a reality even in great software companies.

Motley: Enough! Enough already! You are going to make me start pulling my hair out just thinking about it, and I really don't have that much hair to begin with.

I understand the need for milestones. From my perspective of being on an agile team, we keep going as usual, make sure we integrate on a regular basis, be strict about our meaning of "done" for tasks, fold the exit criteria for milestones into our everyday development and guess what? Our team won't struggle through trying to meet exit criteria in the high pressure closing of a milestone. Smooth sailing.

Maven: That's the spirit. Your team is going to rock.

______________________________

Maven's Pointer: Learn the intricate details of the milestones in your company. At Microsoft, practically every team has a "code complete" milestone. Most developers take that milestone for granted. However, the definition of "code complete" is different on every team. Do all features need to be done? Are to-do's allowed in the code? Do you need to run static analysis prior to code complete? Is some measure of API documentation required by the milestone exit? Learn what "code complete" and the other milestones mean on your team and address the exit criteria early.

Maven's Double Pointer Indirection: Avoid cheating on the exit criteria when the end of a milestone draws near and the project manager does not want to change the date. You are only cheating yourself. Do your best to meet the exit criteria and maintain high product quality even in early milestones. Revisit the exit criteria for future milestones if the exit definition is too strict.

Maven's Resources:

None this time