The In-Between Time

Within a year of my first agile project, there was a shift in leadership in the IT and software development organizations.  This leadership didn't fully understand or buy into agile development, so the implementation started to deteriorate.  At the same time, many of the advocates of agile development began leaving for other companies, so I found myself as the lone voice for the development practices and methodologies I had come to love.

Many people would probably ask why I didn't leave too, and it would be a fair question.  I liked the company and most of the people who worked with me, and I thought I would be able to push the organization back to agile practices.  I tried to stick it out and fight for all the right things.  Because of my tenure with the company and the projects I had been involved in, I knew the company and its business pretty well.  This experience gave my voice a little weight with the development teams, so I would encourage things like unit testing and small releases when opportunities presented themselves.

During this time, many new developers to the team would come to me for help.  As often as I could, I would try to sit side-by-side with them to work through issues, discuss design, and help them grow in their skills.  I learned how to adjust my communication to deliver ideas to different audiences*.  I also learned how to communicate new technologies and technical concepts to developers.  Even though we weren't following an agile methodology, I was growing and improving.

The company got into a mindset that it wanted to buy software to handle many of the big projects, and use custom software development to integrate the larger packages with each other.  I found myself doing a lot of maintenance work and being assigned to integration projects.  The integration projects were OK, but because of the personnel assignments, I wasn't heavily utilized.  The maintenance work was good because I exercised my unit testing muscles, but they didn't offer a lot of growth in new technologies.  As much as I liked the company and what it did, I progressed to the realization that I wasn't growing as much as I could be.

Even though I wasn't immersed in agile practices, I learned and developed quite a bit.  Skills such as communication, mentoring, unit testing, integration testing, quality testing, and learning the business would become crucial to success at my next company.

* This is still an area of improvement for me.

My First Agile Project

My first agile project was a re-write of an existing system.  The existing system was written in an early version of Java 1 and morphed as time passed.  It was a desktop-based application.  This re-write project was going to go through a full requirements gathering phase, design the application for scale, integrate it into the existing ERP system, and put it on a newer Java 1.2 system.

I joined the project part-way through the requirements gathering, and participated in many of those meetings.  These meetings were quite often contentious.  Many people had many opinions about what the new system should do and how it should do it.  Most of the people from the IT team were worried about the project.  The senior architect suggested that we use a new approach called Extreme Programming to deliver the system, hoping that the new approach would address many of the concerns.  I eagerly read the first Extreme Programming book, and got very excited.  The author spoke directly to all of the problems I encountered during my first internally-focused project, and his suggested approach made a lot of sense.  We were able to convince our management to let us try it.

We set up an area for the project team to work.  It contained open tables with shared computers.  Everything was arranged to make it easier to do paired programming.  The machines were configured identically so that it was easy to move around.  There were about six developers assigned to the project, along with a DBA, project manager, and architect.  We also identified a business user that would be available to test the system and answer questions.  With everything in place, we jumped into the Extreme Programming approach.

I don't remember how we prioritized the requirements, but we had a list of stuff to attack in order.  At every iteration boundary, the group would gather together with flip charts for planning.  We would write a feature/requirement at the top of the flip chart, talk through the tasks needed to accomplish it, and put estimates to the tasks.  We hung the completed sheets on the walls around our meeting area.  After several requirements had been planned, we picked what we thought we could get done in an iteration.  Those charts were moved to the walls around the programming area for the team to see.

Every morning the team met for stand-up, and talked through who would work on what task.  If there were any major roadblocks we talked about them, and tried to align the pairs to knock out the road blocks.  If there wasn't a particular pairing necessary for the tasks at hand, we picked pairs based on who was available and who had a task, and started our day.

The pairs worked side-by-side in the pairing area.  The keyboards and mice would move back and forth as pairs alternated coding, and if a pair got stuck, they would ask another pair for help.  Coding went fairly smoothly and efficiently.  Occasionally some personalities would clash, but either the project manager or architect would help defuse the conflict.  This was one of my favorite times writing code because it was productive, efficient, and the camaraderie was great!  Our progress through an iteration was tracked with burndown charts plotted on a big flip chart on the wall.

As features/requirements were completed, we brought the business user over to test the features.  Any identified bugs were addressed right away, and the user would test again.  We typically brought the business user over as features were completed; we didn't wait until the end of the iteration.

This project progressed well until we came close to a busy season in the company where the original tool was used heavily.  The company wanted to use the new tool for the upcoming busy season, which pushed us to work longer hours and aggressively trim scope.  Ultimately, we delivered the first version of the new system to the team that needed it most for the busy season, and brought other teams on board over the coming months.

Being a first agile project was difficult for a few reasons.  First, the rest of the company didn't understand the agile approach, and put a lot of pressure on the team to do things differently.  Second, the team was learning a new approach, which made it difficult to communicate with the rest of the company and each other.  Lastly, some of the team members hadn't bought into all of the Extreme Programming practices (most notably unit testing), and that difference sometimes caused more friction on the team than was necessary.

I view this project as a success!  The company got a system delivered when they needed it.  The applicaiton was very well designed and well written.  The team of developers gelled pretty well, and continue to stay in touch with each other even though everyone moved on from that company.  It also solidified for me the importance of culture within a development team, as well as how many of the agile practices influence the quality of software.

Now it was time to mature our practices and move them forward.

Becoming an Agile Practioner

As I have brought new people on to my team and taught them agile development, I have either told stories about my evolution into agile development, or reflected on it.  I keep thinking that it would be a good idea to document that evolution before the details become any fuzzier than they already are.  So, that's what I'm going to do.  This first post lays out my background and what led to me getting introduced to agile development.  Future posts will document my practice of and progress through agile techniques.

Backstory

I started my career in software development creating imaging systems for customers.  The team I was on consisted of software developers and system/network administrators.  We took on discreet projects setting up, maintaining, and creating imaging systems based on software provided by a vendor.  Some of our projects were nothing more than equipment setup and installation, while others involved complex software systems that we developed.

All of our projects implemented a version of the waterfall methodology.  There would be a requirements gathering phase that resulted in a contractual statement of work.  The tech team would then design the system based on the requirements, create it, test it, and when possible, test it with the users before delivery.  Some members of the tech team would then deliver the system, which often involved hardware set up as well as software installation and configuration.  The project "leader" would then take the customers through a formal User Acceptance Test and get an official sign-off.  At this point, the project was in a maintenance phase.

The majority of projects that I was involved in using this approach were highly successful.  Since this was my first job, it was the only approach I knew.

After a couple of years on this team, I would quite often be involved in leading these projects and seeing them through to completion.  I knew the software and approach very well, and I was enjoying success as a result.

While on a trip to a client sight, my boss informed me that he was leaving the company to start his own business.  The resulting transition moved me onto a team focused on internal software development projects using a completely different technology stack.  Needless to say I was a bit lost!

I was given a few small projects to tackle, and I struggled with them.  Not only was I trying to learn a new technology, I was also trying to understand what the team was trying to accomplish and for what reasons.  With so much in flux, I needed to establish some consistency to maintain my sanity.  I turned to the tried-and-true methodology for delivering software that I had used previously.

At first, the waterfall approach seemed to work well.  I was able to get a definition of requirements, and could design the system.  Myself and another developer from the previous team worked to create the system in question, and eagerly set up a User Acceptance Test to show it off.  This is the point where things came off the rails.

The stakeholder liked what we had done, but added several additional requirements during the test.  This was not uncommon, so we satisfied the requests and re-did the test.  Again, things weren't quite right.  We did more work.  We showed it off again.  We went through several of these cycles, eventually getting the system to a point where it could go into production.  We never had the same sense of accomplishment that we had with our previous waterfall projects.

It felt like the tried-and-true methodology that I had come to rely on had utterly failed, and I could not stop analyzing what I did wrong.  I struggled to contain scope and keep the internal stakeholder pinned to a set of requirements.  The code drifted out from under us as the scope moved.  Worst of all, we didn't have the great sense of accomplishment from a truly successful User Acceptance Test.

I struggled most with two aspects of the project.  First, I could not control scope for the life of me.  Without a formal contract of any kind, or any leverage with a VP of the company, scope moved every time the VP saw a demonstration.  Second, I found it extremely difficult to design and code a system using a new technology stack under the confines of a waterfall approach.  I didn't feel like I had the leeway I needed to experiment and learn what needed to be done.

At this point, I turned to an experienced software developer in the company for help.  The developer introduced me to the original Extreme Programming book, and thus began my journey as an agile software developer.

Calculator Exercise

Calculator

A long time ago when I was doing Visual Basic development, I create a programming exercise that I used to help teach new developers Visual Basic.  The program is a simple calculator.  It allowed me to teach people how to create VB forms, add and manipulate controls, and write some logic that needed data from the UI and had to put data back into the UI.

This project was also great for teaching a new language because it wasn't dependent on databases, file systems, or external APIs.  I have recently re-created this exercise for a new developer on my team, and for myself to work on learning Javascript.  So that I don't have to re-create this again, I'm writing up the project here so I have it.

Exercise

Create a calculator that can do basic arithmetic with two operands.

• The calculator should have a display area.
• The display area should show zero if no number has been entered.
• Once a number is entered, that number is displayed.
• Once an operator is selected, the number displayed should be zero until the next number is entered.
• Users can enter numbers by clicking the number buttons, just like a physical calculator.
• The user should be able to use digits 0 - 9 and the decimal point.
• The basic arithmetic operations of addition, subtraction, multiplication, and division are allowed.
• Integers and decimal numbers can be entered.
• The user should be able to click a "clear" button to reset the operation and empty the display area.

UPDATE:  Here is my HTML/Javascript implementation:  https://github.com/haled/CodingTraining/tree/master/gui_calculator.

Recently, David Heinemeier Hansson (DHH) published a blog post stating that TDD (Test Driven Development) was dead.  A member of my team found the post, and sent it around to the rest of the team.  Here is my take on the article.

I think DHH is laying at the feet of TDD much of his bad coding habits.  The thing I think people miss with TDD is that there has to be some concept of a larger design before you can write the first test.  Without that, it is difficult to know where to start.

When my team starts a new project, we try to find a "single thread" through the project that allows us to explore the overall architecture, define the technology to be used, and deliver some functionality to spur further conversations with stakeholders. This "single thread" is typically our first user story, and it helps us define a small-scale roadmap for the effort. We then let the unit tests drive the design so that we don’t build coupled, complex systems as we implement the roadmap.

While I can see how it is easy to blame TDD for come becoming unwieldy (I've seen it happen with my team too), I don't think it is the root cause of that problem.  If anything, TDD prevents the code from becoming absolutely unmaintainable, even as the architecture strays.