The Dream Team Nightmare
It took a while to arrive because the book was out of stock at Amazon, but it’s finally here, just in time for the holiday break: Portia Tung‘s “Dream Team Nightmare“!
I sat down with a cup of coffee and started to read the book. Portia’s writing style is engaging [...]]]>
The Dream Team Nightmare
It took a while to arrive because the book was out of stock at Amazon, but it’s finally here, just in time for the holiday break: Portia Tung‘s “Dream Team Nightmare“!
I sat down with a cup of coffee and started to read the book. Portia’s writing style is engaging and lively with lots of dialogue and very short chapters. At the bottom of the chapters you have to make a choice and then go to a designated page.
I’ve been on agile projects for years, so I expected to breeze through the book. After all, most teams face the same problems. I’ve solved them many times. Why should this “Dream Team” be any different?
After only a few pages I read
Patrick [who hired you as an agile coach] asks his secretary to escort you out of the office. Before you know it, you’re back on the street.
It feels like you’ve been punched in the gut. Thoughts swirl in your head. Should have. Would have. Could have. You decide to take time out to reflect on what happened. You’re not quite ready to give up doing a job you love. not yet.
THE END
Fired! On my first day. Game over. Do you want to play again? Of course, but now I’ll make smarter choices.
And… I was asked to leave the Dream Team and see if things would go better with another team. THE END.
“If at first you don’t succeed, stubbornly try again and again”, that’s my motto. So, one more try.
Aha! We come to a part where my mission is described as a user story with acceptance tests. That will help me to understand better what’s expected. I restart the book and start working with the team. I flip backwards and forwards as the book directs me to see the consequences of my choices. It’s getting smoother. And then there’s a conflict with one of the team members. At the end of the 5 days I present my recommendations. And then… nothing happens. THE END.
This agile coaching lark is harder than it looks.
This is frustrating. I’ve only scratched the surface of the book, read a few chapters and each time I reach a dead end. Reminds me of some projects I’ve been on.
And then I have a brilliant idea.
What would Portia do?
I’ve been lucky to work with Portia and see her at work. I will restart the last time and at each choice ask myself “What would Portia have done in this situation?” Portia would
- talk to everybody to understand what motivates them
- help the team to make their own decisions
- reach agreement on the value we’re creating
- get a good understanding of where we are
- define goals together and clarify them with testable acceptance criteria
- take some time to reflect regularly
- help the team to create and explore options
- lighten up the mood with silly exercises like “profile cards“, cookies and team lunches
I can do that. It’s just a matter of taking a bit more time before making a decision. Let’s start again, from the top.
This time, with the help of Portia (sometimes in the role of Jiminy Cricket to keep me on the straight and narrow, sometimes as the Blue Fairy who grants wishes and saves the day) I progress through the book. There are still a few choices, but fewer and fewer.
The team starts working together to visualize their situation. Faced with the enormity of their task, they feel demoralized. We come up with three options to deliver value and involve the Product Owner.
And there it gets tricky. If I’m not careful, the unspoken simmering conflict between team and product owner/management erupts again: the company needs more than the team can deliver; the team blames the product owner for imposing unrealistic scope and deadline. THE END.
And that’s where it usually ends, but there’s another option. There’s always another option.
Instead of saying “It’s impossible to deliver this scope by this deadline!” you can ask “What do we need to achieve the goal before the deadline?” Two other agile teams “Predator” and “Green” can help the Dream Team. The teams apply Real Options to decide on the day when they have to decide. Meanwhile they create and explore more options to achieve the company’s goal: different ways to select scope and divide the work between the teams.
Finally, a happy end
From there it’s relatively smooth sailing. By now I see the trap on page 216, where I fail to ask the team to review and improve my recommendations because I’m rushed, coming by a mile. If only it were this easy in real life to take a step back for a moment and take the time to think…
And then we arrive at the final chapters: the team present their delivery options and their improvement actions. Everybody’s energized to work on those actions. I don’t know if they’ll live happily ever after, but the adventure continues.
THE END
Observations and recommendations
- There’s a list of recommended tools on page 203. Appendix 5 contains the coaching tools used in the book. It would be useful to have some links where I can find out more about each of the tools. Maybe something for the Agile Adventure site?
- I loved seeing the Current and Future Reality Trees in use. It would have been great to see a “Conflict Resolution Diagram” be used to bridge the gap between root causes and improvement actions. What are the underlying conflicts that have led and kept the team in its unhappy situation? Maybe something for the next agile adventure?
- Flipping back and forth between chapters isn’t always practical in a paper book. But you can have your cake and eat it too. I bought both the paper and e-book version: the e-book to play, the paper book to loan
- There are a few illustrations in the book: current/future reality trees, profile cards. A few more illustrations would have made the story a bit more vivid: what does the kanban board look like? What does the team area look like? No need to make it into a graphic novel. Henrik Kniberg‘s “… from the trenches” books are a good example of how illustrations can make the story more vivid.
Done. What’s left on the holiday reading backlog?
Some more light reading, because I don’t want to be that agile coach who hasn’t written production code for a decade.
 
Can anyone recommend a good e-book about Clojure that covers core.async?
]]>It provides an excellent environment for exchanging ideas, hands-on exercises and extreme experiences.
The best way to learn is to facilitate a session. We like sessions where you explore ideas as well as questions.
[...]]]>It provides an excellent environment for exchanging ideas, hands-on exercises and extreme experiences.
The best way to learn is to facilitate a session. We like sessions where you explore ideas as well as questions.
The conference will be held on 28 and 29 November, 2013 in Mechelen, Belgium.
The best way to learn is to facilitate a session at XP Days!
We’re looking for sessions where you explore ideas as well as questions. Sessions that dig deeper, going beyond the basic techniques and practices. We really want to find out why/how things work or don’t work. We invite you to propose:
- hands on coding/design/architecture sessions;
- discovery sessions – open ended workshops that explore new topics, common problems, promising techniques, or burning questions;
- experiential learning sessions; get people learning by doing & reflecting; for example games or simulations.
We’re not only interested in agile and software related topics but we also want to explore boundaries and cross borders. What can we learn from other disciplines or sciences?
Available timeslots are 75 and 150 minutes.
We also welcome short experience reports (30 minutes) that focus on what didn’t work and why.
Do you have an interesting story, idea or question?
Send us your session idea today.
What’s so special about XP Days?
For one thing, we constantly try to apply XP, agile, lean, systems thinking, theory of constraints and all the other stuff we talk about. It wouldn’t be an agile conference if it wasn’t organised by using agile values, principles and techniques.
For example: how is the way we build the program agile?
Collaborating to get the best possible sessions
We don’t think BDUF is appropriate or possible, not even for a session description. Therefore, we ask session authors to send in a simple proposal: title, subtitle, presenters, description. It’s the equivalent of a story card: the promise for a conversation about the session.
Once the proposal is sent in, the author(s) can incrementally fill in more information, as the session becomes clearer. There’s a separate deadline for submitting proposals (July 13th) and finalising the proposals (August 28th), to avoid “student syndrome” and last-minute session hurried submissions. Within those two timeboxes, the authors work at their own (sustainable) pace.
Session authors help other session authors by asking questions and giving feedback using the “Perfection Game“. The proposal authors (and the conference organisers) act as “peer coaches“. Through the magic of questions and feedback, the proposal author iteratively improves their proposal(s). Aren’t session authors helping their “competitors” in the race for a place in the program? We typically get 3 proposals per slot, so the competition is fierce. Well, nobody said collaboration was easy. In the end we all benefit from a better conference program. And the organisers see who applies the agile values and who just talks about them.
Isn’t this coaching only useful for beginners? It certainly helps new presenters to marshal their ideas. But, as we’ve experienced while pair programming, experienced presenters get new insights and clarity when “juniors” ask naive questions.
The most powerful coaching questions focus on goals and benefits for participants. Why should someone come to this sessions? What is the one idea you want to get across? What will participants be able to do after attending this session that they couldn’t do before? How will you know this session was a success for participants?
A common problem with session proposals is that the authors try to “pile on” too many ideas. The usual session feedback reads “not enough time”. The solution is not to take more time, but to present less material more thoroughly. Think deeply: what is your Minimum Viable Product? If there’s any time left in your session you can spend it on interaction with participants and exploration of your central idea, rather than adding more ideas.
Release early, release often
A session proposal is not a session. You may have created the greatest session proposal, that doesn’t mean you’ve got the greatest session. There’s only one way to know if your session design works: implement it, release it and get feedback from participants. We therefore encourage presenters to do “tryouts” of their session. We offer places to do this at the Agile Belgium and Agile Holland meetups. You may be able to schedule a tryout at a local user group or in your company. Or just invite a few friends and colleagues to try out your session.
Seasoned presenters know that it takes at least three iterations to get all the details and the timing right.
Preparing to select sessions
Now that we’ve iteratively improved session descriptions, the most difficult task is to select the sessions for the program.
Near the end of the session improvement process we ask all session authors to select the sessions they want to see in their “ideal track”. We use these votes as a start of our selection process.
We also use these votes to calculate the “value” of a draft program. We do this by calculating the Program Attendance Factor (PAF) for each voter. The PAF value indicates how many of their preferred sessions a voter can attend, given the layout of the program. To count, a preferred session must be in the program and it must not be at the same time as another preferred session. A program that has a higher total PAF has more value for voters, because they can attend more preferred sessions.
In preparation for the program committee meeting we create a card for each session. Making a conference program requires a lot of visual management:
- The color of the card indicates the type of subject so that we can quickly see if the program has a good balance of sessions
- The names of the presenters are clear so that we can ensure no presenter has more than one session in a day (sustainable presenter pace)
- The card has coloured dots to indicate the type of session and the experience level so that we can see at a glance if there’s a good balance for participants with different learning styles and experience
- The cards have different sizes representing session length so that we can’t put them in program slots of the wrong size
The program committee reviews all session proposals before the program committee meeting. There are so many proposals that program committee members can’t review or even read them all. Therefore, the committee divides the sessions among its members and trusts that the other members have good judgment.
Before the program committee meeting, the proposals are put into four categories:
- the sessions we really want to see in the program. Each program committee member can “champion” a session
- the sessions that we won’t consider because they’re incomplete, withdrawn or inappropriate
- the sessions that were selected in the voting process
- other sessions
Sessions on the board
We have large sheets of paper that represent each of the days with drawn slots that are just the right size for the session cards.
Building a program happens in three rounds:
- Create a first version by putting the championed and most voted for sessions in appropriate slots. We do this track per track. For example: first fill a track on both days with technical sessions, then fill a track with process sessions… It’s OK if some slots are still empty.This first step should go quite quickly, without too much discussion. The goal is not to create a perfect program; it’s not even a workable program. We just need a version to start iterating.
- We spot a constraint violation, for example. a presenter who does two sessions in one day or we’ve selectedtoo many sessions of one type or subject. We resolve the constraint by swapping the problem session with another same-sized session already on the board or not on the board. We may also spot improvements in balance or PAF score. These are also performed using swaps. The only constraint is that we can’t introduce constraint violations by this swap. We keep iterating until the program stabilizes. We select a few “backup” sessions that we can add to the program in case one of the selected presenters can’t come.
- We internally publish a draft version of the program. All organizers can review the program at their leisure to spot any constraint violations or improvements. We often have to take a bit of distance to spot these. When nobody has any more improvement ideas, we contact the authors of selected and rejected proposals. Sometimes presenter availability can introduce new constraints (for example, the presenter can only be present on the first day but his session is scheduled on the second day). In that case, we go back to swapping sessions to resolve the constraint.
- DONE. Until something happens like a presenter dropping out.
Getting better
We continuously improve this session proposal-improvement-review-selection process. We’ve incrementally built a tool that supports our workflow. New features get added just-in-time as we notice irritations or get new ideas for improvement. Most of the organisers participate in other conferences where we “‘steal” the best ideas. In return, we invite everybody to “steal” any idea they like.
In summary: creating a proposal, growing and refining it, coaching other to improve their proposal, doing tryouts and refining the session is a lot of work. And then you might not even get selected because there are so many great proposals.
Is it worth it? What’s the worst thing that could happen? You spent some time to understand an interesting subject better. That’s not so bad, is it? If you get selected or if you just attend, you get to spend two days with open, intelligent, helpful and experience people to explore and discover interesting new ideas and problems. And one of those ideas or problems could be yours.
]]>It may not be immediately obvious, but the way your company manages its finances, costs and budgets has a profound effect on the way projects or products are started, run and terminated. You may have been in situations where you sat back in amazement at some incomprehensible management [...]]]>
It may not be immediately obvious, but the way your company manages its finances, costs and budgets has a profound effect on the way projects or products are started, run and terminated. You may have been in situations where you sat back in amazement at some incomprehensible management decision and thought “what were they thinking?”
They were probably thinking about budgets and costs. You will be surprised again next time unless you learn to understand and dialogue with your CFO and cost accountants.
Fun with cost accounting
Pierre Hervouet and I have created a session that explains the basics of cost accounting (based on making and pricing cocktails) and presents three alternative views you may find useful:
- Throughput Accounting
- Lean Accounting
- Beyond Budgeting
The session doesn’t certify you as an accounting master, but it provides food for thought and pointers to plenty of material you can dig into if you want to know more. The materials (currently only in French) are published on the agilecoach site.
Join the conversation
Why don’t you go see your CFO or cost accountants today? Ask them what’s keeping them up at night. You may discover that you face much the same issues and that the solutions are similar. Yes, yes, accounting and budgeting are getting more agile, more lean!
The Agile Alliance has a new “Agile Accounting Standards” program to “Engage with FASB‘s Emerging Issues Task Force to promote and develop an Agile Accounting Standard that will better define and standardize internal IT development costs for organizations that use an iterative or agile software development methodology” because  “The phased gate language [of the current standard] results in significant confusion and challenges of interpreting how to map the iterative work that happens throughout an Agile project lifecycle and is becoming an increasing urgent issue.“
]]>In a previous post I described how we performed a root cause analysis for a simple bug: one incorrect value in a dropdown. Performing such a heavy analysis (which generates a lot of rework) may not be appropriate for every bug.
Here’s [...]]]>
In a previous post I described how we performed a root cause analysis for a simple bug: one incorrect value in a dropdown. Performing such a heavy analysis (which generates a lot of rework) may not be appropriate for every bug.
Here’s how another team handled a very similar bug: one value missing from a dropdown.
The fast way to deal with simple bugs
- There’s a bug: in one screen one of the dropdowns misses one value: “X”. This bug is unexpected: in all other screens the behaviour of the dropdowns is correct, each of them contains “X” as the final and default value. This bug only appears in one screen. Why only this screen? What’s so special about this screen? Isn’t this the same code for all dropdowns with the same behaviour?
- The bug is reported during internal testing. The bug can be repeated very easily.
- Developers grumble (I told you the “Thank you” step in the ” algorithm to write perfect code” was difficult!)
- A developer takes the bug and fixes it: an extra value “X” is added to the dropdown in the screen
- Tester validates: go into the screen; open the dropdown; the value “X” is there. Bug closed.
- Software gets shipped to customer
- Done. Next bug!
Easy.
A few days later…
- Customer files a bug report: each time they enter this specific screen an “X” gets added to the dropdown. Enter the screen twice, you see “X” “X”. Enter again, you see “X” “X” “X”. And so on…
- Developers grumble: “Not another stupid bugreport!“
- A developer takes the bug and analyses it. “Some idiot has added ‘X’ to this dropdown. Let’s remove that.“
- Tester validates: go into the screen; open the dropdown; no “X” is added. Bug closed.
- Software gets shipped to customer
- Done. Next bug!
Easy. Only took a few minutes to fix and (a few days later) a few minutes to test. And another release to build, ship and install.
A few days later…
- Customer reopens their bug report: when they enter the screen, there is no “X”. To be clear: they expect exactly one “X” in this dropdown (and all similar dropdowns in other screens). Not zero. Not an infinite number.
- Developers grumble. “When will they make up their mind?“
- Developer takes the bug and fixes it: an “X” is added to the dropdown unless there’s already an “X” in the dropdown
- Tester validates: go into the screen, one “X”; go into the screen again, still one “X”; go into the screen again, still one “X”; go into other screens; go into this screen, still one “X”. Stop the application. Restart the application. Go into the screen, one “X”; go into the screen again, still one “X”. Bug closed.
- Software gets shipped to customer
- Done
Easy. Only took an hour or two to fix and (a few days later) an hour to test. And another release to build, ship and install.
And they all lived happily ever after
Except for the customer who grumbles “how can I trust them with the important stuff if they can’t get the simple stuff right?”
Except for the developers who grumble “how can we get any work done if we have to keep fixing these stupid bugs?”
Except for the testers who grumble “why do we have to retest every bugfix a thousand times? Can’t ‘they’ get things right the first time? We need fewer releases, more detailed specs, more elaborate test scripts, more time to test and, above all, a lot more testers to get any quality in this application.“
]]>A simple algorithm to write perfect code
You don’t have to watch the presentation. The message is this: each time there’s a bug:
Someone finds a [...]]]>A simple algorithm to write perfect code
You don’t have to watch the presentation. The message is this: each time there’s a bug:
- Someone finds a problem and reports it to you
- Thank the reporter
- Reproduce the problem
- Add (at least) one failing test
- Correct the problem
- Rerun all tests and correct your correction until the tests pass
- Improve your tests
- Improve the way you write tests
- Look for similar problems. Goto 2
- Make this type of problem impossible
- Perform the actions that were identified during the Root Cause Analysis
But that’s just common sense!
We’re all agile lean continuously improving test driven extreme programmers, aren’t we? Doesn’t everybody do this?
Yes… but…
- It takes too much time
- We can’t do this for every bug because we’ve got too many bugs
- We don’t want to waste time on bugs, we prefer to spend time adding valuable features
- As Dijkstra said: “ program testing can be a very effective way to show the presence of bugs, but it is hopelessly inadequate for showing their absence.”
- <your objection here>
Just a little taste
The presentation tells the story of a team that performed a Root Cause Analysis. Here’s another team’s story:
Coach: Can we try a small Root Cause Analysis experiment?
Dev: Yes, but… we don’t have a lot of time.
Coach: Do you have one hour? We can timebox the experiment.
Dev: Sure, but… you can’t do anything useful in one hour.
Coach: Maybe you can’t; maybe we can.
Dev: ???
Coach: Have you seen any interesting bugs lately?
Dev: Well, I just fixed a bug. But it’s so trivial you won’t discover anything useful.
Coach: Thank you! Let’s see.
I love clear bug reports
First we look at the bug report:
GIVEN a swizzled foobar (*) WHEN I change its properties THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status BUT I'm offered 'A', 'B' or 'C' (*) all names of domain objects have been changed to protect the innocent and the guilty
Let’s apply the algorithm
Coach: have you thanked the reporter yet?
Dev: no…
Coach: Let’s do it now.
Dev: ok… <Calls product Manager>
Dev: Hi, I just called to thank you for reporting the bug about the property dialog of the swizzled foobar.
Product Manager: <surprised> OK…
Dev: The report was so clear the bugfix almost wrote itself. Thanks!
Product Manager: You’re welcome!
Coach: OK. We’ve now done the hardest part; Let’s do the next steps.
Next step: reproduce the problem. That’s quite easy: start up the application, select a foobar, swizzle it and open its property dialog. Look at the dropdown control for the status: it presents options ‘A’, ‘B’ and ‘C’.
Coach: We have a manual test procedure. Can we automate this test?
Dev: No. This is user-interface code. We’ve performed some experiments earlier and decided that it wasn’t worth the time and effort to create and maintain automated tests for the user interface.
Coach: OK.
Fix and Test
The fix was really simple
Buggy :
status.add('C') ;
Fixed :
if (foobar.swizzled()) {
status.add('Z') ;
} else {
status.add('C') ;
}
Rerun the application, perform the manual test: the correct options are now offered.
Result! Bug fixed! High Five! Job well done.
Hmmmm… The fix is indeed simple and the bug is now gone. But that IF is worrying. I’ve seen (and had to maintain) code that was riddled with IFs: each time a bug was detected, the developers added an IF for the specific conditions and expected outcomes described in the bugreport. Let’s add a post-RCA action: let’s read and discuss the ANTI-IF campaign.
Dev: You see now: this is a trivial bugfix, there’s nothing to learn here.
Coach:Maybe. We’ve only spent 10 minutes yet. Let’s see the rest of this code
Show me the code
If I take off my glasses, squint a bit and look at the code, this is what I see:
void showProperties(Foobar foobar) {
}
Red lines are user interface code, calls to the UI toolkit. Green lines are simple java, C#, ruby… UI-independent code.
Guess where the bug is… In the Green code. But we can’t test it, because we can’t test user interface code. So, that doesn’t help us.
A small step for a programmer…
We don’t have any tests, so any refactoring is going to be risky. Let’s do some simple, safe refactoring: let’s move all the Green and Red code together.
Now the code looks something like this:
void showProperties(Foobar foobar) {
}
Exactly the same code, it does exactly the same thing. What have we achieved? Nothing. Yet.
Another small step
Now that we’ve got all the green code together, what does it do? Essentially, it fills in a number of variables (like the list of values for the status), which are filled up with values to put into the UI controls.
Let’s do another small, safe refactor:
- Create a new class. I don’t have a good name yet, let’s call it “Stuff” for the moment
- Move every local variable in the green code into the Stuff class
- Create an instance of Stuff in the function
- Fill in all fields of the instance, just like you fill in the local variables
Again, nothing really changes. We’ve just collected all local variables in one object.
Our code now looks something like this.
void showProperties(Foobar foobar) {
// GREEN
Stuff stuff = new Stuff() ;
stuff.status.add('A') ;
stuff.status.add('B') ;
if (foobar.swizzled()) {
stuff.status.add('Z') ;
} else {
stuff.status.add('C') ;
}
....
// RED
statusDropdown.setOptions(stuff.status) ;
}
Finally, a real refactoring
Now the code has been reorganised, we can finally do a real refactoring, still taking small steps because we’re working without a safety net.
Let’s extract the green and red code in separate methods. Our code now looks like this:
void showProperties(Foobar foobar) {
// GREEN
Stuff stuff = prepare(foobar) ; // TODO: find a better name
// RED
display(stuff) ;
}
Note to self: “Stuff” and “prepare” aren’t very descriptive. That’s probably because we don’t understand the code well enough yet. Let’s revisit naming when we understand better.
We’re now 30 minutes into the Root Cause Analysis
A giant leap for testing
Aha! We now have a method “prepare” which contains the bug AND doesn’t depend on the UI. Can we test the code now? Yes we can!
void swizzledFoobarsHaveZStatus() {
// GIVEN a swizzled foobar
Foobar foobar = makeAFoobarSomehow() ;
foobar.swizzle() ;
// WHEN I change its properties
Stuff stuff = foobarPropertyDialog.prepare(foobar) ;
// THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status
assertEquals(3,stuff.status.getSize()) ;
assertEquals('A',stuff.status.get(0)) ;
assertEquals('B',stuff.status.get(1)) ;
assertEquals('Z',stuff.status.get(2)) ;
}
This test fails before the fix. It succeeds after the fix. We now have an automated regression test for this bug.
Improve your tests
This test raises a lot of questions:
- What if the foobar isn’t swizzled? Are the options ‘A’, ‘B’ and ‘C’ correct in this case? Should we add a test?
- Are there any other special cases for status depending on the properties of a Foobar?
- Are there any other fields that depend on the properties of the Foobar?
- Are there any other properties of the domain that are important?
- ….
This could be the start of a really great conversation with the Product Manager and testers!
Result: we’re 45 min into the RCA and we’ve written an automated regression test of that bug in supposedly untestable code.
Names
Those stupid names “Stuff” and “prepare” irritate me. Now that we’ve got automated tests for this code, we can refactor more audaciously.
What is “Stuff”? It contains the data as its shown in the View of the Foobar property dialog. It’s a ViewModel. Let’s rename it to FoobarProperties.
What does “prepare” do? It creates a FoobarProperties and stuffs values into it. What does FoobarProperties do? Nothing, it just sits there and contains these values. We might as well move the code from prepare into FoobarProperties:
void showProperties(Foobar foobar) {
FoobarProperties properties = new FoobarProperties(foobar) ;
display(properties) ;
}
And now the unit test becomes a unit test of FoobarProperties, a pure processing class, no longer of the mixed processing/UI class FoobarPropertyDialog:
void swizzledFoobarsHaveZStatus() {
// GIVEN a swizzled foobar
Foobar foobar = makeAFoobarSomehow() ;
foobar.swizzle() ;
// WHEN I change its properties
FoobarProperties properties = new FoobarProperties(foobar) ;
// THEN I EXPECT to be offered a choice between 'A', 'B' or 'Z' for the status
assertEquals(3,properties.status.getSize()) ;
assertEquals('A',properties.status.get(0)) ;
assertEquals('B',properties.status.get(1)) ;
assertEquals('Z',properties.status.get(2)) ;
}
Improve the way you test
Now that we have a unit test for FoobarProperties we can add more tests for different cases. Looking at those tests we’ll see that some properties of a Foobar are independent of its state. E.g. we always have a status ‘A’ and ‘B’. We can include those invariants in our tests. We’ll talk with the Product Manager first and together extend the testcase.
We can now see that we consider too much code as “UI code” and therefore not testable. If we separate ViewModel code from View code, we can cover more code with fast unit tests.
Look for similar bugs
Coach: are there other places in the UI where we display or change the status of a Foobar?
Dev: Yes… Maybe 3-4 screens and dialogs
Coach: Did we make the same mistake there?
Dev: Let’s quickly test the application. It would be quite embarassing if we got the same bug report for another screen…
Dev: Ooops! We made the same mistake in one other dialog. The other dialogs are OK.
Coach: Let’s note the dialog to be fixed and move on, because we’ve only got a few minutes left in our timebox and I’d like to do the next step first before fixing this bug.
Dev: What more can we do?
Make this type of problem impossible
Now, before we fix the buggy dialog, we’ll apply the same safe refactorings to make the code testable, add tests to demonstrate the bug (and serve as regression tests once the bug is fixed) and then fix the bug. If we consistently test our ViewModel code and validate our ViewModel behaviour with the Product Manager, we’re less likely to overlook certain cases.
The fact that this bug appears in some dialogs and not in others tells us that we’re looking at different code. Some code takes into account the “swizzledness” of a Foobar, some code doesn’t.
But we can do better: why is this code duplicated? Ideally, we’d want one instance of the code that decides which status options to show. Otherwise, if the rules change (or more likely, if we discover we’ve missed an existing rule) we’ll have to remember to update all the pieces of code that determine status options of a Foobar. So, once we’ve extracted and fixed the ViewModels from both our buggy Dialogs, we’ll extract the common code that determines the status options. Of course, this common code will have unit tests that verify this common behaviour.
Afterwards, we’ll do the same to the Dialogs that were implemented correctly. We can do this refactoring gradually, once the two bugs have been corrected. Ideally, we’ll do this if we have to change the code of those Dialogs anyway, to fix a bug or add a feature. Even if we don’t touch these classes, we’ll make sure we refactor them within X time, so that we don’t have to remember these “dangling” refactorings too long.
Some developers have taken the “swizzledness” into account, some haven’t. Let’s share our findings with the team and the Product Manager. We may have to organise a session to clarify some of the subtleties of our domain. Once they’re clear we can encode and document them as automated regression tests, so that we get a failing test next time we forget to take into account one of those subtleties.
Dev: Hey, coach, your hour is up! Shall we get a coffee?
Coach: Great! Let’s step away from the keyboard
Looking back (over a cup of coffee)
What have we done in 60 minutes?
- Isolated code that contains a bug from “untestable” code
- Added an automated test that shows the bug and can be run as a regression test after the fix
- Simplified the code by separating the ViewModel from the View
- Identified a new class of testable code, the ViewModels
- Found another bug before anyone noticed
- We know how to make code testable and better factored for this type of bug
- We know how to avoid this type of problem and be ready for changes in the domain
Looking forward
During the Root Cause Analysis we noted a number of actions to be taken. We make each of these tasks visible (for example, by adding them to the Kanban board):
- Extend the FoobarTest to cover more cases, in collaboration with the Product Manager and testers
- Test and fix the second Foobar status bug
- Make the code that determines the allowed status values common between the two bugfixed dialogs. Validate tests with the Product Manager
- Refactor the other dialogs that display Foobar statuses so that they use the common code
- List the subtleties of the domain and organise a knowledge sharing session with the Product Manager
- Ask the team to review and discuss the ANTI-IF campaign
- Let’s read some more about ViewModel architectures. If it looks useful we’ll make this a standard way of designing our user interfaces. If we do, we’ll have to see how we transition gradually to such an architecture.
Dev: Well… I never expected so many issues and ideas to come out of a Root Cause Analysis of such a simple bugreport. Let’s hope we don’t do too many of those Root Cause Analyses, because they generate a lot of work.
Coach: ????
Dev: That was a joke, coach.
I’m sold. Now, let’s get back and fix that bug we found.
]]>
Devoxx fr 2013 Real Options – Comment et Quand (ne pas) prendre des décisions from AgileCoach.net [...]]]>
On Friday march 29th I’ll present a session about Real Options and other techniques to take better architectural decisions at a better moment. Billions of years of evolution have equipped us with these wonderfully irrational brains that sometimes get in the way of making good decisions. With a few simple but counter-intuitive [...]]]>
On Friday march 29th I’ll present a session about Real Options and other techniques to take better architectural decisions at a better moment. Billions of years of evolution have equipped us with these wonderfully irrational brains that sometimes get in the way of making good decisions. With a few simple but counter-intuitive techniques we can make our decisions a bit less stressful and more useful.
See you in Paris.
Vous avez encore jusqu’au 2 mars pour envoyer vos “pitch” pour des sessions. Il ya déjà plusieures excellentes propositions. J’envoie ma proposition dans quelques instants.
Qu’est-ce que [...]]]>
Vous avez encore jusqu’au 2 mars pour envoyer vos “pitch” pour des sessions. Il ya déjà plusieures excellentes propositions. J’envoie ma proposition dans quelques instants.
Qu’est-ce que vous attendez?
The conférence Agile France 2013 will be held on May 23rd and 24th at the lovely Chalet de la Porte Jaune, close to the chateau de Vincennes.
You have until March 2nd to send in a “pitch” for a session. We’ve already received many interesting session ideas. I’ll send my proposal in a few minutes.
What are you waiting for?
Ils sont fous, ces agilistes!
]]>Mini XP Day reruns 12 of the best sessions from last year’s program in 3 parallel tracks. The conference takes place in Mechelen in Belgium (between Brussels and Antwerp).
There’s room for 90 participants and the conference usually sells out. So register now to ensure you don’t miss out on [...]]]>
April 26th in Mechelen, Belgium
Mini XP Day reruns 12 of the best sessions from last year’s program in 3 parallel tracks. The conference takes place in Mechelen in Belgium (between Brussels and Antwerp).
There’s room for 90 participants and the conference usually sells out. So register now to ensure you don’t miss out on this great event.
Picture from the “Product Box” session at XP Days Benelux by Yves Hanoulle
]]>22-23 March in Brussels, Belgium
Agile Open Belgium is an open space conference in the tradition of Agile Open conferences.
You determine the subjects on the program.
Join us on 22 and/or 23 March in Brussels.
]]>22-23 March in Brussels, Belgium
Agile Open Belgium is an open space conference in the tradition of Agile Open conferences.
You determine the subjects on the program.
]]>I started writing bugs when I was 15-16 years old.
It all started innocently with some small BASIC programs on a home computer. But I soon moved on to the hard stuff: Assembler, Forth, C, LISP, Smalltalk, C++. Before I knew it I was working on products with several [...]]]>
I started writing bugs when I was 15-16 years old.
It all started innocently with some small BASIC programs on a home computer. But I soon moved on to the hard stuff: Assembler, Forth, C, LISP, Smalltalk, C++. Before I knew it I was working on products with several millions of lines of code and tens of thousands of recorded bugs.
After discovering Extreme Programming I decided to kick the habit.
I want to share with you the eleven step algorithm I used to get better.
I’m Pascal, I’m a recovering bug writer
]]>La deuxième présentation à la Conférence Agile France 2011 proposait six bases essentielles pour mettre en place un environnement de travail Lean ou Agile. Comme toujours il y a de bonnes nouvelles et de mauvaises nouvelles:
La bonne nouvelle: Lean et Agile ne sont pas de la magie, entre temps on sait [...]]]>La deuxième présentation à la Conférence Agile France 2011 proposait six bases essentielles pour mettre en place un environnement de travail Lean ou Agile. Comme toujours il y a de bonnes nouvelles et de mauvaises nouvelles:
- La bonne nouvelle: Lean et Agile ne sont pas de la magie, entre temps on sait pourquoi, ou et comment ça marche
- La mauvaise nouvelle: ce n’est pas compliqué, mais c’est vraiment dur de mettre en place les prérequis nécessaires.
La présentation ne donne qu’un aperçu de chaque élément. Voici des ressources pour les 3 premiers élements, qui peuvent vous aider dans vos recherches. Les 3 autres éléments seront décrit dans un billet suivant.
1. La Théorie des Contraintes
Originalement décrite par Eli Goldratt dans le roman “Le But”, cette théorie se résume très facilement:
- Le résultat de chaque système est déterminé ou limité par un de ces élements, le goulot d’étranglement
- La seule façon d’améliorer les résultats est de travailler sur le goulot.
- Améliorer les autres élements du système n’apportera pas de bénéfices, cela aura souvent un effet négatif!
Comme mon grand-père savait déjà : “pour rendre une chaine plus forte, il faut renforcer le maillon le plus faible”.
Le “Jeu du Goulot d’étranglement” vous fait vivre les conséquences qui vont souvent contre le “bon sens”.
2. Les Real Options
Au lieu de prendre des décisions difficiles le plus tôt possible, comme nous encourage toute la littérature sur l’architecture informatique, il faut
- attendre jusqu’au “bon” moment pour prendre chaque décision. On peut calculer exactement quand c’est le bon moment: la date de livraison – le temps d’implémentation de l’option
- jusq’au moment de la décision on garde toutes les options ouvertes
- on utilise le temps gagné pour rechercher plus d’informations ou pour créer d’autres options
- on essaie de réduire le temps d’implémentation de chaque option afin de repousser vers l’arrière le moment de la decision
L’heuristique que j’utilise:
- Une décision difficile à défaire doit être prise tard. J’essaie de réduire le temps d’implémentation pour avoir plus de temps de reflexion et évaluation.
- Une décision facile à défaire peut être prise tôt. J’essaie de convertir des décisions difficiles à défaire en décisions faciles à défaire.
Exemples concrets:
- Les User Stories nous donnent l’option de prendre des décisions difficiles de planning et contenu du produit plus tard que d’habitude
- Du code clair, facile à comprendre, bien factorisé avec des tests automatiques nous permet de défaire des décisions de design et architecture à faible coût qu’on a fait auparavant pour implementer de nouveaux besoins
- Le tableau Kanban permet à l’équipe de voir les goulots en temps réel et de réagir en conséquent.
L’article “Real Options Underlie Agile Practices” par Chris Matts (en anglais) explique les Real Options et le lien avec Agile et lean. Il y a un résumé des Real Options sur le site Agile Coach.
3. Gérer par la valeur, pas par les coûts
Au départ de nos projets on se met d’abord d’accord sur notre définition commune de “valeur”. Don Reinertsen appelle cela un “Project Economic Framework” dans The Principles of Product Development Flow: Second Generation Lean Product Development. Nous appellons cela un “Business Value Model” ou “Modèle de la Valeur Métier”.
Bien définir la Valeur avec toute l’équipe apporte beaucoup de bénéfices:
- Toute l’équipe est alignée
- Comme nous comprenons mieux le vrai but, il est plus facile de trouver des vraies solutions
- Il est très facile de prioriser
- Les projets deviennent plus petits parce qu’on élimine ce qui n’ajoute pas ou pas assez de valeur
La présentation
La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” Ã la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.
Conflict Resolution Diagram Tutorial – French
View more presentations from AgileCoach.net.A la fin de [...]]]>
La semaine passée j’ai présenté comment résoudre les conflits avec le “Diagramme de Résolution des Conflits” Ã la Conférence Agile Paris. La présentation est disponible ci-dessous. Plus d’informations sont disponibles sur le site Agile Coach.
Conflict Resolution Diagram Tutorial – French
A la fin de la présentation il y a deux questions pour voir si vous avez compris la leçon:
- Est-ce qu’il est possible de former un gouvernement belge avec cet outil? Si oui, pourquoi? Si non, pourquoi pas?
- Est-ce que vous pouvez résoudre ce conflit récurrent entre Product Manager et Développeurs:
- Le Product Manager a besoin d’estimations et de planning très détaillé et fiable pour publier une roadmap qui dit quand quel fonctionnalité sera livrée quand ET livrer ces fonctionnalités comme promis
- Les clients, qui souvent sont des grandes entreprises avec plusieures filiales dans les monde et beaucoup d’utilisateurs, ont besoin de cette roadmap pour planifier quand ils vont implémenter une nouvelle version
- Les Développeurs sont “passés au Kanban”: ils ont arrêté de faire des estimations ou des plans. Cela prenait beaucoup de temps et ce n’était jamais correct.
- Les Développeurs “éliminent le gachis” parce qu’ils doivent aller de plus en plus vite pour satisfaire les requêtes d’un nombre de clients qui toujours croissant.
- Tout le monde veut livrer les fonctionnalités au client au moment ou les clients attendent ces fonctionnalités.
Vos réponses et questions dans les commentaires…
D’abord essayez de clarifier le conflit.
Puis, découvrez les suppositions derrière chaque étape du raisonnement.
Translation
I presented an interactive tutorial on how to apply the “Conflict Resolution Diagram” at the French Agile conference in Paris. You can see the English version of the presentation at the Agile Coach site.
At the end of the French version of the presentation there are two tests to see if participants understood the tool:
- Can you use this tool to form a Belgian Governement. If yes, why? If not, why not?
- Can you resolve this common conflict between Product Manager and Developers:
- The Product Manager needs detailed estimates and accurate planning because she has to create a long-term roadmap which spells out which features will be delivered when AND deliver those features when promised to keep customers’ trust
- Customers, who are typically large multi-site companies with many users of the product, need the roadmap because they need to plan when they will roll out which version throughout the enterprise
- Developers have “gone Kanban” and have stopped estimating and planning because the estimates took too much time and were incorrect anyway
- Developers stopped estimating and planning to decrease waste so that they can keep up with the increased demand for features from the increasing user base
- The whole company wants to deliver the features customers ask for when customers expect them.
Answers on a postcard or a comment…
First, try to clarify the conflict.
Then try to find the assumptions behind each step of the reasoning.
Topic:
This is an informal meetup of the Belgian Agile and Lean community. Come after work and meet people you usually only meet at conferences. Anyone interested in Agile or Lean can join.
Add your name to the list to attend.
Location:
Foodsquare Rue du Marché aux Herbes 120 1000 Bruxelles
Between Brussels [...]]]>
Topic:
This is an informal meetup of the Belgian Agile and Lean community. Come after work and meet people you usually only meet at conferences. Anyone interested in Agile or Lean can join.
Add your name to the list to attend.
Location:
Foodsquare
Rue du Marché aux Herbes 120
1000 Bruxelles
Between Brussels Central station and the Grand’ Place.
See you there!
]]>Mechelen, December 1st – 2nd 2011
XP Day Benelux is an international conference about Agile methods, intended for people from all walks of life who are involved with IT. It provides a good opportunity for exchanging ideas and sharing experiences and is suited for both experienced participants and beginners in Agile methods. The focus [...]]]>
Mechelen, December 1st – 2nd 2011
XP Day Benelux is an international conference about Agile methods, intended for people from all walks of life who are involved with IT. It provides a good opportunity for exchanging ideas and sharing experiences and is suited for both experienced participants and beginners in Agile methods. The focus of this conference is on practical knowledge, real-world experience, and active participation of everyone.
XP Days Benelux 2011 will have something for everyone. Sessions for people who are new to Agile, sessions for experienced people, a good mix of technical, experience, management and process sessions. We’ll have sessions on Agile in real life, stories of success and horror, hands on workshops, and sessions that will completely surprise you!
You can be a contributor too
We’re looking for enthusiastic people who want to lead these sessions. People who work in any role, business or form. People who are willing to share, and are prepared to learn. Reflective practitioners who are not only interested in quality work but also want to know why things work as they do.
Are you new to presenting? Do you have a nice idea, but you don’t know how to shape it into a session? Don’t worry, we will offer lots of ways to help you:
- We have coaches who can help you create your session.
- Through our session proposal system you will get feedback that will help you shape your session
- We provide opportunities before the conference to try out your session.
- We have a set of personas to give you some idea of the type of participants you’ll meet at XP Days.
Have you presented sessions before? The extensive feedback will give you an opportunity to improve your session further. And you can use your experience to help other presenters to improve their session.
How to propose a session for XP Days
Becoming an XP Days presenter is simple (but not easy):
- Submit a session idea (until July 9th, 2011)
- You’ll receive a login to our session improvement tool
- You complete your proposal and improve it with the feedback you receive (until August 27th, 2011)
- You give feedback on other proposals to help their presenters to create the best proposal they can
- Early September, the program committee selects the sessions for the program based on the following criteria:
- Quality of the session
- A balance of session subjects and formats
- Participation of the presenter in the improvement process
- Votes from everybody who proposed a session
Important dates
- Now to July 9th, 2011: submit session proposals
- Now to August 27th, 2011: improve session proposals
- September 12th, program committee meeting
- September 19th, program decided
Propose a session now to get as much time as possible to get feedback and improve your session.
See you at the conference!
]]>Here are the slides for the “Agreeing on Business Value” session we ran at Mini XP Days Benelux 2011 and will run again at the SPA conference in June.
The exercise uses a case study that’s not published, so you can’t peek and prepare for the session 🙂
Agreeing on [...]]]>Here are the slides for the “Agreeing on Business Value” session we ran at Mini XP Days Benelux 2011 and will run again at the SPA conference in June.
The exercise uses a case study that’s not published, so you can’t peek and prepare for the session
The “Bottleneck Game” is a simple game that illustrates many Agile, Lean and Theory of Constraints topics. It’s available for free with a Creative Commons license so that everybody can play it. And people do play it all over the world. For example:
Thierry Cros played the game in Morocco. Kevin [...]]]>The “Bottleneck Game” is a simple game that illustrates many Agile, Lean and Theory of Constraints topics. It’s available for free with a Creative Commons license so that everybody can play it. And people do play it all over the world. For example:
- Thierry Cros played the game in Morocco.
- Kevin Rutherford played the game in Manchester.
Great productivity improvements for both teams! But we all know software development isn’t manufacturing, right?
Try the game. Try some of the ideas. Just like in the game, your team can create more value with less effort and a lot less stress.
Portia Tung and I ran the “Agreeing on Business Value” session at the Mini XP Days Benelux 2011 conference. In the workshop participants have to create a “Business Value Model” for a case we provided. The Business Value Model shows the most important goals and measures of the company and the [...]]]>
Portia Tung and I ran the “Agreeing on Business Value” session at the Mini XP Days Benelux 2011 conference. In the workshop participants have to create a “Business Value Model” for a case we provided. The Business Value Model shows the most important goals and measures of the company and the relationships between goals. We often run this workshop to let a team come up with a common definition of “Business Value”. As a result of the workshop, everybody’s has a clear and common understanding of the value the project or product is going to deliver.
We asked the teams to add what they learned at the workshop on the posters. Here’s a gallery of the outputs of different groups. Click on the images to get a larger picture.
Team 1
In the model different types of goals have different colors: financial goals are blue, organisation goals are green and people goals are yellow. At the top are the “lagging measures” (those that can only be measure late). At the bottom are the “leading measures” (that can be measured early) that will be used to predict the achievement of the desired lagging goals. Arrows indicate that one goal has an effect on another. You’ll see that most things are interrelated. The good news is that achieving one goal can help achieve other goals in reinforcing loops. The bad news is that you may have to achieve many subgoals to achieve your desired goals.
This team identified the following learnings:
- Makes a complex project more clear
- Business alignment. Today business cases are made individually
- Helps to give an overview of goals for all stakeholders
- Make decisions at goal level, not at feature level
- (You can use this for) portfolio management!
- Thinking about measures
Team 2
Here we se a simpler model, but still representing the financial, organisational and people goals with their relationships. Everything leads to “Make Profit”
What they learned:
- When we talk about business value, we need to think about how to measure leading and lagging indicators
- Adding the relationships generated new insights
- Plan-Do-Check-Act
- Eliminate “business value” that doesn’t really add value
Team 3
Another very clear model with positive (+) and negative (-) effects between different goals. In the end, it all results in “Cost Cutting”
What they learned:
- It starts with a vision
- You involve everybody
- To build a model, iterate over the following steps until satisfied:
- Identify goals
- Define Lagging and Leading measurements
- Identify relationships (“Diagram of Effects”)
Team 4
This model has exactly one leading and one lagging indicator per area. Together, the goals result in profit.
This team created a diagram of what they learned:
- Value is not just money
- Value must be measurable
- We have leading (“early”) and lagging (“late”) measures
- We need to identify the relationships between the measures
Team 5
This team considered more lagging (yellow) and leading (pink) goals. Many of the goals have more than one possible measurement. If you have multiple ways to measure a goal you can choose the cheapest measure to collect or find some data that’s already being collected.
The important points for this team:
- Identify
- Categorise
- Quantify
- Relationships
What the presenters learned
- Everybody got the same case, but there are differences in the models. There is no “right model”, the team has to find one that’s useful. Over the lifetime of a product or project the business value model will probably change, as different goals change in importance
- The case is not too simple, and there’s lots of information, just like a real project. Despite that complexity teams of six “strangers” came to a clear agreement on the goals of a project within 90 minutes. How long does it take in your project to come to agreement on goals and priorities. If your projects are like mine, probably the whole duration of the project
- Making our definition of business value clear, finding ways to measure and thinking about effects and relationships helps to come up with new insights
- Participants don’t ask many questions. We were available the whole time to answer questions about the technique or the case, but despite having real live “customers” in the room, participants concentrated on the written materials
- We started by describing and drawing the company vision on the whiteboard. Most teams quickly lost sight of the vision. Once they “rediscovered” the vision, they found that it answered some questions about value and priority. It would be good to remind people of the vision before every turn. Maybe we could do this in our work too? Why not start each project meeting with a reminder of the vision?
If you want to know more, head on over to the agilecoach.net site where you’ll find more about Business Value Modeling and some other useful tools.
If you applied any of these techniques, let us know how it went.
]]>In this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.
Come and play with [...]]]>
In this interactive tutorial you’ll be able to apply “Business Value Modelling” on a case study, to decide on the goals and definition of value for an improvement project.
Come and play with us!
]]>This will be two days of engaging discussions around Agile in General. Don’t expect polished presentations, it’s all about sharing ideas and interaction.
To learn more about the Open Spaces concept, check out the description.
This Agile-fest [...]]]>
This will be two days of engaging discussions around Agile in General. Don’t expect polished presentations, it’s all about sharing ideas and interaction.
To learn more about the Open Spaces concept, check out the description.
This Agile-fest is kindly hosted again by IBBT.
In this edition, we would like to support learning/exploring ‘Agile’ by experience and call upon your imagination to come up with agile simulations, games. Of course plain old discussions are fine too!
See you there
]]>