What is Success? (James Shore)
| 16 May 2008 | James Shore/Blog |
My understanding of success has evolved over the years. At first, I thought of it as a pyramid of levels, a la the CMM:
- Level 1: The software works
- Level 2: It's maintainable
- Level 3: It provides value
- Level 4: It provides more value than it costs
- Level 5: It provides the most value possible with the resources used
Later, I realized that there are actually multiple aspects to success:
- Organizational success is necessary for a product continue to receive funding.
- Technical success is needed to keep maintenance costs under control
- Personal success is required to receive support from stakeholders, prevent sabotage, and gain team member commitment.
Recently, Jurgen Appelo pointed me at an essay he wrote that discusses (among other things) the nature of success. He takes a completely different approach. In Jurgen's view, success is the absence of failure. One thought that occurred to me as I read is that we could measure success as the length of time a product is in production. An intriguing idea.
It's a fascinating essay, long, but worth the read. Take a look.
Save Your Job: Choose higher-bandwidth communication (Sammy Larbi)
Feature Injection (Chris Matts)
The Art of Agile Development: Stand-Up Meetings (James Shore)
| 14 May 2008 | James Shore/Agile-Book |
in 99 words
At a pre-set time every day, stand in a circle. One at a time, briefly describe new information the team should know.
Some teams use Scrum's formal variant, answering three questions: "What did I do yesterday?", "What will I do today?", "What problems are preventing me from making progress?" This formality is not required; use it if it's helpful, ignore it if not.
Be brief. Thirty seconds per person is usually enough. Discuss details later, in small group discussions.
Don't let the stand-up stifle communication. Talk about issues as they appear--don't wait for the stand-up.
as haiku
Overwatered, drowned--
students, uncomprehending,
did what they were told
Inside This Section
- Stand-Up Meetings
- How to Hold a Daily Stand-Up Meeting
- Be Brief
- Questions
- Can people outside the team attend the stand-up?
- Participants are being too brief. What should we do?
- People are always late to the meeting. Can we treat them to parking-lot therapy?
- We don't sit together. Can we still have stand-up meetings?
- Results
- Contraindications
- Alternatives
- Further Reading
Commentary
Back in the 40's, the story goes, American troops landed on a remote island. The natives of the island had never seen modern civilization before, and were amazed by the men and materials Allied forces brought by the island. They watched the troops set up an airstrip and a tower, don headphones, and call great metal birds filled with valuable Cargo down from the heavens. When the bird landed, shares of the Cargo were distributed to all of the islanders, bringing prosperity and comfort.
One day, the troops left, and the great metal birds stopped arriving. Missing their Cargo, the islanders made their own airstrip out of woven bamboo. They constructed a tall platform, placed their chief on the platform, and had him don coconuts carved to look like headphones. But no matter how hard they tried, the great metal birds never returned.
Decades later, researchers found the island. The natives still donned coconut headphones and called to the heavens... to no avail. They named the islanders' odd religion a Cargo Cult.*
*I first saw this story in the writings of Richard Feynman. Wikipedia says it's based in reality. Steve McConnell has also riffed on this subject.
Cargo Cult Agile
The tragedy of the cargo cult is its adherence to the superficial, outward signs of some idea combined with ignorance of how that idea actually works. In the story, the islanders replicated all the elements of cargo drops--the airstrip, the controller, the headphones--but didn't understand where the airplanes actually came from.
I see the same tragedy occurring with Agile. Many of the teams I know have adopted just two aspects of agile development: stand-up meetings and biweekly planning sessions. Nothing else.
But you know what? Stand-ups are one of the least important aspects of agile development. In a way, they're an admission of failure.
Okay, I'm exaggerating. A bit. But consider this: one of the values of Agile is communication and collaboration. The daily stand-up meeting exists to promote communication. But if the team really collaborated well, would it be necessary? Your team really should be sitting together, pairing, and sharing ownership of their work. If they're really doing that... really doing it... the stand-up doesn't add much value.
So I see these Cargo Cult Agile teams following the rituals of agile development without understanding the underlying ideas. They have a daily stand-up meeting, but they don't collaborate. They plan every two weeks, but they don't deliver.
It's probably inevitable that teams water down and misunderstand agile development. It's unfortunate, though--and a little ironic--that a set of methods created to reduce meetings and waste is being abused to increase them. Cargo Cult Agile teams often go from a weekly one-hour meeting to daily half-hour meetings. This is not an improvement.
Stand-up meetings are a neat tool, but they're hardly the core of agile development. Beware Cargo Cult Agile. Don't use stand-up meetings to avoid real communication and collaboration.
Collaborating with our Customer (Simon Baker)
Our Customer and the editors have day jobs and every now and again they're not available for a conversation. We have to respect their flow time. This doesn't happen that often because we have a great sense of team across the product stream and everyone knows we're in this together. Nevertheless, if we can't get feedback when we ideally want it, we can always rely on the Clinic Time at the start of each day. This is a 15-minute time slot at 9:30am, immediately before the daily stand-up, where everyone in the product stream is available. It provides the team with a sure opportunity to seek out the feedback they need and there's an open invitation to the Customer and editors to drop into the bullpen and get previews of where things are at in the iteration, share ideas and get feedback, and raise any issues.
To help us understand the editors' jobs and how they work individually and together we shadow them twice a week. For an hour at pre-arranged times, a pair of developers and testers sit with the editors observing them doing their jobs and asking questions. This reveals many important things about their workflows, their behaviour and how they use the publishing system, which are a great help when we're designing how functionality will work.
Our iterations start on Wednesdays and on Wednesday afternoons our testers hold a Playshop for the editors where they get to play with the functionality showcased by the team the day before. We only do this while we're building that first release of product. Once the first release is live we deploy to the production environment at the end of every iteration. What we're working towards is more user-centred design within iterations but that's another post.
Tags: collaboration, conversation, clinic time, shadowing, playshop
How to resize your Boot Camp partition on Mac OS X (Sammy Larbi)
Velocity, capacity and productivity (Simon Baker)
Some people use velocity as a measure of productivity. Productivity is the rate of production measured in terms of the rate of output per unit of input, but I like to think of velocity as the capacity of the team because it represents the maximum number of story estimation units a team can take on in a planning game based on yesterday's weather. I prefer to measure productivity in terms of the goal and getting stories done is not the goal, generating revenue is. Getting stories done is the means to achieve the goal.
Productivity could be something like the business value delivered per iteration per unit of story estimation, but business value is typically subjective and therefore not easily quantifiable. Productivity is perhaps better represented by the revenue generated per iteration per unit of story estimation, e.g. £10,000 per ideal pair day. A complementary measure of productivity uses pure monetary terms and is the ratio of the revenue generated to the cost of delivering the functionality responsible for generating that revenue, e.g. £10,000 / £5000 = 2.
A product stream should work to maximize return on investment and the team should challenge itself to increase its velocity. Pressuring people to work harder, work longer hours, and take on an increased workload is not the way to increase velocity. It's the way to start a death march. Causing people to sacrifice their work-life balance is detrimental to the health of the people and the product because tired people drop quality and create more defects. People should be allowed to practice energized work where they work only for those hours where they are genuinely productive and maintain high quality. And a team must be given the space and the time to find the velocity at which it can work and deliver at a sustainable pace.
The way to reveal extra capacity and increase velocity is to relentlessly remove obstacles, eliminate waste and improve continuously. Help the team focus on the product, on quality, and to deliver only the functionality that adds value to the product and generates revenue. Keep the process simple and intuitive so that people don't have to stop and think what the next step is. And protect peoples' flow-time by preventing interruptions. Help the team avoid creating inventory, i.e. functionality that is complete but cannot generate revenue because it is not deployed to the production environment. Quickly remove obstacles that are identified in the daily stand-ups and minimize dependencies so the tream doesn't have to rely on others to get stuff done. This also cuts down on the time spent waiting around and chasing down and the effort required to hand stuff over.
Tags: velocity, capacity, productivity, user story, done
Cap the conference :) (Willem van den Ende)
Marc Evers and I were a bit buzzed… We hoped, this year, to start announcing agile open earlier (and, unlike last year, not keep repeating ‘we should get started’). Well, unlike last year, we didn’t keep repeating it. We just didn’t get round tuit…
So last week, we finally got together around a whiteboard, decided that we did want to hold it in June (like last year, and as we planned), but we didn’t have a location etc. and didn’t want to spend as much time as last year in sending out invoices, dealing with exceptions etc.
So, we decided to go with an affordable conference location and leave things like hotel, dinner out of the basic package. That means we can send out just one type of invoice - you come two days, or you don’t, and beside diet preferences there are no options. Well, you can of course volunteer (we got spontaneous offers for that. ) or sponsor. We also decided to cap the conference at just thirty participants, so we could go with the venue. One of the reasons being, we thought we can’t get that many participants in a month anyway… Surprise, surprise, sending out the invite to a couple of mailinglists, and we’ve already passed the twenty participants mark. And we have some sponsors as well (we didn’t expect many in this timeframe, so we’re pleasantly surprised. Now we have to make sponsor packages 
and facilitate the other volunteers so we can self-organize )
So, without much further ado, I’m proud to announce the next
Agile Open Europe 2008
will take place in Utrecht, NL on June 5th and 6th. A vibrant place to push the envelope and do business together. And yes, we will find Belgian Beer - one participant listed that as a dietary requirement ;) Looks like its’ going to be good fun again. See you there!
And if you ’still’ haven’t registered - there’s a handful of places left…
Save Your Job: wud u pls lern 2 rite so ppl can reed ezr? (Sammy Larbi)
NUnit 2.5 Alpha 2 Released (Charlie Pool)
With a European trip about to start, I decided to release a second Alpha so that the new stuff would get some visibility. I won’t be doing another release till late June, so please give this one a try.
As compared to 2.4, NUnit 2.5 has quite a lot:
- Data-driven tests using [TestCase] and [DataSource]
- Additional asserts and constraints, including inline exception tests.
- Parallel and distributed testing using pNUnit.
- Bundled addins, now including RowTest and CSUnitAddin.
For more info, see the release notes.
In addition, watch the NUnit mailing lists or this blog for info about other extensions as they are released for NUnit 2.5.
A Simple NUnit Usage Recipe (Charlie Pool)
Scott White has a blog about NUnit Best Practices. The approach may require adjustment on more complex projects, but it’s a very simple recipe for those starting out with NUnit.
Conscientious Uncertification (James Bach)
I’m thinking of having badges made which say “Conscientiously Uncertified.” It’s for those of us who want to resist the dumbing down of our craft by cynical consultants promoting bogus tester certification programs.
For me, when I see that someone is certified as CSTE, ISEB, ISTQB, or CSTQE, I immediately think “there goes someone who was bullied into compliance.”
Any suggestions for what the badge would say?
Here are some options:
- Conscientiously Uncertified
- Certification Objector
- Uncertifiable
- No Bullies
- Proud to Be Uncertified
I should have a logo made, so like-minded freedom fighters can post it on their blogs. By refusing to give in to the thugs of certification, a tester shows he can follow a more difficult and more admirable path: self-education and self-certification.
Side Note: There is one certification program coming along that looks worthwhile, to me: the AST BBST certification. It will be difficult to obtain, based on demanding online coursework. It will not claim to be anything more than a certification that the tester has successfully made it through the course(s). Some of it is already available through the AST. The rest is coming. So far, the courses are free to AST members.
I will probably not be able to get this certification (I’m too disruptive in class), but at least I helped create it.
Mythbusting - Collective Code Ownership (Mark Levison)
In researching "Are there weaknesses with Collective Code Ownership?" for a news item on InfoQ I was struck by the number of myths that get repeated around Collective Code Ownership. I thought it time to burst a few balloons.
A number of writers equated Collective Code Ownership (CCO) with "no ownership" or chaos. Yet nothing could be further from the truth. Let's revisit Martin Fowler's definition (he's a better writer than I):
Collective code ownership abandons any notion of individual ownership of modules. The code base is owned by the entire team and anyone may make changes anywhere. You can consider this as no code ownership, but it's advocate prefer the emphasis on the notion of ownership by a team as opposed to an individual.
Now its not easy to practice CCO and to make it work you need an agreed on set of coding/formatting standards. You also need to practice pair programming to help maintain the required discipline. But its not chaos.
Simon Lin mentions a team that shared a single version control account. I'm not sure where this myth commons from. CCO says that we all own the code and that we're all responsible for maintaining it but nothing is said about sharing the same account. I think that responsibility requires that we're accountable for what we change.
Ralf's Sudelbücher
argues that "Collective code ownership is limiting software quality", in a rather lengthy note from two years ago. His core argument appears to be that generalizing specialists can't know all of the domains that they need to code and so produce weaker code. The number of domains that a project might encompass has grown so large (ASP .NET, SQL, ADO, ...) that no one programmer on the team can command a knowledge of them all. On this last point we agree. However I don't think that means that team members who aren't specialists can't produce good quality, simple code in other problem domains. Simplicity is easy to appreciate no matter what the problem domain. In addition most new API's follow well established patterns for a lot of methods (i.e. open/close) that make it easier to pick up the basics. To solve the remainder of Ralf's problem: when coding in area where you don't know the speciality well either pair with the specialist or get them to review it after the fact. Effectively implementing Martin Fowler's Weak Code Ownership. At least this way we avoid the inevitable bottlenecks when we really on the point hats to do all the work.
One fact I'm coming to believe: to achieve the discipline required for CCO to work you need more than just common development standards. You also need to write most of your code using Pair Programming and Test Driven Development (at worst Test Minutes Afterward). Without these practices, consider using Weak Code Ownership where each module/package has an owner/evangelist who's role is to ensure that the conceptual integrity is not only maintained but explained to other team members.
Why Game AI Still Sucks (Sammy Larbi)
Behold, the power of Extract Method (Sammy Larbi)
Save Your Job: Don't be "the grumpy old code ogre" (Sammy Larbi)
Save Your Job: Don't be (Sammy Larbi)
What does age have to do with learning new ideas? (Sammy Larbi)
SwingHelper (Darren Hobbs)
One of the most common causes of sporadic bugs in swing applications is doing things on the wrong thread. Most common of these is when a thread that is not the Event Dispatch Thread does something that updates the gui. Its very easy to do accidentally as seemingly innocent operations done on a background thread can fire off event listeners and end up inside code it shouldn't as a result.
CheckThreadViolationRepaintManager from the SwingHelper project is a very useful class that can be easily plumbed into a Swing application to report any wayward threads getting into gui code.
Also from the same stable is the EventDispatchThreadHangMonitor which can report when the Event Dispatch Thread spends too long outside its main loop (which will result in a sluggish and unresponsive gui).
A View From Inside ISTQB/ISEB (James Bach)
Alan Richardson writes this commentary from inside one of the stupidest of the certification programs: the ISTQB (well, he says “ISEB”, but by all accounts, it’s being taken over by ISTQB stormtroopers).
Long ago I also tried to change a certification program from the inside. I also failed. Now I do my best to cultivate the community of people who rise above it. As Alan points out, rising above can be difficult, because of all the poor fools who’ve been duped into believing that an ISTQB tester certification actually means something important.
What such certification really means is that, in England, and several other countries, certain unscrupulous or plain ignorant consultants are able to hold the testing craft for ransom, and almost no one will call them to account. Some of the perpetrators know full well what they are doing, but many of them, I think, know so little about testing that they honestly don’t realize what harm they do to the industry.
– James
Common.Addins.Build : Addin Building Made Simple (Charlie Pool)
Let me start right out by saying: I know some of you won’t find this to be simpler - but it is! If you can’t bring yourself to install NAnt or work from the command line, then this isn’t for you. But if you can get past the initial hump - or if you’re already past it - then this is for you.
The hardest part about building - as opposed to writing - addins is getting the references right. Addin solutions in Visual Studio generally contain from three to five projects: the addin assembly, the assembly referenced from user tests, a unit test assembly, possibly a separate test fixture assembly for use by the tests and one or more samples. All of those have to reference the nunit assemblies they will be used with when they are installed. Getting it right is tedious at best, requiring multiple visits to the Add Reference Dialog. And from time to time, Visual Studio will decide to use a different assembly from the one you expected.
I finally got fed up with all this and decided to write a NAnt script for one of my addins - CSUnitAddin actually. After it was done, I looked closely and realized that most of it was boilerplate - the same code with a few property changes would build other addins. So I started to factor out the common code into an include file, with the result that my CSUnitAddin.build file now looks like this:
<?xml version=”1.0″?>
<project name=”CSUnitAddin” default=”build” basedir=”.”><!– Include the common build file –>
<include buildfile=”../common.addin.build”/> <!– 1 –>><!– Define non-default names for sample project –>
<property name=”sample.dll” value=”money.dll”/>
<property name=”sample.dir” value=”money”/><!– Define non-default names for fixture project –>
<property name=”fixture.dll” value=”CSUnitTestFixtures.dll”/>
<property name=”fixture.dir” value=”CSUnitTestFixtures”/><!– This addin is for the csunit framework –>
<property name=”target.framework.dll” value=”csunit.dll”/><!– Define alt library with proper version of csunit –>
<!– Must be here since lib.dir is defined in the common file –>
<property name=”csunit.version” value=”2.0.4″/>
<property name=”alt.lib.dir” value=”${lib.dir}/csUnit-${csunit.version}”/></project>
This example actually has to do more than most, since it uses a “foreign” testing framework. I’ll walk through the steps for you:
- First, the script includes the addin.common.build sript, which will do all the work.
- Next, it defines non-standard names for the sample assembly and it’s directory. I could have eliminated this by calling them both “sample” but I wanted a non-generic name here.
- I do the same thing for the “fixture” assembly - an assembly that contains csunit-based tests, which are loaded and run by my unit test assembly. In this case, I might have stuck with the default (CSUnitAddinFixture) and saved a few lines of xml.
- I set the target.framework.dll to csUnit so that my sample and fixture assemblies will be built with a reference to that framework rather than the default nunit framework.
- This particular addin has multiple library subdirectories for different versions of csUnit, so I set the alt.lib.dir property to indicate which one I want to use.
So, let’s say that I want to build and test this addin with NUnit 2.5, using both the .NET 1.1 and 2.0 builds. I can do this with two commands:
nant release net-1.1 nunit-2.5 clean build test
nant release net-2.0 nunit-2.5 clean build test
The script will locate my NUnit 2.5 installation, build the addin and it’s associated assemblies (four in all), install it and run the tests using that same installation. NUnit 2.5 has separate net-1.1 and net-2.0 directories, which the script knows about, so the two builds will be installed separately.
This is how I’m building addins now. I use Visual Studio to do editing and syntax checking, leaving the actual builds to the script. As a result, I no longer need to deal with mismatched references or with the tedium of using the gui to switch between NUnit versions.
The Common.Addin.Build script is open source, licensed under the Academic Free Licence 3.0. You can get it here.
Testers in our agile team (Simon Baker)
In the pre-planning game with the Product Owner, Customer and a few developers, the testers help grease the wheels for the coming iteration's planning game by teasing out, through conversation, preliminary details about the candidate stories to get them to about the right size. Details are noted in pencil on the reverse side of the story cards. The planning game is similar to the pre-planning game except the whole team is present. Typically, the Customer is absent because the conversations can get technical in order to estimate the stories but the Customer can be there if they want. Again, the testers help tease out story details and capture these as acceptance criteria, in pencil, on the reverse of the story cards. The team works together to identify the right acceptance criteria for each story. The planning game is about doing just enough planning to reach consensus on estimates and commit to a delivery goal. Everyone understands that, as collaboration occurs and the story is developed, it may be necessary to add, remove or modify acceptance criteria.
When stories are started in an iteration, developers build them out in vertical slices that satisfy specific acceptance criteria. When a slice is ready, the developers have a conversation with the testers, demonstrate its functionality and walk through the automated acceptance tests. When the testers are happy they're left to run their automated build, which deploys the latest code to their environment. Here they'll conduct their exploratory testing. Exploratory testing functionality as it emerges, slice by slice, helps avoid a tail-end testing crunch in the iteration or, worse, trailer-hitching testing in a separate iteration. Developers might also ask the Product Owner and Customer to preview a slice to get more feedback. When this happens, the testers act as chaperones to keep abreast of emerging details and are part of any decisions made relating to the story.
Testers starve without slices so they pull slices from developers on a regular basis to maintain a flow of stories that ultimately make it to done in time for the showcase.
Defects are rework and an expensive form of waste. When a defect is found in a story and the story is still being developed, the defect is a stop-the-line event. The testers interrupt the developers working on the story and ask them to fix the defect in the next slice. This conversation usually includes the testers showing how to reproduce the defect. If the story is no longer being developed - maybe the defect was discovered after a story was completed - the testers write the defect on a pink card, which is then placed at the top of the board, so it will be the next card to be started.
Testers on our agile team have found their working day to be very different. They're using the same testing skills and they're finding new skills as they collaborate more within the iteration.
Tags: testing, agile, collaboration
Maybe Pair Programming isn’t such a good idea (Steve Freeman)
“Keyboads dirtier than a toilet” (BBC)
It justifies my view that eating lunch at the desk is uncivilised, and that pairing stations should have two keyboards.
Now that everything is USB, maybe we should just carry our own input devices and just plug in when wherever we’re working. Hmmm. Sounds like my dissertation, maybe I should have stuck with it…
Finding Bugs is Easy (Greg Vaughn)
Using Addins with NUnit-Console (Charlie Pool)
A recent bug pointed out that addins are not recognized when running tests under the console runner. This is due to a missing entry in the nunit-console.exe.config file, which you can easily fix yourself. Follow these steps to have your addins recognized when using the console runner:
- Open the nunit-console.exe.config file in any convenient editor - notepad is fine.
- Find the <runtime> element
- Insert the code below within the <runtime> element. You can copy it from nunit.exe.config if you prefer
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="addins"/>
</assemblyBinding>
From this point on, your addins should work equally well in both the Gui and Console runners.
NUnit 2.4.7, 2.5, 3.0: What’s With That? (Charlie Pool)
A few folks are confused by the various release numbers being announced or discussed all at one time, so I thought I’d clarify:
NUnit 2.4.7 is the latest production release of NUnit. It’s the one we recommend most people use for your tests. Some fairly critical performance bugs have been fixed in the last few releases, so you should update even if you’re only one or two digits back. See what you’re missing !
NUnit 3.0 is the planned - but not yet released - next generation NUnit. We call it the NUnit Extended Testing Platform, to distinguish it from the current NUnit Framework. It will provide a superset of the functionality of the current framework and is generally described here. I’ll be posting further info on NUnit 3.0 as it progresses.
NUnit 2.5 is release that wasn’t originally planned. The 2.4 series was supposed to be followed by 3.0. However, a number of people asked for a quicker release that included features provided by other test frameworks, which are currently missing from NUnit. So 2.5 is now in alpha, with extensions to support data-driven tests, easier exception testing and a number of other goodies. It’s also being bundled with pNUnit, an extension that supports distributed parallel tests. See the release notes for details. Watch for the second Alpha release sometime next week.
Hopefully, this will clear things up till we generate some more numbers.
The difference between blame and accountability (Simon Baker)
Deal with the root cause. Have a conversation and hold the person accountable.
To me, the difference between blame and accountability is language and delivery. Here's a couple of examples:
"That code you wrote to do thingamyjig is rubbish. It's causing all sorts of problems."Here you're assigning blame, which can be exaggerated with intonation and gesture.
"You know that code you wrote to do thingamyjig?Here, on the other hand, you've approached the person, offered to help improve the code and created a learning opportunity for him (and probably for you too) that will help address the root cause and prevent it from happening in the future.
I think there might be a better way to do it. Can we sit down and try refactoring it?
I'd like to show you what I'm thinking and get your feedback on it."
Tags: communication, accountability, blame
People do pair-programming (Simon Baker)
- Keyboard hogging
- Drivers over-doing the running commentary
- One-way conversations
- Procrastination through too much discussion
- Copilots disengaging
- Copilots playing on their handheld device
- Copilots not thinking at a system-level thinking
- Holding one another accountable for smelly code
- People not remaining aware of other person's skills and level of experience
Here's some of the posters:
I wanted to emphasise the need for effective communication because, as a team, we're highly collaborative and extremely conversation-driven, so I spent 10 minutes talking about it. Everyone knows that communication happens in many ways - language, gestures, pictures, code, etc - yet people often don't recognise that everyone wants to get along and do their best. When people sometimes respond to something you've said in an unexpected way - maybe they're argumentative or obstinate, or perhaps they look confused - there are usually good reasons. Responding in kind is not the way to go. That's just going to make the conversation spiral negatively. Consider how the other person might have interpreted what you said. Find out what possible reasons might exist for their reaction.
A conversation is simply an exchange of information but they can be hard work. It's important to alternate between informing and listening. If you're saying something, don't assume your message is received. Ask for acknowledgement. Ask the other person to play it back to you. When speaking, delivery is everything. Is your delivery causing people to not listen? Saying it louder probably won't work. Try saying it differently. If you're listening to someone, don't just hear them, actually listen. Maintain eye contact, visibly show interest and focus on what they're saying. Verify your understanding by playing it back to them, in your own words.
People label people. These labels essentially stereotype people and encapsulate how you expect them to behave. Labels are a handy means of characterizing a person but they can create negative perception. "What I don't hear, I make up, and I hold you responsible for it." It's difficult but you need to at least be conscious of the labels you use.
Communication needs to be congruent. Balance your own needs, desires and goals against those of others, taking into account the context or environment in which you're interacting. Every person is different. Every pairing session is different. You have to invest in growing a pairing relationship over time with every person in the team.
The action we took out of the retrospective was to give and get feedback within pairs after each pairing session using a 10-minute reflection on the interaction. Here's how it works:
At the end of each pairing session the pair rip an index card in half and each person writes his name at the top of the half-card. The pair discusses the session and each person makes notes on their half-card about what worked well for them, what didn't, and where the interaction can be improved. They do not critique one another. When complete, they exchange the half-cards providing each person with a reference to the pairing session from the other person's perspective. When the pair comes together again they combine their card-halves and work together to improve their relationship and interaction. At the end of each pairing session, the pair writes new card-halves to drive continuous improvement.
We'll run with this for a while and see what happens.
Tags: pair-programming, promiscuous pairing, communication, retrospective, collective code ownership, collective story ownership
Two kinds of YAGNI (Steve Freeman)
I seem to be blog-stalking Keith again.
In his post on Creation under Constraints he uses a post from Andrew Binstock to write about the benefits of discipline on creativity. After all, is there anything more constrained than the form of a Rock’n'Roll song? Bartok had a thing about using the Golden Ratio to structure his work. Even in my misspent youth playing free jazz, the good musicians had an identifiable voice that implied form and structure.
Getting back to the point (there is one? ed.), the phrase You Ain’t Gonna Need It (YAGNI) often seems to be applied at the micro level by using primitive types: I’ll just use a String for this address, I can figure out whether I need a type later. Except that, later there are Strings all over the code, only some of which should be Addresses and, by the way, it turns out that I’ve assigned some company names (also String) to address fields by mistake.
String is about implementation, it’s not expressive in the domain of the code. And I’d double that claim for anything that involves templated collections, when there are three or more levels of nested angle brackets it’s time to turn back.
An alternative view, is to say: I need an Address, I’ll declare an empty type and add features as I discover the need. I don’t expect to need a getBytes() method on Address, but I might well need to ask it for its post code.
Over time, I’ve become more and more convinced of the value of declaring types for everything. I don’t observe this practice as much as I think I should, probably for the same reason I have too many fillings.
Incidentally, for a fine example of working under constraints, the Abelson and Sussman videos go for hours before they discover a need for mutable values.
We’re famous (kinda) (Steve Freeman)
There’s been quite a buzz in the narrow world that I inhabit about this recent interview with Donald Knuth. For us “TDDers”, the relevant quote is:
[…] the idea of immediate compilation and “unit tests” appeals to me only rarely, when I’m feeling my way in a totally unknown environment and need feedback about what works and what doesn’t. Otherwise, lots of time is wasted on activities that I simply never need to perform or even think about. Nothing needs to be “mocked up.”
Keith has discussed this point nicely. Personally, in a scarily long time in software (which including tourism at some of the best research labs in the world), I know of a handful of people who can think very hard and then type in a working program of more than 3 lines.
In the meantime, I’m curiously chuffed that the concept of mocking appears to have entered the vocabulary of someone so far away.
As I said, I inhabit a very narrow world.
What I've Been Using Lately (Bret Pettichord)
The Art of Agile Development: Ubiquitous Language (James Shore)
| 30 Apr 2008 | James Shore/Agile-Book |
in 99 words
Programmers should speak the language of domain experts to avoid miscommunication, delays, and errors. To avoid mental translation between domain language and code, design your software to use the language of the domain. Reflect in code how users of the software think and speak about their work. One powerful approach is to create a domain model.
The ubiquitous language is a living language. Domain experts influence design and code and the issues discovered while coding influence domain experts. When you discover discrepancies, it's an opportunity for conversation and joint discovery. Then update your design to reflect the results.
as haiku
Fireflies light the night--
Signaling for a mate, or
perhaps, a dinner
Inside This Section
- The Domain Expertise Conundrum
- Two Languages
- How to Speak the Same Language
- Ubiquitous Language in Code
- Refining the Ubiquitous Language
- Questions
- Should we avoid the use of technical terms altogether? Our business domain doesn't mention anything about GUI widgets or a database.
- Results
- Contraindications
- Alternatives
- Further Reading
History
In the first edition of Extreme Programming Explained: Embrace Change, Kent Beck introduced the "Metaphor" practice, also called "System Metaphor."
Each XP software project is guided by a single overarching metaphor. Sometimes the metaphor is "naive," like a contract management system that is spoken of in terms of contracts and customers and endorsements. Sometimes the metaphor needs a little explanation, like saying the computer should appear as a desktop, or that pension calculation is like a spreadsheet. These are all metaphors, though, because we don't literally mean "the system is a spreadsheet." The metaphor just helps everyone on the project understand the basic elements and their relationships.
The words used to identify technical entities should be consistently taken from the chosen metaphor. As development proceeds and the metaphor matures, the whole team will find new inspiration from examining the metaphor.
The metaphor in XP replaces much of what other people call "architecture." The problem with calling the 10,000-meter view of the system an architecture is that architectures don't necessarily push the system into any sense of cohesion. An architecture is the big boxes and connections.
You could say, "Of course architecture done badly is bad." We need to emphasize the goal of architecture, which is to give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks. By asking for a metaphor we are likely to get an architecture that is easy to communicate and elaborate.
Kent Beck, Extreme Programming Explained: Embrace Change
This didn't work out so well. Detractors of XP latched on to System Metaphor as an example of XP's irresponsibility: of course architecture is important! How could it not be? How could this silly idea of "metaphor" replace architecture?
On the flip side, people who liked and used XP struggled to understand the idea of System Metaphor and its place in XP. Early XP conferences had whole workshops devoted to coming up with a metaphor for your system. Its meaning and purpose was debated on Ward's Wiki, source of the best and most complete early information on XP. On my first XP project, the one where tried everything religiously, we dabbled with system metaphor, too, giving our classes names like "forklift" and "warehouse." (Our system was a data warehouse, you see. Except that it wasn't.)
Most people just ignored System Metaphor. Kent Beck stuck with it for a while, but eventually dropped it as well. When the second edition of XP Explained was published, System Metaphor was gone, with nothing to replace it.
Meanwhile, Joshua Kerievsky had created Industrial XP (IXP). IXP never really caught on, possibly because the name was so similar to the name of Joshua's company, Industrial Logic. It was a good method nonetheless. I had the opportunity to coach a team in its use as part of an long-term coaching effort in Toronto.
Joshua was a reviewer for Eric Evan's excellent book, Domain-Driven Design. It's probably no coincidence that Domain-Driven Design is an explicit practice in IXP. The IXP web site quotes Evan's book to describe the practice:
The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process. Domain-Driven Design fills this need.
Eric Evans, Domain-Driven Design
I think domain models are an excellent tool and Eric's book is wonderful. Domain models aren't appropriate in all situations, though, which is why we didn't include domain-driven design as a practice in our book. Instead, we used another pattern from Eric's book: Ubiquitous Language.
A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of the design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person uses different language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
...Therefore:
Use the model as the backbone of a language. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Eric Evans, Domain-Driven Design
As I look at the IXP site now, I don't see any reference to Ubiquitous Language. But I seem to remember that it was a major part of that project in Toronto. That's probably why it was on my mind when I mentioned it to Shane as a possible practice for our book.
Programmers program in the language of technology: classes, methods, algorithms, and databases. Domain experts talk in the language of their domain: financial models, chip fabrication plants, and the like.
You could try to translate between the two languages, but it will add delays and errors. You'd produce some software eventually, but you'd probably introduce some bugs along the way. Instead, pick just one language for the whole team to use--a ubiquitous language.
James Shore and Shane Warden, The Art of Agile Development
So here we are, full circle. The core idea of System Metaphor was to "give everyone a coherent story within which to work, a story that can easily be shared by the business and technical folks." (Beck00) And the core idea of Ubiquitous Language is to "reflect in code how users think and speak about their work." (Shore07)
Right back where we started, except without that funky metaphor stuff.
Reintegrating Watir and FireWatir (Bret Pettichord)
Rsync Your Referrer log (Greg Vaughn)
#! /bin/sh
rsync -Cavz -e ssh --delete /Users/gvaughn/Sites/gigavolt.net/blosxom/ \
userid@webhost.com:/WebSite/gigavolt/blosxom/
rsync -urptgovLz -e ssh --copy-unsafe-links \
userid@webhost.com:/WebSite/gigavolt/blosxom/ \
/Users/gvaughn/Sites/gigavolt.net/blosxom/ And my book goes farther east! (Jimmy Nilsson)
So cool!
Not only has my latest book, "Applying Domain-Driven Design and Patterns" been translated into Russian
(more information here), but now I've been informed that the Japanese translation has been published as well. The Japanese version
looks like this:
Should We Adopt Scrum or XP? (James Shore)
| 26 Apr 2008 | James Shore/Blog |
A reader recently asked:
I have learned a bit about Scrum and Crystal and found that things are looser and they do not prescribe practices as XP seems to and that they want you to work toward finding the practices that work for your team. An example is Mike Cohn saying that he does not like to prescribe practices, like TDD which he believes in, but wants the team to discover for themselves their need of it as they do root-cause analysis and retrospectives. Does this go against y'alls advice on trying to do all the practices and later adjusting things to meet your needs as a project? Or is it something different?
[For example, see] Mike Cohn's thoughts about Scrum and XP. In particular starting with Scrum and creating your own XP.
My response:
I agree with Mike Cohn's description of the differences between XP and Scrum. I would emphasize that Scrum and XP are very similar, with the exception that XP includes more "how to" practices. There's also a bit of an focus difference; I feel like Scrum's focus is "let's create a self-organizing team" and XP's focus is "let's create excellent software." In other words, when I talk to Scrum people, they tend to talk more about self-organization and enabling the team; when I talk to XP people, they tend to talk more about software and delivering value. But despite that difference in attitude, the actual practices are very similar.
Mike's closing statement, that Scrum brings big benefits by itself, matches my experience. Scrum is also easier and less threatening than XP, so I see a lot more people starting out with Scrum. On the downside, the teams that start with Scrum tend to struggle more than the teams that start with XP. The XP teams experience more pain starting out, but then get to a high performance state within the first year. The Scrum teams I know have a much longer ramp-up time, generally having code quality problems for several years. Actually, I have yet to meet one that wasn't having code quality problems. None have gotten to the same high performance result that good XP teams do.
Granted, these statements are based on my experience, and my experience is formed by the people I meet at conferences and the companies who hire me. High performance teams generally don't hire me, so it could be that I'm not meeting the high performance Scrum teams.
Nonetheless, my experience is that Scrum teams have an initial success and then struggle. XP teams struggle to get started, but once they figure it out they have more success. Sometimes they don't figure it out, fail, and give up. With Scrum, teams seem less likely to realize that haven't figured it out; I've met teams who said they were using Scrum but weren't doing anything of the sort; they were just using the terminology. That happens with XP, too, but to a lesser extent, and usually of the form "we're doing XP but not..."
To boil it down to simple statements (perhaps too simple):
Scrum: easy to adopt, very hard to master, fails quietly. You're more likely to successfully adopt Scrum, but the benefits won't extend to your codebase and you'll struggle with legacy code for many years. If you're missing pieces, you may not realize it.
XP: hard to adopt, easier to master, fails noisily. You're less likely to successfully adopt XP, but you'll be well positioned for long-term success and mastery. If you're missing pieces, you'll probably be able to tell.
I have one complaint about Mike's essay. XP doesn't prescribe engineering practices, as Mike says; it includes them. For teams new to agile development, I do recommend that you use all of the practices from the start. However, a team that knows what it's doing will change its practice of XP over time. No two experienced XP teams practice XP in the exact same way, and there's no requirement that you do exactly what the books say. For example, one long-running XP team I know has evolved away from using iterations entirely, but I'd still think of them as practicing XP.
However, in order to know what to change, you have to know how the techniques work in practice. That's why I recommend starting out with all of the practices. Otherwise, it's like deciding to be an avant-guarde violinist without first mastering the violin.
Should you start with Scrum or XP? I recommend starting with XP, but Mike's right--you won't succeed if you force the practices down people's throats. The team has to agree to try them. If they're not ready to do that, you might be better off starting with Scrum. Then you can use that success, along with some of the code problems you'll encounter, to guide them to XP.
Finally, if you have the opportunity to get a coach to help you adopt your method, I recommend that you do. A good coach will help the transition go a lot more smoothly.
Save Your Job: Dispelling Illusions of Fear Disguised as Ethics (Sammy Larbi)
Software Development as profession? Not Yet, Probably Never (Mark Levison)
In discussing Scott Bain's book: Emergent Design: The Evolutionary Nature of Professional Software Development Martin Heller asks Is "professional software developer" an oxymoron?
In the book (which I've not read yet), Scott makes the case for the use design patterns, test driven development, coding style and readability. This sounds like the book we all wish our colleagues would read (not ourselves of course - we're already perfect).
Martin then hones in on Scott's suggestion:
that software development is by nature a professional activity, and should be conducted as a professional activity. He also says that we're not yet conducting it as a professional activity.
He finishes by asking the question 'Is the phrase "professional software developer" an oxymoron?' My answer is no, but I think the question misses Scott's point. Scott is asking to consider what it would take to become a profession as a way to force us to start wrestling with difficult questions. I agree that we need to start asking difficult questions especially with the mounting numbers of costly failures in large out of control projects (both public and private sector).
But I would argue strongly against seriously considering becoming a profession. My concerns are two fold: would standardisation limit the testing and adoption of new ideas and look what happens in the name of a profession in some other fields.
- Consider if we had become a profession 10-15 years ago. Waterfall development and lengthy reviews of every output would be mandatory. How Agile, Lean and the related engineering practices have grown up in that environment? If we standardised today how would we improve on what we have now.
- Also be careful of the professional bodies you seek to mimic. The American Psychiatric Association has in recent years defined a number of diseases largely based on the lobbying of drug companies that wish to cure them. I shudder to think what the right people with money would do to the Software Professional Association.
So I agree with Scott this industry needs a shake up and we need to seriously consider how to get better. But I think that becoming a profession is the wrong path to take.
I look forward to hearing other opinions.
If you enjoyed this post, subscribe now to get free updates.
Kate Oneal: Diet Cola With Carl (XProgramming.com)
Where's the money? (Simon Baker)
| Women's | Men's | |
|---|---|---|
| Weekly demand | 120 | 120 |
| Price | 105 | 100 |
| Raw material cost | 45 | 50 |
| Cutting time | 2 | 10 |
| Sewing time | 15 | 10 |
| Total process time | 17 | 20 |
Each machine has an operating capacity of 2400 minutes per week and the company's weekly operating expenses are £10,500.
| Machine | Minutes necessary for women's shirt | Minutes necessary for men's shirt | Total minutes necessary | Necessary minutes / available minutes |
|---|---|---|---|---|
| Cutting | 240 | 1200 | 1440 | 60% |
| Sewing | 1800 | 1200 | 3000 | 125% |
Clearly, there is not enough capacity at the sewing machine to satisfy the market demand for both types of shirt. The company does (maybe) the obvious thing and focuses on the most profitable product. It satisfies all the demand for the most profitable type of shirt first and then uses the remaining time at the sewing machine to make the other type of shirt. The women's shirt is more profitable. It sells for more, fabric costs are less and it is quicker to make. The company can make 120 women's shirts using 1800 minutes at the sewing machine. The remaining 600 minutes at the sewing machine allows us to make 60 men's shirts.
| Revenue from women's shirts (£105 x 120) | £12,600 |
| Revenue from men's shirts (£100 x 60) | £600 |
| Total revenue | £18,600 |
| Raw material cost for women's shirts (£45 x 120) | £5,400 |
| Raw material cost for men's shirts (£50 x 60) | £3,000 |
| Total raw material cost | £8,400 |
| Gross margin | £10,200 |
| Operating expense | -£10,500 |
| Net profit | -£300 |
By focusing on the most profitable shirt the company ends up making a £300 net loss every week.
Say the company did something else. Let's say it decides to make 120 men's shirts and use the remaining time at the sewing machine to make women's shirts. 120 men's shirts use 1200 minutes at the sewing machine. The remaining 1200 minutes at the sewing machine allows us to make 80 women's shirts.
| Revenue from men's shirts (£100 x 120) | £12,000 |
| Revenue from women's shirts (£105 x 80) | £8,400 |
| Total revenue | £20,400 |
| Raw material cost for men's shirts (£50 x 120) | £6,000 |
| Raw material cost for women's shirts (£45 x 80) | £3,600 |
| Total raw material cost | £9,600 |
| Gross margin | £10,800 |
| Operating expense | -£10,500 |
| Net profit | £300 |
By increasing the production of the least profitable product while decreasing the production of the most profitable product the company ends up making a £300 net profit every week. Conventional cost accounting wants to minimise the cost of making a product based on the assumption that the lower the cost of a product, the greater the company's profit. One element in the cost of making a product is the time the product uses company resources. Therefore one way to reduce the cost is to reduce the time at a machine.
For a £100 investment we can reduce the cutting time of a men's shirt from 10 to 8 minutes. That's a 10% reduction in the total process time for a men's shirt, down 2 minutes from 20 to 18 minutes. This is a good investment from a cost accounting perspective. Trouble is it won't increase the overall net profit. The company will still have the same bottleneck on the sewing machine so it can't produce any more shirts than it could originally. The weekly net loss is worse, -£302 (net loss plus -£2 which is approximately the investment of £100 spread over 52 weeks).
For a £1000 investment the company can decrease the sewing time of a women's shirt by 1 minute and increase its cutting time by 3 minutes. This increases the total process time for a women's shirt by 2 minutes. Cost accounting would probably reject this because it increases the product cost. However, by reducing the sewing time required by women's shirts the company has effectively created more capacity at the sewing machine, which allows it to make more women's shirts and satisfy more of the market's demand.
| Revenue from men's shirts (£100 x 120) | £12,000 |
| Revenue from women's shirts (£105 x 85) | £8,925 |
| Total revenue | £20,925 |
| Raw material cost for men's shirts (£50 x 120) | £6,000 |
| Raw material cost for women's shirts (£45 x 85) | £3,825 |
| Total raw material cost | £9,825 |
| Gross margin | £11,100 |
| Operating expense | -£10,500 |
| Investment | -£20 |
| Net profit | £580 |
By increasing the process time of a product, and therefore increasing its cost, the weekly profit has almost doubled.
A company's capacity to produce and sell product is a system or chain of interdependent activities. Trying to maximise profits by cutting costs and investment will eventually damage a company's capacity to make sales. The goal of every company is to make money, not to save costs. Capacity should be protected. A company should do everything possible to uncover excess capacity (by eliminating waste and re-evaluating how things are working) and find new ways to use its existing system and the costs built into it to generate more profit without significantly increasing investment. Then it should look to reduce investment (because that increases Return On Investment) but only by producing less inventory, i.e. product that has not been sold. Cutting costs is the easy option - it should be the last option a company considers.
Tags: value, throughput accounting
ANSI Art Extravaganza (Sammy Larbi)
The Art of Agile Development: Real Customer Involvement (James Shore)
| 23 Apr 2008 | James Shore/Agile-Book |
in 99 words
To widen your perspective, involve real customers. The best approach depends on your market.
Personal development: you are the real customer. Congratulations. Go forth and write algorithms.
In-house custom development: turn your real customers into on-site customers.
Outsourced custom development: get real customers to be on-site customers. If you can't, stay in touch and meet face-to-face frequently.
Vertical-market and horizontal-market software: beware of giving one customer too much control. Appoint a product manager to understand customer needs. Create opportunities to solicit feedback. Examples: customer review board, beta releases, and user experience testing.
as haiku
roses, cucumbers--
I chose beauty, but Sensei
desires to eat
Download this poster!
Inside This Section
- Real Customer Involvement
- Personal Development
- In-House Custom Development
- Outsourced Custom Development
- Vertical-Market Software
- Horizontal-Market Software
- Questions
- Who should we use as on-site customers when we can't include real customers on the team?
- We're creating a web site for our marketing department. What kind of development is that?
- Results
- Contraindications
- Alternatives
Commentary
It's all about communication.
I like to say that successful software requires three components: organizational success, technical success, and personal success. Organizational success because we need to turn a profit, or realize some other sort of value. Technical success because we don't want to throw away the software and rewrite it every few years.
What about personal success?
When Shane and I were first writing the book, I thought of personal success from the perspective of the development team. "Without personal success, you'll have trouble motivating yourself and employees," we wrote. And that's true. In thinking about it further, though, I've come to realize that personal success is much more important than that.
Much as we might like to believe otherwise, we humans are fairly irrational creatures. We tend to make decisions for emotional reasons rather than logical reasons. That's where personal success comes in. You might be building the best thing in the world, but if your project doesn't make the person thinking about it feel good--if it doesn't contribute to her personal success in some way--she's not gonna love it. And if she doesn't love it, she's not likely to push it. And if nobody else important pushes it either... goodbye, project. The end.
It gets worse. Sometimes the need for personal success leads to sabotage. True North pgs tells the following (true) story in their Mastering Projects workshop:
Jerry was furious [about his project being cancelled]. After investing so much time and energy in the project, he was intellectually convinced of its importance and he was emotionally committed to it. Could the company be this stupid, he wondered? Do I really want to work for a company that is this stupid?
At 4:45 p.m. Jerry resigned and went home. His boss called him two or three times the next day, but Jerry refused to take the calls. It took him a week to get over his rage. It took another six weeks to get a new job.
Shortly after Jerry started his new job, he received a call from an old friend still working for his previous employer. Jerry's friend related a story that was circulating among some of the people there. The story went like this: An executive in the Sales Department learned of Jerry's project about three weeks before the project was terminated. According to the story, he instantly disliked the idea, basically because selling the equipment would require a knowledge of hospitals and medical-purchasing practices that his sales force did not have. So, according to the story, he got one of his people to fabricate some very pessimistic numbers about market potential. He sent these numbers to a marketing executive, who was also a good friend, along with a note asking, "Why are we wasting research on this project?"
True North pgs., "Mastering Projects Workshop."
Adapted from John Kotter's Power and Influence, 1987.
Personal success. It's so damned personal.
So. Keep personal success in mind. Not only do you need the support of important stakeholders, you also need to avoid sabotage. How? Talk to people. Find out what their interests are. Watch for little reactions when you describe various features. Ask if your needs make their lives difficult. Offer to help ease their pain. Give them a chance to be a part of your success.
It's all about communication.
Rasta supports data-driven testing (Bret Pettichord)
FOAF Images (Ian Davis)
Back in 2002 I submitted four cute faces as my entry in the informal FOAF icon competition. Now those images are pretty ubuquitous but somewhere in the intervening years and server moves the page I maintained linking to them disappeared. With a nudge from danbri I put together a new page to serve as their home: http://iandavis.com/2006/foaf-icons/
Kate Speaks: Background and Prologue (XProgramming.com)
Upgraded to Wordpress 2.5 (Ian Davis)
I finally made the upgrade. Some things might be a bit wonky around here, especially as I converted all my categories to tags. Expect some broken links and feel free to comment here if you spot anything missing. On the plus side, I added a new Sitemap-style page
Cloud Security (Ian Davis)
Just came across a new blog called Cloud Security by Craig Balding that looks to have a lot of potential. Cloud computing is definately the trend du jour and we need more discussion and information around the security of cloud services.
Wonder if it’s this Craig Balding?
One for the subscription list…