Again, conversations give me a zillion things to write about.  The recent conversation that has cropped up again is my various viewpoints of the Agile Manifesto.  Not all the processes that came after the manifesto was written, but just the core manifesto itself.  Just for context, here is the manifesto in all the glory.

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.

Several of the key signatories at the time went on to write some of the core books that really gave Agile Software Development traction.  If you check out the Agile Manifesto Site and do a search for any of those people, you will find a treasure trove of software development information.

My 2 Cents

First off, I agree with a few people out there.  Agile is not Scrum for instance.  Do NOT get these things confused when checking out Agile, or pushing forward with Scrum.  As David Starr points out in his blog entry,

"About 35 minutes into this discussion, I realized I hadn't heard a question or comment that wasn't related to Scrum. I asked the room, How many people are on an agile team that is NOT using Scrum?

5 hands. Seriously, out of about 150 people of so. 5 hands."

So know, as this is one of my biggest pet peves these days, that Scrum is not Agile.  Another quote David writes,

"I assure you, dear reader, 2 week time boxes does not an agile team make."

This is the exact problem.  Take a look at the actual manifesto above.  First ideal, "Individuals and interactions over processes and tools".  There are a couple of meanings in this ideal, just as there are in the other written ideals.  But this one has a lot of contention with a set practice such as Scrum.  There are other formulas, namely XP (eXtreme) and Kanban are two that come to mind often.  But none of these are Agile, but instead a process based on the ideals of Agile.

Some of you may be thinking, "that's the same thing".  Well, no, it is not.  This type of differentiation is vitally important.  Agile is a set of ideals.  Processes are nice, but they can change, they may work for some and not others.  The Agile Manifesto covers the ideals behind what is intended, that intention being to learn and find new ways to build better software.

Ideals, not processes.  Definition versus implementation.  Class versus object.  The ideals are of utmost importance, the processes are secondary, the first ideal is what really lays this out for me "Individuals and interactions over processes and tools".  Yes, we need tools but we need the individuals and their interactions more.

For those coming into a development team, I hope you take this to mind.  It is of utmost importance that this differentiation is known and fought for.  The second the process becomes more important than the individuals and interactions, the team will effectively lose the advantages of Agile Ideals.

This is just one of my first thoughts on the topic of Agile.  I will be writing more in the near future about each of the ideals.  I will make a point to outline more of my thoughts, my opinions, and experience with the ideals of Agile and the various processes that are out there.  Maybe, I may stumble upon something new with the help of my readers?  It would be a grand overture to the ideals I hold.

I recently watched a video presentation of Alistair Cockburn, who is a fairly major name in the Agile Development Community.  It pushed me to put this entry together for future discussion that I intend to kick off (at least on this blog & the few readers I have).  I have worked on the following Agile Projects:

• My most recent project utilizing Agile Processes was at Webtrends for my stint in Engineering late 08 and earlier 09.  I worked on a team to build web services for Webtrends data access for customers.
  • The team consisted of three people, one being a team lead.  Our primary use of Agile was somewhat limited as it was a new process for the team.  We performed continuous builds via Team Foundation Server and test driven development when feasible.  We were limited in using TDD to some degree as a large part of the work was configuration based for server configuration and required a large degree of integration tests more than isolated unit tests.  In addition to TDD we also utilized user stories, burn down charts, and to some degree kanban style prioritization.  The project was a rocking success, and is now offered as a Webtrends offering and documented, discussed, blogged and continuously maintained and advanced.  Even though I am on a different team now working directly with customers to implement integrations with these REST based web services, the engineering team continues forward with more Agile practices being used daily, including paper prototyping, furthering the unit testing majority of the teams, and more.
• After* and before* the Webtrends engagement I helped to initiate Agile in a development group of 4 people at Axiom Group (now Axiom EPM) to build a Excel UI to SQL Server for accounting data storage, manipulation, analysis, trending, and retrieval.  I helped get the group kick started, and the software that was released is now called Axiom Planning.
  • The team of 4, split into two pairs, and we did pairing & individual development.  Other agile software methods used were rapid learning, extensive test driven development, continuous integration (w/ TeamCity), unit tests in builds w/ good coverage (the logical kind), mocking (for databases), self organizing team, paper prototyping, and direct daily communication with customer representatives.  We also as pairs and as a team used refactoring heavily.  In addition heavy utilization of design patterns and domain driven-design was used in close collaboration with the customer.
• In 06 & 07' I worked with Centerstance Consulting on a project which started Waterfall and moved to Agile during the course of the engagement.  We started off a team of 5 developers, grew to about 16 at one point, and shrunk down toward the completion of the overarching architectural design to about 8-12 again.
  • The teams ranged from 4-5 people per team with a team lead, to two teams with two sub-teams split with a team lead each doing their own respective stand ups (SCRUM style), a continuous integration was setup, unit & integration testing was eventually put into place across a wide spectrum of the code base.  Mocking, faking where appropriate, and general unit testing took place, with business analysts acting as customers.
• For Ghallt Enterprises I served as CTO with a business partner, leading efforts among remote teams, utilizing Agile practices (yeah, remotely, I know, it seems crazy) to develop social media software.  Methods included continuous integration, build management, pair development, code review & refactoring on a regular basis, and other practices.  Even though this is a company that a friend and I started, it served to provide a catalyst for me to push forward extensively into Agile Processes.  The level of progress, quality of code, and other characteristics that are inherent to effective Agile Processes were of a level that left no reason to endeavor toward traditional style project planning or Waterfall style approaches.

I?ve worked with others to mentor and experiment with pair development, continuous integration, unit testing, and other processes to enhance and streamline the software development life cycle.

* I write after and before Webtrends because I left Webtrends in 08' to work the Axiom effort, upon kicking that off, I then headed back to Webtrends to work on the then new Web Services with REST Architecture Project.

Beware, this is a LONG entry and if you don't read all of it you may end up offended, but rest assured what I'm writing here is the absolute truth and recruiters, project managers, project leads, development leads, developers, and anyone getting into the software industry or that has been in the industry I have many points of advice and warning.

I was recently hanging out with one of my friendly local tech recruiters over a drink or three and some good food.  They asked me to proof their position they where about to post.  As I am a friendly guy, I decided I would.  It has been a LONG time since I've looked at a post like this, as I haven't actually used Monster, Dice, or any of those sites in a rather long time.  Maybe I've thought the industry had matured a bit sense I last checked the pulse.  Being in Portland where the industry is generally about 5-10 years ahead of the rest of the country (and the world for that matter) I am always hopeful.  Here are some snippets from the post and an immediate translation.

Under the required skills section I saw a couple of points;

• Creation of automated unit test cases.
• Automated builds
• Ability to manage multiple projects and tasks simultaneously.
• Dedicated to completing assigned tasks on time.

Under the preferred skills and characteristics where some more real gems, but this one just stood out.

• Willing to work overtime, holidays, and weekends as requested by management.

My first response when looking at this was, "are you serious?  you really expect someone to take this job?  It has abusive environment and poor conditions all over it!!!!"  I was seriously shocked, after all these years, and maybe I just don't read job requirements much anymore and there are tons this crappy.  So let me elaborate a little more on this description.

First off, just from those descriptions the position looks aberrantly abusive, environmentally (i.e. work environment) bad, and probably psychologically torturous for a software developer.  Maybe I'm wrong, but whoever decided to put these requirements in the post is looking for either A: someone who is desperate for work and will last for a very short time under the abuse or B: someone who is already sadomasochistic and loves the pain of the torture.  There are amazingly software developers like that.

Now I have to pick apart some of these.  "Creation of automated unit test cases."  This immediately tells me a couple of things;

• There are some tests, they are NOT unit tests if this has been slammed into a requirement spec for automated tests cases.
• There are so many contradictory words in this request that it just doesn't make any actual logical sense.
• Unit tests are isolated, often used during refactoring, not always during automation.  Automation tests are not particularly unit, often are integration tests, and aren't really used during refactoring but instead during QA. 
• "Cases", well cases just hangs there as if Agile Processes & Waterfall Processes are having a subversive fisticuffs fight right after the specs are finished.  Whatever the "case" this requirement only really shows one thing, some type of testing is required, and the prospective candidate won't know what kind and it appears nor does the person writing the requirement.

Let us hit on the next statement.  "Automated Builds".  Ok, this one sounds like a legitimate requirement.  But stop a second and think about it along with the other requirements.  Is it logical with the others or does it exacerbate the other requirements by its simple specification?  Considering people these days people are doing CI, continuous integration, along with automated builds it leaves me with this thought that someone hasn't modernized the build process for a long while.  With that said it leaves me to this next specification and the point I want to make.

"Ability to manage multiple projects and tasks simultaneously" is a beauty.  That's the spirit for destroying any good velocity and productivity a developer might have, interrupt them a lot and give them multiple tasks all at once!  If it is a contract position, one would probably want the hire to stay productive on task, if it is a permanent position you might want them to handle multiple efforts.  However stating this immediately, before any discussion or interview is made with an individual this specification should leave a developer with the inherent fear that the project, whatever it may be, IS BEING MANAGED POORLY!  This is a massive, glaring red flag.  Sure, most projects these days are probably running through rough spots, but don't chase away the smart talent before the position even gets a glance at by the top talent.  I can promise you the top talent will look at this, and think, "well maybe they can hire me as a consultant to get them back on track, but I'm not going into the trenches because it already sounds like a "death march" with many "mythical man months" being consumed.

"Dedicated to completing assigned tasks on time" is always a hilarious thing to read.  This should be translated to "working insane hours to get tasks done based on a schedule that you have not be consulted on, or at least ignored after you?re consulted, and then getting reprimanded because you didn't finish a task that has been mismanaged from the beginning!"  This specification is probably the biggest alarm of them all.  This specification almost immediately should tell a prospective candidate that the project, or project(s) are probably being mismanaged.  If the project has had so many problems as to need to put ?dedicated to completing?" in the specification as a point there are problems.

Now someone might read this and think, "but it sounds like a good trait" and I'll state simply that it is a very good trait in a developer.  I can tell you with high confidence, developer's absolutely have this trait but are often put in circumstances that they can't meet deadlines.  I can also say with high confidence that probably 80% of the time a task is not met by a deadline it is not the developer's fault, it is the planning process & management that is in place.  Mind you, 80% is a conservative estimate, a more accurate number would probably be in the 90% range.  Developer's want to create, design, developer, and do good work. Developer's are not your McDonald's employees, these people are highly skilled.  Even the weakest developer is likely to want to get things done, but if the leadership has mismanaged the project, they'll then have to fail.  It is a sad situation that it is so often this way, but that's the cookie crumbling.

The last one anyone can see is a major red flag.  "Willing to work overtime, holidays, and weekends as requested by management".  If this where a contract position, that is a command to abuse the hours ? spend a ton of em' and bill em' because you know, just from this requirement that you'll have to anyway.  If it is a permanent position, this is really bad news for the developer.  Right from the get go a developer should look at this and realize their social life, their love life ? if they have one, marriage, or whatever else is about to go down the drain.  If something like this is in a job profile specification then you can bet money, that you'll be expected to and will have to work ridiculous hours.

With all the other specifications combined the sad fact is that you'll probably be stepping directly into a project death march from day one.  Simply put, this project, whatever it is will fail with about a 90% chance on delivery date and cost.

The Awesome Shiny Good News Out of All This!

There are ways that everyone in this scenario can get things straightened out (and no, I'm unfortunately not available right now I'm happily employed ;p ).  Here are the first 9 steps to getting things going in the right direction and staving off the death march and immanent failure.  I would have written up the first 10, but that seems touch?!

1. Get existing members into a room that are involved in this project and show them this specification.  Then throw away the specification and dig deep to find the GOOD PARTS of the project that might make it fun and exciting to a prospective candidate!
2. Immediately toss as much Waterfall Methodology in the dumpster out back AS FAST AS YOU CAN!  Read up immediately on Agile, lean style, scrum style, anything of that sort.
3. This one will be painful for the project managers, but do it if you want to succeed.  Throw away the gantt charts and project plans, if you don't you've already failed the software development effort.
4. Sit down and create some stories about what this software has to do.  Talk to the users and get it straightened out, look at the components that might need to communicate.  Bring in all the key stakeholders again and tell them the project is at RISK.
5. Find ways to get happy developers, existing and future.  If you don?t have happy developers you WILL NOT have a solid, reliable, quality product or service in the end.
6. Either figure out your burn down chart or your iterations, get stories lined up for the next steps ? i.e. the ones in the immediate next week or two and DO NOT start putting stories on a scheduled chart or out past the 2nd or 3rd iteration.
7. Get a steady velocity, stop abusing the developers, stop working overtime at every opportunity.  Overtime slows down a project, don't tell me you have to because there isn't enough time because you're perpetuating the lie that OT will build a product.  Steady, consistent, happy, clear thinking developers get a product built.  Some OT might happen, but get it the hell out of a job specification and reduce it to a minimum on the job.  You want developers that want to do a little extra, not developers that feel slave driven.
8. Make sure the teams eat lunch, communicate, get to know who everyone is, and can deal with their respective team members traits and can communicate.  Without effective and regular communication nobody is going to finish anything on time, let alone of high quality.
9. Seriously, go have a beer/beverage/cold drink or something with the team and get things out in the open.

Ok, so there are a ton more steps.  There are things that come after this, that come after the project is repaired, and even after that.  But this is the simple start to correcting the problems.  I really hate seeing projects fail, I HATE seeing projects fail because often, there is no reason for it.  Almost every project I see that fails is because of the dumbest list of reasons;  fear, bad management, Waterfall, miscommunication, and others.  The wicked thing is, every single one of these reasons has a solution that humanity in its everyday project endeavors has resolved!  We as human beings have the knowledge, out there, we just have to search for it and find it and know it!  So many projects don't have to fail!

So get to it, and I hope everyone that reads this can straighten out their projects and add to the list of successful projects, instead of outright failures.

Agile is the popular process du jour these days.  Every time I hear "Yeah, we do Agile" or "I know Agile, been doing it for years" I cringe.  These statements are spoken with the idea that Agile is this steadfast, unchanging, unalterable, single process that everyone is following.  It is often spoken without any knowledge of the history of Agile, the people who signed the manifesto, or what the true ideal of Agile is.

Agile is always changing, will always be changing, and we'll most likely all be new to it all the time.  Agile is something that flows differently for each group that tries it, but there are core tenants that must be met.  These tenants aren't part of a "process", but could be, they aren't part of a "method", but might be a result.  The point is, nobody really knows Agile, they know their team.

...or maybe they don't know their team if they think they know Agile?

That is something to seriously ponder.  So how does one know when they're talking to someone who really does adhere to the Agile Manifesto.  This is actually the simple part.  Generally they won't even mention Agile at first, but instead they discuss processes almost immediately.  Things they do to enable the developers, things they do to maintain velocity and keep things upbeat and positive.

Some of the first signs that a shop is truly Agile can be summarized by the answers to a few questions.

1. Does the team always have working software?
2. Can you regress and refactor quickly?
3. Do iterations ending or burn down charts stop velocity?
4. How many hours a week is the average?
5. How often does the team have to work excess hours?

...and one of the most important questions of all...

6. How often does your team get to speak with customers?

Does the team have working software?  If it doesn't, it's probable that they are not Agile, or not quit Agile yet.  A team needs to have working software.  The only lgeitimate excuse I've ever heard is, "we started yesterday and are a few days away from working software".  But even then, there should at least be some paper prototypes, or discussion notes with the customer about the proposed working software.

Once there is working software, how fast can the team regress and make changes?  How fast can the team refactor?  How often is the technical debt paid down?  This is a major sticking point that I hear a lot.  Teams must maintain testing, regression, and the ability to refactor.  The team must refactor regularly and keep the debt paid down, if not, there isn't a reserve entity out there to pay down the technical debt or provide a stimulus!  Without these things a team is running rough of Agile.

At the end of iterations does the team stop completely, take a breath of fresh air, and prepare for the hike up the mound of progress again?  If this happens, something is definitely wrong.  Iterations aren't supposed to break progress, merely reflect and maintain veloctiy.  This is where I've become more and more a fan of lean style or kanban style.  The hard stop that iterations often incur is very detrimental to velocity and sometimes even to morale.

Speaking of iterations and mounds of progress, how many hours are worked for that progress?  Are the hours consistent and maintainable?  If not, they should be.  Beware the other inconsistency of trying to apply 40hr work weeks to everyone.  Some people can do 40 and some can do 50, the key is to maintain velocity and maintain morale.  If one person does 50 hrs per week, great, make sure they're not burning themselves out.  Make it easy for them to maintain that.

The customer?  "What, we have to pay attention to the customer?", is a statement I heard recently.  I can't help but just look down whenever I hear this, at least when it is spoken seriously.  The development process and software process should NEVER get disconnected from the customer.  The industry as a whole learns this lesson over and over and over again each year.  We should all now know, we must stay in communication with the customer.

With all those thoughts, I leave this entry with a question for everyone, "Is your team really Agile?"

In my humble opinion, as long as a team is working on acheiving and getting these key points in place, all is good.  If not, the team should probably reflect a bit on what the end goal is.

I just stumbled onto this entry by pure accident.  It however really struck a note with me.  I'm a BIG fan of lean agile.  Agile without the iterations, just continuous, fast, always integrating and always developing software.  It's fast, absurdly fast, and when the practice is done right, the code quality increases in a very significant way.  Deployments though have always seemed to be a little bumpy still.

Well what about Continuous Deployment? This just might be one of the major missing pieces to the whole lean agile process!  I think I might just set it up for fun and see how it transpires. 

Ideas, efforts, capital, and more than everything else, the team.  This is something I hear time and time again, and know so very well, but it seems some companies still lack that insight.  To them the idea is the idea, the effort, or just the capital, the team is a second rank priority.

Those companies I would immediately sell them short, because they've sold the most important aspect of anything short, the team and the individuals of the team.

What about when those things connect?  It's always a hard road, it is always difficult day to day in the beginning, but when all those thing connect under a good team, the company has a huge chance of success.  I'd even proffer to say far greater than the average business's chance of success.

Everything from the operational needs of a company to the capital outlay, the people with experience will always tell you team first, everything else is secondary.  The first statement in the agile manifesto is, "Individuals and interactions over processes and tools", which I can't agree with more than I already do.  The individuals of the team are of the utmost importance, without, you have no team worth any effort, capital, or ideas.

On this topic, what are good ways to get teams to connect with the ideas, efforts, and capital of a project?  How does a team really buy into the ideas, stay strong during the effort, and were does one generate solid capital for a project?

The Team and Ideas

Google has one of the best methods for assuring buy in on ideas for a team.  It is one of the simplest solutions I've ever heard, let team members work on the projects they want to.  With this simple idea you get automatic buy in on the ideas of a project because it was chosen by the individual.

The Google solution of course does not work everywhere.  In places were there are only a few team members or a few projects to work on, there is only singular focus on a couple primary ideas.

A good solution in smaller teams is to find, at least that I've personally found effective, is to break apart architectural needs and goals into stuff people want, let them pick and chose, and then the remnants that no one really wants to touch, dole it out accordingly.  This way the unmotivated is somewhat avoided by the motivated.  Result, increased buy in for the ideas behind the project.

The Team and Efforts

What motivates a team to work together well?  One of the best things that works, especially from a management perspective, is an Agile process that places individuals together on a frequent basis.  However I'll be the first person to point out that a weak team, Agile does NOT fix.  In those situations there are needs to have a strong leader, that can mitigate differences and initiate communication and assure that the individuals are working to bridge the disparate goals into the primary objective goal.  Either way, a strong leader is pivotal to assure good cohesion of the group, but things are even better by an order of magnitude if the team just works well together.

What about other forms of motivation?  What about the extra effort?  Well first off, I'm a strong proponent of not burning out team members and that means working a sustainable pace.  Unless one wants to throw away the project and start from scratch in the short term, a project needs effort from the team members in a sustainable, consistent, and smooth way.  If too much effort is expected, dire consequences are all that is left to be had, so work sustainable, and reap the good results.

So far these things mentioned are big picture things to get a team to really put together a strong effort.  The other ideas, that are far more effective than anything I've ever seen, are doing things together as a team outside of work.  I don't mean require a bowling day with the team.  I don't mean push everyone into doing something outside of work.  What I'm talking about is the good natured friendliness of people to have a beer after work, to check out a movie, to grab lunch together to discuss a few work related, or non-work related topics.  When a team is cohesive on that level, the team just naturally is more relaxed about putting forth a strong effort and especially about working a high speed sustainable project effort.

The Team Capital

The team capital can mean several different things; revenue or income related money matters, assets and equipment to work with, and any of a number of things that capital is needed to complete a project.  This major connection point is probably the second most important of all the connecting points.  Without solid capital and the tools that are purchased there is only so much a team can do without tools.  Sure they can hang out, talk, and even come up with solutions, but they can't create those with capital and tools.

A major element of motivating a team and assuring a good sustainable effort is to equip a team appropriately.  I don't mean they need a X Box in the corner and a 60" TV to play it on, even though it would be nice.  What I'm talking about is making sure team members have appropriate space or even offices maybe.  Make sure the team has monitors, good solid monitors with high quality and maybe even dual monitors.  Make sure each member has good hardware and the appropriate software for their efforts.  If they're a BA make sure they have solid specifications and analysis tools, make sure developers get the good tools like ReSharper, TestDriven, and others.  With the right tools, a project can then have the appropriate priority focus on the people and interactions, without the right tools the team just dwells on how to even finish their day.

So those are a few points I just wanted to make and also to provide a quick once over for people to read.  This entry is a kind of reference for how I like to start and work with a team on a moving forward basis.  It really is all so simple;  Individuals & The Team first, capital & tools second, find solid sustainable effort, and get buy in for the ideas of the project.

Just reading up on some thoughts being fed through twitter and I stumbled on one by @robbyrussel "today == laundry + hacking day".  I couldn't help but run through a few scenarios were I've seen people getting work done over the last few years.  Everywhere from the grocery store to the zoo bomb runs (before jumping aboard the ride).  Of course, one of my favorite ways to get work done is to jump aboard the streetcar and wire up with the SprintPCS card and work away.  For some reason, the streetcar, or MAX, is usually a great thinking place for me.

I've also read that maybe 5-15% of the people who could work remotely actually do.  A lot of that has to do with a paranoia from business interests about what an employee is doing and they are rightfully concerned.  I wouldn't want someone to work remote, not do anything, grab a check and then disappear on me.  This fortunately is easily resolved with various modern processes and communications.  Agile itself bodes fairly well to remote work even, as long as those communication channels are maintained well.  I worked for about a month with someone completing work for me in Brazil, with just a few hours of communication a day, to remove roadblocks and hurdles, he (Jay! thx for the help!) was able to knock out the work tasks for the project super fast.

That leads me into another though, meddling over into my transit interests and economics in general.  A few assumptions stated; the tech market provides a vast amount of wealth in the US, it also consumes a vast amount of resources.

Technology workers continue their move toward more social interaction at work and to continue increasing productivity and efficiencies while decreasing our vast usage of the infrastructure. With these actions the tech sector alone could begin a revival of sorts within the economy itself!  But as I look at some companies that I'll refer to as legacy companies, it is a slower move than it should be.  This shift to a more socially interactive, agile, and effective production method for software, and even hardware, in the marketplace needs to increase.

In Atlanta,Georgia and other auto-centric areas of the country the tendency for telecommuting has been increasing, but not nearly as much as it could.  In no ways would it eliminate the poor infrastructure design of Atlanta, that will take a lot of other work, but it would lead to more economic activity and allow for growth of more elaborate town centers.  Portland on the other hand, would probably benefit even more from this because it is already setup for this type of work.  Numerous individuals already work remotely in Portland, Oregon and have social interaction and efforts that make many legacy companies efforts seem arduously slow and cumbersome.

Just to name a few companies right off, that could drastically benefit from this even more are Microsoft, Intel, and other giants.  In many ways these companies have done great things with remote work, arguably their best work is done via remote effort.  They however could save millions a year on real estate and space needs by merely investing in local infrastructure and economic activity to provide places to setup these remote workers.  A coffee shop, a town center, simple meeting place for groups, are perfect for this type of effort.

The companies that have the greatest distances to cover to gain competitive advantage with remote work utilization are the real legacy companies.  These companies range from Ford, GM, Blue Cross, and other giant entities that really don't build software as a primary revenue generator, but do build a lot of software.  These companies need to improve their management capability to better leverage these remote working abilities.  The advantages are too numerous to avoid.

When looking for work, always push for this type of work atmosphere, at least push for it being reviewed.  I can promise that any company that doesn't take more advantage of remote workers will eventually lose their edge and fall to the wayside with the legacy companies that have already been put to death by inefficient and arduous old school thought.

It's time to provide this freedom on a large scale.  Get with the progress.  Cheers!

Daily Habits and attitudes of an Agileish Developer

1. Always talk to the other developers around you about what is going on, what you're doing, what they're doing, and know what is going to affect your work.
2. Pair up often to develop parts that you are both respectively working on.
3. If you need a break from social existence, do some mindless work, don't work on intricate parts of code.  If you can't verbalize and discuss what is going on, you don't need to be poking around in that particular code.
4. Get user stories, if questions about the story arise, ask questions, if the story doesn't make sense, get the story changed.
5. Make sure you can figure out a way to test your code, if you can't you're most likely designing something poorly.  If you can't test it in isolation you probably haven't thought it through all the way.  Sometimes though some code just has to be badly written.  :(
6. If you find yourself getting lost in code, refactor.  If you find you've written this piece of code before and deja vu is setting in refactor.  If you have more than 2-3 questions every few minutes about a piece of code, refactor.
7. If you can't read a story from the code and the code tests, refactor.

Not sure how many people do or don't get into a good flow at work.  I wonder how many do versus how many don't.  Currently I imagine that not many places have a good development flow.  Instead they have more of the wait, talk, wait, wait, wait, now develop really fast type flows.

I was just brainstorming and attempting to think of a good flow.  So far this is what I've come up with.  Starting in the morning, going through the day of a normal week long or maybe 2 week long iteration.

An agreed arrival time is met, let's say 9:00am is promised by the team.  A quick stand up begins at this time.

Stand up should consist of NOTHING more than this is what I did yesterday (that the group needs to know), what I'm doing today (regardless of what one might think affects someone else), and what I'll plan to get to tomorrow.  Then, after those three quick items, mention the road blocks & concern for roadblocks that are anticipated for the day.

9:15 am IF needed, otherwise don't do this step.  Review burn down chart, priorities, and what other elements of the project will need reviewed for the day.  Identify members external to the development teams and break off for those meetings.

9:20 am Begin individual dev efforts.  I'd prefer TDD style with a pair partner, maybe not to sit side by side, but each do respective work and either swap or mix up each others assignments on a frequent basis.

During the course of this morning work session if user stories are needed, clarification is needed, or any questions come up they should be asked immediately to whoever the primary stakeholder of that information is.

...contextual notes:

In no way should user story meetings need to go over 10-15 minutes.  Long design sessions just mean that information will be lost and these elements will need returned to.  It is better to have working code and product in hand of users than it is to have some fancy design.  At the same time however, in stark contrast to this is the need to keep in mind the architecture.  Depending on were, and in what way, the working code touches other parts of the architecture the design might need to be discussed separately than a user story design session.  Either which way, the overall meeting should NOT go over for extended periods of time.  Design sessions and user story clarification should be quick, and foster communication that is to the point, fact finding, and then production of working code for that user story should ensue.

sarcasm alert:  unless of course you DON'T want a fast moving development effort.

...end of contextual notes:

Noonish - lunch - foodz - sustain life - etc.

Last minute events should be:

30 minutes before departure for the day one wraps up by making sure there are no incomplete work stories in progress and commits all code.  Anything that actually needs to continue the next day needs to be noted for the following day at stand up.  If all tasks are completed the same should be done.

The first and last days of the iteration.

The only exception to the above work flow for the day should be on the first and last day of an iteration.  The biggest difference is user story meetings, clarifications, discussions, architectural planning, and burn down chart maintenance should be done at the beginning of the iteration.  This should be when bug fixes, architectural changes, and other big picture items should be discussed and planned for the ensuing iteration.

At the close of the iteration a clean, building, operable drop of the application needs to be made.  A test deployment and initial regression test should be performed by end of day on iteration end.  The quality assurance process then continues testing for x days and begins immediate bug and issue tracking that will feed back in to the next iteration.

This, is as I see a smooth flow for reaching fast, sustainable, and got morale based throughput.  If anyone has any thoughts on this I'd love to hear were this breaks down.  I've made a an effort to keep this description relatively simple, but would love more input.  Anybody from the peanut gallery?

I've been extra active reading blog entries lately and have come upon a few that have really got me kind of wired.

Software Development Dogmata - Good Practices Gone Bad

The first one is this article by Daniel Pietraru (who I do not know) over on little tutorials "Software development dogmata - good practices gone bad".  There are few major issues I have with this slight skewing of facts.  Overall, excellent article, but there are some issues.

First is the "Agile != Flexible".  Read the manifesto, there is no such thing as Agile that isn't flexible.  The birth of agile that is mentioned is rather skewed too.  If you truly want to learn about Agile, and you have a motivation to have good, happy, satisfied employees that are highly productive, look up the motivations behind Agile.  Otherwise, don't.

Daniel then goes on to negate the benefits of a short development cycle.  Iteration based development has proven so effective almost every major process out there these days takes some form of this.  As for the statement he makes "you cannot demo a car engine until it is fully built" is patently wrong.  You CAN demo a car engine and that is the entire point behind computer models used solely to design engines, and cars in general, in a very LEAN or AGILE manner.  So you can deny it, but I believe these methodologies, the focus on individuals, individual motivation, individual enablement, and other such characteristics of lean, agile, and others is exactly why Toyota has stomped the competition is is basically the world leader in automotive manufacturing and quality.

One really can't deny Toyota's success, and it is the prime cut of what agile is.

Pair programming, he has a slightly decent point on this topic.  I too find myself torn about the usefulness of pair programming.  It does, however have positive effects, but I don't buy into the eXtreme Agile approach to the whole pairing with one keyboard and one mouse.  Working together, communicating, and effectively integrating code into the main continuous integration serves just fine.  But, I can't really knock it either as I haven't truly tried hard core pair programming.

He goes on to slander design patterns, TDD, UML, and a few other things that most developers are fully aware is very helpful in software development.  Not sure why he hates so much of successful software.  I ponder, what does he like about successful software?

In Daniel's defense, he does have some valid topics, just the article is angry and seems to be centered incorrectly and lash out in ways that don't do the points he makes justice.  He does point to a very effective proven use of Agile methodologies, on a massive scale, for a company that turns a little it of profit now.  Google - so read the WHOLE ARTICLE of Stevey's (this guy works for Google and I've read his material several times) and don't be so frustrated with Agile, there ARE good and bad versions.  But I digress, on to the next.

Naming Conventions:  Are They Really That Important?

I stumbled on this entry, I don't know when, but somehow it reflected several conversations I've had recently.  I like naming conventions, when enforced by ReSharper, Intellisense, or something of that sort.  But to remember all, and then have new developers go about learning them all in today's development environment is...

...well...

...an utter waste of time.  Naming conventions are in no way important like they used to be.

Source Control is not a feature you can postpone to vNext

I just thought as I have many times, Microsoft doesn't seem to get source control.  Ayende @ Rahien (the awesome software simian) goes on a slight rant about the absurdity of their solutions so far.

Why are the Microsoft Office file formats so complicated? (And some workarounds)

It also seems that with my new effort to build awesome Office interfaces, tools, and solid back end architecture for these systems I've found the insanity of Microsoft's Office file formats.  I never realized, but Joel Spolsky, who I've read a lot of lately, worked on the Excel team at one point.  He points out that there a more than a few pages (349 in one PDF) of documentation solely about the file formats of Office.

A Field Guide to Developers

Joel also did a great write up in the year 2006 about how to get a keep top developers happy and productive.  Things like private offices, cool toys, a good physical work space, and one of the most important topics being the social existence of programmers.  It points out the importance of having great colleagues, independence and autonomy, how they're treated, and that there are no politics of the feeling type.  As he states in the entry, "And this is the kind of environment you have to create to attract programmers. When a programmer complains about “politics,” they mean—very precisely—any situation in which personal considerations outweigh technical considerations. Nothing is more infuriating than when a developer is told to use a certain programming language, not the best one for the task at hand, because the boss likes it. Nothing is more maddening than when people are promoted because of their ability to network rather than being promoted strictly on merit. Nothing is more aggravating to a developer than being forced to do something that is technically inferior because someone higher than them in the organization, or someone better-connected, insists on it.".  This, no politics philosophy, is absolutely 100% true!

Of only it was more common!

Top Five (Wrong) Reasons you Don't Have Testers

...and an article on why a company, that intends to build good and reliable software should always have software testers.  Again, by Joel Spolsky.

I also dug up another very interesting experiment that the company 37signals undertook.  4 day work weeks.

Workplace Experiments

Amazingly, they got the same out of a 4 day work week as a 5 day work week.  Oddly enough people work much more diligently and effectively when they're able to get a solid weekend of separation from work.  This obviously wouldn't work with every occupation, like for instance McDonalds would probably get minimal amount of use out of 4 day work weeks, but software developers are not McDonalds employees.

Another great article in a similar vein is Increasing sustainable pace.  One of the comments is a classic combination of my railroading interests and software development, "Working more hours may not be the best solution. In the long run, working smarter always wins over working for longer periods. John Henry was the best rail spike driver in his day, and he died proving it. Power tools today let anyone work faster than John ever did.".  I firmly believe that smart workers will produce far more than a bunch of overworked code monkeys.  In my experience this has also been proven time and time again.  This blog entry led me to a few searches, which then led me to some other articles.

That has been my reading for the day.  It's been a ton but I just got on a blog reading kick and figured I'd write up what I've read as of late.