Author: Robert Binzley

Time for the second morning session here at CodeMash.  This session is called User Stories Closing the Agile Loop and is being given by a gentleman by the name of Barry Hawkins.

Barry says requirements churn is not a crisis.  This really hits home, it feels like it is, but it is also a reality.  Barry is now walking through the agile manifesto.  Creating working software over comprehensive documentation does not mean we don’t create any documentation.  It means we create high quality documentation that people actually want and use.

Barry’s reviewing the pieces of the manifesto and talking about his real world experiences and what they practically mean to him.  This is really interesting stuff.  Comparing estimation process with business in its usual way similar to a game of poker.  Points out contracts are made at beginning of project when we are as ignorant as we’ll ever be about the project, this may not be the optimal time to lock in absolutes.  An Agile approach would dictate a softer approach that involves collaborating and allowing for changes along the way as we learn more.

Underlying agile assumptions:  Motivated self-directed people make up the team.  Cross functional team, have everyone you need to move product from concept to launch.  Good teams have a QA person at all stages, not just at the end.  Teams have highly available domain experts.  A culture of testing.  A failure tolerant environment.  Value projects completed, not projects launched (context switching for developers can be time costly).

Most agile adoption is driven by development teams.  Usually it is not management that proposes development is done using an agile methodology.  This produces situation where development doing iterative approach while business is still providing phased waterfall analysis, use cases at best.  Hard to fit non iterative requirements/analysis process into iterative development process, very time costly to translate requirements.

What are user stories?  Barry recommends the book User Stories Applied for deeper understanding.  User Stories are place holders for interaction, not a substitute.   User Stories are much smaller than use cases, they focus on a small strip of functionality, they don’t dictate detailed requirements such as UI requirements.   User Story structure:  “As a ___ user, I can ____, so that _______”.  Structure defines who is going to do what and what benefit it will provide.  The “so that’ is the benefit statement and is very important.  Stories should follow Bill Wake‘s  INVEST acronym: Independent, Negotiable, Valuable, Estimatable, Small, and Testable.

But what about __________.   Business won’t cooperate: maybe business doesn’t like you, you say no to often.  Could it be that business has come to believe no will already be the answer.    Functional spec already written:  you can turn these into user stories.   Team is not co-located: wiki’s can help here.  no UI for code : just  becuase no UI doesn’t mean there aren’t users.

Well that’s that.  Very good presentation I thought.

The keynote speaker at CodeMash this year was Mary Poppendieck.  Very interesting talk about what was called the LEAN software development methodology.  Approach was apparently based on lessons from Just It Time manufacturing learnings.  Basics involve eliminating waste by not doing things that don’t have value to your customer, always learn, build quality (TDD)  into the process at all levels, make decisions as late as possible and delivery quickly.

Specifically Mary focuse on five concepts, Purpose: everyone in the organizations should know why they’re doing what they’re doing at a meta sesnse.  Passion:  people should be passionate about the organiation.  Persistence:  hard work and practice, especially practice is necessary.  Pride: Cathedral builders versus stone cutters and Profit:  Organizations should make money but that shouldn’t be only goal.  Goal should not be to make as much money as possible, but to be profitable while servicing clients and employees.

I’m back at CodeMash, and it’s Thursday morning.  Just left the keynote, more on that later.  Now sitting in first morning session, Iteration 0, a session on how to get prepared for an Agile project.  Presentation is being given by a gentleman by the name of Ken Sipe.

Goal, many organizations have problems getting started wtih Agile, this presentation is oriented on how to overcome these problems.  Ken is an old RUP guy, used to teach Rational courses, has a background doing XP programming, now a scrum master.

Review of different development process, first Waterfall.  Waterfall seems to be corporate default.  Iterative process is different in that provides for feedback.  Corporate environments have problems with an iterative process, why, lack of control of process can’t predicate the future with as much certainty as they’d like.  Corporate environments have trouble with communication.  Iterations force process to happen before last minute, akin to term paper being done the night before it’s due.  If have interim due dates, iterations, things go better, feedback is introduced earlier in the process.  Agile is an iterative approach.

How do you know what the right size is for an iteration?  Larger iterations mean less feedback, but iterations that are too small don’t allow enough time for anything to get done.  Generally most organizations are probably erroring on the side of having iterations that are too large.

Iterations create trust with business.  Business starts to realize you can respond to their needs because they see the results of their feedback sooner.  Business also is asked to give feedback more often, again building trust.  Also allows feedback about progress against plan early and reliably in project.

What agile is not, it’s not evolutionary based on iterative development, it does require documentation, it does require architecture, it is not cowboy development.

Pair programming, many organizations say they do agile but do not allow pair programming.  If you aren’t pairing you aren’t really doing agile.  Pairing is just in time code review. Should swap pairs regularly, disseminates information across team.

What is an iteration?  Opening meeting.  Standup meetings daily and a closing meeting.  Standup meetings need to be no more than 15 minutes and stand up meeting must actually happen daily.  Iteration size, change it around to find points of pain, fix pain points and go to iteration length that seems appropriate.  The more you remove yourself from actual agile practices the more risk you introduce into the project.

Who should attend an opening meeting and what’s it for?  Optimally an actual end user should be involved.  It is optimal to have an actual end user on the project full time.  Should have a BA, DBA’s, developers, architects and QA in the opening meeting.  Purpose of the opening meeting is to define the vision of the user for the iteration, and to agree on acceptance criteria.  Poorly defined acceptance criteria is a large reason for iteration failure.  Should have a second follow up opening meeting to break out an allocate assignments.

What is the closing meeting for?  Is iteration accepted by the user, define velocity of team.  Need to resolve bug level to velocity.  Is the team going too quickly to have a better looking velocity at the cost of quality?  What kind of bugs are coming out of QA?  Are we getting functional bugs?  Functional bugs should be caught in dev process in Agile.

Stand up meeting, the Pig Rules.  In a ham and egg breakfast the pig is fully committed, the chicked in simply involved.  Only pigs are allowed to talk in a standup meeting.

Pre-Iteration 0, collect user storied.  Need to estimate ROT, is project justified.  Build your team.  Create a release plan and iteration strategy.  Team needs to be prepared for transparency.  Pairing and code refactoring may happen to your code by someone else.  Very transparent process

Team Building Phases

1. Forming – Team meets very friendly
2. Storming – Team forms as get to know each other has some conflict
3. Norming – Team becomes settled works well together
4. Performing – Team hits its stride

User Story gathering.  Some projects have all the stories up front, some have enough to start and expect that others will be provided along the way.  Either approach requires a business analyst.

Feature Slip versus Time Slip.  In a RUP based approach you will slip dates to get features done if running late.  Agile will slip features as iterations are done when they are done.  Can extend agile projects and add iterations to handle feature slip.

Agile alignment with QA options.  One option:  Have BA and QA building test plans for next iteration while dev is working on current iteration.  QA executes test plan for previous iteration during current iteration.  Features are considered complete when dev has finished iterations.  QA bugs will be added to future iterations.  QA executes regression testing against iteration -2, while executing test plan against previous iteration and creating test plan for next iteration.  Only dev is working on current iteration.

Second Option: have dev work on many iterations before QA starts executing tests against first iteration.  Allows many things to change before QA gets involved, someone pointed out this seems very waterfall like, Ken agreed and said first approach is better.  Both approaches based on production level code coming from development iterations because of TDD and pairing.

Coming to the end of session, getting into QA now.  Someone asked for a definition of velocity, a fairly standard agile concept.  Discussion on point allocation to stories and iterations and such.  Question of team size, Ken indicated an 8 person team is very large, shouldn’t have bigger teams but more smaller teams or scrum of scrums.

Iteration 0 is heavily about automating everything possilbe before real iterations begin.  Why automate?  Predictablily, get frequent predictable feedack.  Have to setup Version control in iteration 0.  Build project should be setup in automated fashion so all things regarding release and such can be done with the push of button.  Setup build server to handle moves.  Setup build server to automate unit testing and code coverage.  Setup automated repoting for management that will be used in iterations.  Initial design concepts should be decided on in interation 0.  Are you using and MVC model for presentation, logging models.  Where it makes sense make these decisions in iteration 0.  Ken advises to run iteration 0 like any other iteration.  Have an opening meeting, stand up meetings and a closing meeting.  In iteration 0 the user is you and your team.

Well lunch was good, still at CodeMash.  Now sitting down in the afternoon session on Practical Behavior/Test Driven Development.  Apparently supposed to have some prereq software, so I’m trying to set those up on my machine rigth now.  Presentation is being given by a gentleman by the name of Philip Japikse.

Reviewed the concepts of User Stories and Context Specification.  Apparently these underpin the usage of MSpec, a tool for automating the running of user tests.  MSpec allows you to write Context Specification tests that group unit tests into a context of a feature expressed as a context specification.  The point apparently, is that MSpec will autogenerate HTML reports that can be shown to business analysts and other business stakeholders so they can understand what is being tested and how it’s being tested.

An example of a template of a test using this syntax looks a little like the below:

using Machine.Specifications;
using MbUnit.Framework;
using Rhino.Mocks;

namespace ThirdPartyToolSetupConcerns
{
    [Subject("0-Complete Application Concerns"), Tags("0-Complete Application Concerns")]
    public class When_Setting_Up_Third_Party_References
    {

         Establish context = () =>
	{
	   _toolMock = MockRepository.GenerateMock<ItoolRepository>();
	};

         Because ACTION;

        It Should_Get_List_Of_Tools_From_Command_Line = () =>
	{
	        _toolMock.Expect(tm => tm.HasTool()).IgnoreArguments().Return(true);
		var toolValidtor = new ToolValidator(_toolMock);
		Assert.IsTrue(toolValidator.HasTool());

	};
        It Should_Look_Up_Files_Required_For_Each_Tool_From_Database;
        It Should_Copy_Missing_Or_Updated_Files_Into_Correct_Directories_For_Each_Tool;
    }
}

The “Establish” and “Because” are delegates created to allow the test to be written in a context specification manner.  It seems to me that each “IT” is a separate actual unit test.  When run looks a lot like running tests in nUnit as long as you’ve named your test classes and test methods in a meaningful manner.  I think the value of MSpec is that it generates reports that are nicely formatted for your business stakeholders and such.

To implement the tests you use lambda expressions with no parameters, hence the ” = () => ” syntax, to create the code that does the setup and the code that implements each test in each one of the “IT” areas.  If no closure after an “IT”, then that test hasn’t  been implemented yet.  Above there is one closure for setup code and one test is implemented.

Actually there’s a little more, it looks like the benefit here is to layout the unit tests that you will fill in using a TDD approach and have the skeleton verified by your business stakeholders before you begin.  You can layout tests in the manner above without actually filling in the tests or any code and show the nicely formatted report about what you will test to your stakeholders and get agreement before moving forward.  Once you have business agreement on you MSpec setup you can then start codign by filling in the tests defined in each “IT” and writing code to make the tests  pass….interesting.

Now we’re going to start filling in some code ourselves.  Let’s see how this goes.

Just went over the notion of a “Row” test.  Apparently not supported in MSpec, but is supported in mbUnit and nUnit.  The idea is let’s you declare several different parameters for the same test so can write one test and run it with many different inputs.   Sounds like a really good way to cover my test cases with less code.

It looks like “Establish” delegate is used to demarcate a section of the test for setup.   Anything that needs to be setup for the “IT” tests to run below would be put here.  Phil suggests making all variables ‘internal’ and marking test projects friends so can set variable values for testing.  Phil went indicates he never marks any variables private, always internal so they can be accessed from a test.   Interesting…….

Beginning to go over mocking in a test driven development situation.  Phil’s using RhinoMock, whcih is what we use, so this is all making good sense to me.  Phil just setup an example showing how to inject the mock object into a method, it looks almost exactly like the process we use, so nice to see these experts telling people to do what we already do!  I like a little validation.

Going over the nitty gritty of using a mock object.  Specifically we’re talking about creating a wrapper for the file system so we can mock file system operations.  Interesting discussion, Phil suggests you only ever throw custom excpetions.  He suggests this because you can log in the creation of your custom exception and not worry about logging exceptions as they’re bubbled up.  Interesting theory.

Well presentation is winding down.  Very interesting, bdd stuff could be very beneficial from a process standpoint.  Also, again feel very good about what we are already doing after sitting through this.  Now have to figure out what to do for dinner!

I’m sitting at Code Mash, in Sandusky, Ohio.   Right now I’m  listening to a presentation on Fundamentals of Sofware Engineering.  A little basic so far, given  by a gentleman by the name of Jon Kruger.   First part went over basics of OOP, encapsulation, inheritance and such.   Had a break now going over SOLID Principles and he’s basing it on Uncle Bob Martin’s book Agile Principles, Patterns and Practices.  One of my favorites and where I got my SOLID leanings from!

SOLID overview was a little confusing.  Presenter seemed to suggest to igore the principles until forced to not to, except he did seem to suggest to always follow DIP.  I  would disagree, I would suggest ignoring them until problems ocur makes it more likely for problems to ocur.  I would agree shouldn’t follow them blindly either, though.

Presenter is really high on Dependency Injection Containers.  Specifically he showed examples of StructureMap.  Looked useful, we rolled our own mostly because I wasn’t aware these existed when I did it.  I like to think it shows I had good instincts that I even thought to create dependency injection framework all on my own.  Probably should replace with one of these though.

Presentation is over, time for a  little hands on coding at the end of the session.  They’ve just haned out some requirements for a game and we’ve been given really bad code to try and refactor, or rebuild it from scratch.  Should be interesting.

Pair coding with my work buddy Ryan, trying to refactor/fix/update and ASP.net MVC project that implements two basic games.  We’ re quickly running out of time, struggling to figure out how to add 2 jokers into the deck for just one of the games!

Well we’ve decided to change direction and just confirm code meets the requirements we’ve been given.  We’ll fix and put in tests for deviations we find.  Clock is ticking!

Well that’s over.  Didn’t get a whole lot done on the coding task, not quite sure that it fit in well with the presentation, but maybe it’s just me.  Overall a pretty good presentation.  Mostly what I took from it was that we’ve been doing the right things on my current project.  That’s always good to hear.  I feel I contributed quite a lot to our current practices and approach and its nice to feel like we’ve done it right.