Are We There Yet?

So far I have been talking about aspects of agile methodologies that I am not a fan of. So lets look at what I am a fan of. One aspect of Agile Methods that I am a big fan of is the definition of done. Done is a sore spot in project management. People tend to define down based on what they have to do personally. For a developer, done typically means that the code is complete. The trick is that the no one cares if the code is done, except the developer. The customer is not buying code. The customer wants to know if they can use function XYZ. Project Management for development projects looks for the completion of functionality XYZ, but typical development projects are not organized or focused on completing XYZ. The more common organization is that the Developers work on their own, the QA people work on their own, the Doc Writers work on their own, etc. Of course they interact, but they do not work together. This leads to a "my part is done" mindset. If I am a Developer in a group of Developers, what can I say about a feature except that the code is complete?
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.

Through a Mirror Dimly

I don't know what I am doing part of the time. That is a difficult thing for any engineer to admit, but it is true. The early days of any software project are filled with uncertainty. This is when you find out what is real and what is hype. This is when the development team really pushes back on the customer/marketing. The customer doesn't have to justify what they want, but they do have to understand it. I can't create an application that is "easy to use", "responsive", or "pleasant to look at". These are all requirements I have received in the past, but I cannot fulfill them. I can build an application that has buttons on the left that define the application steps, properties for the current tool/action in the lower center and help in the lower right. I can ensure that the user will get some type of feed back for every action in less than a quarter second. I can ensure that the widgets drawn on the screen have rounded corners and a 3D glass effect like those in Vista. The difference may see like trivia to some, but as an engineer the difference is huge. These differences are also important for QA and acceptance. The first set of requirements cannot be tested. The second set can.
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.

I am not a brick in the wall

I enjoy what most people would call "Hard" music. I grew up with the Sex Pistols, Black Sabath, and of course Pink Floyd. I enjoyed the Wall when it came out (both the album and movie), and still listen to it from time to time. The title song contains the lyric, "All in all you're just another brick in the wall". Its not what most would call a pretty picture. Yet its the way most Agile Methodoologies view development staff.

I am told that I should not consider individuals when I am planning my projects. It is better to plan for the team. I can just guess how much the team will get done. Then as I track how much the team actually gets done I will start to understand how bad my guesses are and I can plan accordingly. Setting aside for the moment the idea that I should not try to become better at estimating how much work a task is, lets focus instead on the idea of scheduling for the team.

I have spent most of my professional life working on integration code. I have a background in hetworking (I used to be a network administrator and troubleshooter). This gives me a special insight into how the network is going to respond to the various schemes for getting two (or more) applications to talk to each other. I tend not to make certain mistakes because it is obvious to me that the underlying network will have issues with it. As a result of this experience I tend to get integration tasks done more quickly than other programmers. More then just getting them done faster, my solutions typically have fewer problems in the wild.

This is not just me patting myself on the back, however. I am especially bad at creating GUI code. I tend to take a long time. I tend to focus on things that turn out to be of little importance and not spend enough time on things that are important. Not to say that my code is trash, but it is not nearly as good as some other people on my team who have sort of specialized in GUI development. They just natuarally avoid certain mistakes that their experience has told them to avoid.

Now let's consider that I am planning a vacation (which I am). I will be gone for a week and a half. If it turns out that there is little integration work during that time, this will have a minimal impact on the schedule. After all the GUI work that I would have gotten done in that time is limited by my ability to do GUI work (or lack there of I guess). If there where a great deal of integration work then the story would be reversed. However I am told not to worry about such things. This seems odd to me. Am I really supposed to believe that my manager and I can switch places (see last weeks post) and that will not have an effect? That I can trade work with the Intern who is not yet finished with his degree and the outcome will be the same?

No I think not. Maybe I just don't understand, but it has not been due to lack of trying. I think Agile methodologies have it dead wrong when I am told not to do detailed planning and to ignore people's strengths. Of course I think Agile methodologies get other things right. But more on that next time.

I'm a Nerd God

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.

Being Agile

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.