Instead of making judgments for people, I think you come out ahead if you state the benefits and drawbacks of whatever current approach is being practiced, and also the benefits and drawbacks of an Agile approach you are suggesting. This works best from the bottom up, because you need to be able to have developers realize benefits greater than their current approach in order to realize business savings that you can then promote up the chain.

For example: say a business uses a waterfall approach (3 month releases with a 2–3 week up front design.. I find this to be typical). There are several ways that if you are critical of your current process you can gently migrate to an ever more effective one. Even if the end result (where the team decides to stop changing the process) does not look like Scrum, or XP, but is better than where the team started, isn’t this preferable to proposing sweeping changes promising the moon and stars and getting shot down? Here are some areas to look for improvement:

• introduce automated testing
• introduce a build server that runs those automated tests
• propose leaving design tasks for another day to take some time to prove out design discussions and ideas
• introduce code reviews that are pinpointed on topics everyone can agree on that are critical to code health. These will differ from team to team but might include design principle violations, formatting, framework contenders, etc.
• start a refactoring list, prioritize, and evaluate after the release to see if anything on the list would make the next set of features coming down the pipe easier to implement
• keep focus on YAGNI
• invite people to look over your shoulder (pair programming… but don’t call it that… instead say you could use a second set of eyes)
• shorten your cycle by a week, or advocate splitting a release into two releases
• suggest to remove artifacts that you create, that are never used after they are created
• be critical of meetings you are sent to. If you can’t get out of the meeting, suggest that only you go and take notes for others.
• promote unit tests that test units (this works best if code abides by design principles), and code that can be unit tested. This will help your design be more decoupled.

The alleged benefits of doing nothing is that you will continue to doing what it is you are doing, and whatever results you are getting now out of your process will continue. Many people consider known issues (over budget, late release, or 60 hour weeks to make a release) to be better than unknown issues. Try to understand why people feel this way and empathize with them.

The alleged benefits of any agile approach are:

• the smaller your feedback cycle the more feedback you will get
• what you create is able to adapt more easily, because its had to due to the increased feedback
• you have less things that you really don’t need, since what you focus on is feedback driven with less guesswork
• because you create less waste, and are able to change more easily, you incur less risk

Note that these benefits are not code specific. When you apply these benefits to code you arrive at tangible development benefits such as:

• the more often your code releases to version control the sooner you find out if you broke something, and the better you will remember what it was that might be the culprit, saving time and money
• the more often you test code you wrote the sooner you find out when someone else changed something that affects you, allowing you to react to it sooner, saving time and money

The degree to which you realize the above benefits is a factor of your team’s ability to embrace change on all levels. But if you force them to bend all at once, or too quickly, there is a good chance you will break something. Never put your live frog in boiling water; its best to turn up the heat slowly.

• The design in software development is the source code
• Building Bridges
• Software Design

One of the key enablers for being able to gather metrics is its repeatability. Other Benefits of agile: much less time spent on requirements (traditionally up front, and throughout, vs just a little up front and more throughout). Developers spend more time coding, because they are not in endless requirement meetings up front. Vet architectural decisions early in the process. If you create your standard diagram describing the system, you are not going to prove out that system until implementation time, which comes much later. In agile you are proving out the architecture and its maintainability in every iteration.

While its a bad idea you ask people how long is it going to take to do this, you can ask them how complicated a task is relative to a task that they did previously. Business Analysts can put together user stories that place the focus on the user, rather than the system. The developers then consume these stories (which have much less detail than a use case), and then the developers decide on a high-level architecture (stuff that is hard to change later: what language you are using), and then sit down with the business analyst and rate the story cards on a complexity scale. Its either a 2,4,8,16. I’m asking how complicated stories are in relation to one another. You are not trying to slice things by hours or days. The project manager takes this list of numbers and multiplies them by a load factor (size of project, how many meetings you have) with the assumption that its going to be wrong, because we are going to change it as it goes along. Realize that you are going to get your first data point in two weeks, so that after several months you can hone the load factor number to the point where you will be fairly accurate as you go along. Q: the story doesn’t have enough details though A: Its good enough, and I’m not trying to get an exact estimate. Q: but what about technical requirements that influence the story? A: well you can have technical stories because because these are going to make things more complicated, and so they should be factored in.

The load factor is the magic part of all of this, and it may be wrong, this is a skill that the project manager needs to gain over time. Not only are you throwing the dart on the wall, but you are going to tweak it as soon as it makes sense to do so. There is magic in all estimation processes, and most people are asking each developer to apply their own magic. Its a better idea to have one person apply the magic and get better on this, so at least the error is spread evenly. Too keep from poisoning the well they use rock paper scissors at thought works to throw out their estimate, so that people are not influenced by others. YAGNI: you are not going to need it. Try to only do things that are needed to complete the story. It is better to keep related things that you swear you are going to need, on the back burner for when you are going to implement it. Chances are good that what you write now will need to be heavily modified when it comes to it later.

Agile is actually disciplined because it is driven by story cards. The cards have the domain defined completion criteria. You must have Specific completion criteria that reside in the domain, and it must be a hundred percent done to be done. Until its a hundred percent done its zero percent done.

Metrics: most of the metrics books are outdated. The way we write software now changes abruptly: we are writing more complicated things. Problems have gotten harder, although tools and languages have gotten better. Most text book metrics focus on thousand lines of code and other meaningless metrics. For example how do you measure productivity if someone finds something better that removes 20,000 lines of code? You need to validate your measurements continually. Otherwise you are measuring apples and oranges. Agile gives us consistent repeatable steps.

Testing is the best metric you can have. One thing you hear people talk about is trying to compare software to bridge building. The design is not nearly complete enough to be the design. The design in software development is the source code, and the building is pressing the compile button. Our manufacturing process is really cheap. If bridge builders could build little pieces of bridge and test them as they went along it would be a lot easier to build bridges. So over time they use civil engineering to vet their design. The engineering rigor towards software building is testing. Why bother with all of the plans when you can manufacture things so cheaply and just run it to see if it works. The guy who was the heaviest critic of the man who designed concrete reinforced bridges built the tacoma bridge that collapsed. The concrete bridges were proved to be better through testing, mathematics of the day ended up failing: they claimed that the concrete bridges would not hold up, and that the tacoma bridge would. Glenn Vanderburg has a blog entry devoted to this, in fact, Neal borrowed the bridge example from him. Both link to a facinating article written in 1992 on the topic of whether or not Software Design is Engineering, written by Jack W. Reeves.

Microsoft Project is the most abused piece of software ever. People usually create the gant chart and show the completion date. Then the manager says no I need it done sooner, and then they hack together a shorter timeline. We are wishy washy on completion: we make up percentage numbers as we go. And most managers as a result believe that we failed mathematics. Binary completion criteria for all tasks is the key factor of being able to do metrics. This gives you the ability to say to a manager we are 62.3 percent done. This also gives you the ability to say to people who are changing the scope: here is our list of things we are doing, what would you like to remove so that we can do this new thing. You also want tasks that are as atomic as possible. Things that take 5 days are not so good, things that take 2 hours or a day are great, things that take 8 days need to be split up.

Project managers at thoughtworks use spreadsheets and not Project. There was some discussion as to wether or not share Sparky’s spreadsheet. They decided that they would allow you to download Sparky’s spreadsheet, but to remove the formulas. The spreadsheet is the result of many many projects that Sparky has worked on. The first page is the high level overview for managers. The first box is the sanity check question: “Do you have enough development capacity remaining to complete the remaining Priority A cards. “Number of cards through narrative” means that the BA’s have filled in details and have determined what the completion criteria are.

The binary completion gives you a concept of done that does not have the fuzziness of I’m % so far done. Q: who manages this A: the project manager does this. The PM has 3 jobs: 1. keep client and business people out of the way of the developers 2. keep good snacks 3. keep everything going and on track and measure progress, move impediments letting people do their development work instead of emails, meetings, and tech support. Q: how do you handle bugs A: the failed tests get high priority cards for the next iteration.

Code coverage tells you not that things are correct, but rather that your code has been touched. You want to try to not have the users be the first people that are touching the code. You can download slides and examples from Neal’s site, which includes Sparky’s spreadsheet.

We are looking for a process that lightweight and sufficient. There is a point of diminishing return for everything we do, so sufficiency needs to be focused on. Machines are getting faster, but we are not really getting better in delivering software applications. Capers Jones has a study that finds that only 10% of software projects were successful: on time, within budget, feature complete, works (failure free). Is this reasonable? Venkat thinks it is, since few other activities have outside of politics have such a dismal failure rate and are put up with. Is software design engineering? The term came from the 60’s where people wanted to be focused on following principles and procedures as a path to success. Success does not come just by trying: we have to learn and make mistakes. This is why its extremely important to be open about what solutions are out there and to find out how things might benefit us. Is software like manufacturing? Its cheap to build software and deploy software, so this breaks the comparison. How much time does it take to produce 100 cell phones? This can be quantified. But how much time did it take to build the first cell phone: 37 years. Manufacturing is predictive, while product design is not. It is our job to take what customers what and figure out what they will be wanting: how what they want is evolving. Most software development is an innovative process rather than predictive manufacturing. Waterfall is a bad idea because it expects that phases are complete once you move beyond them.

The longer you wait between getting the requirements and getting feedback from letting users use the application (not just demoing it), the higher the chance that what you develop is not what they want. Unfortunately one of the constraints is that project planning does not take interaction between users and developers into account. Have you worked on projects where you are fixing bugs months after the deadline? Is this not hypocrisy that we say we meet the deadline, but the quality is bad? Can you rename notepad.exe to the project name, deliver it, and say you have met the deadline? Giving users what they want must be factored into meeting the deadline. It is not enough to deliver something on time, you must deliver what the customer wants on time. It is best to deliver things in much shorter cycles to account for the changing environments and requirements.

Notice in the agile manifesto (link) that it does not say what should be done or what shouldn’t be done, rather it focuses on priorities and principles. No matter what methodology we pick, any methodology that is dogmatic will fail. Venkat does not use any one methodology, but rather does a hybrid of methodologies for his projects. XP brings emphasis on what works, and tells us to do more of what works. For example code reviews are extremely important. But most people hate code reviews because people don’t want to have their code bashed, or there are other political reasons for not doing it. Venkat prefers a more tactical low profile task level code review. XP says, why not do code review all the time: which brings about the instant code review of pair programming. One thing that he feels is a high benefit is that he feels more energized after pair programming, than programming by himself all day. XP also emphasis short cycle, and de-emphasises documentation.

Consider the control variables of software cost time quality and scope. These things are not independent of one another. Do not let your customers control all of these, or they will be picking failure. If you change the time the quality is impacted.

Consider the values communication, simplicity, feedback and courage. Courage is about admitting that things stink and are overly complicated and redoing them. Courage is about taking responsibility and ownership of things. XP takes good commonsense principles to the extreme. If code review is good we will review code all the time: pair programming. If testing is good every body will test all the time. If design is good, well make it part of everybody’s daily business through refactoring. If integration is important then we’ll integrate and test several times a day. Venkat told an experience of someone who had a 3 minute continuous integration build environment where there was an audible shout every time there was a successful build, and a “you haven’t learned a thing” in an intimidating voice when there was a failed build, so that someone would know right away when things fail.

For using XP it is important to look at the size of the team, greater than 10 is more difficult, but doable. Also the culture and work environment is important. If you have no control over those factors he suggests you get another job. If the organization is not willing to succeed then we need to find an organization that is committed to being successful.

Scrum specifies things a little bit higher so that its principles work well on a management level. Venkat prefers a hybrid of scrum and XP when running teams, because he has found the greatest success with that combination.

Evolutionary Project Management (EVO): one of the oldest agile development processes from 1960s by Tom Gilb, published 1976. Short 5 days iterations, evolutionary requirements and design, measurable short list of project objectives.

RUP: skeptical, but it does have a good emphasis on incremental, however often times people place too much emphasis on documentation.

Crystal: No shoe fits all. If you are developing a game and it crashes once in a while someone might cuss. However if you build an application that manages casinos there needs to be more due diligence. Depending on what your impact of failure is your development approach must change. So he has stages from clear to red, where the hotter the crystal is the darker the color and the more emphasis on methodology and structure. Here he mentions the concept of domain driven design where he tries to bring the relevance of what people want directly to the software.

LD: emphasizes that everything is changeable, and that reversibility is extremely important. Needs determine technology, complete don’t construct.. these are some of the emphasis of LD.

ASD (adaptive software development): speculate collaborate and learn cycles with a non-prescriptive nature.

DSDM (popular in europe). One of things he likes is taking requirements prioritized as must have should have and want.

FDD (Feature Driven Development). Some of the things it proposes is controversial. It has short cycles, but expects requirements to be well captured and understood, which can be questioned. Expects class to be assigned to individuals: which goes against the idea of team ownership, a core principle of XP.

Ceremony: when you have to do things. usually this must not be bad, but it depends on what the ceremony is. When it is documentation then it can be bad, a stand up meeting is not that big of a deal. What are the ceremonies that give you the most value (I would say) and that work for your particular team.

He mentions that you should leave time for planning the next iteration and having a retrospective on what worked and what didn’t work. Agile exposes things very quickly so that you will fail faster.

Analogy: in the hospital someone might have heart failure and in this case the doctor does not say: you should have been exercising go run some laps. Therefore if you are working on a project adapt the methodology where it makes sense. If things are critical there is going to be less room for very aggressive XP practices of which the team has no familiarity.

Q: Now a days people try to leverage different tools to help project management and to facilitate communication. How do you think the importance of those tools help agile development.
A: there is a saying that a fool with a tool is a dangerous tool. It is the people that make the difference. Venkat has found that post-it notes are very effective. He also finds that face to face communication is very important. Next there are wikis that are a light weight way to document things so that you can see how things evolve. Tools have not given his teams the best benefit. Integration tools are the tools where he has gained the biggest benefit: unit testing and continuos integration tools. Venkat leans more towards face to face interaction over tools, that is where the emphasis is.

Q: Adapting scrum, and what he has noticed is that stand up meetings evolve into things that make the meeting go much longer, and that many use it as a forum for excuses. How do you manage that, and how do you take what you get from that and communicate that properly to project management who are not looking in burn charts but rather Microsoft project.
A: This is where the scrum master is an important role. First of all people must be on time. Secondly when people start talking the scrum master must politely keep the emphasis on things that are pertinent. If you ask me at the end of the day what my pain point is I’m not going to remember it. So there is a wall where they have a list of what hurts and what works so that during the day people change list list. In the scrum meeting they very quickly touch on each item.

They do component centric development, and to him the interesting thing about this is proof that you can scale up agile development techniques (throughout this talk he assumes that everyone at the conference is sold on Agile, this interesting. He seems to equate agile with continuous integration, planning, design, development, and testing cross-functional teams - he also tends to use the word continuous over agile)).

Jazz: joint project between IBM Rational and IBM Research to build a scalable, extensible team collaboration platform for seamlessly integrating tasks across the development cycle. The approach that they used was pain point centric. Software development should be fun and enjoyable. They wanted to eliminate the pain points (slide with a short list of common development pain points). One of the most interesting pain points to me was reconstructing the state of a failed build .. in general some of this build focused .. and also interesting is that Maven seems to address several of the pain points.

First they thought maybe there is a silver bullet that we can apply (kind of like adding refactoring to IDE tools… one thing eliminates a lot of pain). Take a look a the components:

-Requirements,
-Source Control
-Work Items,
-Builds,
-Reports,
-Process,
-Repository,

They have a closed source stack: WebSphere DB2, and an opensource stack tomcat, derby.

Jazz themes: team first, process awareness, and pervasive transparency (people can see what is going on in the project). Unfortunately the server is down to illustrate jazz, (which is developed using jazz: eat your own dog food).

Team First: the tool should know about the team. You also want to know what is going on with the team, and who is present (chat), and rss streams to see what happened in a team (team information). Each team has its own build (track an rss inbox) which tells you what happened in a team.

Lesson in scaling agility: at first everyone lived in the same build. There was no isolation and each team was swimming in a big soup. The tension is between sharing (lets you know what is broken) and isolation (lets you progress). We really want both. So the next step was to have component center development. You can have a high velocity in your component, and slow down the moment you reach the API. However, this is only a good architectural level, what we want is team-aware tooling: teams own components, tool support for collaborating on components, tools approach to improve a teams effectiveness collaborating on components. What you want is collaboration between components. For Jazz they do this by having a Team of Teams, and then individual teams, where each item has its own build, and team events, with the base teams feeding in to the parent team.

Process Awareness: people and their interactions are key, tools should support he team interaction. Each team owns its own process, and each team is different (self organizing) so you need to support teams that tweak process. The process can control and govern and control how the tool behaves, and must be highly tweakable. But which process? The process is context sensitive: i.e. process depends on development line: maintenance vs. next release. Process is context sensitive also to the development phase and once again to the team, since each team is different.

Process control points: define workflows, enhancements change requests etc. The most interesting process is advisors: advise how certain things should be executed. This allows hooks into interesting points of team interaction: such as submitting a change advises that there should be a code review. So the quick fix initiates a code review process. How do you evolve the processes? What they learned is you don’t want to evolve them top down, but rather you want to promote them bottom up, to be adopted by the entire team upon acceptance. (process customization is specified in XML? or is there a front end to that XML file I assume?). The framework leverages EPF (Eclipse process Framework) to help people define their processes, and it includes lots of examples.

Pervasive Transparency: transparency in: plans, development (project health, linking between project artifacts (which test failed linked to component), end game (done), and process.

In the thread there is also a link to a blog entry from Tobias Mayer. David also attended the same Scrum event I attended. Soon after I ran into him in Chicago and he told me that he left the training event after the first day. David said he thought that … well he says it best himself. To be very honest: at the time David told me this I was still on a Ken Schwaber high. I lacked the ability to think critically about anything David was telling me that day. Today though is a different day, not to mention 4 months later.

Today I think David has a point, and that the thing that people are identifying in the thread David pointed me to is a distinct smell: Selling Agile. To sell a product you need to define it and package it. Maybe Agile should not be defined to the degree that it can be sold. Cultures are too different, experiences too varied, and the problems being solved are often disparate. The changes that Tobias suggests are pragmatic and reasonable, but they don’t fit the package that Scrum comes wrapped in. How ironic is it that any Agile approach has rigidity that does not allow you to refactor the approach itself?

I realize now that there is no magic way to sell Agile so that it can succeed in a non Agile environment. If you want to adopt Agile there are plenty of references that allow you to start using it. The use of Agile must be adopted using an iterative incremental approach - a nimble approach - an Agile approach. Agile is not to be sold, it is to be used.

Assuming you are writing your test afterwards. If your code requires refactoring in order to be unit tested effectively (and mine always does when I do try writing tests after writing the code, because I don’t notice testing difficulties until I try and write the test) then you are changing something that presumably works, but without a way to automate the check that you are not adding new bugs (since you haven’t written the test yet).

This will either cause the refactoring of your code to take longer than if you did have a check in place, or if you don’t refactor your code the test will most likely be of lower quality. The test may be low quality because if you don’t do the code refactoring

1. there may be too much setup in the test,
2. the test may be too tied to other dependencies,
3. the test may not be focused enough on just the class you are testing,
4. and therefore the test is more brittle (small changes in code result in difficult refactoring of the test).

My experience is that it is more painful and risky to add a test after I write the code. Such pain causes me not to want to write any tests. Not having enough tests makes me less eager to change design to properly accommodate a new functionality, which usually results in duplication, brittle design, and other things that perpetuate yet more pain.

(BTW as I’m writing a test the above four things often happen, and that is how I know to stop adding functionality and refactor my code. All this having been said, some people are able to write their code keeping testability, clear responsibility deliniation, and decoupling in the back of their minds… so that their code does not need refactoring to introduce those qualities in order to write a clear concise test. I’m not one of those people.)

Files that had the name FileUtil, FileUtils, about 500
Files that had the name StringUtil, StringUtils, about 900

And those were just the ones that published their code online, and included the file name in the comments.

Maybe its a sign of the “maturity” of the language? Its time for a solid meta language that removes the necessity of me ever having to call StringUtils.isNotBlank(). Rails? Maybe in the web space. But in general people are so UI centric when they give requirements that really amount to “I want to see and manipulate such and such data within the company”. Functionality and cost seem a secondary consideration.

Oblivion plays wonderfully on a MacBook Pro, now that apple has released boot camp. You will want to play it wide screen. Personally I love being able to see far off into the distance so I prefer lowering the resolution to 848 x 480 (currently, but I might give turning off far away lands a try, since mostly I’m looking at what is right in front of me). But I might change my mind, and turn off far off lands feature and go back to 1280 x 768 widescreen, with a couple of other things turned down. At 1280 x 768 resolution with everything maxed out framerates go into the single digits should something attack. So there is a trade off. But its the game play that I’m most after, and Morrowind was just not as nice on an Xbox. The biggest problem is the interface. I really like having quick keys when I play. It just adds a little more realism, and causes me not to have to pause the action and scroll through a list of spells or items to find what I need. That and I disliked seeing it on a TV. It just wasn’t as engrossing for me. My main point though is that its more than playable on a MacBook Pro, its downright enjoyable. The graphics are amazing, no matter what resolution you play at.

I’ve played Elderscroll games since Daggerfall. That game was amazing. It was huge, the dungeons were incredibly complex (even with the cheat book I had problems). The graphics however were repetitive when you were wondering around outside.

Morrowind made the area covered much smaller, but added amazingly textured landscapes. Vegitation that you could harvest and mix into potions (how geeky is this: I had an access database of all ingredients and their effects on a handheld so that I could easily look up what I needed for this or that potion), as well as an involving plot that I was actually able to finish (never came close to finishing Daggerfall). But it was missing several things: shops were open throughout the day, there were no pack animals, and the actions of people were very repetitive.

Oblivion is much more realistic in those respects. I did the same thing in Oblivion that I did in the previous two titles. Once out in the open I followed the plot line and went to the first location indicated to me, on foot. One of the things I liked in Morrowind was the retreat and save for later aspect to dungeons, caves, and other places. Oblivion lets you run through underground caverns right off the bat (I have not had to retreat much at all). There is an upside to this: the whole game is playable it appears, right off of the bat, and its really hard to kill yourself playing at normal difficulty (I still haven’t died, and I’m playing my character unarmored!). I’m concerned that there isn’t enough to look forward to in later stages of the game. We’ll see. In Morrowind I played a Wood Elf, whose archery skill maxed out at one point. This time I its an argonian, but still with the bow and arrow. Like in Thief I can retrieve my arrows (a nice change! accidentally draw back on your bow, fire into the ground and retrieve). Sneak attacks do 3x damage, so I cleared two dungeons I found of imps in now time. Sneaking in general is much easier than it was in Morrowind, which makes the game more realistic.

Magic recovers without needing to rest at an amazing pace. I’ve only had to rest for an hour in four days of in game time, and that was so that I could level up. I have to need a heal potion, as my restoration spells do wonders. I also don’t need to drop my weapon anymore to cast, which is nice, and less confusing in the heat of battle.

Weird stuff: Thievery is as it was in Morrowind.. steal what you want so long as someone does not see you. But the monk guy that I had to deliver the amulet to told me to put back the apple that I stole (I just didn’t notice him sitting quietly in the corner and thought he was out for the day), but then happily talked to me afterwards. You would think I would have had to go into town and pay my fine first, but oh well. I did have to do just that in order to recover from the speed drain I picked up from a wolf at the little chapel by the Monk’s house.

Also there was this episode where I chased a deer who then ran into the water, where I hacked at him with my sword. There seem to be quite a few deer running around. I’m just not used to seeing deer.

There was a guard who was on horse back who I followed for a while. We came across a poacher who had killed several deer on the road, and the guard promptly killed guy. I helped, just being nice, but never got a thank you. He examined the deer and then got back on his horse. Just then a deer came out which I shot and hit with my bow. Though it didn’t die, you would think the guard would have complained to me about my action.

Then there were these two people I came across who were fighting. I of course took the side of the archer and joined in. Once again no thank you, and no dialog that gave me a clue as to what had just transpired.

Sideways cave was a little bit of a letdown, but I’ll have to check on line to see if I maybe missed something. I found lots of potions, but there wasn’t a final destination or a single great find in the place.

I’m debating turning up the difficulty, we’ll see how it goes.

As everyone says, this game is a huge improvement on Morrowind, as the previous titles have been improvements on former successes. Which is why it takes bethesda so long to release them. There are few games that I buy soon after they come out. The Elderscroll titles are always be on that list.