Tag Archives: Agile

Jeffrey Palermo 4:19 am on October 6, 2007
Tags: Agile, alt.net,   

altnetconf – Alt.Net kicks off with clarification of “What is Alt.Net”

Alt.Net kicked off this evening with the setting of the agenda.  We have so many topics, there are going to be a LOT of great discussions.  I feel privileged to be a part of a conference that is potentially shaping the .Net community. . . and I enjoyed meeting Martin Fowler for the first time.  We have plenty of space for all the discussions thanks to St. Edward’s University in Austin.  St. Ed’s has been very supportive of the developer community here.

First and foremost, we established that Alt.Net does NOT mean anti-Microsoft.  Earlier, I gave some values and principles as an attempt to clarify somewhat how _I_ think of Alt.Net.

Alt.Net does not mean tools.  Alt.Net is a way of thinking, a value system.  At its core, we want to be passionate about our craft.  We want to use the best tools for the job (we know those tools change every 2.5 years).  When a new tool that is better comes along, we will happily drop current tools (and that’s a good thing).  We want to keep an open mind about how to write software because we know there is no _one true way_.

Another key point is that Alt.Net encourages the challenging of every assumption we make.  Assumptions can turn to habits, so we must be aware when context changes and rechallenge our assumptions to ensure we are working in the best way.

We intentionally limited the defining discussion because that discussion will be going on all weekend.  Alt.Net is a very positive message, and everyone at the conference is looking for ways to improve the .Net community, not whine about it.  The opening was very positive and upbeat.  There are a lot of smart folks in the room, and I look forward to learning from them over this weekend.

In short, we don’t have a definition.  Sorry folks.  We have 100 or so people at AltNetConf, and we have almost as many definitions, but we all share a passion to develop better software and educate others in the same.  While there are some folks using completely different platforms, most are using .Net and want to continue building on .Net, so Alt.Net does not mean finding an alternative to .Net.  On the contrary, I want to learn the best ways to fully leverage the platform.

For all bloggers, we are tagging content as “altnetconf” to help make this stuff more searchable.

 

[tags: altnetconf, agile, alt.net]

Jeffrey Palermo 4:49 pm on September 23, 2007
Tags: Agile, , , , , , , ,   

What are the Alt.Net principles? – my answer

I’ll be attending the AltNetConf.  Convenient for me that it’s in Austin, TX.  It’s an open space conference, and I consider it the founding conference of a conversation that is “Alt.Net”.  I’ll be proposing the topic: What are the Alt.Net principles?.

The definition of Alt.Net isn’t defined yet.  It’s not even at a point where I can explain what it is and actually have other agree with me.  

Since I know the guy who originally coined the term, I have some insight into what David meant, but I’m going to propose some principles that, together, should be the definition of Alt.Net.

First, Alt.Net inherits Agile, and IS Agile.  Therefore:

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan 

Extended principles:

  • Excellence and quality
    In a world of wizard-generated, disposable software (disposed 2 years later by necessity, not choice), Alt.Net focuses us on excellence in the software we create.  While the world may pay for and accept software that lives for 2 years before becoming utterly unmaintainable, we don’t accept shoddy work.  We know that we can deliver high quality software faster than others can deliver low quality software, so we accept no less than the highest in quality.  We strive for excellence through solid engineering practices and a high level of software education.  Coincidentally, Extreme Programming helps in this area, but Alt.Net does not specifically _mean_ XP.
  • Alternative Vendors
    A  common theme in many .Net shops is they are “Microsoft” shops.  In other words, if it doesn’t come from Microsoft, they won’t use it.  This makes no sense.  Microsoft is not a large enough company to be the vendor to the whole world.  .Net is a great platform, and we as a community have chosen the platform and choose to participate in this segment of the industry.  We strongly believe that 3rd party vendors complement the .Net platform in a way that can contribute to excellent working software.  In fact, some 3rd party offerings are superior to Microsoft’s offering.  For instance, in a strive for excellence in an e-commerce website, a team may choose a mature O/R Mapper like NHibernate to accelerate team speed and produce a flexible data layer; however, Alt.Net does not _mean_ ORM.  Open source software is a source of excellent 3rd party alternatives built on the .Net platform, and it should be used over Microsoft alternatives when they contribute to excellence; however, Alt.Net does not _mean_ open source.
  • Joy in our work
    We know that we will produce better software if a team is motivated and morale is high; therefore, we use libraries, tools, and practices that add joy to the working environment.  We abandon or correct libraries, tools, and practices that make it a drag to work on the software.  For instance, many find that Visual Studio is a bit slow to work with and that adding Resharper to the IDE adds a high level of joy while working with .Net code; however, Alt.Net does not _mean_ Resharper.
  • Knowledge
    We know that we will never know everything there is to know.  We strive for a greater understanding of software through studying successes and failures of the past as well as the present.  We educate ourselves through many sources in order to bring the most value to our clients.  We keep up with other platforms, such as Java and Ruby, so that we can apply their good ideas to .Net development and increase the quality of our .Net software.  The technology is always changing, but the knowledge accumulates.  We know that the knowledge applies no matter how the technology changes.  With knowledge comes humility because without humility, knowledge would pass us by.

The above are principles, so they are intentionally abstract.  Below, I’ll list some items that are concrete.  These items apply the principles but are more directly applicable:

  • Read more than just MSDN magazine and MS Press.  Authors like Feathers, Fowler, Martin, Evans, etc have a lot to give (Knowledge)
  • Use Resharper.  It makes working with Visual Studio a (Joy).  But if another vendor comes along that does even better than JetBrains, consider switching
  • Use NUnit  over MSTest,  Subversion over TFS SCC,  Infragistics/Telerik over in-the-box controls,  RedGate over in-the-box SQL tools.  Each of these is a better alternative to that which Microsoft provides (Alternative Vendors).  Use NHibernate over hand-rolled stored procedures and especially over DataAdapter/DataSet, but if EntityFramework proves to actually be superior to NHibernate in a meaningful way, consider using it.
  • Use a responsible application architecture.  Don’t put everything in Page_Load like you see demonstrated at MSDN Events.  Use knowledge to create an application that can stand the test of time and not be rewritten every 2 years.  Deliver (high quality and excellence). 
  • Automate every repetitive task; builds, tests, deployments, etc – excellence and joy

The concrete examples could go on and on, and I hope AltNetConf produces a long list.  I’ll be interested in having my proposed principles accepted by the community there or revised into something better.  Either way, I’d like to get to a point where there is an accepted definition of Alt.Net.

Jeffrey Palermo 5:23 pm on July 10, 2007
Tags: Agile, , ,   

Baking requirements – Developing with raw ingredients is waste

I have learned an important lesson from my combined experiences at all the places I’ve worked.  That is:  raw requirements cause waste.  A term I’ve used (and have heard others use) is that requirements are either “baked” or “not baked”.  For a development team to plan an iteration, or a scope of delivery, the requirements need to be baked.  If we pull the development team into a planning session, we ensure the requirements are fully baked before the meeting.  Developers will be asking specific questions about the details of the requirements, and answers need to be readily available.

A big cause of waste is when a project manager inaccurately declares the requirements as actionable and the entire team meets.  This is the most expensive meeting you can have.  As soon as the developers ask questions, a discussion ensues among business stakeholders on what the requirements should be.  At this point, the developers sit and listen until the stakeholders finish defining what the system should do.

The above is a strong indicator that the requirements aren’t baked.  There are holes in the analysis, and it comes out as soon as a developer asks a question about the expected behavior.

TIP:  Project Managers:  ensure the requirements are fully baked BEFORE you take up the ENTIRE team’s time.  You may need help from the architect or tester, but ensure the center is not raw when the whole team is pulled in.

UPDATE:  ScottBellware was a bit confused about the context of this post (see comment below), so I thought others might be also.   This post is about behavioral requirements for a single user story.  Very small scope.  Before the team can estimate, this story must be “baked”.  Otherwise, the coding is guesswork.

Jeffrey Palermo 1:53 pm on July 9, 2007
Tags: Agile, ,   

Arcast – The Agile Architect podcast now online

 http://channel9.msdn.com/ShowPost.aspx?PostID=322781

The above is a link to an Arcast episode where I had a conversation with Ron Jacobs about what an Agile Architect is.  Give it a listen and tell me what you thought.  My basic point (beyond introducing Agile for those not familiar) was that the architect on an agile team is the guys who looks ahead beyond the current iteration.  I mostly agree with Sam Gentile as he outlines his views here. 

Jeffrey Palermo 1:46 am on April 17, 2007
Tags: Agile, , ,   

Results of a SOLID pair-programming day – level 200

There it is.  A pile of ripped up note cards denoting all the engineering tasks completed by my pair.  This was an unusual day because it started at 7:30am with some white board modeling and brain-crunching a very, very tough problem.  We wrote out some tasks to get us started, and we played the TDD game.   It was such a tough problem that neither my pair partner nor I could imagine the complete solution, but we could imagine a few things that would be included.  We wrote down the items to do on note cards and ordered them.  The navigator manned the note card deck.  In the course of completing some of the engineering tasks (all part of the same story), we uncovered new tasks that needed to be done.  We wrote those down and added them to the bottom of the pile.  We also ran into a brick wall and had to stop to do another task before we could continue.  We wrote that down and added it to the TOP of the stack.  We used these note cards as a true STACK.  FILO.  It helped us stay on track.  We finally got through the stack, and when we did, the story was implemented.  We didn't have the complete plan at the beginning, but we adapted and changed the plan along the way.

This pile of ripped up note cards is all that's left of that nasty story.  It did take us all day, though, and at 6PM, we both were wiped out!  It was the last day of the iteration, and we had committed to the story.  We ate a quick lunch at our desks and worked straight through.  It was great that we were able to meet our iteration through micro-adaptive planning.

I hope I don't have to do that again for a long time because that was the most difficult pair-programming I have ever done.  We were talking through the problems _all day_.  My brain was hurting on the way home.

My pair partner commented that it would have taken him 3 days if he had had to work through this nasty story by himself.  Pairing on the entire solution cut the delivery by 2/3. 

Jeffrey Palermo 1:05 pm on January 24, 2007
Tags: Agile, , ,   

The first task of a new software project is to build trust – level 300

Please read this post by Brad Appleton (and some links off the post) about building trust in a software team.  The notion is very profound, and we don't talk about much in professional circles.  I, for one, can easily be drawn into only thinking about the technical aspects of software development.  It's easy because it's something at which I excel.  Years ago I went so far as to scoff at a previous employers attempted evaluation of "soft skills", but I know see the importance of it.  Technical skills are necessary, but the greatest techy on earth can be rendered ineffective if no one will trust him.

Jeffrey Palermo 2:18 pm on December 22, 2006
Tags: Agile, , ,   

Driving a “no bugs” team culture – level 200

I've been reviewing Jim Shore and chromatic's upcoming Agile book, and I especially like the "No Bugs" section here: http://jimshore.textdriven.com/Agile-Book/no_bugs.html

Large, dusty bug databases abound.  Some teams have a process where this is unavoidable.  Some teams use a bug database as a roadmap *shudder*. 

Personally, I believer that a "low priority bug" doesn't exist.  If it's a bug, why would you ever think of not fixing it?  If a product manager decides that the current behavior of the system is acceptable for the time being, then why would you call it a bug?  You may find the behavior of the system undesirable, but ultimately, it's the product owner's call what is desirable or not.  Maybe he agrees it's undesirable, but there are other things more undesirable (like the complete absence of several large stories). 

In my experience, poor management leads to a code-and-fix culture – working off a bug list.  It's "easy" if there is just a running list of bugs.  The team stays busy, and you can track work (kind of).  What is hard is to lay out a prioritized road map and manage the growth of the product.  Managing the product is actual work. 

Many things can contribute to a low bug count:  proper roadmap planning, good developers, automated tests, good software design, etc.  I think the average life of a bug is also very important for the team culture.

To drive a culture of "no bugs", bugs cannot be allowed to live long.  If a bug is announced, and nothing happens, the team accepts that the bug is there, and they will fix it "when they get to it".  If someone stops and immediately addresses the bug, then the team knows that bugs are not acceptable.  From a management perspective, I give bugs top priority.  If there is a bug on our wall (red index card), it has top priority – no questions.  The bug is not allowed to live.  This is key for driving a "no bugs" team culture.
 

Jeffrey Palermo 6:46 pm on November 10, 2006
Tags: Agile,   

Iteration discipline: another Agile mind-shift – level 200

In an effective organization, discipline is key.  You can't run a loose ship and expect to be effective.  One of the disciplines that his hard to master is speculation.

Speculation

When working on a story, the developer team might have questions or even ideas for improvement.  A common temptation is to speculate about a solution that seems right to the developer(s).  Sometimes this speculation is correct, and sometimes it isn't.  Either way, developers should not speculate about business value.  Note that I am assuming we have a healthy organization where a product manager (or customer) is actually planning the software and thinking about business value.  In this environment, the customer is responsible (and qualified) for determining priority based on business value.  A customer is charged with knowing the problem domain and making decisions about what software to write to fulfill the business need.  Developers take this business landscape and deliver a technical solution to the business problem.  Developer speculation can hurt productivity when developers start making assumptions about the business problem. 

I talk about discipline because it takes effort sometimes to force the customer to make business decisions.  Developers are the technical experts, and customers are the business experts.  Just as a customer is not qualified to make assumptions about technical feasibility or technical estimates, a developer is not qualified to make assumptions about business value or priority.  When I say "qualified", I mean it is not their role in the organization. 

How to beat developer speculation (or guessing)

  • Keep the customer onsite so that the communication overhead is very low.  That way whenever questions come up, the source of information is right there.
  • Plan the iteration effectively.  An iteration planning meeting should model and task out the work planned for the iteration.  Whether if be one, two, or three weeks, do a good job planning so that all big questions are answered up front (or spikes are declared for specific items).  Lean on the customer during the iteration for smaller, detailed questions.  If you have a hard time planning for your three-week iteration, shorten the iteration to one or two weeks.
  • Focus on delivering software.  Focus on the iteration.  For the individual developer, that means trusting your customer and manager.  Developers are creative and have good ideas.  These ideas should be communicated to the customer, but the customer is responsible for integrating those ideas into the roadmap.  An idea that pops up mid-week should not halt the iteration unless it was something critical that was missed.  Planning (in detail) only a short period of time allows for changing course rapidly since each iteration's plan is defined in real-time.  Remember, the customer (or customer representative) is always planning the future roadmap.
  • Don't tolerate it.  This is more of a management item.  It's a slippery slope.  If a little speculation (or developer-driven business plan) is allowed, then more will follow.  Be clear about the roles of the development organization, and have the developers enforce this discipline within the team.  All technical discussions should focus on iteration deliverables.

What about planning ahead to prevent major technical problems?
Someone on the team should be a strong enough developer to understand these issues.  This is not a role, but more a capability.  If the team is filled will strong developers, then any developer is capable of seeing a roadblock coming.  If the team is more junior with only one senior dev leading the way, then it will fall on that person's shoulders, but this is more of a team-makeup issue.  In practice, with strong people, you have high-quality, loosely coupled, well-tested code that is delivered every iteration.  In this healthy environment, the code is easy to change to react to business decisions down the road.  If you have good people, they won't be coding into a roadblock.

 

What's the secret?
No secret.  Get good people, and they will deliver good software.  There is no cookie-cutter process that magically turns a dysfunctional developer culture into an effective one.  Good people, driven by Agile principles formulate a good process and deliver good software.

Jeffrey Palermo 2:20 pm on August 31, 2006
Tags: Agile, ,   

How to produce a software product quickly, part 3 – level 300

In my first two installments of this series, I talked about:

These first two guidelines are very important.  The first drives efficiency, and the second drives effectiveness.  Even doing these first two well can leave a team spinning its wheels, however.  If parts 1 and 2 are fully implemented, we are now certain that the team is focusing on the small portion of work that delivers great value.  We are also sure that the team's time isn't being wasted with nonessential or repetitive tasks.  What's next?

Part 3: Use Powerful Tools

A skilled craftsman needs good tools.  First, the craftsman needs the correct tools.  Second, the craftsman needs those tools to be powerful.  A craftsman plowing along with inadequate tools is exerting more effort than necessary.  Why use a hammer and nail when a nail-gun is available?  Why use a screwdriver and wood screws instead of a power drill?

Workstation power

This is the most obvious, but sometimes neglected, tool for a software developer.  Does it make sense to have a highly-paid professional on staff using a mediocre workstation?  The programmer will spend time waiting on a machine.  The answer, of course, is no.  The newest member of my team came on board with a 3.4Ghz Pentium D (dual core) workstation.  1Ghz FSB, 10,000 RPM SATA drive, 2GB RAM.  He had never seen Visual Studio 2005 install in 10 minutes.  Compared to what I'm paying him, his workstation cost pennies.  He spends less time waiting on compiles.  The local build runs very fast as well.  In my mind, it is well worth the cost.

IDE & related tools

Many programmers with whom I talk use Visual Studio.  Just Visual Studio.  Some haven't been exposed to other tools for software development.  First and foremost, Visual Studio is a pretty good solution/project linking and compiling package.  It's pretty poor at helping the coding process, though.  There are a few neat extras you can unlock through SHIFT+ALT+F10 in 2005, but they are sparse.  Install Resharper into the IDE, and it comes alive.  It does use more RAM, but RAM is cheap, and the boost it provides is more than worth it.  Without Resharper, Visual Studio is just a glorified text editor that compiles.  With Resharper, you know about compile errors on the fly, and unused code is grayed out, so you know it's safe for deletion. 

Team tools

It's one thing to give an individual programmer the best tools money can buy.  It's another to focus on the team tools.  There are some tools that all members of the team depend on.  Besides the network connection and the printer, I'm talking about a revision control system and a build server.  It's important to have a quality revision control system.  The team needs to be able to rely on the branching and merging capabilities as well as the commit transactions.  My team uses Subversion.  It has proven itself time and time again. 

The build server is another shared asset.  It must be fast as well since every member of the team will have to wait on it at some point.  The build server can either have the build script run on it manually, or a CI server can run the build when new code is checked in.  Either way, the build needs to run fast, be configurable, and be reliable.  My team uses CruiseControl.Net with NAnt and MSBuild.

Other general, programming and debugging tools

There are many tools that help with a single part of development.  The IDE is the tool that stays open all day long, but other tools are just as critical for specialized tasks.  There is no way I can list them all, but I'll give a run-down of the tools I use:

  • Resharper – productivity add-in for Visual Studio (refactoring, code generation, etc).
  • Lutz Roeder's Reflector – disassemble the .Net Framework.  It's better than documentation.
  • CruiseControl.Net – build server for .Net
  • RealVNC – share the desktop.  Good for pair programming or informal presentations.
  • RssBandit – Keep up with the programming industry through RSS news, blogs, etc.
  • GAIM – Universal IM client.  Use to shoot over snippets of code, svn urls, etc to team members.  Supports all IM services.
  • Google Desktop – Launch programming tools quickly without using the start menu.  Find code files easily.
  • TestDriven.Net – run/debug unit tests right from the code window.  Integrates with NCover for code coverage metrics.
  • Windows Server Admin Pak – Remote desktop to many servers with the same MMC snap-in.
  • TortoiseSVN – Windows client for Subversion.
  • NAnt – build scripting.  In fact, you can script anything with XML using this.  We even use it for zipping up files.
  • NUnit – unit testing framework.
  • StructureMap – IoC container.  Uses attributes for linking interfaces with implementations.  Minimizes Xml configuration.
  • Who's Locking – find out what process has your precious assembly locked.
  • DebugView – hook into the debug stream locally or on a remote server.
  • DiskMon – monitor what's going on on the disk.
  • RegMon – see what keys are being read.
  • FileMon – see what files are being read.
  • Subversion – fast becoming the standard for source control.
  • Ethereal – monitor network traffic.  Find out exactly when and how often your application is communicating over the network.
  • VirtualPC or VMWare – test the software on all supported platforms.
  • Visual XPath – quickly create the correct xpath to get a node from an xml doc.
  • Regulator – Hash out regular expressions quickly with this tool by Roy Osherove.

The list is never ending

Always be on the lookout for tools that will save time or speed you up.  Tools are always improving.  It's important to talk with other professionals from different companies to see what tools are helping them.  Chances are that those tools can help you as well.