Two exciting announcements (Baby, and INETA)

1.  I am now a father.  That’s right, Gwyneth Rose Palermo was born on August 28th, 2007.  The name came from the family:  Grandmother: Rose, Mother: Rosemary, Mother-in-law, Gwendolyn.

She was born 7lbs, and is now over 7lbs, 6oz.  Growing well.  Born with a full head of hair and eyes wide open.  I’m very proud.  I have plenty of pictures published on http://baby.palermo.cc

2.  I’m now on the INETA Speakers’ Bureau. Most of the .Net user groups in Texas have heard me speak, but now any INETA group can request a presentation.   Because of my recent baby, I’ll begin accepting speaking requests starting in December, so if you have a meeting in December you’d like filled with an INETA speaker, you can request me by name when you submit the request on INETA.org.  My favorite topics are Agile engineering practices like TDD, CI, DDD.  I also love to talk about O/R mapping with NHibernate and Software Configuration Management (SCM).

AgileAustin kick-off meeting a big success.

Last night a new user group, AgileAustin kicked off its meeting schedule with a presentation by Jim Van Riper from Troux Technologies.  

Background on AgileAustin:  AgileAustin was formed by an idea from Kert Peterson and manifested by many others.  The mission of AgileAustin is:

. . . to promote agile software development concepts such as those set forth in the Agile Manifesto (agilemanifesto.org), to create a public forum for the exchange of practice information, and to create opportunities for the professional development of members.

The group meets on the 2nd Tuesday of every month at 6pm at the Microsoft office. 

Mr. Van Riper related how in 9 months Troux restructured its product department to turn a failing product into a wildly successful one.  he relates how Troux adopted Agile as a means to transform the product group.  They overlaid another level over the Agile Manifesto:

Culture encompassing (Individuals and interactions over processes and tools)
Vision encompassing (Working software over comprehensive documentation)
Customer commitment encompassing (Customer collaboration over contract negotiation)
Embracing failure encompassing (Responding to change over following a plan)

Mr. Van Riper’s goal is to work himself out of a job.  he contends that when there is a healthy culture, people can come and go, and the culture remains.  The culture at Troux had to change from top to bottom.  their Agile transformation affected the CEO all the way down to individual contributors. 

At Troux, Mr. Van Riper owns the backlog, owns the vision and owns the budget.  By that structure, the process is very streamlined.  The development team owns the software.  They own every aspect of it, and they focus on fast delivery of it.  It’s interesting to note that the company only has 14 developers, but they release every 3 months. 

Mr. Van Riper emphasized “knowing when to stop”.  Instead of adding every possible feature, Troux uses market judgement to know when enough is enough to put out a release. 

As part of the culture change that occurred at Troux, Jim aimed to “Squash passive aggressive behavior and bitching.”  Troux has a disciplined chain of command, and they realize that not everyone needs to be involved in every decision.  If someone doesn’t like the decision, they can escalate, but the buck stops at the CEO, where the chain of command stops.  No design by committee, but a clear chain of command.

The next section of the presentation really impressed me:  “Hire the best, fire the rest.”  All management was replaced in the process.  Mr. Van Riper contends that some aren’t good enough, and some choose not to adopt Agile, so others self-select to move on.  Some might interpret this to mean that to adopt Agile, all current people have to leave, but I contend that if the organization isn’t getting the job done, then a lot needs to change, including some of the people responsible for the failures.

Jim also touched on team workload.  he doesn’t want folks working more than 45 hours per week because if they are tired, he doesn’t want that code checked in.  The code likely won’t be good if written while the programmer is fatigued.  I have to reiterate that Jim is relating things that have turned Troux around into a success.  These things worked for his organization.  Jim enjoys the churn in the organization because it constantly brings a fresh perspective. 

As far as product strategy, Troux does NOT copy the market.  They focus on their users’ boss, not the user directly.  By doing this, they make the users more successful in the eyes of the bosses, not just themselves.

Troux breaks up work into “Must”, “Hope”, and “Wish”. 

  • Must – will not ship without.
  • Hope – might ship without.
  • Wish – will ship without, but this needs to be kept in mind for future releases.

Jim recognizes that support and maintenance can sabotage projects.  Developers are routinely pulled off for support without adjusting the schedule for the project.  That just doesn’t make sense.  Bugs coming back from the fields are escalated up to the product owner so one person can assess each on relative to other potential work.  If bugs go into a release, other features must come out.  The plan has to be based on reality. 

Kill the product manager

It sounds crazy, but this is what Mr. Van Riper means:  In waterfall, Ghant charts are sacred, and Agile causes all practices to be rethought.  To some, throwing away the Ghant chart is heresy.  Jim relates that Ghant charts are produced along with Market requirements documents (MRDs) and that MRDs assume perfect knowledge, which is a fallacy.  MRDs are never always correct.  Rather, Troux makes product managers part of the Team, not separate from the team producing MRDs to be consumed by the team.  For those familiar with the Pigs and Chickens analogy, Troux makes product managers pigs instead of chickens.  This makes product managers completely committed and not just merely involved. 

“We need Product Management separate from Product Development for checks & balances.”  Mr. Van Riper scoffs at that notion and considers it dysfunctional.  Jim is the VP of Product, and everyone involved in a product release reports to him, product managers, software developers, and testers (with the help of line managers).

Jim equates lots of documentation as fear of failure.  “Henry Ford called failure an opportunity to begin again more intelligently.”  Troux prefers to get something working, share it, then fix it.

Gary, the Director of Development, capped off the presentation with an explanation of how development is organized to get stuff done.  Scott Bellware was more than happy to ask questions which enhanced the presentation and challenged the speaker.  We had a bit of difficulty defining an “ad hoc” process.  Gary  related taking the development organization from a waterfall process with sign-off gates to a successful Agile process which actually produced working software.  At first, everyone contended that if only waterfall was followed, the software would succeed.  In reality, the software was failing in many ways.  Individuals would try valiantly, but just work themselves to a pulp.  The company depended on heroism by individuals, not the coordinated work of a gelled team.   

Gary called out the importance of a cadence to the developers’ work.  Iteration by iteration, the group obtained a stride, and through it all, the team built trust.  Developers instilled discipline in themselves.  Through past experience, developers were asking permission to do things that were necessary like unit tests.  By pushing decisions down, developers decided how the work should be done – not management.  Then by planning capacity, Troux was able to plan based more on reality and have the developers empowered to execute with discipline. 

Tools:  Gary recommends not using any tools for the first six months in order to establish the desired values.  Then, tools can be adopted base on fit.  He’s referring to project management tools like Rally, Team System, etc.  Finally, Gary helped his developers change and on the other hand, insisted they do so.  Then, he got out of the way.  About practices, he contends that continuous integration is their most important practice and that their holy grail will be when the build doesn’t break any more.

Metrics:  Gary does track some metrics, but they are very high-level and posted publicly.  He only tracks burn-down  of an iteration as well as builds.  He doesn’t attempt to track everything because that’s not valuable.  By the amount of discussion surrounding metrics, it sounds like there are a lot of opinions. 

The first meeting of AgileAustin was a huge success with standing room only.  Visit AgileAustin.org if you are interested in the group, and join us for our next meeting on October 2nd.

How to be a ScrumMaster

What is a ScrumMaster?  From wikipedia: “Scrum is facilitated by a ScrumMaster, whose primary job
is to remove impediments to the ability of the team to deliver the
sprint goal. The ScrumMaster is not the leader of the team (as they are
self-organising) but acts as a buffer between the team and any
distracting influences.”

It’s not just an Agile Project Manager.  It’s an agile coach with a slant toward the practices of Scrum.  I, myself, am an Agile coach.  I coach a mixture of Scrum, XP, and Lean.  Along with teach developers better software practices and how to be more effective, I also advise management on how the department can be structured better.  Business drivers and analysis are probably bigger risks in the software process than the programming part, so that’s a big part of my job.

I have decided to earn the certification for the work I am already doing, so I’ll be attending ScrumMaster certification training on September 20, and 21.  If you are interested in ScrumMaster training, register for the course and come take it with me. The course is in Austin, and the Thursday of the training coincides with an AgileATX lunch.

Regular price for the course is $1195 per person. Register by August 31st and receive a $200 discount (for a per-person price of $995).  Here is the full information.

Ask the experts chat on August 23 – sign up now

I’ll be participating in the

August 23, 2007 Ask An Expert Live Chat Experts

If you have a question about anything .Net, anything, you can sign  up for it and ask your question.  There is a healthy list on the experts panel.  Check out the link for more information. 

http://community.strongcoders.com/blogs/ryan/archive/2007/07/30/august-23-2007-ask-an-expert-live-chat-experts.aspx 

Utility methods, utility classes, common classes – a blob is not an abstraction

This morning, I was reading the blog of J. Michael Palermo IV, and in his recent blog post, “utility methods – are they the devil”, he asks whether utility methods are evil, and he concludes with “no”.  I don’t know about the evil part, but it caused me to reflect on my past.  While Mike is talking about utility _methods_, I’d like to address utilty _classes_.

I remember a time when I created a “Util” class and put in methods that contained everything from reading the contents of a file to putting a log message in the event viewer.  Essentially, anything I couldn’t jam into a screen went into a utility method since I wanted to share this code.

I paused and reflected because I haven’t written one of these classes in several years.  I can trace it back to my adoption of the Domain Model pattern and domain-driven design in general.  DDD stresses separation of concerns and giving each class a single responsibility.  Domain classes represent a single concept in the domain, and domain services provide one service to the application. 

When I look at a “Util” class and search for the concept it represents or its responsibility, I struggle.  I see it might be writing to files, writing to the event log, transforming XML with a provided XSLT stylesheet, etc.  When I see all these things going on, the only name that is general enough is “Util”, and that’s not an abstraction.   It’s not meaningful.  It doesn’t say anything about what’s going on inside or what the responsibility is. 

I don’t even think about it these days, but I like to create abstractions for everything (ok, not EVERYTHING).  I think it makes the application so much more maintainable, and the folks who have worked with me agree.  These aren’t my ideas, by the way.  I’m very good at stealing ideas from others:  Martin Fowler, Robert C. Martin, Michael Feathers, Kent Beck, Eric Evans, Jimmy Nielson, and many others.

Consider the following needs that might be in a “Util” class:

  • File reading/writing – I have an IFileSystem interface for when my application needs to know it is using a file.  On the other hand, if I’m reading xml data from a file, and the xml is data for system logs, IFileSystem isn’t an appropriate abstraction.  Here, I’d use ISystemLogRepository since my abstraction is a data store for SystemLog.  My application doesn’t care that it’s in xml, just that it can be retrieved.
  • Writing to event log – I’d have a ILogWriter interface with a WriteToEventLog method if my application really needed to know about the event log.  More often, my application only needs to care about logging _something_, and I’d configure Log4Net to pipe the message into the event log as one of the appenders.
  • Transform xml – I’d use an IXmlTransformer interface to front this concept for my application.  This interface would be used on the extremities of the application since in the core, there is no need for xml, only domain objects.

When I think back to my use of Util classes, I have to say it was before I was unit testing my code, before I had heard of Inversion of Control containers, and when I wrote my code very tightly coupled.  I’m not making the statement, “if you use Util classes, you are type XXXX”, that would be absurd, but since I adopted testing, loose coupling, and DDD, I haven’t written a single Util class.

Exception:  I HAVE written a util class in my integration test project called TestData.  It has static methods that populate common domain objects and save them to the database as a method to set up the context for an integration test that makes use of the the database.  In production code, I can’t find a Util class by any name.

Austin .Net User Group hosts JP Boodhoo for August 13th, 2007 meeting

This is to announce the August meeting of the Austin .Net User Group on August 13th, 2007.  JP Boodhoo is giving one of his Nothin’ But .Net courses in College Station (where I went to college), and I snagged him for a user group presentation.  Here are the full details:

Topic
Generics: They’re not just about collections (Level 300, .Net Track)
In this session participants will be introduced to advanced usages of generics outside of the realm of just strongly typed collections. They will learn about how the focus of generics in the realm of collections has clouded the fact that generics can be used to introduce powerful capabilities into your application frameworks and solutions. Practical demonstrations will be utilized to showcase how developers can immediately start harnessing the power of generics in their applications today. People will walk away with new ideas as to how they can leverage generics in their own application development.

Speaker
Jean-Paul Boodhoo

jeanpaulboodhooJean-Paul S. Boodhoo is a .NET delivery expert who has been working with the .NET Framework since beta 1 of .NET 1.0. He spends his days working as an independent consultant; helping teams realize success through agile practices and pragmatic Behavior Driven Development techniques.

He has a passion for sharing information on applied behavior driven development with .NET, and has written articles for Visual Studio magazine, DevX, Code, and MSDN that utilize BDD to pragmatically apply .NET. As well as presenting on popular podcast/screencast DotNetRocks and DNRTV Jean-Paul has had the opportunity to deliver webcasts for Microsoft on the topic of design patterns in the real world. He enjoys getting active in local user groups presenting ways that developers can harness the power of .NET to realize flexible, maintainable applications.

He has a passion for empowering developers to break the stereotypical developer mold and take the effort to break into the developer community to make their own mark. His efforts in the community have earned him a Microsoft MVP award. Jean-Paul can be reached at jp@jpboodhoo.com and makes continual efforts to update his site at http://www.jpboodhoo.com. When not developing Jean-Paul can be found relaxing with his amazing wife and their four beautiful kids.

more…

Giveaway
books, mugs

Date/Time
8/13/2007 5:30:00 PM – 8/13/2007 7:30:00 PM

Location
Microsoft Technology Center
Stonebridge Plaza, Building One, 9606 N. Mopac, Ste. 200, Austin, TX 78759
512-795-5300

Focus on the core: the most important part of the application

Technologies are coming and going faster than every before.  In this environment, how can we provide companies with a good return for their software investment.  Looking back, J2EE was all the rage.  Software executives were banking on J2EE and making significant investments.  The same thing happened with COM+, ASP 3.0, etc.  Managers were projecting significant savings by using these.  Now, where are the savings.  Many applications written with these are being rewritten in newer technologies. 

Why?  Because the applications had no core.  By core, I mean, the center of the application that describes the business domain.  Typically, these are classes and interfaces.  Creating classes using COM+ or J2EE doesn’t an application core make.  The core doesn’t care about surrounding technology. The core is your domain model.  By its design, it’s the most important part of the application, but, done well, it’s portable. 

Look around and see if you can relate to this:  A software team focuses much energy on making the database as good as possible and they create stored procedures to pull back the data as quickly as possible.  They also consider the use cases of the screens that are necessary.  Using technology X for the presentation, they make database table designs and stored procedures that return exactly what the screen needs to show to the user.  Perhaps J2EE or COM+ is used in the passage of information from the database to the UI.  Perhaps Enterprise Java Beans for COM+ components perform some transformation or calculations necessary for the screens. 

Take a step back and remove the screens.  Remove the database.  Is there any application left?  Can you point to any business rules or domain concepts left in the application after the presentation and storage components are removed?  In my experience, I’ve had to answer “no” more than once.  This is absolutely the wrong way to develop software.

Software systems should be resistant to climate change.  The technology climate is always changing.  The core is the most important part of the application, and it should be insulated against changes on the outside.  Over time presentation technologies have changed many, many times.  Data access technologies haven’t sat still either.  We still have the relational database, but the manner of using it is constantly changing. 

Software health check:  Take away the code used to talk to the database.  Take away every screen.  You should still have an application.  You should be left with your application core or domain model and domain services.  Everything should be intact. 

Handle changes in technology gracefully.  If your application has a healthy core, you will be able to upgrade to the next-generation UI.  You’ll be able to change your data access to use LINQ or an ORM without much impact.  If you don’t have a healthy core, any change in technology requires almost a wholesale rewrite.

Any software system is a large investment for a company.  That software is expected to last a LONG time.  By focusing on the core of the application (domain model), the software will be able to weather changes in the technology climate.  By creating a healthy core, your software will be able to drop and adopt technologies as necessary.  Let’s stop rewriting and rewriting and start creating healthy software.

The inspiration for this post came from Jim Shore’ s thoughts.

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.

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.