Search This Blog

Saturday, February 27, 2010

James Shore: Large-Scale Agile

link -> James Shore: Large-Scale Agile
reusable software will form a new bounded context that will likely need its own team for ongoing enhancements and support. Users of the code won't be able to make changes when they need to. Instead, they'll have to make a hand-off to the other team and wait for the change, which increases delay and error. Even the team that originally developed the code will likely slow down, because the component will now be outside of their bounded context too.
Seems like we just talked about this on Friday with the stash

The Problems With Acceptance Testing

link -> The Problems With Acceptance Testing

Thursday, February 25, 2010

Being Agile?

I started reading Scaling Software Agility after finishing Scaling Lean and Agile Development. Here is a quote from the forward to Scaling Software Agility

We say “agile processes,” but actually the process, whether formally described or tacit in people’s heads, is not agile in itself. People can be agile; teams or organizations can be agile. You do not “do agile,” you “are agile.” If you only do agilewithoutbeing agile,you will fail and not know why, and you will be left blaming some book.

I could have sworn I read that same quote in Larman's book. I confess I still don't understand exactly what it means. Probably something like don't just follow the practices blindly. Try to understand the underlying principles and values and make sure you are staying true to them.

I am not sure which camp I fall into being or doing. I am working on it.

James Shore: The Art of Agile

link -> James Shore: The Art of Agile
James Shore consults and writes about high performance software development for teams who are willing to be great.
trying to determine if I am using the work slack properly

James Shore: The Art of Agile

link -> James Shore: The Art of Agile
James Shore consults and writes about high performance software development for teams who are willing to be great.
trying to determine if I am using the work slack properly

a better team

link -> a better team
our agile quiz online, only works for one person not a team though

XP Practice: Slack | Agile Software Development

link -> XP Practice: Slack | Agile Software Development
trying to determine if I am using the work slack properly

Cal Poly Supermileage Team Develops Car That Gets 2752.3 MPG | Inhabitat

link -> Cal Poly Supermileage Team Develops Car That Gets 2752.3 MPG | Inhabitat
A Green Design Blog, Sustainable Design Blog, Future-forward design for the world you inhabit - your daily source for innovations in sustainable architecture and green design for the home.
4 gallons would last me a year

Tuesday, February 16, 2010

Sunday, February 14, 2010

Andy Palmer » Making Feedback More Effective

link -> Andy Palmer » Making Feedback More Effective
Feedback is hard. This helps.

Current Project

link -> Current Project
FitNesse Narratives When we first heard of the "Given When Then" structure for writing acceptance tests, we knew instinctively that it was a better way of writing executable examples (wrapped in the structure of an automated test to reduce ambiguity). It was presented by Dan North and Joe Walnes at XP Day 2006 Since then a number of frameworks have risen up using that structure. Many of these can be written in plain text. Despite this, there are still many teams using FitNesse and the new table parsing Test System called SLIM. Unfortunately, the way FitNesse is used is, too often, as an .automated testing. tool rather than as a tool that documents desired software behaviours in a customer-friendly way (using automated tests). There is a substantial difference in practice, despite such subtle difference in the words. FitNesse own acceptance tests require explanation text surrounding the tables. We liken this to having comments in code, they are at risk of not being maintained and becoming disconnected from the executable content. They also add clutter to the page making it harder to understand the intent than if the descriptive words themselves were executable. For this reason - and because we find the "includes", variables and hierarchical wiki features of FitNesse useful, we wanted to give FitNesse users the opportunity to use the "Given When Then" style whilst enjoying the benefits of
This sounds cool. I wonder if they ever got it working.

Friday, February 12, 2010

Domain Events – Salvation

link -> Domain Events – Salvation
Domain Events are one of the patterns Eric Evans said he left out of his DDD book. I would like to learn more about them.

Thursday, February 11, 2010

Sunday, February 7, 2010

Scrum Training Institute — Library

link -> Scrum Training Institute — Library
The Scrum Training Institute (STI) is the premier global provider of certified Scrum training and consulting. Founded by Jeff Sutherland, the co-creator of Scrum, and leading international Agile experts Gabrielle Benefield, Pete Deemer and Jens Ƙstergaard, STI provides a complete solution for companies seeking high-impact results from Scrum and Agile development.
The Scrum Primer has some cool statistics from Yahoo's rollout to 2000 people


From Clean Code

Fortunately, making our systems testable pushes us toward a design where our classes are small and single purpose. It’s just easier to test classes that conform to the SRP. The more tests we write, the more we’ll continue to push toward things that are simpler to test. So making sure our system is fully testable helps us create better designs.

I have heard this point many times. I can't say I have ever written anything that is fully testable so I don't know if what the author is saying is true or not. I have seen where writing tests helped me simply my code so I am interested in trying what the author recommends. I saw this really interesting book(Growing Object-Oriented Software, Guided by Tests) on TDD recently. I am going to add it to my short list of books to read.

The majority of the cost of a software project is in long-term maintenance. In order to minimize the potential for defects as we introduce change, it’s critical for us to be able to understand what a system does. As systems become more complex, they take more and more time for a developer to understand, and there is an ever greater opportunity for a misunderstanding. Therefore, code should clearly express the intent of its author. The clearer the author can make the code, the less time others will have to spend understanding it. This will reduce defects and shrink the cost of maintenance.

I am really lucky that all the developers on our team understand this point really well. We are all passionate about refactoring our code. Even though we have mastered the "why", I feel like we are still in the early stages of knowing the "how" part of solving this problem. I am really excited though to see what we come up with. We definitely have a group of people that can solve this problem.

Self Organizing

From Scaling Lean and Agile Developement

In the context of scaling and multiteam development, there are many opportunities for a team to require a representative at meetings. It is useful for a ScrumMaster to not act as the team representative. One Scrum goal is an engaged self-managing team; thus, a good ScrumMaster will avoid taking any management-like role or activity, including team representative. Other team members need to learn to take on all management-related roles and activities.

I would like our team to be self organizing. I have read a lot of tips in this book about how to accomplish that. One of their main points is that as long as their is someone on the team that considers themselves a manager then the team will never self organize. I have always felt like I was a big part of the problem, but I was not sure specifically what I was doing wrong. The quote above gives one tip for me to stop going to meetings to represent our team.

So then the question is what should I be doing? Maybe I should read more about the role they call ScrumMaster. Here is a short description. It sounds interesting.

ScrumMasters that (1) act as Scrum-method coaches for their teams and the Product Owner, (2) help their team become a real team by facilitating conflict and removing obstacles, (3) help the Product Owner, (4) remind the team of their goal, and (5) bring change to the organization so that overall product development is optimized and maximum ROI is realized.

Keep trying against your beter judgement

From Scaling Lean and Agile Developement

One common mistake teams make, when presented with a Scrum practice that challenges them, is to change Scrum, not change themselves. For example, teams that have trouble delivering on their Sprint commitment might decide to make the Sprint duration extendable, so they never run out of time and in the process, ensure they never have to learn how to do a better job of estimating and managing their time. In this way, without coaching and the support of an experienced ScrumMaster, organizations can mutate Scrum into just a mirror image of its own weaknesses and dysfunction, and undermine the real benefit that Scrum offers: Making visible the good and the bad, and giving the organization the choice of elevating itself to a higher level.

I have struggling with this one. How do you convince someone to keep trying something when it does not seem like it is working? I have read in other places that you should keep trying it until you feel like you have mastered the practice. Then after you have mastered the practice you can chose not do it knowing full well the implications of your decision. I guess then the question comes down to how do you know you have mastered something.

Maybe there are no black and white answers. I guess all we can do is try to do the right thing and keep reflecting and reevaluating our decisions.

I like the idea of thinking of these things as experiments. Where there is really no right or wrong decision to be made, instead there is just a different lesson to be learned depending on which choice you make. The important point though is you have to regularly stop and reflect objectively and be willing to change and keep trying new things. That is probably the hardest part.

Thursday, February 4, 2010

Understanding Section Handlers - App.config File - CodeProject

link -> Understanding Section Handlers - App.config File - CodeProject
This article explains configuration section handlers defined in the System.Configuration namespace and explains how to create custom sections handlers by implemeting the IConfigurationSectionHandler interface.; Author: Palanisamy Veerasingam; Section: ASP.NET; Chapter: Web Development
We could use to put all of our settings that someone would need to edit in a separate file instead of them editing web.config. That way when we change web.config in our build they will pick up our new changes instead of using their saved off copy

jsc (c# to javascript)

link -> jsc (c# to javascript)
jsc can convert your C# Application to PHP, JavaScript, Actionscript, Java, C and C#
would be cool to be some of our larger business logic type stuff that needs unit tests in C# instead of javascript

Wednesday, February 3, 2010

How To Fail With Agile: Twenty Tips to Help You Avoid Success published in Better Software on July 1, 2008

link -> How To Fail With Agile: Twenty Tips to Help You Avoid Success published in Better Software on July 1, 2008
Not everyone involved in an agile transition wants the change to be successful. This tongue-in-cheek article details twenty things you can do to sabotage an agile transition. Of course, the twenty things also serve as reminders of things to avoid or watch out for. If you'd like to hear this article rather than read it, Ryan Wiancko of IndustryBroadcast has recorded it.
Pretty funny

Welcome to the Coding Dojo

link -> Welcome to the Coding Dojo
Agile Coaching recommends these and to help developers improve their skills