Friday, September 23, 2005
40 Hour Work Week, Energetic Work, Sit Together and Points
We view items in the title as all having something to do with each other, in our particular context. Currently many people work "off-line". I frequently start at 5:00 in the morning from home, and don't go into the office until 10:00. Others may work late at night. It is our believe that this is an anti-pattern, in that it violates "Sit Together" and "Pair Programming". (Yes, we won't be pairing - but we'll be "group programming" of a sort).
We also all have other projects we are responsible for. XP talks about not time slicing - but we don't think we can get away from it - and we've all done it for so long that we *think* it will be fine. But what we have done is come up with our "Team" hours. During that time, we'll Sit Together, and that is the ONLY time we'll really work on the project. (We may build some test harnesses, etc. "off-line" - but all building tests, code, stories, etc. will be done "on-line"). So mostly we'll work on our other projects off-line.
We have picked 23 hours a week where we will work on-line. We believe that this will provide Energetic Work - in that is when we'll be focused on this project, making good progress, running tested features, measuring velocity over weekly iterations, etc. We won't violate the 23 hours a week - or not violate it much (an hour or two here or there maybe). That will be our "40 hours a week". We will never work late (for us), never work the weekend, etc.
In addition to never working off-line, we also will only do work if there are 2 of the 3 programmers present. This will occur almost all the time - so we shouldn't lose too much down time because only one person is present. If one person is out, the other two will bring them up to speed when they return.
In looking at our 23 hours a week of "energized work" - we decided we can produce 46 hours of work, rounded down to 45 (division of 3). We'll use this for estimating. Yes, Ron suggests to start with 1/3, but we are going with 2/3s of the hours of the team. We think we can sustain that. We might be wrong. We'll then translate that into 45 points per iteration, with each person doing 15 points. 1 point per hour is perhaps pretty fine - but some of our stories are pretty small. That is the nature of how we do things and we believe it will work for us. We'll see.
One of the great things about XP (we believe) is incremental design. And we feel (based on reading, email list, etc) that we can apply it to XP itself. So much of our conversations contain phrases like "Well we don't exactly how we'll do this yet, but we have an idea, we'll start in that direction, and we'll refine as needed."
I love the line from the pink book.
What if we don't have the process totally define yet... don't worry, we don't.
We also all have other projects we are responsible for. XP talks about not time slicing - but we don't think we can get away from it - and we've all done it for so long that we *think* it will be fine. But what we have done is come up with our "Team" hours. During that time, we'll Sit Together, and that is the ONLY time we'll really work on the project. (We may build some test harnesses, etc. "off-line" - but all building tests, code, stories, etc. will be done "on-line"). So mostly we'll work on our other projects off-line.
We have picked 23 hours a week where we will work on-line. We believe that this will provide Energetic Work - in that is when we'll be focused on this project, making good progress, running tested features, measuring velocity over weekly iterations, etc. We won't violate the 23 hours a week - or not violate it much (an hour or two here or there maybe). That will be our "40 hours a week". We will never work late (for us), never work the weekend, etc.
In addition to never working off-line, we also will only do work if there are 2 of the 3 programmers present. This will occur almost all the time - so we shouldn't lose too much down time because only one person is present. If one person is out, the other two will bring them up to speed when they return.
In looking at our 23 hours a week of "energized work" - we decided we can produce 46 hours of work, rounded down to 45 (division of 3). We'll use this for estimating. Yes, Ron suggests to start with 1/3, but we are going with 2/3s of the hours of the team. We think we can sustain that. We might be wrong. We'll then translate that into 45 points per iteration, with each person doing 15 points. 1 point per hour is perhaps pretty fine - but some of our stories are pretty small. That is the nature of how we do things and we believe it will work for us. We'll see.
One of the great things about XP (we believe) is incremental design. And we feel (based on reading, email list, etc) that we can apply it to XP itself. So much of our conversations contain phrases like "Well we don't exactly how we'll do this yet, but we have an idea, we'll start in that direction, and we'll refine as needed."
I love the line from the pink book.
What if we don't have all the stories defined?
Don't worry -- you don't.
What if we don't have the process totally define yet... don't worry, we don't.
Practices
Following are the list of XP practices. Note to self: I should also go look at the 12 points in James Shore's The Extreme Programmers' Oath. These were taking from XPEe2. Turns out we'll be following almost all of them. Where not, there will be comments. If there are no comments, then we are going to follow that practice.
Primary:
Corollary:
As noted previously, management had requested that the team (3 programmers, 1 customer proxy, 1 tester) get together and discuss all the primary principles and pick which ones we'd use. Note any issues we couldn't resolve on the team, and then invite management in to discuss with them which principles we had picked and get them to help us resolve issues.
We walked through the above and discussed them all. What we though they meant to us, how we thought they applied, etc. And as you can see, we picked almost all the principles (primary and corollary) - and we had no issues. There was complete agreement on all of them.
It took us most of the day - and it was a very successful start.
Tomorrow - we start with stories. Cool. :)
Primary:
- EnergeticWork
- IncrementalDesign
- PairProgramming
- Initially we are going to try SitTogether and see if we can get enough benefits from pair programming. We will pair at times - as needed. I know - folks would say that is Always. But we are going to ease into this. If we find pairing always works well for us, and we are comfortable with it, then we'll start doing it. But at first we will at least talk a lot, and look at each others stuff as we get little pieces done.
- TestFirstProgramming
- WholeTeam
- InformativeWorkspace
- SitTogether
- ContinuousIntegration
- TenMinuteBuild
- We don't believe this applies, because we are using a system that doesn't really "build". But we understand the philosophy of quick acceptance tests, etc. and so we'll keep an eye on that.
- WeeklyCycle
- QuarterlyCycle
- Usually our implementations are faster than quarterly. We'll go with the idea behind this though. Small releases that are quicker than normal, immediate customer feedback, etc.
- UserStories
- ProjectSlack
Corollary:
- NegotiatedScopeContract
- We don't think this applies in our environment.
- PayPerUse
- We don't think this applies in our environment.
- DailyDeployment
- We are going to try and be extreme... but not that extreme - at least for now
- RootCauseAnalysis
- RealCustomerInvolvement - CustomerProxy
- ShrinkingTeams
- We are starting with 3 people - so we don't think our team will shrink.
- TeamContinuity
- CodeAndTest
- SharedCode
- SingleCodeBase
As noted previously, management had requested that the team (3 programmers, 1 customer proxy, 1 tester) get together and discuss all the primary principles and pick which ones we'd use. Note any issues we couldn't resolve on the team, and then invite management in to discuss with them which principles we had picked and get them to help us resolve issues.
We walked through the above and discussed them all. What we though they meant to us, how we thought they applied, etc. And as you can see, we picked almost all the principles (primary and corollary) - and we had no issues. There was complete agreement on all of them.
It took us most of the day - and it was a very successful start.
Tomorrow - we start with stories. Cool. :)
Wednesday, September 21, 2005
We are starting!
So - we're starting with "true" XP. By true I mean we aren't just going to take some concepts that we've heard of, like TDD, and try and apply them in our current process, but we are actually going to "try this XP thing" out. How did we get here?
We are starting a new implementation. It has to be done "quickly" and we want to get a minimal amount of functionality out and then build upon that. This is the perfect XP kind of thing. Let the customer pick what they want first, build it, and then let them pick some more. Quick development, quick feedback.
So - building on what I wrote in "Purpose" - we went and talked to the customer last week. They have many features they'd like us to do - eventually; but only one they have to have now. I talked to them about doing iterations and short releases, and they totally got it and are all for it. Unlike many of our current customers, where they pretty much know what they want, in the two day talk we had with our new customers, the features changed back and forth. This perfect for XP's "Embrace change" philosophy. So - we're going to "try this XP thing".
Because I'm totally engergized about this, my approach is "we should just do this". My old manager had a different (more XP philosophy) thought. He asked to borrow XPE2e on the plane ride out. He said, "You should let the senior manager read it on the way back", which I did and he read it. So when we got back together on Monday, 3 of us had now read the book and had some common ground in understanding and terminology. We then put together the team, and my old manager (very wise guy that he is) said, "I know you are rearing to go - but I think we should buy a few more books, let everyone on the team read them, and then we'll all have a common understanding." Excellent point. I want to start NOW - but a day or two isn't going to kill us.
So, that is what we are doing. Monday night I bought 2 more books, Tuesday and Tuesday night folks read them, and today on Wed we are getting together to discuss which practices we are going to follow and how we will do it. As has been suggested, if you are in an organization that is used to a process, don't just scrap it all and follow every XP practice. Maybe pick some of the principle ones, then do the collary, etc.
Following my "purpose" - here is a summary of how we got to our current state, and what our next steps will be:
And reasons I believe this will work great for the current system we are trying to build:
Again - the main keys at this stage:
I'll report back within the next few days with what practices we've decided on, and how things are going!
We are starting a new implementation. It has to be done "quickly" and we want to get a minimal amount of functionality out and then build upon that. This is the perfect XP kind of thing. Let the customer pick what they want first, build it, and then let them pick some more. Quick development, quick feedback.
So - building on what I wrote in "Purpose" - we went and talked to the customer last week. They have many features they'd like us to do - eventually; but only one they have to have now. I talked to them about doing iterations and short releases, and they totally got it and are all for it. Unlike many of our current customers, where they pretty much know what they want, in the two day talk we had with our new customers, the features changed back and forth. This perfect for XP's "Embrace change" philosophy. So - we're going to "try this XP thing".
Because I'm totally engergized about this, my approach is "we should just do this". My old manager had a different (more XP philosophy) thought. He asked to borrow XPE2e on the plane ride out. He said, "You should let the senior manager read it on the way back", which I did and he read it. So when we got back together on Monday, 3 of us had now read the book and had some common ground in understanding and terminology. We then put together the team, and my old manager (very wise guy that he is) said, "I know you are rearing to go - but I think we should buy a few more books, let everyone on the team read them, and then we'll all have a common understanding." Excellent point. I want to start NOW - but a day or two isn't going to kill us.
So, that is what we are doing. Monday night I bought 2 more books, Tuesday and Tuesday night folks read them, and today on Wed we are getting together to discuss which practices we are going to follow and how we will do it. As has been suggested, if you are in an organization that is used to a process, don't just scrap it all and follow every XP practice. Maybe pick some of the principle ones, then do the collary, etc.
Following my "purpose" - here is a summary of how we got to our current state, and what our next steps will be:
- I did some XP reading on the mailing list, went to some cosAgile meetings, and then read XPE2e and the pink book
- My management read XPE2e
- Team members read XPE2e
- We are going to meet (just "the team" - no management) and discuss what practices we'd like to use in this first release
- After we decide that we'll meet with management and discuss issues, concerns, get buy-off
- Then we'll start doing it
And reasons I believe this will work great for the current system we are trying to build:
- User has "stories" in mind, but may change priority and doesn't have all the "requirements" worked out yet. We can expand those with "conversation" as we work the "stories"
- We have a great customer proxy on-site
- Managment has agreed that we can take a "Whole Team" approach and has oked the team
- The first "release" is very small in scope, so we don't have to take a BDUF approach, but can a few features out quickly that are small in scope and valuable to hte user
Again - the main keys at this stage:
- Everyone has read the book and has a common understanding, and is energized about trying this
- The customer is willing to take an iterative approach to their problem, where we do frequent releases and get them something now, rather than more things in a "big bang" approach
I'll report back within the next few days with what practices we've decided on, and how things are going!
Saturday, September 10, 2005
BDUF, little waterfalls, user stories, and on-site customers
There have been a few discussions on the xp mailing list that discussed BDUF (Big Design Up-Front) vs Agile/XP methods. And also the concept of "little waterfalls". Are you really doing iterative/xp like development, or have you just taken your big waterfall (2 months of writting requirements, 3 months of doing design, 2 months of coding, 1 month of integration testing) and just broken it down into iterations where every iteration is a little waterfall - 1 month of writting requirements; many "tasks" where each one is 2 days of doing design, 2 days of coding, 2 days of tessting; and then at the end 1 month of integration testing. Are you doing waterfalls, they are just smaller ones?
On Implementation we currently do little waterfalls. How much depends on the team, but we are obviously doing it. This was highlighted by the fact that some members recently wanted to go back to doing very detailed designs before entering the "coding" phase. We no longer use Word documents - we now use the Wiki. This has given us some benefit in that everyone can see everyone elses comments - real-time; we can be more collaborative, because the author/reviewer can have on-line conversations and everyone can see them; etc. However, in this context, what is happening is people are pretty much writting all of their code on the wiki (or in the actual source and then copy/pasting it to the wiki) but not compiling it or running it. Using an XP term - they are getting no feedback. Using another XP term - this is a waste of productivity. In any case, this is what is happening. The "design" is then reviewed, comments made on standards, style, approaches, etc. And refactoring happens. But again - with no machine feedback. The feedback is all at the human level. Once that is all approved, then the person copies the "design" back into their code (or maybe they've been updating the code all along and copying it into their "design") and then they start the "coding" phase.
At that point they are running the code and, for the most part, manually verifying that they have the results they want. This is very much a waterfall approach. In any case - that wasn't what I really wanted to talk about - but it lays the context of "here is where we are now". Another part of this (and what I wanted to discuss) is "requirements gathering" and "writting requirements". Again - we take a traditional waterfall type approach. We get all the requirements up front, and have them as detailed as possible. Requirements may change or have to be clarified (and the fact that we acknowledge that is a good thing), and ideally (in our current process) those will get documented. Everything has to be documented, in detail. The XP thought on this is that it is a waste of time. I'm reading Extreme Programming Installed right now, and it talks about this. It talks about the programmer directly talking to the on-site customer and resolving many of these little issues - that aren't discussed in the user story (which is a pretty high level statement of some feature that should be implemented - my words). We don't have an on-site customer, but we have an on-site customer representative (the Business Analyst (BA)). The XP thought is that a developer going over and clarifying something with the BA is a "good thing". It is better than email, irc, using the wiki, etc. - because it is human communication, faster, etc. We currently tend to believe this is a "bad thing". And the following from the book sums this up very well,
At this point a light-bulb goes on for me. I'm trying to reconcile how cool I think XP is, how much I like change and the whole idea of going to User Stories, etc. appeals to me; but at the same time - at work - I'm pushing for "You need to make sure you get the requirements specification updated" - "You need to make sure and add that requirement to the wiki", etc. And this is exactly it - the proven fear (i.e., this has happened over and over again and lead to bad things happening) that the information will get lost. That we'll be reviewing the design or code and say "That doesn't meet the requirement" and the programmer will say "Oh - yeah, I talked to the BA and that isn't the real requirement" or a tester will be testing the system and have the same experience.
XP, in part, addresses this by the statement above. "..., but remember that you will have specified acceptance tests,..." And that is why we have the fear. Because we DO NOT have specified acceptance tests. We do a lot of testing and we do a great job of testing... but it is more a waterfall approach to testing. We have unit tests and regression tests. And we have tests written by the testers that are based on the requirement documents (and thus the need for everything to be documented). But we don't have what I believe XP is talking about. We don't have the developers/testers and BA sit down and write the acceptance tests together. And we definately don't have any form of TDD where the discussion that appears in the book (or happens in "hallway conversations all the time at work) drive two new tests to be written - RIGHT THEN. The book is right. IF as soon as that conversation happend, the people involved sat down together and wrote up the new tests - and then let everyone know those tests existed - and those tests were part of the test suite that automatically runs whenever testing is done. Then yes, we wouldn't have to go update the requirements documents - because the tests meet that need.
And beauty of this XP practice is that the XP way is so much more efficient. It uses human communication to resolve/clarify - which is faster. It uses an acceptance test to document it (which given the right framework, etc. - is faster than having the BA document it, the developer review it, etc. etc.) and that acceptence test has dual purpose. Not only does it document the requirement, but it is then used to prove that the system meets the requirement. In our current methodology that is two tasks. The requirement statement documents the requirement - and then some time later (days for sure, but more likely weeks) a tester writes a test to prove that it works. Based on their understanding of what the text says - not of what the actual human said.
The challenge, imo, is to get people who are used to working in this methodology to change. Because most likely they are going to think it is less precise (it isn't written down in a document) and that it takes more time (because it is so easy to just write it up, vs having to create a test). The truth of the matter thoug, is that the test is more precise - the system will either do or not do exactly what it is testing, and that it will take less time - because there is so much wasted time when requirements are misunderstood and code is redone, tests are redone, information is lost, etc.
So - as is said over and over in the XP books and discussions - you can do some of XP (and most likely you'll have to adopt it a piece at a time), but the more practices you do, the more "bang for the buck" you'll get. Here is a great occurence of that. You can do user stories on their own - but how they really work is when they are combined with acceptence tests - and acceptence tests that are written in collaboration with the user and written as the user story is being worked, not after the fact.
Bottom line: We currently have a problem that our requirements are not always percise enough and sometimes hallway conversation information is lost. The solution is NOT to write more detailed requirements. The solution is to use User Stories COUPLED with developing Acceptence Tests - not only upfront, but any time more information is learned; Acceptence Tests which reflect that newly accquired information.
On Implementation we currently do little waterfalls. How much depends on the team, but we are obviously doing it. This was highlighted by the fact that some members recently wanted to go back to doing very detailed designs before entering the "coding" phase. We no longer use Word documents - we now use the Wiki. This has given us some benefit in that everyone can see everyone elses comments - real-time; we can be more collaborative, because the author/reviewer can have on-line conversations and everyone can see them; etc. However, in this context, what is happening is people are pretty much writting all of their code on the wiki (or in the actual source and then copy/pasting it to the wiki) but not compiling it or running it. Using an XP term - they are getting no feedback. Using another XP term - this is a waste of productivity. In any case, this is what is happening. The "design" is then reviewed, comments made on standards, style, approaches, etc. And refactoring happens. But again - with no machine feedback. The feedback is all at the human level. Once that is all approved, then the person copies the "design" back into their code (or maybe they've been updating the code all along and copying it into their "design") and then they start the "coding" phase.
At that point they are running the code and, for the most part, manually verifying that they have the results they want. This is very much a waterfall approach. In any case - that wasn't what I really wanted to talk about - but it lays the context of "here is where we are now". Another part of this (and what I wanted to discuss) is "requirements gathering" and "writting requirements". Again - we take a traditional waterfall type approach. We get all the requirements up front, and have them as detailed as possible. Requirements may change or have to be clarified (and the fact that we acknowledge that is a good thing), and ideally (in our current process) those will get documented. Everything has to be documented, in detail. The XP thought on this is that it is a waste of time. I'm reading Extreme Programming Installed right now, and it talks about this. It talks about the programmer directly talking to the on-site customer and resolving many of these little issues - that aren't discussed in the user story (which is a pretty high level statement of some feature that should be implemented - my words). We don't have an on-site customer, but we have an on-site customer representative (the Business Analyst (BA)). The XP thought is that a developer going over and clarifying something with the BA is a "good thing". It is better than email, irc, using the wiki, etc. - because it is human communication, faster, etc. We currently tend to believe this is a "bad thing". And the following from the book sums this up very well,
You might also be concerned that this important information about the requirements will get lost somewhere, but remember that you will have specified acceptance terst, and they will surely cover [the requirements that were being discussed]."
At this point a light-bulb goes on for me. I'm trying to reconcile how cool I think XP is, how much I like change and the whole idea of going to User Stories, etc. appeals to me; but at the same time - at work - I'm pushing for "You need to make sure you get the requirements specification updated" - "You need to make sure and add that requirement to the wiki", etc. And this is exactly it - the proven fear (i.e., this has happened over and over again and lead to bad things happening) that the information will get lost. That we'll be reviewing the design or code and say "That doesn't meet the requirement" and the programmer will say "Oh - yeah, I talked to the BA and that isn't the real requirement" or a tester will be testing the system and have the same experience.
XP, in part, addresses this by the statement above. "..., but remember that you will have specified acceptance tests,..." And that is why we have the fear. Because we DO NOT have specified acceptance tests. We do a lot of testing and we do a great job of testing... but it is more a waterfall approach to testing. We have unit tests and regression tests. And we have tests written by the testers that are based on the requirement documents (and thus the need for everything to be documented). But we don't have what I believe XP is talking about. We don't have the developers/testers and BA sit down and write the acceptance tests together. And we definately don't have any form of TDD where the discussion that appears in the book (or happens in "hallway conversations all the time at work) drive two new tests to be written - RIGHT THEN. The book is right. IF as soon as that conversation happend, the people involved sat down together and wrote up the new tests - and then let everyone know those tests existed - and those tests were part of the test suite that automatically runs whenever testing is done. Then yes, we wouldn't have to go update the requirements documents - because the tests meet that need.
And beauty of this XP practice is that the XP way is so much more efficient. It uses human communication to resolve/clarify - which is faster. It uses an acceptance test to document it (which given the right framework, etc. - is faster than having the BA document it, the developer review it, etc. etc.) and that acceptence test has dual purpose. Not only does it document the requirement, but it is then used to prove that the system meets the requirement. In our current methodology that is two tasks. The requirement statement documents the requirement - and then some time later (days for sure, but more likely weeks) a tester writes a test to prove that it works. Based on their understanding of what the text says - not of what the actual human said.
The challenge, imo, is to get people who are used to working in this methodology to change. Because most likely they are going to think it is less precise (it isn't written down in a document) and that it takes more time (because it is so easy to just write it up, vs having to create a test). The truth of the matter thoug, is that the test is more precise - the system will either do or not do exactly what it is testing, and that it will take less time - because there is so much wasted time when requirements are misunderstood and code is redone, tests are redone, information is lost, etc.
So - as is said over and over in the XP books and discussions - you can do some of XP (and most likely you'll have to adopt it a piece at a time), but the more practices you do, the more "bang for the buck" you'll get. Here is a great occurence of that. You can do user stories on their own - but how they really work is when they are combined with acceptence tests - and acceptence tests that are written in collaboration with the user and written as the user story is being worked, not after the fact.
Bottom line: We currently have a problem that our requirements are not always percise enough and sometimes hallway conversation information is lost. The solution is NOT to write more detailed requirements. The solution is to use User Stories COUPLED with developing Acceptence Tests - not only upfront, but any time more information is learned; Acceptence Tests which reflect that newly accquired information.
more on Purpose
So - thinking about it some more, I decided that I don't want to just post - "Here is what we are trying, and here is why". That wouldn't really describe the journey well enough, would it? It would kind of be like "Here are the places we stopped on the trip, and where we ended up" - but maybe not all the conversations that helped get us there.
I'm doing quite a bit of reading right now: xp books, the xp mailing list, and articles written by some of the xp authors. Mostly those that are pointed to be discussions in the mailing lists. I'm just soaking it up. Great stuff.
But as I'm doing this, I'm also thinking about potential problems I see in how we do things. Things that could possibly change. Things that are already close and could easily be tweaked - things that are far away. So, I'll discuss some of those as well.
I'm doing quite a bit of reading right now: xp books, the xp mailing list, and articles written by some of the xp authors. Mostly those that are pointed to be discussions in the mailing lists. I'm just soaking it up. Great stuff.
But as I'm doing this, I'm also thinking about potential problems I see in how we do things. Things that could possibly change. Things that are already close and could easily be tweaked - things that are far away. So, I'll discuss some of those as well.
Monday, September 05, 2005
Purpose
I have quite a few blogs - my main one being WorshipJunky. So - why anoter one? This one (like all my secondary blogs) is to blog some specific aspect of my life - whether it be recipes I've written or experimented with, my mission trip to Costa Rica, or my short life as Jarill.
Quite some time ago I heard of Agile programming and XP. I originally stumbled across the first Wiki a number of years ago. Based on that we (the Sheriff Infrastructure team at MCI) started using the wiki (and also IRC along with logs) as a way to do more collaborative development. We were already very collaborative and pretty iterative, but in mostly a mini-waterfall sort of way. With the wiki, we became more collabortive, because instead of a "write a 100 page document", "review it for a week", "discuss it for a day" and then "update it for a week" sort of cycle, we went to a "write it for a few days (or maybe even 30 minutes"), "review it for 10 minutes", "discuss it for 5 minutes" and "update it for 5 minutes" sort of cycle. This let us iterate much quicker and provided us with the benefits of
So - we were doing this "wiki thing" and disucssing things on IRC - because some of us work every different hours than everyone else - and we say improvement. Then we picked up on TDD (Test Driven Development) and we started applying that. I don't remember how we first came upon it, but from my point of view it was probably a number of things.
So - we were doing some short (for us) iterations, doing some TDD and being very collaborative and iterative. To us, this felt like we were doing "Agile" and "XP" - although we knew to someone who was truely doing it, we might seem like we were a long ways away. But at least it was moving towards it.
Recently, I went to a talk hosted by cosAgile in which Ron Jeffries spoke. That was sort of a turning point. It did a couple of things:
Luckily, at this point in time, I also got the oppurtuinty to work on a new project. The group I'm in (Sheriff) builds a system (which I've discussed on my main blog here and there) that is primarily composed of two layers. The Infrastructure (which provides a common framework, transport, layer, etc. - written in C++) and customer specific Implementations (which build upon that framework and are primarily written in CLIPS). About a year ago I transitioned from being the Infrastructure Architect to being the Chief Architect over both the Infrastructure and the Implementation. This has meet with some successs (mostly technical) and some failures (mostly process and people based) as I try and move some "Agile/XP like" practices into the implementation teams. Much of my failures could have probably been avoided if I had actually read the XP books first, and taken some advice on how to do this... but oh well. Live and learn. In any case, I'm at the point where I might actually be working on a new implementation.
This is very good from an XP point of view - because archtiects should actually *write* code. They should sign up for tasks, etc. This is also good from my own point (before I read it in an XP book) - because recently it has become very apparent that I need to "get in the trenches" to actually experience some of the issues. And also to prove that some of the techniques I'm pushing/suggesting (pushing is probably a very bad XP word) will actually work. Saying that we can do TDD is one thing. Using TDD on a successful implementation then having that as an example, is a much better way. As our many of the techniques.
So - this implementation is currently in the "we need to talk to the customer and agree this is the right thing to do" phase. But we have high hopes it is. Assuming we can achieve some benefit for the customer, then we'll probably do a new implementation and I'll probably be on the team. This will be brand new, from scratch (although we have a lot of code, experience, patterns, etc. in other implementations). So some framework will be set - BUT we might be able to approach this in a whole new way, using a new development process.
To me - this seems like the perfect place to "get in the trenches" and also to try and bring in some new XP practices. We probably won't do them all. We might not use an exact practice, but might try a principle, etc. But I believe it will be a step forward. And in thinking about this - I decided to start this blog, for a few reasons:
So - having said all that, the purpose of this blog is to jounal my journey of "Starting down the road to XP". Why we pick the principles/practices we pick. Why and how we carry some of those out. Up-front, how we think those will work and hopefully in hindsight whether or not we were right. What we learned, etc.
And a final note - this may be a bit premature. I'm not sure of the implementation or that I'll be on it yet... But I'm pretty sure. And so I'm approaching this somewhat iteratively. Here is where I think I'm going and how I want to get there... So let me put these thoughts down now. If it turns out I don't go that direction, nothing but a little time lost. If I do go that way, then I'm already a bit ahead (because I've already started this blog) and it always helps me to write things down as I think of them, rather than after the fact.
Quite some time ago I heard of Agile programming and XP. I originally stumbled across the first Wiki a number of years ago. Based on that we (the Sheriff Infrastructure team at MCI) started using the wiki (and also IRC along with logs) as a way to do more collaborative development. We were already very collaborative and pretty iterative, but in mostly a mini-waterfall sort of way. With the wiki, we became more collabortive, because instead of a "write a 100 page document", "review it for a week", "discuss it for a day" and then "update it for a week" sort of cycle, we went to a "write it for a few days (or maybe even 30 minutes"), "review it for 10 minutes", "discuss it for 5 minutes" and "update it for 5 minutes" sort of cycle. This let us iterate much quicker and provided us with the benefits of
- knowing if the author was off-track,
- team verification (Feedback as an XP term) very quickly, and
- to some extent let us finish the design quicker, because at some point we knew we were "done enough"
So - we were doing this "wiki thing" and disucssing things on IRC - because some of us work every different hours than everyone else - and we say improvement. Then we picked up on TDD (Test Driven Development) and we started applying that. I don't remember how we first came upon it, but from my point of view it was probably a number of things.
- I ran across it on the Wiki
- Team members probably read about it
- I saw/heard about it in seminars - Seeing Martin Fowler do a quick refactoring... well you just know it is "right". Even if you think "Man, I don't see how we could do that on our project"... Seeing him change code, test it, have it go green, then change, test, etc. etc., all in a minute. Well its just beautiful.
- And very importantly - we HAD to do it. We got to a state where we had a complex set of functionality, being developed by multiple team members, and we were never sure how "done" we were. Eventually the manager insisted what we write a bunch of tests and start running them, to see where we were at.
So - we were doing some short (for us) iterations, doing some TDD and being very collaborative and iterative. To us, this felt like we were doing "Agile" and "XP" - although we knew to someone who was truely doing it, we might seem like we were a long ways away. But at least it was moving towards it.
Recently, I went to a talk hosted by cosAgile in which Ron Jeffries spoke. That was sort of a turning point. It did a couple of things:
- Confirmed that some of the things I and some team members thought were "right", were actually viewed as "right" by... the gurus.
- introduced me to cosAgile - and from there I started doing weekly pair programming in Java (which I don't know) using Eclipse (which I don't know). But it gave me a chance to see some of this in practice. It aslo caused me to
- join the xp mail list - which caused me to spend much time reading and thinking about Agile/XP - and caused me to
- buy XPE2 (XP Explained V2) and the XP Installed (the pink book). Both of which caused me to think about things in a different way and move me from thinking about that "Agile/XP" to having a better understanding of what it is. Well the books and the mailing list.
Luckily, at this point in time, I also got the oppurtuinty to work on a new project. The group I'm in (Sheriff) builds a system (which I've discussed on my main blog here and there) that is primarily composed of two layers. The Infrastructure (which provides a common framework, transport, layer, etc. - written in C++) and customer specific Implementations (which build upon that framework and are primarily written in CLIPS). About a year ago I transitioned from being the Infrastructure Architect to being the Chief Architect over both the Infrastructure and the Implementation. This has meet with some successs (mostly technical) and some failures (mostly process and people based) as I try and move some "Agile/XP like" practices into the implementation teams. Much of my failures could have probably been avoided if I had actually read the XP books first, and taken some advice on how to do this... but oh well. Live and learn. In any case, I'm at the point where I might actually be working on a new implementation.
This is very good from an XP point of view - because archtiects should actually *write* code. They should sign up for tasks, etc. This is also good from my own point (before I read it in an XP book) - because recently it has become very apparent that I need to "get in the trenches" to actually experience some of the issues. And also to prove that some of the techniques I'm pushing/suggesting (pushing is probably a very bad XP word) will actually work. Saying that we can do TDD is one thing. Using TDD on a successful implementation then having that as an example, is a much better way. As our many of the techniques.
So - this implementation is currently in the "we need to talk to the customer and agree this is the right thing to do" phase. But we have high hopes it is. Assuming we can achieve some benefit for the customer, then we'll probably do a new implementation and I'll probably be on the team. This will be brand new, from scratch (although we have a lot of code, experience, patterns, etc. in other implementations). So some framework will be set - BUT we might be able to approach this in a whole new way, using a new development process.
To me - this seems like the perfect place to "get in the trenches" and also to try and bring in some new XP practices. We probably won't do them all. We might not use an exact practice, but might try a principle, etc. But I believe it will be a step forward. And in thinking about this - I decided to start this blog, for a few reasons:
- Blogging sometimes helps me with my thoughts. First, because in writting stuff down, I sometimes have to think about it a little harder, and Secondly, in assuming that someone (even if it turns out is no-one) is going to read it - it also helps me think things through a little bit more
- I've noticed a number of people on the XP mailing list have blogs where they put ideas out, w/o just posting them all to the list - so it seemed like a good thing to do, and
- It occured to me that there are a number of "how do I start doing this" type questions out there... and that somehow, in documenting how I do this, it might not only help myself, but help others.
So - having said all that, the purpose of this blog is to jounal my journey of "Starting down the road to XP". Why we pick the principles/practices we pick. Why and how we carry some of those out. Up-front, how we think those will work and hopefully in hindsight whether or not we were right. What we learned, etc.
And a final note - this may be a bit premature. I'm not sure of the implementation or that I'll be on it yet... But I'm pretty sure. And so I'm approaching this somewhat iteratively. Here is where I think I'm going and how I want to get there... So let me put these thoughts down now. If it turns out I don't go that direction, nothing but a little time lost. If I do go that way, then I'm already a bit ahead (because I've already started this blog) and it always helps me to write things down as I think of them, rather than after the fact.
