Lean & Agile : A Panel Discussion

Thursday, 25 August 2011 13:02 Written by AdventureTech 2 Comments

Today we have short Q&A about agile practices with out esteemed guests Winston Churchill, Albert Einstein, Mark Twain, Martin Luther King, Jr, Gandhi, Bruce Lee, & Franklin D. Roosevelt.

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Churchill: The farther backward you can look, the farther forward you are likely to see.

Albert Einstein: A man should look for what is, and not for what he thinks should be.

Question: Is this because full discovery early on is hard to achieve?

Martin Luther King, Jr.: Everything that we see is a shadow cast by that which we do not see.

Albert Einstein: Occurrences in this domain are beyond the reach of exact prediction because of the variety of factors in operation, not because of any lack of order in nature.

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Gandhi: I do not want to foresee the future. I am concerned with taking care of the present. God has given me no control over the moment following.

Mark Twain: I was gratified to be able to answer promptly, and I did. I said I didn't know.

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Albert Einstein: No problem can be solved from the same level of consciousness that created it.

Mark Twain: Get your facts first, then you can distort them as you please.

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Bruce Lee: Notice that the stiffest tree is most easily cracked, while the bamboo or willow survives by bending with the wind.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Albert Einstein: Any intelligent fool can make things bigger and more complex… It takes a touch of genius – and a lot of courage to move in the opposite direction.

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Bruce Lee: Learn the principle, abide by the principle, and dissolve the principle. In short, enter a mold without being caged in it. Obey the principle without being bound by it.

Franklin D. Roosevelt: One thing is sure. We have to do something. We have to do the best we know how at the moment… If it doesn't turn out right, we can modify it as we go along.

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Churchill: To improve is to change; to be perfect is to change often.

Bruce Lee: All fixed set patterns are incapable of adaptability or pliability. The truth is outside of all fixed patterns.

Gandhi: Constant development is the law of life, and a man who always tries to maintain his dogmas in order to appear consistent drives himself into a false position.

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Churchill: The truth is incontrovertible, malice may attack it, ignorance may deride it, but in the end; there it is.

Mark Twain: Let us make a special effort to stop communicating with each other, so we can have some conversation.

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Churchill: A lie gets halfway around the world before the truth has a chance to get its pants on.

Gandhi: An error does not become truth by reason of multiplied propagation, nor does truth become error because nobody sees it.

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Franklin D. Roosevelt: Are you laboring under the impression that I read these memoranda of yours? I can't even lift them.

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Martin Luther King, Jr.: You don't have to see the whole staircase, just take the first step.

Franklin D. Roosevelt: There are many ways of going forward, but only one way of standing still.

Bruce Lee: Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way round or through it. If nothing within you stays rigid, outward things will disclose themselves.

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Franklin D. Roosevelt: The only thing we have to fear is fear itself.

Did you like this? Share it:

Breaking the rules

Thursday, 21 April 2011 10:49 Written by AdventureTech 1 Comment

Scenario 1 – You approach a 4 way stop sign, with exceptional visibility in all directions. You have to decide if you will roll through the stop sign, or be a ‘good driver’ and come to a full stop. Since you see no benefit in fully stopping you decide to roll on through. As you drive on a motorcycle officer pops out from behind a bush and writes you a ticket for not complying with the law.

Scenario 2 – You need to finish a new feature on a project, so evaluating the design options and impact of them. You can either follow the standard approach that your team uses or save half the time and implement it in a much simpler way. After realizing half the effort for the same effect is the best value for the customer you decide to use the simple implementation. As you finish up and commit your changes into source control, the commit notification alerts the resident ‘architect’ and they scold you for not following standards.

The point I am trying to convey is that rules/standards should only be in place to help people that need guidance, either from a lack of knowledge, or lack of a clear choice. Unfortunately the inflexible nature from the bodies of governance stem from a lack of trust. If you don’t have trust in your developers decisions making capabilities then you have a broken system, and your rules are more constraining then they are helpful.

To sum it up in one line, if you are familiar with the Serenity Prayer then this format might sound familiar…

Grant me the serenity to follow the rules, courage to defy the rules , and the wisdom to know when to do which.

Did you like this? Share it:

Software development guarantees

Sunday, 10 April 2011 20:52 Written by AdventureTech 0 Comments

Engaged in an agile software project you can find yourself fighting, nearly daily, a customer asking for guarantees about what you are building.

They want to know:

Everything you plan to build
How you plan to build it
How long you will take to build it
How much it will cost to build

These are reoccurring questions you will get from a customer you are already engaged with. While not bad questions, the connotations that come along with them are. Every time you provide an answer to one of these you need to prefix it, suffix it, get written verification and audio confirmation that these are estimates and not guarantees.

However when working on a new customer engagement, these can be even harder realizations that they see as excuses since, in their other hand resides a second proposal stating precise (read not accurate) answers that are ‘guaranteed’.

There are numerous arguments, diagrams and case studies that can back up your approach to providing software as a vendor. In lieu of delivering on those points to the customer I would, just once, love to play one of my favorite movie clips from Tommy Boy to express my feelings…

Tommy: Let's think about this for a sec, Ted. Why would somebody put a guarantee on a box? Hmmm, very interesting.
Ted Nelson, Customer: Go on, I'm listening.
Tommy: Here's the way I see it, Ted. Guy puts a fancy guarantee on a box 'cause he wants you to feel all warm and toasty inside.
Ted Nelson, Customer: Yeah, makes a man feel good.
Tommy: 'Course it does. Why shouldn't it? Ya figure you put that little box under your pillow at night, the Guarantee Fairy might come by and leave a quarter, am I right, Ted?
Ted Nelson, Customer: [impatiently] What's your point?
Tommy: The point is, how do you know the fairy isn't a crazy glue sniffer? "Building model airplanes" says the little fairy; well, we're not buying it. He sneaks into your house once, that's all it takes. The next thing you know, there's money missing off the dresser, and your daughter's knocked up. I seen it a hundred times.
Ted Nelson, Customer: But why do they put a guarantee on the box?
Tommy: Because they know all they sold ya was a guaranteed piece of shit. That's all it is, isn't it? Hey, if you want me to take a dump in a box and mark it guaranteed, I will. I got spare time. But for now, for your customer's sake, for your daughter's sake, ya might wanna think about buying a quality product from me.

When you purchase a product do you make a decision based on the company’s guarantee, or upon their ability to deliver a quality product?

Did you like this? Share it:

Fighting atrophy

Friday, 18 March 2011 10:17 Written by AdventureTech 1 Comment

You have ideas and beliefs on how software should be developed and you spend hours a week researching the newest development practices, going to conferences/user groups to hear experts talk about a subject that challenges what you thought you knew. When you finally start to get “on board” the sources you were taking your inspiration from before now are telling you something else, in direct opposition to what you just learned.

The truth is that you were doing it wrong before, your doing it wrong now and you will be doing it wrong tomorrow. This an important realization that you need to grasp before you can continue to grow as a developer, the ability to accept that you don’t have the best answer but you are willing to fight towards it using what you know today. But just because you know you are not right should not stop you from acting like you are, developing software is an an exercise in learning and you learn more from being wrong that you do from being right.

To quote House when asked “How is it that you always assume you're right?” he responded "I don't, I just find it hard to operate on the opposite assumption. And why are you so afraid of making a mistake?”

The longer you are involved with software development the harder this is to swallow, you have a tendency to believe that once you reach a certain maturity in your career that you just have it figured out.

To me a graph of the continuous evolution of software would look similar to this. With every new wave comes good useable ideas & techniques that should be kept but without knowing when it has reached the apex you will continue to follow it down the rabbit hole until until it leads you to a place you don’t want to be. If you do this very many times you will convince yourself that the newest fad in software development is not worth following because you have been burned by trying to be on the “bleeding edge” before.

Depending on your situation, how much risk you are able to take on will vary. It is understandable that not every business can afford to follow the movements and instead decide to stick with the establishment, however you must not find yourself stuck below the orange line watching all the movements come and go without integrating lessons learned from the people who are taking the risks.

If you are in the movement don’t get discouraged that you must take one step back to take two steps forward.

If you are in the establishment, what you hold dear today came from a movement yesterday, so don’t forget to pay attention to what’s happening around you.

Did you like this? Share it:

Making Machine.Specifications less ‘machiney’

Tuesday, 15 March 2011 13:18 Written by AdventureTech 2 Comments

I have been a user of Machine.Specifications or Mspec for awhile now, and have been pretty happy with how much more readable it makes my unit testing.

If you are not familiar with Mspec it is a testing framework for context/specification that uses delegates to setup the Act, Arrange, & Assert pattern.

There are several good getting started guides if this is new to you, but here is a basic example of the structure.

    public class When_a_content_admin_asks_for_a_non_existent_page
    {
        Establish that;

        Because of;

        It Should_check_the_repository;

        It Should_present_a_blank_add_content_screen;

        It Should_auto_populate_the_url_field;
    }

Now of course to do unit testing you must be able to do mocking/stubbing/faking etc…, I am normally a user of Moq and that is what I use in my Mspec test to establish my mocks. While it works well, all the noise it takes to arrange all of my mocks at times bothers me. While the noise was irritating I just dealt with it because setting up mocks is just something you have to do, but luckily I recently discovered somebody else had the motivation to

actually do something about it.

Machine.Fakes is a compliment to Machine.Specifications and reduces the obligatory mocking and dependency injection code in your tests and replaces it with a bit of magic. Machine.Fakes itself does not depend on a particular mocking framework, it uses a plugin style that lets you use any framework of your choosing. As I write this the options available (on NuGet) are Moq, FakeItEasy, Rhino.Mocks, & NSubstitute.

Here is an example of a simple MVC controller test of mine using just MSpec & Moq.

public class When_a_content_admin_asks_for_a_non_existent_page
    {
        Establish that = () =>
        {
            var auth = new Mock<Authorization>();
            auth.Setup(x => x.IsContentAdmin(GivenIt.IsAny<HttpContextBase>()))
                .Returns(true);

            _repo = new Mock<ContentRepository>();
            _repo.Setup(x => x.Exists("a/bogus/url"))
                .Returns(false);

            _controller = new MeekController(_repo.Object, auth.Object);
        };

        Because of = () =>
            _result = _controller.Manage("/a/bogus/url");

        It Should_check_the_repository = () =>
            _repo.Verify(x => x.Exists("a/bogus/url"), Times.Once());

        It Should_present_a_blank_add_content_screen = () =>
            _result.AssertViewRendered().ForView("Manage");

        It Should_auto_populate_the_url_field = () =>
            (_result.AssertViewRendered().Model as Content.Manage).ManageUrl.ShouldNotBeEmpty();

        static ActionResult _result;
        static MeekController _controller;
        static Mock<ContentRepository> _repo;
}

You can see that I am Mocking both an Authorization and a ContentRepository interface, with the ContentRepository defined as a field so I can assert upon it later. Both mocks are passed into the class constructor of my system under test (SUT). Now while this is not a ton of noise we can trim it down to a more readable state with Machine.Fakes, below is my updated test.

public class When_a_content_admin_asks_for_a_non_existent_page : WithSubject<MeekController>
    {
        Establish that = () =>
            {
                The<Authorization>()
                    .WhenToldTo(x => x.IsContentAdmin(GivenIt.IsAny<HttpContextBase>()))
                    .Return(true);

                The<ContentRepository>()
                    .WhenToldTo(x => x.Exists("a/bogus/url"))
                    .Return(false);
            };

        Because of = () =>
            _result = Subject.Manage("/a/bogus/url");

        It Should_check_the_repository = () =>
            The<ContentRepository>().WasToldTo(x => x.Exists("a/bogus/url")).OnlyOnce();

        It Should_present_a_blank_add_content_screen = () =>
            _result.AssertViewRendered().ForView("Manage");

        It Should_auto_populate_the_url_field = () =>
            (_result.AssertViewRendered().Model as Content.Manage).ManageUrl.ShouldNotBeEmpty();

        static ActionResult _result;
    }

There are a few things to point out

First thing to notice is that I am inheriting from a WithSubject<> base class, this is where you specify your SUT.
Under the Establish we are no longer newing up any concrete mocks we are only telling Machine.Fakes of our expectations with the The<> object.
Without an instance of a mock you will now be using the Machine.Fakes method for inspecting if a call was made or not with the same The<> object used to setup it up.
Any place that you had been referencing your SUT you will replace with the Subject property.
Since we are no longer declaring an instance of our mocks or SUT we can remove the field declarations.
I am still using the GivenIt.IsAny<HttpContextBase>() from my Moq framework to establish the parameter expectation.

It did not reduce the lines of code a ton but but this is a pretty lean test to begin with, the important part is that we removed most of the plumbing code that had nothing to do with setting expectations.

Conclusion… I am a happy camper that has to type even less now.

Did you like this? Share it:

Category: Brian Wigfield

Lean & Agile : A Panel Discussion

Question: Why do you believe there is benefits in building & watching metrics and then projecting dates versus utilizing pre-defined project dates?

Question: Is this because full discovery early on is hard to achieve?

Question: The what did you tell your project manager the last time he asked you for an accurate estimate?

Question: Some managers like to create their own artificial estimates to fit their plans, does this work out well in some cases?

Question: But wouldn’t it be fair to say that without a estimate to hold somebody to, that the work item will not be completed in a timely manner.

Question: If there are shortcomings in the waterfall methodology, should those just be addressed in the methodology instead of creating entire new development method?

Question: Do you believe in following Scrum as prescribed or do you believe “Scrum But” is acceptable?

Question: What would attract a team to using an Agile approach with a loose definition of procedure such as KanBan or “Scrum But”

Question: If you have gathered metrics using an Agile approach and your manager demands you to complete a feature in a timespan that your metrics say is not possible, how do handle a response telling them that?

Question: It is popular to display a large visual task board so that the team is transparent to anybody interested, why is this information important to be constantly available?

Question: When starting a new project do you like to create detailed documentation before hand to make development easier?

Question: Ok so you may not like a lot of documentation but how can you get started with none?

Question: Having removed so many potential roles and overhead in a development team, should people in those roles be in fear of losing their job?

Breaking the rules

Software development guarantees

Fighting atrophy

Making Machine.Specifications less ‘machiney’

Connect With Us

Contact Us

Upcoming events

Recent Blog Articles

Blog Categories

Recent tweets