Behavior Driven Development - TDD and DDD rolled into one

To be honest, I like to think that I’m pretty good at keeping up with the cutting edge of what developers are doing to improve their effectiveness, I’m pretty well versed in agile software delivery approaches like domain driven design, test driven development, agile modeling. I also am pretty well-versed in and have real experience in things like SOA, AOP, Web 2.0 , REST, patterns of all kind...

and then every once in a while I become completely humbled by learning that I have been totally ignorant of some fantastic new innovation within the development team.

This time that innovation is behavior driven development, a fusion of test driven development , agile user stories, and domain driven design.

What behavior driven development allows you to do is take a set of user stories and supporting acceptance tests written in natural language and turn them into explicit, testable requirements that become part of your automated testing and build routine.

For example:

take the following user story

As a customer
  I want to update my customer profile
  So that my personal data is always accurate
 
  Scenario 1: customer enters invalid birthday (must be 18 years or older) 
  given that the customer enters a birthday
  and that the customers age is calculated to be less than 18 years 
  When the test is run
  the following error message should be displayed "customers must be 18 years or older to be valid members of this website!"

  Scenario 2: etc.

Using a behavior driven specification framework like Story Test, one develops acceptance tests (either automatically using a tool or manually)
like the following
  namespace StoryQ.Tests.Documentation
  {
    [TestFixture]
    public class CustomerSpecification
    {
 
        [Test]
        public void ValidCustomerBirthdayScenario()
        {
            Story story = new Story(" writing executable specification for customer birthday");
 
            story.AsA("customer")
                .IWant(" update my consumer profile")
                .SoThat(" my personal data is always accurate")
 
                .WithScenario("invalid birthday scenario")
                    .Given(" the customer enters a birthday")
                    .Add ("any age is calculated to be less than 18 years")                  
                    .Then(" display error message saying that the customer must be 18 years or older to be a valid member of this website")
 
                .WithScenario("Writing specifications again")
                    .Given("That i have written everything in text")
                        .And("still have no asserts")
                        .And("and have another condition")
                    .When("the test is run")
                        .And("I am happy")
                    .Then("the test result should be pending")
                       .And("here’s just some more and’s");
 
            story.Assert();
        }
 
    }
  }
These user story specifications leverage the concept of a ubiquitous language from domain driven design, and are built just like regular user stories leveraging concepts such as value driven questions , and responsibility driven design.
IMHO, this is brilliant stuff and really ties together the concept of testable requirements and executable specifications.
 
This kind of innovation that comes from the open source world is also why, IMHO big vendors finding it increasingly difficult to match the pace of free products.
aa
 

..

Co-Presentation with Scott Ambler at Deloitte

It's been a while since I've had the opportunity to blog, but last week I had a opportunity to present on real-world agile development on large-scale projects with another firm employee, Sunny Ip, as well as the notable agile luminary Scott ambler . Our firm invited Scott to speak to some of our practitioners on why agile matters, and how it can be applied to environments that many critics state agile can not possibly thrive or succeed in.

As I have stated in previous posts, the firm that I work for it as much a management consulting firm as it is a applications development firm. Needless to say, many agile best practices and principles do not form the core tools that a lot of our practitioners use. While this is slowly changing, thanks to a core team is passionate and experience in using agile, having Scott present on the values of these approaches is essential to spreading this message within our firm.

I thought Scott did an amazing job in giving a no-nonsense and extremely frank presentation on why our firm and others like us need to start taking this seriously.

Scott managed to pack a lot of material in a relatively short period of time, topics included:

• agile overview


• surveys on the success of agile and traditional projects-a lot of great no-nonsense material was presented


• shortcomings of pure agile approaches (XP, scrum, etc.)


• extending agile with the rational unified process (RUP)


• applying agile in outsourcing staff situations


• applying agile to the database group and database platforms

I'm sure I did not list every topic covered here, but these were the major ones that resonated with me.

After Scott's presentation sunny and myself presented 4 separate case studies where our firm has taken advantage of agile best practices on large-scale delivery projects. Examples included:

• large-scale public sector transformation project with 20 plus developers in parallel


• assisting the enterprise architecture office in developing a reusable SOA platform


• using agile modeling techniques to properly analyze and design a domain driven solution for a provincial students assistance and loans application


• using agile delivery on a large-scale package implementation also dedicated to any students assistance and loan application

During our portion of the presentation, the audience began to ask questions which were mostly answered by Scott, with additional color/perspective from our firm added in by us.

For my part, my major take away from listening to Scott was that everyone in our firm needs to be much more forthright in pressing our clients on the need for change, and applying innovative/different delivery practices to their organizations. I think anybody who's done any solid delivery work for any length of time is more than aware of how dysfunctional many of our development processes and approaches are in a majority of organizations. But changing the situation requires courage, and the bravery to speak out to CXO level leadership. We really need to provide a frank assessment of the things we see on our day-to-day implementation projects. There's a huge amount of reward that can be gained from adopting agile in a pragmatic fashion. Costs can be lowered while simultaneously increasing quality and reducing risk. These things that business can buy into.

Again my thanks to Scott for a great presentation.

Changing the World, One Step at a Time

As some readers of this blog may be aware, I've had the opportunity to present on a number of occasions on the topic of government and Web 2.0. It's pretty obvious from where I'm standing that there is a lot of interest in pursuing Web 2.0 to enable the kind of cross organizational and government assistance collaboration required to make government really successful.


Paul MacMillan and I have tended to structure the presentation in two parts, where Paul gives a brief introduction of Web 2.0 and then proceeds to provide some great examples of where Web 2.0 is currently being used by governments around the world. I then tend to follow up with a discussion on what are some of the first things government organization should do in order to adopt not only Web 2.0 technology but a Web 2.0 "culture". I was genuinely surprised by the incredibly positive feedback and enthusiasm expressed by the audience concerning Web 2.0 adoption. Clearly the issue of how to get started is on the top of a lot of people's minds within government. The Canadian federal government is also starting to make some "Web 2.0" purchases, which while encouraging, might indicate an attempt to follow a traditional top-down mindset to a topic that clearly requires more collaborative, grassroots driven thinking to take close off.

Because of the perceived interest, we have started working on a
sequel to our original government 2.0 paper, Change the World or the World Will Change You that will be focused on advice, best practices, and
patterns that could make governments more successful when adopting Web 2.0. I plan to leverage a lot of the excellent patterns posted on wikipatterns , as well as continue to contribute patterns on an ongoing basis. Rather than developing the paper exclusively within our organization, I'm hoping to be able to share my thoughts and comments with the public as they evolve, and try to get feedback from anybody else out there who is equally passionate about the topic. So please feel free to suggest, flame, argue or otherwise criticize/contribute to any of the posts relating to Government 2.0 adoption.

To start, I've posted a overview of what I feel to be a successful government web 2.0 that emphasizes adoption in three stages. The first stage involves numerous incubation pilots, where the focus is on creativity, small targeted objectives, and a lot of learning by doing. In my opinion, members of government need to start getting more comfortable with experimentation and prototyping using a small team close rather than massive upfront design on massive scale. The second stage could still be thought of as prototyping, but now the effort focuses on how to better integrate Web 2.0 technology and culture within a government organization. Basically the focus here is creating a set of blueprints that can serve as the basis for larger adoption, again learning by doing and trial and error is way more important than philosophy and conjecture. The final stage, mainstream adoption is basically a self-fulfilling prophecy, providing leadership continues to focus on removing many of the roadblocks that will get in the way.

Feel free to post any initial comments here, or on the
overview itself.

Online Collaboration, Making the 1st Move

There is a clear and demonstrated interest in adopting Web 2.0 within the government, but what is the first step?

In the paper
Change Your World or the World Will Change You, Deloitte described the value that online collaboration could bring to governments and their citizens. The paper provided an overview of how Web 2.0 technologies can be leveraged to enable governments to engage in a highly collaborative, network based, communications model. The paper also described some of the top benefits of this fundamentally new culture of cooperation, referred to as Government 2.0. Some of the benefits listed were improving policy outcomes, streamlining internal operations, increasing effectiveness of government information, and attracting the next generation of tech savvy top talent.

In the course of presenting our paper, we have had a chance to have numerous conversations with various levels of government concerning Web 2.0 and how it applies to governments. It is clear that there is a lot of interest in adopting the technologies and culture represented by the Web 2.0 phenomenon within the public sector. A common thread that is often raised in these discussions revolve around how to get started. How does one apply a paradigm as revolutionary as Web 2.0 to an organization as large and complex as the government? A range of obstacles have been presented to us, ranging from issues of culture, restrictive web policies, to limitations of government IT.

Adopting an online collaborative approach supported by Web 2.0 will have an unprecedented impact on the way governments do their work, the scope of these changes threaten to stall any large-scale adoption

There is a significant amount of inertia to overcome when introducing any large-scale change within the government. Traditionally government work has taken place in a monolithic, highly structured, top-down environment. Adopting Web 2.0 technologies implies a significant change in working culture. Collaboration becomes much more important than control, workers are subjected to an unprecedented level of transparency, and the lines between different levels of government, supporting organizations, and citizens become much blurrier. IT will also need to rethink many of the ways that it has traditionally supported its stakeholders. IT will have the added responsibility of providing government and citizen end users with a constantly evolving "collaborative ecosystem". In order to properly fulfill this role, IT will have to adopt more lightweight, collaborative development approaches, becoming an enabler of change.

The scope of these changes can seem overwhelming and intimidating, to say the least. An enormous amount of analysis would be necessary before all of the possible issues and risks were covered to the extent necessary to satisfy all involved. Imposing a large upfront Web 2.0 analysis effort as a requirement prior to any government Web 2.0 adoption could effectively paralyze any meaningful progress within the space for many months and potentially even years. This would result in a significant loss of potential opportunity for the government, as it churns through the potential outcomes of any possible missteps relating to Web 2.0.

Successful Government 2.0 depends on demonstrating value immediately, starting with carefully chosen, tightly scoped 'incubation ' pilots -emphasizing innovation, trial and error, and learning by doing. Pilots will evolve over time to a more 'stabilized 'state, becoming more sustainable solutions-better integrating into existing infrastructure, considering usage policies and other standards, and becoming ingrained into the overall vision of government. Eventually solutions and platforms will be 'mainstreamed '-and considered an everyday part of government life

Complement Long-Term Strategy and Visioning with Incubation Pilots

Instead of dedicating initial Web 2.0 activity on a large, enterprise scale strategy, government organizations should also run a carefully selected set of Web 2.0 'incubation" pilots . Incubation pilots should be targeted at a set of internal and/or citizen end users that would most likely identify with the Web 2.0 approach. It is important to carefully limit the scope to a very specific set of objectives. This has the dual advantage of limiting the risks and exposure should things go wrong, while simultaneously allowing the piloting team the freedom to profit from the creativity, innovation, and trial and error learning necessary to determining the proper fit of Web 2.0 within a particular government environment.

Continue to Pilot, Stabilizing and Integrating with the Enterprise

As each incubation pilot comes to a close, experiences gained and lessons learned will be re-factored into the larger, enterprise-level Web 2.0 adoption strategy. As the strategy is refined, future initiatives will become more deeply integrated with existing government assets, examples include organizational standards, policies, and IT technology and procedures.

Once the value of Web 2.0 approaches have been clearly demonstrated through some of the initial "incubation" successes, the piloting effort shifts to realizing a fully integrated, controlled environment that is dedicated to developing and testing replicable Web 2.0 strategies. Pilots can now be used to determine how existing government assets need to evolve to support a Web 2.0 approach, including administration, policy, and other support structures that are essential to full government adoption.

Mainstream adoption is largely a self-fulfilling prophecy, providing the right components are in place

It will not be immediately obvious when a particular government or government organization has graduated from piloting to actual mainstreaming. One of the many appeals of the Web 2.0 approach is the viral pattern of adoption. The important point to take from this is that a Web 2.0 approach should be pursued in small increments, consistently revisiting the platform, policies, and any other components in an iterative fashion. As on the consumer Web, much of the work relating to mainstreaming the "Web 2.0" approach within the government will not be the result of any particular top-down decision.

That being said, leadership has a lot of power to make Web 2.0 a more effective force within the government. One of the most valuable things they can do first is give their members license to experiment, innovate, and try out these new technologies to better enhance collaboration. It is important that leadership foster a collaborative, transparent culture that rewards experimentation and places an equal value on lessons learned through failure as on a particular Web 2.0 success.

Further posts will further elaborates on how to execute this "trial and error" adoption approach.