Thank you everyone who attended our presentation last night at the Calgary Agile Methodologies User Group. We had a tonne of fun, and hope that you took away some valuable information.

We are pleased to have Adam Alinauskas, Joel Briggs, Luu Duong and Mo Khan from eCompliance Management Solutions speaking to us this month with their presentation "Shortening the Feedback Loop - Our Sprint in a Nutshell"

Under the Agile software development umbrella there are many principals, processes, methodologies, and practices that fit this style of development. Many companies are relentlessly seeking and implementing ways to continually improve how they design, develop and deliver software. We believe and have found in practice that the Agile way of software development enables, supports and drives this continuous quest for efficiency and improvement. One of the primary goals of Agile software development is to satisfy customer needs through early and continuous delivery of valuable software. We find that most of the business value comes from creating an environment where a shorter feedback loop allows our team to be more proactive and adapt quickly as and when necessary. In this presentation we will share and walk you through a typical sprint/iteration at eCompliance.caT and highlight to where we have shortened the feedback loop and increased efficiency and feedback quality.

About eCompliance.ca: eCompliance Management Solutions Inc. is the leading provider of Occupational Health & Safety (OHS) Management solutions in Canada. Our vision is "To be the preferred technology partner of Canadian organizations in OHS by providing efficient and effective practical solutions to measure, manage and mitigate Health & Safety Risks in the quest for 'Zero Incidents'."

Our team is comprised of 3 dedicated developers, 1 project manager, 1 super dedicated product owner and a trusty task board. Although, we're a small team we've been uber successful, and so far have been able to out perform the competition (in a surprisingly short amount of time).

One of those reasons is because of how "tight" (read:close) the team is. What I mean is that we're completely open with each other, which has allowed us to really gel as a team. We have our good days and bad days, but overall I feel like I can honestly depend on my team mates, and likewise.

We all make the same salary, and have the same amount of shares. There's no super heroes on our team. We all have strengths and our weaknesses, but there's no sense that any one of us feels like we are obligated to outperform one another. We're judged based on team performance rather than individual performance.

"The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?" - Kent Beck from Extreme Programming Explained

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck, Cynthia Andres Read more about this book...

Depending on the day, we each step up to lead the team. There's no water cooler discussions about why a member of the team makes x dollars, while I make x - 20K. We're either performing or not, and call each other out when we're not.

So far, this has helped our team gel. I'm curious to hear how about why you and your team are so "tight"?

One of the books I've read this month is....

Extreme Programming Explained: Embrace Change (2nd Edition) (The XP Series) by Kent Beck, Cynthia Andres Read more about this title...

I really enjoyed reading this book. It paints a picture of what an ideal XP team can look like and talks about the principals, practices and values of XP. I'd like to share some excerpts from the book that really stuck out and hand an impact on me.

"If you have six weeks to get a project done, the only thing you can control is your own behavior. Will you get six weeks' worth of work done or less? you can't control others' expectations. You can tell them what you know about the project so their expectations have a chance of matching reality. My terror of deadlines vanished when I learned this lesson. It's not my job to "manage" someone else's expectations. It's their job to manage their own expectations. It's my job to do my best and to communicate clearly."

One of the things I learned about myself is that I hate being late. This isn't a great trait to have in the world of software development. When I'm handed a deadline I become so eager to meet it that in the process of racing to the deadline quality is compromised. I can't control deadlines or others expectations but I can control my own behavior and if I work consistently as hard as I can without letting go of quality.

"I chose practices for XP because they meet both business and personal needs. There are other human needs; such as rest, exercise, and socialization; that don't need to be met in the work environment. Time away from the team gives each individual more energy and perspective to bring back to the team. Limiting work hours allows time for these other human needs and enhances each person's contributions while he is with the team."

It sucks how XP and Agile have become buzzwords in the industry that mean more to the marketing department then to the software developers. I've said it before and I'll say it again...

"You aren't doing Agile. YOU ARE AGILE!"

"Part of the challenge of team software development is balancing the needs of the individual with the needs of the team. The team's needs may meet your own long-term individual goals, so are worth some amount of sacrifice. Always sacrificing your own needs for the team's doesn't work. If I need privacy, I am responsible for find a ways to get my need met in a way that doesn't hurt the team. The magic of great teams is that after the team members develop trust they find that they are free to be more themselves as a result of their work together."

You've got to sacrifice something, regardless of context you're talking about, in order to succeed. What's important is deciding on what you're willing to sacrifice in order to get closer to your end goals. I have found that pushing the people outside of their comfort zone a little bit not only helped me in growing but also the team as a whole. I also learned that it's important to slow down and reflect. The up and down rhythm of an XP team is balanced by the different members of a team, and with trust it's much easier to maintain that balance.

E.G. Team member A might be a hardcore, heads down, must punch out code as efficiently as possible. Team member B may be more of a let's take it a little slower and sit back and think about the problem at hand kind of guy. With trust the two team members will be able to develop a rhythm that keeps the project going at a sustainable pace without sacrificing quality.

"I trust two metrics to measure the health of XP teams. The first is the number of defects found after development. An XP team should have dramatically fewer defects in its first deployment and make rapid progress from there. Some XP teams that have been on the path of improvement for several years see only a handful of defects per year. No defect is acceptable; each is an opportunity for the team to learn and improve."

Test-driven development/design rather then design in your head driven code. The test is a clear statement of truth. It documents the design that would otherwise be locked up in your head and is very black of white about whether or not the subject under test satisfies the test specification or behavior that is expected. If the team is not disciplined even the best of the best XP teams can forget about the principals behind the practices, and stop following the practices. One of the most important things about unit tests is the early feedback. I want to know as soon as possible when a component in the system is not behaving as expected. By waiting for QA to pick out bugs, then log a bug, then assign a developer to look at the bug does not deliver early feedback, I consider this waste! It's a vicious cycle that can be reduced greatly.

"The problem with reviews is that most reviews and raises are based on individual goals and achievements, but XP focuses on team performance. If a programmer spends half of his time pairing with others, how can you evaluate his individual performance? How much incentive does he have to help others if he will be evaluated on individual performance?"

Out of all the chapters in this book I think chapter 3 is my favorite. It's titled "Values, Principles, and Practices", and to me it speaks the loudest of what is XP and why would we want to consider using it as a methodology for building and delivering software.

I highly recommend this book!

If you're going to practice any form of unit testing you need to learn about the different types of tests. I have yet to read XUnit Test Patterns, but I'm sure this will offer a great deal more detail then this post. Also, I'm anxiously awaiting "The Art Of Unit Testing"

Unit Tests

Unit tests are blocks of code that exercise very specific areas of a code base to ensure the it is meeting it's responsibility (NOT responsibilities in the plural sense. See Single Responsibility Principal). At it's core its asserting that a very specific result or behavior is met. Unit tests can be broken down into two types.

Black Box Testing (State)

The first is the traditional state based (black box) unit tests. These are unit tests that assert that components of the system exert a behavior that expected from the perspective of a client component. It cares less about the actual implementation of the component and more about the result. These types of tests tend to be easier to refactor and are a great way to start learning about test driven development or unit testing in general. The unit tests give you the confidence to go in to the trenches and make significant changes to the underlying implementation. This allows you to evolve a code base with confidence and precision. (And remember software development is an evolution. Using the same architecture and tools that you did from several years ago could indicate a smell.)

For example:

 1         [Test]
 2         public void Should_be_able_to_lease_a_slip() {
 3             ICustomer customer = CreateSUT( );
 4             ISlip slip = ObjectMother.Slip( );
 5             ILeaseDuration duration = LeaseDurations.Monthly;
 6 
 7             customer.Lease( slip, duration );
 8 
 9             Assert.AreEqual( 1, ListFactory.From( customer.Leases( ) ).Count );
10         }

White Box Testing (Interaction)

This type of unit test is more focused on the interaction of components then the result. It's verifying expectations that components are working as expected with it's dependencies under different conditions. It's a way to simulate different environment conditions without actually having to exercise the component in that environment. The canonical example is to mock or stub out an interaction with a database or third party component.

It's called white box testing because it's like you can see clearly through the box to see what's going on inside. It might make more sense to refer to this as glass box testing.

For example:

 1         [Test]
 2         public void Should_leverage_task_to_retrieve_all_registered_boats_for_customer() {
 3             long customerId = 23;
 4             IList< BoatRegistrationDTO > boats = new List< BoatRegistrationDTO >( );
 5 
 6             using ( _mockery.Record( ) ) {
 7                 SetupResult.For( _mockRequest.ParsePayloadFor( PayloadKeys.CustomerId ) ).Return( customerId );
 8                 Expect.Call( _mockTask.AllBoatsFor( customerId ) ).Return( boats );
 9             }
10 
11             using ( _mockery.Playback( ) ) {
12                 CreateSUT( ).Initialize( );
13             }
14         }

Integration Test

Integration tests are tests that sweep across a system. They exercise the system from top down, to ensure that it is behaving as expected in a production like environment. This is a great place to weed out contracts that have not been implemented, and help to identify different environment scenarios that may need further unit testing. These tests actually hit the third party components and exercise the full system. These tests typically take a little longer depending on the environment conditions such as hitting a database.

There are frameworks available, such as Fit, that allow business analysts to define test criteria that can then exercise the system top down. The problem with some of these frameworks is that they can implicitly allow the BA to start designing how the system is implemented if taken as a literal design spec. I much prefer writing top down tests rather then implementing fit-like fixtures.

On my bus ride home yesterday, I was trying to think about what separates our office from others and I realized it was that our office was less like an office and more like a design studio.

A studio celebrates discussion and creative thinking. It challenges you to think creatively and outside the box. Your uniqueness is what makes your product a better option than your competitors.

I asked my wife what she pictures when she thinks of a designers studio. Here's some of the things that she said:

• Open style loft
• A New York style high rise building with lots of windows over looking a park or people walking along the street.
• Boards on the wall covered with peoples ideas.
• No cubicles
• Elevated desks, like the ones architects use that are tilted sideways and are high enough to look outside.
• One long table where people can come together.

My picture of a designers studio is quite similar, except I see white boards scattered just about every where. So you can have an impromptu design session while eating lunch, where you can literally stand up and start writing on the wall. I picture an open work space, where people can actually see each other work. I picture constant communication and feedback.

When I think of an office, I picture cubicles where people spend their days isolated at their desk. I picture a lot of emails being read and answered. I picture a lot of phone calls being answered, and less face time with people. The office is usually quiet, so if you want to have a discussion you've got to send a meeting request through outlook and book a board room to communicate with others.

Why is that when we think of where software developers work its in an office and not in a studio. Designing software is a lot like designing art. It takes a lot of creativity to build code bases that not only deliver clients value but also make other developers want to contribute to the code base.

In my opinion, if you are striving to create an Agile shop, start by trying to create a studio environment and leave the office behind.

One of the few things I've learned in the last few weeks is to not be so politically correct when it comes to sifting through code. What I mean is, if you spot a piece of code that can improved, then address it.

Don't hold back your comments because you're worried that the author of the code will feel attacked or hurt. There's also constructive ways of doing this, if you're intentions are to make someone else look bad or prove that you're a better developer then everyone else, then you've got some character flaws that probably need addressing.

If you spot code that smells deal with it. Explain why it smells and construct ways to improve it. You're not helping anyone by holding back your true thoughts. The only way you and your team is going to get better is if you constantly offer each other feedback.

With constant feedback you might start to notice more more light bulbs turning on in your teams heads. It's no use if only you can see why a certain piece of code smells, but the rest of the team needs to see it to.

Most developers try to put out the best possible code that they can. They want to deliver value, so if you spot a better way that someone can do that, show them. It's the code that sucks, not the author.

Pick a sport, any sport! Start going the rosters for different teams and you'll see that the captain of the team isn't always the person scoring the most goals, getting the most assists or on the top ten leader boards in the league.

The captain isn't supposed to be the best player. The captain is a person who knows..

• how to lead by example.
• how to bring out the best in those around them.
• how to stand up for others around them.
• how to listen.
• how to inspire greatness.

In software development it seems all to common that we have this notion that the team lead or project manager should be the best player on the team. They should know more about software development and every new technology coming out better then everyone else on the team. I don't think that's the case at all. In fact in most of those cases, it's likely that the "star" player ends up becoming the one person show.

There's only so much any one person can do, there's so much more that a team can accomplish.

"I may not be able to change the world, but I guarantee that I will spark the mind that will change the world." - Tupac Shakur

I really like some of Chad's thoughts on becoming a leader.

Very few things bring people closer together then dealing with adversity together. It's easy to enjoy good times with others, but people come together when they deal with tough times together.

You never truly get to know someone until you see all sides of them. You've got to see them sad, mad and glad. You've got to get unfiltered, and raw emotion from them to truly understand them.

Pairing is a lot like this, when you put 2 software developers together to solve a problem. It brings them closer together when they solve the problem, together. You get to know all sides of the person quite quickly, from how the deal with stress, to how they deal with differences of opinion, to the pleasure of winning small battles.

There's always a bit of anxiety at first when you put 2 developers together who have little knowledge of one another. It's seems like they're sizing each other up for a fight. ("I can take 'em"!) That's really not how it is, or should be. If you're both focused on the problem at hand, and spend less time worrying about whether your skill sets are up to par, you free yourself to truly enjoy the benefits of 2 minds coming together to put out true value.

One of the things I think I do without actually realizing it is, I announce what I perceive the others persons feeling as my own. When you hear someone say that they feel the say way as you, you tend to feel a little more comfortable with them, and some defenses drop.

When you're pairing with someone, you're completely focused. You don't want to waste the other persons time. The other person surely isn't going to sit idly while you IM back and forth with someone, at least I hope not.

Finding a good pair can be hard, if you don't find one that is close to you in skill and experience it can become more like mentoring. But even a few sessions of mentoring and you can quickly level the skill set of the team. More seasoned developers shouldn't feel like they have to slow down so that the rest of the team can keep up. With constant pairing everyone comes up to speed much faster then doing it alone.

I'm definitely no seasoned veteran when it comes to pairing, but in the last little while at our studio we've gone head first into pairing and I'm really enjoying it. It's so exciting, and it really feels like we're putting out more, much faster and the quality bar feels higher.

For a more experienced take on pairing check out Wendy's post on The Joy of Pair Programming.

This is a story about building the great wall of agility. In the last few month here at the office we adopted this concept of the visual workspace. It's awesome! We lay out our story cards and tasks out on the wall and as soon as you walk in the door you're immediately reminded of what you're currently working on, how far you are from the finish line and who else might need some help.

Our first wall, was literally a wall with sticky notes on it. In the corner of the above picture you can see a photo of "Jim". Jim, was our image of the typical user of this application we were working on. Anytime we had to make a design decision we asked ourselves... "What would Jim do?" 

Our latest wall is a glossy wall that our manager picked up from Rona. It's excellent, because it doubles as a white board. It allows us to write up impromptu design discussion up on the board after our morning stand up.

One of my favorite new additions, is the sprint retrospective. It's a time for a critical look back and to hold hands and sing songs...

Yesterday at work my manager had a group of us get together to watch a presentation by Mary & Tom Peppendieck on Lean development. It was a really good discussion on identifying what makes company's successful and sparked a lot of conversation afterwards. One the major takeaways from the video were the 7 principles of lean software development.

1. Eliminate Waste
2. Build Quality In
3. Create Knowledge
4. Defer Commitment
5. Deliver Fast
6. Respect People
7. Optimize the Whole

Later this afternoon us dev's will be getting together to discuss what these 7 values mean to us, and how to identify and measure them. In the meantime I thought I would share some of my thoughts on the principles just to get my brain warmed up.

1. Eliminate Waste. For me there's nothing more painful then working on something that does not need to be worked on, or building something that does not need to be built. This point drives out the idea of focusing directly on exactly what is necessary to accomplish the goal. Waste is produced when you create unfinished work. (I have a lot of that, you should check out my sandbox) Or building in features that aren't needed, and carry with it potential for introducing "bugs".

2. Build Quality In. I think by developing with a test first mentality you implicitly build quality in because you're only building the system that is required and you're verifying that it's doing what it's supposed to do with unit tests. When the system needs to change, the unit tests help you to verify what parts of the system has been effected by your change. This reduces the "blind faith" attitude of building software in hoping that it works, and instead verifies that it does what it ought too. Verify it!

3. Create Knowledge. To me this goes further then just reading books. True knowledge comes from experience, so to create an environment we need to practice and learn. Books are a great way to start, but following through with practical application of the reading is what makes the reading valuable. What use is it if it just sits in your head?

4. Defer Commitment. When you practice Big Design Up Front, you very rarely have all the information you need to make decisions or even estimates. Like Mary says "The beginning is the time of maximum ignorance." We often jump to making big decisions up front when really most of them can wait, until we have more information. Work towards short term goals, and piece by piece you'll eventually complete long term goals. It may turn out your long term goal ends up being slightly different from the short term.

5. Deliver Fast. This isn't about hacking together code to meet deadlines. I interpret it more as setting shorter milestones and deploying more often. Do we need a web application, that does reporting, and registration all at once? Can it be broken down?

6. Respect People. Ultimately people want to do more good then bad. So "enable" them to do so by treating them with respect. You're not always going to see eye to eye, nor would you want to. But if you're passionate about your stance, speak up and say why. To respect someone you must also be willing to listen,

7. Optimize the Whole. Throughout your cycles whether daily or monthly be conscious of bottlenecks, and take the time to reflect. What's slowing you down? What's not working well? Why? Figure out what or where the weaknesses are, then figure out why and how it can be improved.

As usual wikipedia has some wisdom to share.

More Info can be found here...

So yesterday at work we completed our sprint retrospective for the previous sprint, and as I was reading through the list I thought that this was pretty amazing stuff. So I thought I would share some of what we discussed. First off here's the unfiltered lists from our white board (sorry no images):

Things to keep doing:

• Pairing on problems that are complex.
• More testing = more confidence
• sharing knowledge
• retrospective.

Things to change or remove:

• On certain tasks use pairing
• Dedicate time to acceptance testing
• Need product owner here & communication to users we are building it for.
• using Crystal or not.
• listen to community
• sprint plan changes.
• trying to do before approval.
• disruptions on task at hand
• get better at estimating
• flexible for meetings. (they push our sprint timelines.)

Our list for things to keep doing was short, but the discussion was quite "tall". I felt like we all felt like we had accomplished a lot and felt that we were making some drastic improvements in our development.

The discussion on pairing came up, and I suggested that I really enjoyed pairing with some of the other guys and that it had helped me immensely with dealing with limitations with Crystal reports. It was my first time using it, so i really wanted to get into the guts of it to understand how it all comes together. I found that by pairing we were able to fire off new ideas, on "workarounds" to get what we wanted from Crystal. Who thought that building a table of contents without using a database, data sets, or data tables could be so hard!

More testing equals more confidence. I totally back this statement up! I really feel that getting in to a test first mind set has definitely helped me ramp up my skills as a developer. It's helped me to understand .NET in general at a much faster rate then I think I would have without it. I'm more confident about the code that I write, and I feel like I'm getting closer and closer to understanding and recognizing "separation of concerns".

Sharing knowledge, isn't that what teams are all about. It's difficult for us as individuals to go spike the world and learn about every single topic, but it's more achievable when you do it as a team. I find that when learning a new topic, there's always some friction when getting going. Like where do i get good info? where do i start? where do i get what i need? By distributing the "friction" you can ramp up faster and focus on what's important.

Retrospective. I've really enjoyed our sprint retrospectives, it's become a time for us as a group to reflect on small milestones and to help identify things that helped us and hindered us in our work. I always seem to learn something new or in the back of my mind say ... "He's so right, I didn't notice that." It's a great way to expose blind spots "quickly".

Our list of things to remove or change is a little bigger, in our last sprint I think we recognized more things that hindered us from delivering more value to our customer(s). If it were up to me, I would like to pair more! I really think it's a great way to cross train, and learn more of a code base. You lose that feeling of "that's mO's code". None of it is my code, in the end it all belongs to either my employer or the client. (Intellectual Property) It also helps with getting longer more focused sessions of development. In an 8 hour work day, I would love to say that I spend 4 hours pairing with another, 2 hours working on things on my own, and 2 hours for personal development.

Testing, right now we're having some difficulties with our client. We're trying to get rid of the "surprise", by that I'm referring to when they see features in demo that they didn't expect, or things that were missing that they did expect. I think we were thinking talking about testing, we were talking about getting more feedback, earlier! Sometimes it seems like the client has an expectation of how a piece of functionality should work, but that thought isn't captured properly.

We would love to have more access to our clients, especially a product owner. By trying to get more involvement from the PO, we believe we'll have less surprises, and will deliver more value. Value that can be defined daily if possible!

Crystal reports is a terrible product, we need to spike some alternatives to enable us to build reports how we want to. A tool should allow us to use it in a way we want it too work, not demand expectations of us before we can use it. For example, if I call a method such as "GetLastPageNumber()" I expect it to give me the correct value, not throw an exception when it's a sub report and sometimes work when it's a parent report. I would also like more options then data sets and data tables, like custom collections.

Listen to the community, this was a point made in regards to Crystal. On the advice of JP, and several posts out on the net. We found a consensus that Crystal Reports was a deprecated product, not worthy of current industry demands. Some alternatives that were suggested were "Active Reports.NET" and "Reporting Services".

Sprint plan changes, referred to major changes in priority during the sprint. We've all heard that "Change Is The Only Constant" especially in software development, but if we can reduce the chances of major changes by getting feed back early, it would help to keep our dev's focused and better able to deliver value. Faster!

We need to slow down sometimes, it sucks but it's true. Sometimes we itch at the opportunity to jump in, when really it would save us all a lot of hurt if we just waited for client feedback before getting started. I'm not sure how to best deal with this, but sometimes the wait just sucks, so if we can use down time to learning and improving might be more productive!

Disruptions are disruptive. In code complete, Steve McConnell eluded to disruptions being equivalent to juggling, while holding something in the air. I don't remember the exact line, but I remember reading it and thinking "This is so true." I equate to being like riding your bike and picking up moment, when all of a sudden you are hit by a bus.

Get better at estimating, we were completely off with one task in our last sprint. I think we need more practice at breaking up stories and offering estimates. Perhaps we need to also look at how we choose stories, are they epic?

Death by meetings, ugh... Although often necessary, some seem to drag on more then they should. We need to get better at time boxing and say no to invitations. Sometimes we just may not want to attend every meeting invitation, although turning them down can be hard.

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn

Read more about this title...

The XP Values

• Communication : Most desirable is face to face communication where we can talk, respond, gesture and draw on a whiteboard. Talking = good, documents = bad!
• Simplicity : Focus on creating a solution to the problem faced today, not the problem anticipated tomorrow.
• Feedback :Developers give and get feedback from pair programming, from automated tests, continuous integration. Customers are part of the team even sitting in the same space with the developers, and provide feedback through constant interaction with the team, and through acceptance tests. 
• Courage : They have courage to refactor their code, proceed with an overall master architecture.

The Principles of XP

• Rapid Feedback : Constantly sending and receiving feedback, and responding to it.
• Assuming Simplicity : Favor simplicity and attempt to create a simple solution before evolving to a complex one.
• Incremental Change : Improve the software through small, incremental changes.
• Embracing Change : Developers are able to adapt and accommodate change.
• Doing Quality Work : Insist that the software consistently exhibits the highest level of quality workmanship.

I'm still fascinated by the Agile XP methodology. So when I came across the overview of XP in the Appendix of...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn

Read more about this title...

I had to read on. Here's what I learned:

Roles

• The XP customer role is responsible for writing stories, prioritizing stories, and writing and executing tests that demonstrate that stories were developed as expected.
• The XP programmer role encompasses a broad range of technical skills. XP projects tend not to draw distinctions between programmers, designers, DBA's and so on.
• XP teams benefit for the use of an XP coach and possibly a project manager. The coach is responsible for monitoring the team's use of the XP practices and gently nudging them back on track when they stray.

The 12 Practices

Small Releases

Project progress in a series of iterations, which are typically 1 to 3 weeks long. Features are fully delivered within a single iteration.

The Planning Game

• This is the name for release and iteration planning where developers and customers collaborate to make predictions about the future.
• Prior to planning, the customer has written user stories on note cards and developers have estimated the cost of magnitude of each story and have written the estimate on the story card.

Refactoring

• Refers to the restructuring or rewriting of code so as to improve the code without changing its external behavior.
• XP advocates constant attention to refactoring. Whenever a programmer makes a change to code that should be refactored, she is required to refactor it.
• She's not encouraged to refactor it; she's required to refactor it.
• Instead of spending time upfront thinking through a system in advance of coding it, and therefore taking guesses at some aspects of its behavior, XP systems are refactored and kept in a state that perfectly meets known, implemented requirements.

Testing

• The developers write automated unit tests.
• The customers write acceptance tests.
• In test-driven development, tests are written before the code. Developers follow a short cycle of test-code-test-code... No operational code may be written except in response to a failing test.

Pair Programming

• Refers to 2 programmers sharing one computer and 2 brains to write code. One programmer types the code, the second is watching the code develop and thinking more broadly about the code.
• This leads to lower defect counts, less code is written to solve the same problem, problems being solved more quickly, more people understand each piece of code, an increase in developer satisfaction.
• It requires discipline to refactor every time you notice poorly structured code.

Sustainable Pace

• The believe is that an XP team moving at a consistent but brisk pace will achieve more over a period of time than will a team working at a pace they cannot sustain over a long period of time.
• It is up to the team to determine their sustained pace.
• A team will typically devote around 6 hours per day to pairing and spend the remainder of the day in other activities.
• An XP coach is responsible for monitoring the team for burnout.

Team Code Ownership

• It's common in non-XP teams for individuals to "own" portions of a systems code. This leads to comments like "We can't change the billing source code until Eli gets back from vacation."
• All code is owned by everyone.
• Pairs are expected to change code they didn't write.
• A strong suite of unit tests ensures that changes do not introduce unanticipated side effects.

Coding Standard

• XP teams collectively own their source code, so it's important to follow a coding standard.
• A small, close-knit team may be able to get by without a written, formalized coding standard.

Simple Design

• Pursue a goal of having the simplest possible design that delivers the features a customer needs.
• The operational code and the test code fully convey the programmers intent.
• There is no duplicate code.
• The system uses the least number of classes.
• The system uses the least number of methods.

Metaphor

• Quest for simple design by finding a metaphor that can be used for the whole system. The metaphor describes how they think about the system.
• E.g. "The system is like a chalkboard and various parts of the system can write on the chalkboard. When a user is done with the system she can either save the contents of the chalkboard or erase them."

Continuous Integration

• Code is integrated continuously.
• A developer completes a small change, he checks the change into source control, where the CI box initiates a full build. When the build is finished a full set of unit tests are run. If any tests fail, the developer is notified by email and told about the failure.
• Integration problems are fixed one at a time in extremely small batches as soon as they occur.

On-Site Customer

• The customer is expected to sit with and be part of the development team. The customer writes the stories and the acceptance tests and is also available to answer questions as they arise.
• If the customer is not on site, delays will disrupt the predictable progress of the XP team.

Last night I finished reading...

User Stories Applied: For Agile Software Development (The Addison-Wesley Signature Series) by Mike Cohn Read more about this title...

It was a nice quick and dirty read, to get my feet wet in the world of applying user stories. I really prefer working with user stories as opposed to full blown system requirements specifications. Although, a typical SRS is much thicker then a set of user stories, I think more information is delivered through user stories because it done so piece by piece. As you require the information, it's your responsibility to gather it.

I want to share some of my favorite quotes from the book.

"Pay attention to who is contributing during a story writing workshop. Occasionally a participant will remain silent through much or all of the meeting. If this is the case, talk to the participant during one of the breaks and make sure she's comfortable with the process. Some participants are reluctant to speak up in front of their peers or supervisors, which is why it is important that story ideas not be judged during these sessions. Once participants become comfortable that their ideas will simply be noted, not debated, at this point they will contribute more readily."

I have to admit that at my first story writing workshop I didn't say much. It was kind of a foreign concept to me and I worried about getting shot down by the other developers if I mentioned a story idea. I felt like there was a good chance that would occur because the rest of the team felt they had a similar vision of how the product would look and feel before and discussion had even begun. I later realized that they did indeed want to hear my story ideas, but it just took some time getting used to the culture of the team.

"When you cannot find, or get access to, a real user, avoid falling into the trap of thinking you know your users' minds and do not need or can ignore your user proxy. While each type of user proxy has some type of shortcoming that makes her less desirable than a real user, most developers come with even more shortcomings for pretending to be a real user. In general, developers do not have marketing backgrounds that allow them to understand the relative value of features, they do not have the same amount of customer contact as salespeople, they are not domain experts, and so on."

I know as a developer that there are many times where I know how I would like a piece of software to work. Because it would work well for me, but ultimately that's not always going to work best for the end user. It's difficult to put yourselves in someone else's shoe to try to think like they would. It's much easier to just ask, instead of making a design decision, implementing it then later having them tell you that's not what they wanted.

"Ideally the customer writes the stories. On many projects the developers help out, either by doing the actual writing during an initial story writing workshop or by suggesting new stories to the customer. But, responsibility for writing stories resides with the customer and cannot be passed to the developers."

Wow... I had no idea. Right now we're writing the user stories...

"In a blame-filled organization there are always some individuals who have learned that their best decision is to avoid all responsibility. If you're not responsible for something you can't be blamed for it when it fails, yet there's usually a way to lay claim to at least some of the success. Individuals in this type of culture will want nothing to do with hard decisions like prioritizing features into and out of releases. They'll fall back on statements such as "It's not my problem that you can't complete everything by the deadline, figure out a way to do it."

This seems to happen more often then not. I think when someone because slightly hostile, it's usually because of their own insecurities. But reading the above statement just helped me to realize to think about what they're going through. Who's grilling them, and how can I help so that they're are happy with the software but it also makes them look good to their peers.

The Agile Manifesto

Individuals and interactions ... over processes and tools.

Working software ... over comprehensive documentation.

Customer collaboration ... over contract negotiation.

Responding to change ... over following a plan.

I'm reading a book called.

Agile and Iterative Development: A Manager's Guide by Craig Larman Read more about this title...

I kept hearing this buzz word, I'm sure you've heard it. "Agile"! What does it really mean? If you scour Monster or Workopolis and search for .NET development jobs, just about everyone is asking for some sort of experience working with an Agile methodology. So what does this really mean to be Agile? The first thing that I have learned is this simple rule...

"You are not doing Agile, You are AGILE!"

I did a quick "define:agile" in Google and came across this definition:

"moving quickly and lightly;"

So what does this mean? Well... that I couldn't find a good definition on Google. What I'm learning is that there are many different processes that you can follow that are under this umbrella call the "Agile Methodology". Some of the most popular ones are "Scrum" and "XP".

Scrum:

"Scrum's distinctive emphasis among the methods is its strong promotion of self-organizing teams, daily team measurement, and avoidance of following predefined steps. Some key practices include a daily stand-up meeting (the Scrum meeting) with special questions, 30-day calendar iterations, and a demo to external stakeholders at the end of each iteration." - Agile and Iterative Development: A Manager's Guide

I think a lot of company's take some of the processes they like and mash them up together. I think stand-up meetings would work better, but I have never experienced one. (Try and convince a group of developers that you should stand up for the meeting, instead of sit like they have been... oh boy! ) I think that people tend to get comfortable in their seats and get off topic and a short meeting turns into a un productive time. Now if that happens every day, I wonder how much time is actually lost in a year.

XP:

"XP is probably the most well known agile method; it emphasizes collaboration, quick and early software creation, and skillful development practices. It is founded on four values: communication, simplicity, feedback, and courage. It includes 12 core practices, including the whole team working together in a common room, pair programming, constant refactoring, and test-driven development." - Agile and Iterative Development: A Manager's Guide

I instantly became a fan of the "XP" methodology after reading the above statement. I have begun to start trying to develop in a test-driven style and cannot turn back now. The ability to refactor, refactor and refactor without breaking changes and feel confident in my changes makes me a happy, productive programmer. When you win X number of little battles every day with test driven, or just state driven testing it makes you feel good every night that you go home. You can say... yes the code I've written is working, and working pretty darn well. So what if it's only a small component of the big picture.

So far this is my take on Agile... I have more to read, and learn.