• Two kinds of "agile" organizations

    1. Those that are working to be agile but recognize problems in their development that don't fit the manifesto and attack those problems, usually implementing best practices from XP, Scrum, Crystal Clear, or the resources available at www.agilealliance.com
    2. Those that want to be agile so they declare that they are agile and tout the buzzword around, but for the most part continue to 'do business as usual' under some type of waterfall method.

     

    note: there is no true agile team that does everything perfectly, because agile is always about recognizing problems and attending to them. The biggest problem i've faced in any organization is their inability to recognize a problem as something that they should do anything about.

     

    So, how do i know if i've found a team that is #1 on this list?

     

    1. They have an XP coach, scrummaster, or someone who is an expert on and facilitates agile practices.
    2. The team is allowed to recognize problems and bring them up to the group through having daily scrum/standup meetings (use the term standup meeting or scrum meeting… or timeboxed meeting) where people say only 3 things “what they are doing” “what they did yesterday” “what is blocking their path”
    3. The development team HAS a customer on it (or a good proxy of a customer – good means: Not marketing, not ceo, not project manager, but someone close to the real users of the product)
    4. Everyone on the team is a “developer”, there is no ‘testers’, “architects”, “QA as their own roles. Everyone does everything, it’s ‘crossfunctional’

    how do i know if they're #2?

    1. they'll tell you they're agile
    2. they have an architect, probably draws diagrams but never actually codes
    3. they work from designs instead of from communication directly with the customer. (designs are 3 times removed from the words of the customer)
    4. the developers are always getting hit with a fire drill of some sort "Oh we have a demo in 3 days that needs primary attention"
    5. the source code doesn't clearly communicate the intent of the software so it's supplimented with pages and pages of documentation.
    6. they don't have daily (or at least bi-daily) standup meetings
    7. they don't have unit tests
    8. they don't have acceptance tests
    9. they dont' automate ANY tests
    10. they work from a set scope (this means they have to forsake quality to meet time commitments often unless their PM is clairvoyant)

    Full story

    Comments (0)

  • Agile Statement of work?

    There's no doubt the customer drives development, but how they drive development is up to the chickens (http://www.implementingscrum.com/ for what a chicken is).

    Edgar, a PMP project manager with a huge set of credentials and years experience was showing John the statement of work for their current project. He said, "John i made sure that certain parts of it were vague so that we'd have leeway in what we could make so we can meet the schedule".

    Is it really the policy of PMP professionals to build a statement of work that is so huge but so vague that it can easily be re-interpreted?

    YES

    Why? because the purpose of a statement of work in a non-agile environment is to interpret the customer's need into something the Project manager is positive he can build within that timebox... ie something he's already seen built before. NOT what the customer actually wants, mind you.

    Also, this sets up the gunsights on the customer for the blame game when the product is delivered and doesn't meet the customer's expectations BUT matches the statement of work!

    How many times has a customer said "Well you built what i asked for, but not what i wanted"  ?

    By definition, i don't think a statement of work can be written to suit an agile team because it clearly defines scope (or it should anyhow, though do they ever accurately do so in software?).

    Instead of a SoW, try making contracts with the customer that define HOW the team, including the customer's team member, will work together to bring about the software in an iterative manner.

    If you absolutely must have a statement of work(government contracts?), do the XP planning game up front and figure out the high level user stories, have the customer prioritize them, have the engineers estimate them, build an iteration schedule and make that the statement of work.

    Full story

    Comments (0)

  • Agile Design

    According to the book: Practices of an agile developer, Design isn't left up to the user stories in a completely top down approach. Design is done a little bit at a time until the problem itself is well understood. However, they go on to say in the book that design shouldn't drive your code.

    Ed was talking to Garrett about a component in the system, one that would act as the router in a complex communications platform. Looking at the code Garrett had written he was confused by the methods of the interface presented to him and so he asked "Why is this method there? what does that support?" to which garrett responded "It's in the design diagram, so i put it there".

    Is this happening to you? Don't let your design ideas determine what code gets written.

    Full story

    Comments (0)

  • Agile Courage

    "Courage is being scared but doing it anyway"

    I'm not exactly sure where that quote's from but i don't really think it applies to scrum or xp.

    John started working at ABC company. He thought he was going to be part of an XP/Scrum team. Many of the questions he asked up front didn't exactly jive with scrum or xp but he thought surely if they say they're doing it, they're doing it.

    John got there on his first day and there was no scrum meeting, but he was stuck in HR's office filling out paperwork so maybe he just missed the engineering meeting that's no big deal. He went to IT and got his password and got logged into his machine. A few documents were stacked on his wall-facing desk and he began pouring over some domain definitions and diagrams. This is doing no good, he though, and he asked to be shown how to get into the code repository.

    Looking at the code, John became frightfully aware there was no Xp going on here. There were no tests, the code smelled of brittleness and over-complexity with it's lack of interfaces and use of reflection generated code in a multi-tiered mashup of WCF, remoting, and System.Net Sockets.

    John just got there, so he thought it was completely innappropriate to begin talking badly about the existing source code and it was also way to early to start griping about the management practices or engineering practices. After stewing about it for a while, he opted to just keep quiet until the scrum meeting, which would surely come on the next day, where he could more tactfully bring up his impediment.

    He quietly read his documentation and waited to go home. Upon arriving at day two he was greeted again with a lack of a scrum meeting and everyone went quietly to work on their own little project. Bill was working on service code while Jan and Sidney were pounding away at a demo UI for marketing to show off at the next presentation. Obviously there was no scrum at work here at all, nor does there seem to be an opportunity to express one's feelings about these impediments.

    Scrum meetings are the single most important thing i can possibly think of in Scrum. They are the opportunity to reflect on the very recent past, raise awareness to the very near future, and conjure up courage to 'cry' for help.

    Test driven design is in my opinion the single most important practice of XP because it enables every engineer to have the courage to change any code through refactoring because he/she KNOWS that this code has a test that is designed for it and every other piece of code has a test that will assert he/she has made a correct change and the system still works.

     

    Full story

    Comments (0)

  • Agile Job-Security vs "Finish or Fail you're still unemployed"

    I was discussing the implementation of scrum at a certain organization with a fellow employee today and we talked about the chicken versus the pig storyline. Of course the idea there is that a chicken is only involved while the pig is committed. We argued about the analogy for a little bit and my comment was that "Well a chicken can see a project to fail or succeed and either way will still have a job" and my years-wisened compatriot said with unwavering tone, "Well the developer won't have a job after they succeed or fail either".

    Maybe i'm naive in my youth in the industry, but I find it disheartening to believe that my co-worker would think that a successful project also means the end of his current worth to the organization, but does he have a point?

    I've previously been working at a staffing agency, and i see the daily ebb and flow of software development contract work that comes and goes, the miles long line of software developers and engineers who goes through the revolving door of contract placement. Juval Lowy says in one of his webcasts about SOA and project management that it's best to hire an architect and use a customer or proxy to design the system and the services that it will need then figure out a dependency graph of all of these services. Each service will be assigned a developer and should you only have one service that has no other dependencies then you hire just one developer. This means that for maybe months of design there will be no developers... then it would maybe start with 1 or 2 then ramp up to more depending on the number of services. Obviously as services finishes and dependencies are in place those workers can move on to another task. However, once all of the 'services' (which juval uses the term lightly to mean any component up to and including the UI) are implemented it sure sounds like you would discard the whole team.

    I think this is one giant reason that  Scrum is becoming more and more popular among developers, because scrum teams are always working on a product backlog for their project until funding is gone then they move on to the next product backlog until there is either:

    no more company

    no more scrum

    no more products to make

    Full story

    Comments (0)

  • Agile Time Management - Estimating User Stories

    I read User Stories Applied by mike cohn while i was in maui (don't make fun... i live this stuff) and when reading the part about estimating I thought:

     "I wonder if it might be better to take the peer pressure out of estimating by having the developers all face the same direction (towards the product owner/user proxy/user) and show their cards but not reveal to eachother what they estimated."

    Then the scrum-master/PO can ask

    "James, you're the highest estimate why did you choose that?"

    and then

    "Sally, you're the lowest estimate, why did you choose that?"

    then have them re-bid without ever knowing what the other person bid. I personally haven't done estimating with a team yet so i'm interested to see if this is even necissary or warranted.

    The reason being that, low bidders might come all the way up to the high bidder and the high bidder might go back down to the low bidder having known what their amounts were or other political reasons for 'following' someone elses estimate.

    just a thought... jetlag is killer.

    Full story

    Comments (0)

  • Policy Injection Application Block

    Earlier this year i watched a webcast on the PIAB (policy injection application block) but had sortof dismissed most of it because i didn't think it really applied to anything i was doing at the time. Of course, maybe i just didn't understand it well enough at the time.

    I decided to actually force myself to figure it out this time around because someone had mentioned to me the idea of interception and i had recalled PIAB using interception to do some of the things it does with 'policies'.

    I started out following along with the webcast and making a simple console application with a single business object in it. That code looked like this:

    //Have to inherit from MarshalByRefObject OR you could have an interface for any methods that you want to apply policy too
    public class BusinessObject : MarshalByRefObject
    {
       public void DoSomething(string input)
       {
          Console.WriteLine("I'm doing something");
          Console.WriteLine("press any key");
          Console.ReadKey();
       }
    }

    They mention in the webcast that there's a remoting proxy to wrap the objects, this requires you either use an interface or inherit from MarshalByRefObject (this i think is what enables reflection to create a wrapper at runtime.)

    Anyhow, setting up the actual console app is straight forward:

    class Program
    {
       
    static void Main(string[] args)
       
    {
             
    //we have to set it to use windows principle to make it use the authorization provider... change the identity from "desktop02\james" to your own machine\user setting and test.
          A
    ppDomain.CurrentDomain.SetPrincipalPolicy(System.Security.Principal.PrincipalPolicy.WindowsPrincipal);
    // here we're creating the object, we could just as easily 'new' it up then use PolicyInjection.Wrap<>()
          BusinessObject obj = Microsoft.Practices.EnterpriseLibrary.PolicyInjection.PolicyInjection.Create<BusinessObject>();
    //call our proxy object's DoSomething() method!
          obj.DoSomething("whatup");
       }
    }

    Nothing special, as i said.

    The actual config is where you get into adding the actual policies, and in this case i've chosen to attach an authorization policy and a logging policy. Obviously, you wouldn't want an authorization policy setup in your config file (maybe on the server side but definitely not on the client side). First i'll Setup the authorization policy. I opened up the App.config using the enterprise configuration editor and added a PIAB section. I added a matching rule and set it to match to a member and set that member collection to have 1 item in it. That item was of course "DoSomething".

    (I'm going to lazy it up and not have screenshots but i'll post the code for everyone to download.)

    Then i added an authorization handler and a logging handler.

    Then i added an authorization provider and an authorization rule. The rule required that i be identity "desktop01\james" to match my current user i'm logged into on my machine.

    Then i added a logging block section with a flat file log source (i think event log is a bad idea according to the 70-536 eventlog permissions open up all kinds of security issues so it's best to not depend on those permissions in an enterprise application... i choose flat file but probably xml is the best option these days. but i digest. )

    Once those things are in place in the config, you run it and it will require authorization and it will log all the information i asked it to! Very cool stuff!

     

    download the project for visual studio 2008

    Full story

    Comments (0)

  • Turning off auto complete on windows mobile 5.0

    Microsoft calls it 'Text prediction" i call it "completely stupid".

    I swear mobile 5.0s ability to predict "text that is almost completely the opposite of what i wanted" is amazing.

     

    Take for example this text message i wanted to send

    "thanks but no"

    with text prediction that becomes

    "thanks but notes"

    to support my claim above that it's 'almost the opposite' is that the opposite in this case would be "yes" but it clearly wasn't anything resembling "yes" either.

    "thank you for your time" becomes "thank you for your times"

    "go away please" is "go away pleased"

    I think the big problem is that microsoft expects people to use punctuation on the end of sentences... surely there's no one left in the known world who uses punctuation, is there? (whups)

    The second big problem, is microsoft is so big headed, they assume that what you typed is NOT what you wanted and automatically convert it to their first wild guessed ... but usually not until right as you're hitting the send buttoned.

    Unfortunately turning off "text prediction' inside "text input options" under "settings" does absolutely nothing for this auto complete featured. Someone email me if you know how to get rid of itself. My confused  recipients will thank yourself.

    Full story

    Comments (0)