My Crusade for Agility: Part 11

Welcome to the 11th installment of My Crusade for Agility. In my ten previous posts I've discussed just about everything I can think of relating to championing agile adoption at my place of employment. This is a very exciting installment because we just finished our first development sprint. We definitely have room for improvement. This week was a very unfortunate week to be ending a sprint, and maybe last week was an equally bad week to start one for lots of reasons.


The reason that this was an unfortunate timing for a first sprint is because:

1. We just got new hardware, so there was downtime setting that up.
2. I am taking vacation for the second half of the sprint, so we will be short-handed.
3. We are getting a new team member this week, so there will be some training and whatnot involved with bringing them onboard.

One of the first issues that I noticed with this sprint was that we "finished" all of our stories on the 7th day of a 10 day sprint. So our planning was off and we ended up without enough work to do... or did we? The reason that I say, "or did we?" is because of the second issue. The second issue is that besides the story and task cards we didn't have any acceptance criteria or acceptance tests so as we "completed" most of the stories they seemed to drag on and we continued to code even though the card's criteria was fulfilled. That seems like it could get dangerous because we, the developers, start to make assumptions about how things should work. Another issue is that now that all of the code is written, unit tested and deployed to staging it has not been QA tested.

QA testing is a very important thing that needs to happen. Since we finished the development work with 2 days left we, the developers, could take off our developer hats and put on QA tester hats, however developers don't make good QAs. I say that because if I write some code, then QA test that same code there is a good chance that I am going to be aware of the brittle bits and intentionally avoid them. The whole "switching hats" idea that I mentioned before starts to seem pretty waterfall-ish. We do not currently have a dedicated QA testing team member, hopefully we will one day.

I think our biggest issue that needs to be resolved, at this point, is our broken feedback loop between completing development and QA testing. The reason that loop is broken is pretty obviously a gap in staffing. There just isn't anyone at our disposal who can dedicate their time to quality assurance. Unfortunately, adding to staff is completely out of my control (not a responsibility that I want, btw).

Finally, because I'm going on vacation our retrospective is probably going to be delayed. I think it would be ideal to deliver all of the QA tested and signed-off-on changes sometime on the 9th day of the sprint, have the retro meeting that afternoon or on the morning of the final day then demo everything on the final day. That, unfortunately, is not going to work out this time (for me at least - maybe this is something that the rest of the team will do while I'm gone).

At the end of the day, and the end of this post, I think sprints are going to be a huge win for my team. Adding a full time QA team member would help improve our process significantly, but in the meantime there are plenty of things that we can improve. I plan to write more about our first sprint after we have discussed it as a team, so tune in next time for the 12th edition of My Crusade for Agility.

My Crusade for Agility: Part 10

This is the 10th installment of My Crusade for Agility. I began writing this blog at the beginning of September 2010 about 9 months after starting to work for my current employer. The reason I started this whole thing in the first place is that I saw three things in my new employer: passion, trust and willingness to change. Passion for software development that my teammates and I share, the trust of our employer that we will deliver the products that our partners need to succeed and willingness to change our processes and technology to better help us succeed.

Having said that, willingness to change took time, as did trust. From my employer's perspective, and my new co-workers, I was this new guy coming in suggesting a bunch of changes. I had plenty of software development experience, but not much real experience with the things that I was suggesting, which made it hard to sell. Test driven development, acceptance test driven development, pair programming, iterative development, user stories, continuous integration, and so on. These were all things that I knew about but I had not really done much of any of them in practice, but I knew people who had. Those people are the ones who really helped me get things going at my place of work.

I'm proud to say that with the passion of my team members, the trust of our employer, and everyone's willingness to change we have successfully become an "agile shop", whatever that means. But then again, who isn't? It seems like everyone claims to be "agile", but what does that really mean? I don't know, it depends who you ask. Some people will say that you're "agile" if you do TDD, others will say that you're "agile" if you work in iterations. Maybe it is both, maybe neither. What it means to me is exactly the definition of "agile" which is "ability to move quickly and easily". Adaptive is another word that I think describes "agile" development very well.

To me, the key concept of agile development is being able to continually meet changing business needs as quickly as possible or as they occur. Feedback is important, for software developers and for businesses. Software developers need to know that they are delivering what the business needs and the business needs to know that the developers are developing what they need. We all need the same thing, communication. As early and as often as possible.

As I discussed in my previous post, our communication was not really giving us feedback as early or as often as we would have liked. We have done a solid job of using TDD, ATDD, pairing, and CI, but we haven't really been implementing anything iteratively and getting feedback. This past Monday marked the start of our first 2 week development sprint. This is hopefully a technique that will allow us to deliver an amount of work to our partners so we can receive feedback.

At the end of the first week we have completed the development of 31 of the total 39 points included in our sprint. I'm very happy with that and actually extremely surprised. Not because I didn't think we could do it, but because I was out of the office one day, I left early another day, we got new computers (so we waisted at least a day setting up the new hardware), we did a bit of house cleaning because we have a new team member joining us next week and overall I feel like we have not done a very good job of sticking to the tasks on the story cards.

Not to say that we've been working on completely random or unrelated things, but we have definitely gone outside the scope of what we initially set out to accomplish. While it appears like we are going to get away with it this time, this is a habit that we will need to break for future sprints. One thing that I added to our white board is a TODO box. I just started posting things in there that I come across that are relevant and should be done, but are not necessary to complete the tasks at hand. My hope is that these tasks will be included in future sprints.

All in all, the first week has gone very well. With only 8 points left, I think we will end up making our sprint, which I did not expect for our very first time. I am on vacation next week, so I will not be around for the tail end, but I'm sure my team mates will wrap it up nicely.

I will write another follow up once the sprint is complete to fill every one in with how we ended up.  I also have a few other fun and interesting things to share, so tune in next time. Hope you've enjoyed my first 10 installments of My Crusade for Agility.

Language Exploration: Part 1

I went to college at Indian Hills Community College in Ottumwa Iowa, which I do not regret in the slightest. The Software Development program was outstanding and I'm actually fairly impressed by how the curriculum changes over the years. During my time there, one class in particular really stood out as the one class that taught me the most. This class was called "Language Exploration". The syllabus was simple, take a program that you wrote for one of your other classes and re-write the exact same program in 3 different languages. The reason why I thought this class was the one that I learned more from than any other was because this was one of my first experiences with learning new languages on my own. In this class I basically taught myself how to teach myself new languages.

At IHCC we were taught quite a few different languages which included C, C++, C#, VisualBasic .NET, COBOL, CICS, JCL, Java, PHP, and SQL. For a 2 year program that is quite a wide variety. After graduation I was hired as a COBOL developer and 2 short years later I transitioned to web development using Java and I also supported some VisualBasic 6 applications. During my stint with COBOL I was doing web development using the standard web stack (HTML, CSS, JavaScript) with PHP and Perl. Then I moved to a new employer and started using primarily Python and began a few side gigs using Ruby and PHP.

I've always enjoyed learning new languages. When I've moved from project to project there are certain things that get lost. After using Python for a while and not looking at any Perl code, going back and looking at Perl's data structures takes a few minutes to wrap your brain around (with all of the referencing/dereferencing). Moving between Java and Ruby is difficult because of semi-colons and return types. There are a million different reasons why switching back and fourth between different languages can cause trip-ups.

These little trip-ups are the reasons why I wanted to create a repository dedicated to language comparison. I wanted to recreate my experiences in the language exploration class on a larger scale. Instead of the class's 3 languages I decided to go with 16. My first task was to choose languages. I started with languages that I know, and languages that I've dabbled in then I added a few others that I've heard about but never really used. I decided to cap it at 16 languages for no real reason other than that is how many languages that I came up and seventeen just seemed like too many and fifteen just didn't seem like enough.

The languages are as follows:

• C (my code)
• Clojure (my code)
• CoffeeScript (my code)
• C++ (my code)
• C# (my code)
• Erlang (my code)
• F# (my code)
• Haskell (my code)
• Java (my code)
• JavaScript (Node.js) (my code)
• Perl (my code)
• PHP (my code)
• Python (my code)
• Ruby (my code)
• Scala (my code)
• XSLT (my code)

With a list of languages to work with, my next task was to write a "Hello World" in each of them. I opted to limit that to "Hi". So I wrote 16 programs that printed "Hi" to stdout, one in each of the above languages. That was pretty simple, so I decided to take on a slightly more challenging task. Here are the guidelines that I started with.

• Must print the nth number of the fibonacci sequence
• Must be a command line executable program that takes a single integer argument
• Must print the number from the fibonacci sequence that corresponds to the command line argument to stdout (including 0 so that given 5 the result should be 3, 6 should be 5 and so on)
• Must use recursion

That took a bit more time. Truthfully, the fibonacci sequence is fairly easy to implement using recursion in any of these languages. The hardest part was figuring out how to parse command line arguments and convert it into an integer. Erlang seemed to give me the most trouble here, in the end the solution was not all that difficult, I just had to figure out what it was which ended up taking a lot of time. XSLT was sort of a special exception rather than accepting the number from the command line it was parsed from an input xml file.

My long term goal is to continue to add new simple examples that show how a problem can be solved in each of the 16 languages, and hopefully I will be able to demonstrate some advantages that some languages provide over others.

If you care to browse the examples, please do https://github.com/mattjmorrison/polyglot. Also, I am absolutely not an expert in all of these languages, so if you are and you have some tips for me please submit a patch.

My Crusade for Agility: Part 9

Welcome to the 9th installment of My Crusade for Agility.  Just before starting to write this post I went back and re-read the previous 8, not to toot my own horn, but I think it was pretty good. I'm extremely glad that I had the foresight to write these posts as it was happening. Looking back, I would never remember all of the details and the order of events if I had tried to sit down and write everything all at once after the fact. Score 1 for iteration. So I'm going to go ahead and give myself a pat on the back, not only for the whole agile crusade but also the documentation of said crusade.

In past installments I have discussed a lot of different things. Most of which have centered around the introduction of agile software development to my current employer. It has been going extremely well. Our main code base just recently passed the 90% test coverage mark, which is exciting. We have started writing some acceptance tests using lettuce and we have over 20 automated builds which include not only testing and static analysis but also deployments. 

In Part 7 I mentioned that our workflow process needed work and that so far everything that I've tried so hard to introduce really has only benefited developers. This has pretty much held true until recently. I'll get to our workflow problem in just a minute, first I want to discuss adding value to the rest of the team (non-developers).  The whole team is made of up 6-7 developers and 5-6 non-developers (the non-developers are a combination of management, marketing and customer service). We do not currently have any formal business analysts or quality assurance team members, which is not ideal but we get by OK without them for now (we could definitely benefit a lot by getting both a dedicated QA and BA team member).

During a typical week every team member (for the most part) stays in their silo, either developer or non-developer. The non-developers do use the software created by the developers to troubleshoot and configure things for our customers, but the developers do not communicate much if anything about recent changes or things that are in progress. In a hopeful attempt to open up some communication between the devs and the non-devs I suggested that we start doing a weekly retrospective meeting with the whole team. 

In our very first retrospective the non-devs brought up the fact that we had some data entry screens that were extremely tedious and very time consuming. The following week we were able to demo an import/export feature that ended up saving days of manual data entry. We knew, as developers, that we had created a user interface that was very tedious to work with, but we had never really gotten any feedback complaining about it. These meetings have been very successful. They've given the developers a chance to hear what the customers are saying to our customer service team members and the customer service folks a chance to see what is in the works and what exciting new features have been added to make their lives easier. 

So, going back to our workflow problem that I mentioned earlier. In Part 6 and Part 7 I mentioned that we were using story cards and a white board to manage our (developer) work load. We were, but it didn't last. Our story cards basically corresponded to tickets that we keep in trac and the prioritization of the stories on the white board was pretty much non-existent. We probably spent more time working on things that never made it into trac or onto the white board than we did on anything else. 

Our problem was in the way that we were prioritizing tasks, we weren't, not in advance anyway. We would pretty much work on whatever the boss said to work on whenever he said to work on it. The major problem with this is that the developers are always having to ask "What's next?" and the boss is always having to figure out what is next whenever one of the developers asks, so there is more work for everyone to try to figure all of that out on the fly. Somebody always get caught like a deer in headlights. The boss would say, "What are you working on?". The developer answers, "Uh, um, I don't know, what do you want me to work on?" and the boss replies, "Uh, um, I don't know, I'll get back to you." and in the meantime nothing is getting done.

We've known for a long time that this was something that needed to be fixed, we have also known that the way that we were going to try to fix it was by doing development sprints. Our biggest problem here was that we didn't know what to do. We knew that we needed to dedicate some work to a timeframe and that is about the extent of it. Luckily for us, Trent from CDS Global, agreed to come to our office on a Friday afternoon and do some sprint training. He provided us with all of the missing info that we needed in order to get started. 

After meeting with Trent, we were able to do some backlog grooming to prioritize all of the work that needed to be done, followed by a sprint planning meeting where we created stories and scored them, and broke stories out into tasks. We decided that, as Trent suggested, we would create a theoretical story that we would score with a 1. Our dummy story ended up being something along the lines of, "Add a field to a web page and save it in the database". Using that as a reference point, we went through the backlog and wrote and scored 13 stories for a total of 39 points and decided that was going to be our first sprint.

Today was the first day of our first sprint. We've been going through the stories in priority order and we actually got 8 of the 13 done today. That might sound impressive, but those 8 stories only account for 9 points, so we've got a ways go to, which is a good thing considering that we've got 9 days left. I can already tell that this is going to be an excellent way to keep on track. My hope is that once we finish this sprint we will have a sprint retrospective (which will most likely be a separate get-together from our current weekly retrospective - we should probably work on calling them something different) so we can figure out how to improve our sprinting process, and also have a demo at the end so we can show (hopefully some customers) what our sprint accomplished.

I'm pretty excited about our first sprint. I think it is going to work out really well. I will make sure to post a follow up after our sprint because I'm sure you're just dying to know how it turns out. Tune in next time to hear more about My Crusade for Agility.

October 2011 Pyowa Meeting

The IMT Group will be hosting the October Pyowa meeting on Thursday October 6th at 6pm. As always, IMT will provide free food and soda.

Wes St.Clair of The IMT Group will be talking about Appy.pod which is a Python module that allows you to turn an OpenOffice document into a template.

Does anyone else want to volunteer to present a topic, demo something neat, or get some group help with something that has been causing you grief?

Are there any topics that you would like to hear someone else present? If so, please let me know and I'll see if I can line something up.

Even if you're not able to attend this meeting, I would still be interested to hear about what types of applications people are working on and how everyone is using Python.


I am still working on finding a good (free) solution for live streaming the meetings. Suggestions are welcome.

Look forward to seeing you on the 6th!