Saturday, June 28, 2008
The Agile approach is not to group Developers, but to put a couple of Developers together with a few QA people and a Doc Writer. Now I have a team (hopefully), that is focused on accomplishing some chunk of functionality. Obviously putting people together in a room does not make them a team. Still you have a group that has the possibility and perspective to be focused on completing some functionality for the Customer. What is even better is if the Customer is part of that team as well. Then you can be very confident that the functionality is not only complete, but actually what the customer wants. It wont be all of what the customer wants, but it will be something.
This is a huge change from the way people in this industry typically work. Its a change no one will really want. Still, it can have a dramatic effect on what you get down, and how happy your customer is.
Monday, June 23, 2008
So I find that most of the effort in the first few iterations of a project is actually spent prototyping and refining requirements. This is the time where Stories or Backlog Items are broken down because they were too general to begin with. This is the time when tasks are defined. This is the time when the original high level estimates are tested for sanity. This is also the time when the calendar is consulted to see if Joe UI Guru is going to be on vacation during the bulk of the UI prototype work. This is what used to be called design.
Now I know that we don't have a design phase anymore, but you gotta have a plan. I do agree that it does not need to be a thorough and detailed plan. Still one should identify the areas that represent the most risk. We are not going to spend time trying to figure out how we are going to put text on the screen for most apps. We know how to do that. In fact we know several ways to do that and that choice is an implementation detail. We are going to spend time on how the UI flow works to avoid the steps in the wrong order bug. Or we should. I believe the TDD, code and refactor approach assumes design is inherent in the act of coding and therefore assumes a pretty good, fairly experienced developer. If your team is made up of such people, then it will likely work because of there experience level. If you have say interns working on your team, forcing them to stop an think about the code they are about to create is probably worth while.
So what do we call this part of the development cycle? I like detailed planning.
Check back next week to hear how the story ends.
Monday, June 16, 2008
Monday, June 09, 2008
I am a Nerd God.
Well that's what the test says anyway. My boss is not a Nerd God. He was a nerd and maybe still is, but not a Nerd God. I have dreams entirely made up of code. Note, I was not coding in the dream. Rather all of existence was code. I suspect that I have a little more than healthy obsession with code. I learn new programming languages for fun. I practiced coding before Dave Thomas started Code-Kata. When I am stressed out from a day of coding at work I come home and the first thing I do after saying hello to my lovely wife and daughters is to start thinking about the projects I am working on at home, it helps me relax.
My boss has not done any type of coding for years on the other hand. My boss is well spoken and articulate. He has a good mind for dates (I do not!). He is good at reading people, knowing if they are upset. He is excellent at explaining the problem in a way that all can understand and that does not upset anymore unduly. I am good at inciting a riot with a single statement. OK, not quite that bad, it usually take two or three.
So no, my boss could not do my job, but then I could not do his either. Don't misunderstand me, he could figure it out given time, but the results would not be up to snuff. He has written code in the past. Good code as far as I know. With some practice I am sure he could write good code again, but probably never great code. Not to say that all the code I write is great, but I do write great code from time to time.
I have been a project manager. I received an award for my skills running a project. Kept people on track, got things done and generally hated every minute of it. I am pretty sure the people who worked for me did not find it a picnic either. I would never be a great project manager. My boss is a great project manager. I'm not just saying that in case he reads this blog. I doubt anyone reads this blog :-). He does some pretty amazing things with moving people on our team around. He know just when to pull someone off team A and put them on team B to get both projects done on time. That's what I mean when I say he has a head for dates. We have done some amazing work these last two years that I have worked for him. You would never hear him say it, but a good chunk of what we have accomplished is a direct result of his management. Still he could not do my job.
There is an implied elitism in the idea that my manager should be able to do my job. Its like saying "If you are smart enough to be a programmer then obviously you can manage a project". Does anyone expect the general contractor to be able to do plumbing, electrical and carpentry work? What about sheet rock, masonry, and landscaping? Obviously no one can be good at all of that (and there is more to do). That's why we have different people on the team. Different skills make the team stronger.
Does my boss understand my job, yes certainly. Is he capable of it, no decidedly not. That is part of why he is now a manager. If he was a skilled and adept programmer he would never have been allowed to go into full time management. At least he would not have been allowed to do that at the company where I currently work. My present company values technical people enough that it is never necessary to "make the switch" to management just to get paid more.
What does this have to do with Agile Methodologies though? You'll have to keep reading to find out.
Thursday, June 05, 2008
I have recently taken on a new role at work. I am the tool wright for our Business Unit. This mean that it is my responsibility to ensure that the tools we use are "sharp" and ready to be used. One of the tools we use is our process. I mean the low level development process as apposed to the higher level software life cycle process (though I am responsible to maintain that as well). When I say I am responsible for our development process, that means it's my job to document it. It is also my job to create Templates/Tools/whatever else to make the process work as smoothly as it can. No process has zero impact on those who follow it, but the impact should be minimal and relatively painless.
All this means that I attend many meetings about our process. As we are making the transition from an ad-hock process (read that as essentially no process) to an Agile process (more or less XP), there are many things we have to figure out. One thing I keep hearing from the developers is that we are not Agile, to which management responds we are agile and have been for a while. Furthermore, management insists that we have to be agile to be effective in our market place. You gotta love it when some one takes a word that everyone knows the meaning of and gives it a new meaning.
So what does it mean to be agile and what does it mean to be Agile? Well, Agile used to mean something. In fact it meant something pretty useful after the Agile Manifesto was originally drafted. So you don't have to follow the link I will copy the Agile Manifesto here:
We are uncovering better ways of developing software by doing it
and helping others do it. Through this work we have come to value:
- Individuals and interactions over processes and tools
- Working software over comprehensive documentation
- Customer collaboration over contract negotiation
- Responding to change over following a plan
That is, while there is value in the items on the right, we
value the items on the left more.
That's it. Its fairly loose, but it defines an idea, an approach to the problem. What it doesn't do is cause someone to purchase a book, or high a consulting company. Don't misunderstand me, I have no issues with XP, or Scrum, or DSDM or whatever your favorite Agile Methodology is, but the strict adherence to any methodology is contrary to the fourth point above. The goal of Agile methods (all agile methods) is to respond to the real world rather than focus on the model. A Methodology is a group of methods that have been identified as typically having a favorable result. Sometimes people call them best practices, but the goal is to continue to do what has worked in the past. This is normal and useful. You don't figure out how to get to work each morning, you go the same way you went yesterday and know that you will likely make it.
The issue come when you turn a corner and find that a construction crew has dug up the road to work on the sewer. Obviously you cannot continue to go that way. It might be possible to get through, but it would be risky at best. Likely it would end badly, so instead you think to yourself what other path can I take to get to work. Project management should work the same way and it often does. The issue with Waterfall Methodologies it turns out wasn't that they didn't allow for change, but that people did not recognize and respond to the need for change. Almost all Waterfall methodologies have an idea of a feedback loop built into them somewhere. It is usually very long and so relies on people to remember problems and be interested in fixing them weeks or months after they have been a problem. Agile methods stress shortening this time frame and that is a good thing, but you still have to recognize when the train is off the tracks.
I like the train off the tracks image because I locomotive that has left its rails does not stop right away. It is going to stop soon however and it will make a mess as it does so. I hear people say things like "We are still getting things done, so we must be alright." I don't know why people think that way. It would be like skidding sideways down a freeway and saying we are still going toward our destination so we are alright. No you are not. Yes your moving in the right direction, but you have no control, etc. This will end badly.
So where am I going with this? Response to change is not what makes Agile Methods different. What allows for agility (the ability to change direction) in Agile Methods is knowing where we are. What is important and different about Agile Methods is defining work that can be done in a time frame that allows you to change course. Having things that you can get done in days or weeks means that you can change direction in days or weeks. If everything you are working on is going to take months, then it is very difficult to change priority and work on something different. Yes, but you say it really does take months to do ... I know it does, but to accomplish that you are really doing 100 smaller things that take days or weeks to do. What Agile Methods are about is identifying what those smaller things are and assigning them. So that you can change who is helping with the work, or even what work is getting done this week as the project goes on.