Winging It

Cucumber Is Not A Qa Tool

2011-12-15T00:00:00-08:00

Cucumber Is Not a QA Tool

In my recent travels, and they have been plenty, I have come across some interesting views about Cucumber.

In one conversation someone was looking for "QA people with Cucumber experience." I thought that was pretty cool, they want some testing folks familiar with a rather popular test framework. Then came the second sentence, "I really don't know what cucumber does, but I know that QA people need to do it." (Yes, this person was a recruiter, if you couldn't tell by now.)

Contrast that with conversations with management and leadership types who don't know what cucumber is, but as you explain it you can see the words scrolling across their foreheads, "If we use this, I can lay off half my QA people! Cost savings!!"

Now, I can not totally discount both points, there is a little merit of truth in each one of them. In the first case, a QA group that knows and understands Cucumber can be a great asset to your product team and the long term quality of your product. Additionally, once Cucumber is in place it will free up some QA departments from doing repetitive manual tests and allow them to focus on more exploratory testing.

However, if you consider Cucumber to be only a QA tool, you are missing a good portion of what this and other Acceptance Test Driven Development (ATDD) or Behavior Driven Development (BDD) frameworks can provide.

Note: From this point forward I will use BDD in the discussion. BDD and ATDD are very closely related, almost indistinguishable in practice. I learned the phrase BDD first, so I tend to stick with that. And for writing purposes, it is one character shorter, thus promoting my natural laziness.

Collaboration

The biggest benefit to employing Cucumber, or any BDD framework, is that it tears down a lot of the communication walls to which we have become accustomed. Specifically the Gherkin syntax of Given/When/Then helps bring down those walls by writing acceptance criteria in a plain text format that everybody can agree on.

From the business's standpoint, finally being able to communicate to the development and QA teams in a clear manner has to be beyond welcome. Being able to work with multiple team members and arrive at something for the delivery team that says:

Given the customer has an item in their shopping cart
When the click the checkout button
Then I will have more money in my bank account

No more reams of documentation around a simple feature with wire frames, UML diagrams, feature documents, and other items buried in a wiki somewhere that gets ignored. Plain text is easy, and in my experience the easier something is to use, the better chance you have of it getting used.

Now from the QA person's standpoint, we have actual acceptance criteria that let us know if a feature is complete or not. No more vague language that allows room for interpretation where I can inadvertently add more functionality to a feature because it is what I think the user might want someday. Maybe.

Finally from the developer's standpoint we have features with an end point and a better description than, "Customer checkout feature." And not only do we have more clear, concise feature descriptions, when we are done writing code for the features we have a set of tests that will execute against the plain text features.

Build What We Want

Cucumber benefits all aspects of the business, but possibly its greatest benefit is that it allows us to easily agree to what "done" means for any given feature. The definition of done for a feature won't change over the life of the project, or if it does change we will have a broken Cucumber spec to alert us that we have changed our mind somewhere. But by having that agreement of "done" in place up front it frees up the developers and testers to focus on specifics of implementation and verification of the feature without ambiguity.

Developers of many languages keep a set of unit tests handy that will break if they make a change to existing code. It may or may not be an intentional break, but the point is they have a safety net to catch a logic change. A suite of Cucumber tests has that same watchful eye over your application as a whole, rather than just at the class or method level. If the business changes how a feature behaves and a cucumber test goes red, then the collaboration can kick back in across the whole team and the team can decide how to handle the original intent of the feature with this new feature request.

In short, we have a living record of what "done" has meant to every feature we have developed over the life of the project. By executing tests against those acceptance criteria, we also have a constant check that "done" for existing features remains done.

Cucumber Helps With Quality

So while I don't think Cucumber is a QA specific tool, it helps with overall product quality. By providing a good place for collaboration and by helping the team define "done" early in the feature life cycle, quality has become a first class citizen to your team. Quality is a whole team goal, not just members of the QA team. (By definition, people on the QA team assure quality, they don't build it.)

If you are not using Cucumber or another BDD framework, I would highly recommend looking into using one. However, look into those tools for the benefits they can bring your whole team not simply as a QA tool. And while they will help alleviate some manual work for the QA folks on your team, Cucumber is no replacement for a human being who can dive into the application in ways you never thought of when laying out the acceptance criteria.

After all who would you rather have exploring your app and poking around looking for things to go wrong?

Your QA team?

Or your users?

Kanban On The Factory Floor

2011-11-01T00:00:00-07:00

Kanban on the Factory Floor

Over the last few years I have done a fair amount of work with Kanban on software teams, but recently I got to see Kanban in action in a factory. Knowing that the Lean software movement was born in manufacturing, it was very interesting to see Lean and Kanban in action on a factory floor.

Some quick background details before we get too much further. At the request of my client, I can not share what was being manufactured (or who my client is). What I can say is the items they build are large. Large enough that they need to be separated into pieces to be loaded on to a semi trailer to be shipped. Sometimes multiple semi trailers are needed to ship one item. Steel is the principle material used in the manufacturing, so there is also plenty of cutting, welding, pressing, and painting going on to go from raw steel to completed product being shipped to the customer.

The building itself sits north to south, with the north end being shipping of the finished product. The south end of the building is where the raw materials are received, so the product moves south to north through the building to become a shippable product.

Factory Floor as a Kanban Board

The first thing that jumped out at me upon touring our factory was that the entire building was the kanban board for this particular product. On a software project we will determine our value stream and write it on a whiteboard. These are the steps our features will work through from concept to cash. In a factory, there is no whiteboard with columns on it. Instead there is the factory floor with overhead cranes, welders, and paint booths.

This idea of the factory as a Kanban board is pretty easy to see when you are looking at it. In an attempt to explain it, the south end of the building has stacks of steel with other supplies nearby in a storage area. The factory is run pretty lean, but they still need a supply of welding materials, nuts, and bolts.

The steel begins its journey north through the building by first being cut and shaped. It makes a stop at a plasma cutter, then some of it will move into a huge hydraulic press to be bent into the correct shape. From there it moves into the welding booth where robotic welders make the standard welds. Any custom welding will be done by hand at the next station. Following welding, the product is essentially put together and the finishing touches start by going through a cleaning process then into the paint booth. Once it is painted the only thing left to do is get it loaded on a truck to get shipped to the customer.

That is a pretty abbreviated version of the process. But from a Kanban standpoint once the table under the welding robots is available, a sheet of steel slides in there. Same with the multi-ton hydraulic press. If it has capacity, it has steel being pressed. The steps of the process are not arbitrary, they are physically located to the north of the step that precedes it.

Lean and We Mean It

On the Lean side of things, there is no inventory. Once an item starts getting produced, it has already been sold. There really is no room to keep one or more of these products just sitting around waiting to be sold. It is not a practical solution for this particular factory.

On the other end of the spectrum, there really is not any room for a large amount of surplus steel to be stored, either. If the steel shows up at the south end of the factory, it will go into production pretty quickly in an effort to get it into its customer's hands.

Once again, there physically is no room in the factory to hold excess steel for that "just in case" order that comes in from the field. Nor is there room to hold any extra finished product at the north end of the factory for that "emergency" client.

Work In Progress Limit? Um, Yeah...

On the software side of things we struggle many times trying to enforce our Work In Progress Limits, or our WIP Limits. Many times if we need one more thing put into development or testing, it is just a post-it note...put it in there! Stick it on top of that lesser post-it note if you need the capacity.

Let's take a look at that same situation in our factory. We have a new order that just came in, and it is an urgent one. Yeah, I know we already have 8 tons of steel being welded by the robots, go ahead and put another 8 tons of steel on top of that and get it done first.

Seems a bit silly, doesn't it?

Once again, the physical limitations involved with moving, shaping, and welding tons of steel comes into play. It makes enforcing WIP Limits pretty easy. Only one thing can be cut, welded, or painted at a time. If an "emergency" comes into the queue, it has to wait its turn, there really is no room for it.

On a software team, that limited capacity is just as real, but it is much harder to visualize. It is very easy to see a paint booth full to capacity, not quite as easy to look at two developers and two testers and see that those four people are already running at capacity with the work they have been given.

What We Learned

I have enjoyed working with Kanban in the software industry, but it was definitely worth seeing it working in manufacturing to see the differences. For software teams the idea of limiting work in progress is a great goal, but clearly much more difficult to visualize than it is in manufacturing. My biggest takeaway from seeing Kanban in action in a manufacturing setting was that WIP Limits are easy where there is physically no more space for more work.

The discipline needed in the software implementation of Kanban to enforce WIP Limits and keep queues from building up is more than a number on a white board.

Going Independent

2011-10-20T00:00:00-07:00

Going Independent

I have made a few career moves over the last 24 months, but I have finally gotten to the point where I can go off on my own. I guess more correctly, I finally got the courage to pull the trigger on going independent. So October 28th will be my last day as a full time employee with Pillar.

I am looking at doing more agile coaching and training as I move forward, but banging out some code will never be far away. Making this move should free up some time to explore some other opportunities that have presented themselves, and opportunities that have as yet come knocking.

It's not going to be a big shock to the system as my first job as an independent will be helping my current team transition on a couple of new team members. So, day one as an independent developer, off on my own in a scary new world will be in the exact same chair in the exact same room that I occupied the Friday before as a full time employee.

Ironical.

I would love to go off and list all the folks I have to thank for getting this far, but I would end up leaving somebody out, and they would get all upset, and it would just get ugly at some conference somewhere. I would like to thank my family, Wendy, Brendan, and Alex for their constant support.

Iterations Are Not A Deadline

2011-09-06T00:00:00-07:00

Iterations Are Not a Deadline

I have worked in iteration based systems for years. I have worked in one week and two week iterations. (I have heard tell of people doing iterations measured in months or quarters, which scares the bejeesus out of me.) I have also worked on teams where we have gotten rid of iterations all together because they did not make sense for our situation. Those teams were Kanban teams and we valued continuous flow over the choppy stop, start, "slam QA on Thursday" that iterations can sometimes become.

At a recent conference I overheard a conversation between a colleague and an attendee. The colleague in this case had just given a seminar on Kanban that this particular person had attended and had a few follow up questions. The first few questions were pretty mild, then it happened...

"How do you make Kanban work without the pressure of the iteration to make your developers finish their work?"

That one fired me up. I did not dive in the middle of the conversation red faced and shaking my finger in this way-too-obvious-project-manager's face. Instead, I did the next best thing, I unleashed a strongly worded tweet.

"We need that by, um, Friday"

The first issue here is we have no proof that a deadline forces a team to deliver anything. It might give the illusion that the team beats a deadline, but under the covers somewhere there is an issue. Think back before the salad days of agile when were waterfalling ourselves against massive deadlines, ever move a deadline?

I was on a team doing two week iterations and the second Friday was the end of our iteration. On normal days the team room was emptying out by 4:30 every afternoon, by 5:30 there might be one or two people there. But on every other Thursday it was full until 6:30 or 7 with the last person leaving closer to 9. Why? They had a deadline to beat. Did they get their work in? Usually, yes, but they were hiding the real problem. They were beating their deadline, but they were working hidden OT to do it, taking time away from home, and hiding the real issue from their Product Owner.

I am sure a few people are thinking, "Hey, Tim, they got their work done! Every iteration! They were heros to company!" Those of you thinking that, I say for shame. OK, I do not say for shame, but I do say that they stretched their time box in an effort to appear successful.

An iteration at its core is a time box. It is a fixed amount of time in which we will try to get as much high quality, well tested work done as we can. As a team, this group had agreed to do two week iterations with an iteration day for retrospective and planning. They had agreed to do 72 hours of development and testing, and every other Thursday they were stretching that to 75 or 80 hours. So maybe they did get the work done, but they had broken their agreement - with their Product Owner, and worse, with themselves - to get that work done.

We have all heard of the iron triangle of software development, there are three points of the triangle of time, scope, and quality and only two of those points can be fixed. We like to operate on quality as a fixed point, so pick time or scope and make it variable. An iteration says time is fixed, but all too often it becomes variable because of fixed scope by the end of the iteration.

Use the Time Box

As noted above, the iteration is meant to be a time box. A start and an end to some amount of work. At the end of that time box we hold a retrospective to learn from the previous block of work.

What went well?

What did not go so well?

What went great?

What does the team never want to do again? Ever.

This is the time to learn about your team and make adjustments. If all the work got done with a whole day left in the iteration find out why. Yes be thrilled that all the work got done and your team is awesome, but we still need to learn WHY it happened and WHAT we can do to leverage that in the next iteration.

Now let's say the team did not get their work done a day early. Instead a couple features did not get completed. I am sure we will be asking WHY in this case. Maybe this is the third or fourth iteration in a row some features did not make it to completion. We could say that our team is terrible and they should type faster, but we are seeing a pattern here. Two things jump out at me right away in this situation: Are our stories too large? And are we taking on too many stories per iteration?

If we are taking on too many stories or a few stories that are sized, shall we say, aggressively then start trimming them down a little. Take on less work at the beginning of the iteration in an effort to be successful at the end of the iteration. A team that knocks out its work by the end of the iteration - WITHOUT working until midnight the day before the end of the iteration - will be all smiles at the retrospective.

One bonus to not crushing the team, aside from the obvious good team morale, is you will build some slack in for the team. Any dev team needs a little slack, and not just to shoot nerf darts at each other. Slack allows the team to refactor. Something that was trouble two iterations ago probably needs some attention to keep it malleable for future features.

Slack allows for innovation. Giving the team time to step back and look at features together allows them to find better ways to solve the problem.

Slack allows the team to breath and it keeps them from rushing through problems. The old adage "Haste makes waste" is not more true than in software development. Rush through a solution and you can expect bugs to be opened, leading to more rushing, then bugs, then rushing...wash, rinse, repeat.

I've Read This Somewhere Before...

Agile is about continuously learning, no matter what process you are using. You should be learning more about your team, your product, and your problems every iteration. Every day.

Agile Manifesto line four: "We value responding to change over following a plan."

Iteration deadline: plan or time box?

Katas For Teaching

2011-08-31T00:00:00-07:00

Katas for Teaching

While recently bringing a team up to speed on Test Driven Development (TDD) in a very short time frame we leveraged code Katas as a teaching tool. The Kata approach is to use a simple code exercise and repeat it a number of times to practice the act of writing code rather than the act of solving the problem. In fact, “getting done” is not usually a requirement as Katas are typically time boxed activities. By repeating the problem you spend less time on the solution and more time on your craft.

We got to spend two weeks going through two different Katas with the team. At the end of those two weeks they had definitely learned some new things and had strengthened their approach to TDD. The team also struggled in some areas at the end of our practice time, some of which was attributable to their teachers. We had more things to work on during these exercises, so we did not get to be full time proctor every day.

Day 0 - Roman Numerals: The other coach and myself did the kata using ping-pong pairing, where one of us would write a test and the other the implementation. We did this on the projector to demonstrate TDD. We stressed doing the simplest possible thing to solve the problem, and that changing code that has already been written is part of the practice.

Day 1 - Roman Numerals: Today the team got to dive into their first kata, and they did group pairing on the projector. Again we stressed the “simplest possible thing” which was illustrated pretty well with a line of return 1 to solve the first step of the Roman Numeral kata where “I” is the input.

Day 2 - Roman Numerals: Again the team did the Roman Numeral kata where they were taking in a string of Roman numerals and returning the correct integer value. Today we switched up the focus a bit and looked much closer at refactoring code rather than getting closer to a solution. We spent enough time on refactoring that we did not solve the first subtraction case of “IV.” The team got a pretty good look at refactoring this way and it also helped us stress that the Katas were not about solving the problem.

Day 3 - Roman Numerals: The third day was essentially a repeat of days one and two. The two of us coaching the team stayed out of the way on this one and let the team direct themselves. They combined the first two days by getting further with the solution, but also doing a couple of refactoring steps to keep the code clean. The biggest change today was we stopped using the projector and group coding, and instead had them split into pairs.

Day 4 - Roman Numerals: Day four saw us throw monkey wrench number one into the works: Flip the Roman Numeral problem and take in an integer and return the correct Roman Numeral string. I had forgotten how much more difficult this approach to the problem can be, and it slowed our teachings quite a bit as we collectively became focused on the problem and not on the practice.

One good thing did come from switching the problem up to something more difficult, it got the team lead to ask the age old question: “But TDD takes longer, why do we do it?” After the team lead got a straight answer of, “Yes it does,” he seemed to really tune in. After explaining that we will happily trade a little time in initial development for a lot of time during product maintenance, the entire team was nodding in agreement.

Day 5 - Roman Numerals: Our last day of doing the Roman numeral kata and we went back to the regular way of doing the kata from days one, two, and three by taking in a string and returning an integer. For today’s fun at the halfway point of the kata we had everybody get up and switch pairing stations. This was a way to show that you will inherit somebody else’s code as a project goes along, and with the team all taking the same TDD approach it will be easy to see where the previous pair had left off and what move your pair could make next.

Day 6 - Game of Life: For our next kata we switched to Conway’s Game of Life (GOL). This is a tried and true kata, and though I thought it was quite a jump in complexity for a simple kata, I was sure we could carve out just enough of it to continue on the path of Red, Green, Refactor that we had started with the Roman numerals in the previous sessions.

The first day of the GOL was definitely focused on solving the problem, but that was understandable as it was a new problem and it needed to be solved once before you could delete it and practice solving it again. The team regressed a little from their solid TDD approach from the previous week. Again, not surprising as teams will fall back to “what they know” when things get a bit more difficult, which in this case was trial and error implementations. It was not a total regression as there were a few unit tests written by each pair.

Day 7 - Game of Life: Day two with the GOL went much better. The problem solving was basically over, so focus went back to TDD and refactoring much more. We had to have a few reminders for “simplest possible thing” again as a couple of pairs were implementing nested loops to simulate the game’s canvas when the instructions were to ignore the canvas and focus on the rules for the cells to be living or dead. Once brought back on task they got back to good TDD practice and implemented the four rules for the cells.

Day 8 - Game of Life: Day three with the GOL and we added the canvas concept to the list of rules and how many cells should be alive on that canvas to start and that the group would progress at least one generation. They were to do the practice from the previous days with the cell rules and expand on them with all the new rules. Yes, we took them from 0 to 60 took quickly...and the exercise showed it.

We had one pair not even implement the rules for a cell, instead just started hammering out loops to build a canvas. Another pair focused completely on getting the output of 0 or 1 correct. A third pair did not throw away the code from the prior day, so they already had the four cell rules implemented. Though that was “cheating” just a little, the bigger issue was that they were not even going to use the already written code.

As the third day of GOL shook out, we got most of the pairs back on track, but it took the white board, some coaches jumping in to pair for a bit, and a lot of “Do you have a test for that?” questions. It was definitely a big jump, but in the end things were again progressing in the right direction.

Some lessons learned from this particular day: 1. We added too many rules too quickly. 2. When you are new to something, and in novice mode in the Dryfuss Learning Model, then you want specific rules to implement. By giving the team new specific rules, they hedged directly towards implementing them and ignored building on the prior days’ code. 3. On the coaching side, we totally missed on building on the previous days’ exercises. 4. Like our change in the Roman Numeral kata on day four, adding these rules changed the exercise once again to a problem solving exercise.

Day 9 - Game of Life: For our last day with this team we lowered the rules back to a more sane level which again allowed them to focus more on the practice and less on the problem. This helped as we saw unit test counts rise with each pair and better focus at completing smaller steps rather than trying to solve the whole thing from the start.

Lessons Learned

Katas are a great way to teach, and the changing pairing stations exercise was a lot of fun. But you have to keep the focus on the practice not on the solution. Keeping the problem simple early will allow more focus on the practice. When switching problems, be sure to take the solution in small steps so the focus can remain on the practice.

Be clear in the rules: Deleting the code before you start. Red, Green, Refactor. Solving the problem is not the main goal. If you have the time and availability, be a full time proctor. Watch for pairs having issues, or the whole group struggling, and try to get them back on task sooner. If a team is new to TDD that will usually mean stressing the simplest possible thing and asking, “Do you have a test for that?” often.

I have been through a couple of code camps where we practiced for a few hours and have done Katas myself at Code and Coffee a number of times. But this was the first time I put them to work as a teaching tool over the span of days and can say I was really happy with the results. Even with the goofs we made, we still got the team a long way with TDD in a very short time.

Coaching In India

2011-08-11T00:00:00-07:00

Coaching in India

My client has an offshore team in Coimbatore, India and I recently spent three weeks there working with them. This group of people is about to become the other part of our development team on our current project. They are joining us, merging their code with ours, all working towards completing the project -- we need to become a team and getting the 8,000 mile wall out of the way was step one.

The People

There is no process, no technology, no framework that can lead your project to success without the right people. I had no expectations, good or bad, for this group prior to leaving. I had met the team lead as he had traveled to the US for a week, but I knew very little about the others. (Todd has a great post summing up his thoughts from the trip. I highly recommend reading it.)

What we soon discovered was this group was very excited to learn what we were doing. And not only what we were doing, but why we made the decisions we had made. We had already done four months of development so a lot of the groundwork was laid before they saw the code the first time. Unlike standard Ego Driven Developer who would take one look at the code and respond with, “This sucks, I can do this better,” these guys had already dropped that attitude (or never had it) and were ready to learn what was going into the project.

The First Few Days

The first 2 or 3 days were spent having conversations and finding where everyone was comfortable. Many conversations took place about application structure, domain knowledge, and general practices of the team. It as almost a mini two-day conference that was just focused around our application.

Also in the first few days the team was very excited to show us the features they had completed prior to our arrival. The code looked fairly clean, but there were a few changes to be made, so they excused themselves to make the changes. Later we figured out why they wanted to leave the room: There had been a large amount of copy/paste development done, and they were still struggling to figure out what this copy/pasted code was doing.

One thing to note here, they had created cucumber features, and those cucumber features were green. Before we think they had just copied, pasted, and said “We’re done!” they did have acceptance criteria, and they had put those acceptance criteria to work in the form of automated cucumber tests. So even though the code needed some refactoring, and it needed some better unit test coverage, if we would have had to ship the application the next day, their features were functional and developed to our agreed upon acceptance criteria.

The Task

With the initial conversations out of the way, the task at hand became much more clear. We had a team of talented problem solvers who thought well in C# and general patterns who needed to be brought up to speed on the practices and tools of our team. Essentially we were down to 12 business days to teach TDD, give a clearer understanding of BDD, get them up to speed on mocking, and get them more comfortable with the ins and outs of git and github.

If this was an infomercial, I believe this is where I would say, “What would you pay now?!?”

Don’t answer yet!

The Tools

Step one was to get some in depth TDD going. The best tool here is the daily code Kata, so we started with the Roman Numeral Kata and Todd and I took a ping-pong pairing approach through the first day as a demonstration. (Ping-pong pairing: one of wrote a test, the other made it pass then wrote the next test. Wash. Rinse. Repeat.) The next day, they did the ping-pong approach through the same problem. Everyday for the rest of our time the team paired on a Kata, switching pairs daily, with step one being to create a new dev branch in their local git repository. (We were using this empty C# project for our katas every day.)

The Katas did a good job laying the groundwork for doing TDD on the features that the team was going to work on while we were there. We did a lot of team coding with the projector so we could collectively work our way through the features. As coaches we were guiding rather than ordering which allowed the team to make and correct mistakes.

The second exercise we used almost daily was plenty of refactoring. Todd found a sample of some horrid code online that he converted to C# to use as an example for practice. Todd lead the exercise using some simple refactoring rules such as watching out for duplication, nested if statements, large methods, and multiple parameter methods.

After the introductory refactoring exercise we opened up the features the team had already written and started refactoring. Following the simple refactoring rules Todd had used previously the team went about refactoring their own code. In the first session one of the guys on the team got to delete about 40 lines of code and insert 2, and there were smiles all around the team room as he was doing it. One of the tallest hurdles as a developer is deleting code you have crafted, but this team was deleting it and enjoying it.

By the time we left the team had refactored all four of the features they had been assigned. Most of the refactoring was done as a group, with a different person at the keyboard each day, to help teach what it means to refactor code. Our last week there the team had taken the initiative on refactoring and I returned from lunch one day with a request to do a code review of their most recent refactoring work. Once again, lots of smiles in the room.

The Results

I was surprised how much we got taught in such a short amount of time. By leveraging as many exercises as we could, and doing as much hands on as possible, the team picked up the basics of TDD, BDD, and refactoring. We left a wiki full of cheat sheets (or “bits” as such documents are known to our Indian friends) as reminders for all the exercises we had done, and for some other concepts such as our git workflow and some nHibernate tips.

However, without a group willing to learn and do the work of learning we would have never gotten so far. So a huge credit needs to go to the team for the work they put in to the crash course we were teaching.

Will they stick with it hard core? I doubt it, most teams will revert to “what they know” when the heat gets turned up. But I think this group will be pretty easy to influence back to their new practices...even from 8000 miles away.

Estimation Rant Part Two

2011-06-16T00:00:00-07:00

Estimation Rant Part Two

The Estimation Rant opened the can of worms on estimation. This topic is always a good one on software teams and is sure to drive opinions and discussions around those opinions. Some of those opinions were surfacing in the comments of that post when Blogger decided to flake out. A whole conversation disappearing for a few days is a sure fire way to end said conversation. So why not pick it back up here.

I have estimated and sized work for both the purpose of sales and for delivery - they are different exercises. The conversations take place with a different group of people, and the level of detail needed between a sales estimate and a delivery estimate are much different. A sales estimate should not be concerned with scope. Your client has a business problem that needs solved AND they need your help in solving it. Scope at a story point level - or worse, at an hours level - in a sales meeting is doing a disservice to the client and to the delivery team.

I’m sure a few people are chomping at the bit at that one, that sales shouldn’t be concerned with the scope of a project. That is until you realize the scope of a project will change. Repeat: The scope of a project WILL change. The delivery team is going to tear into the project and they’re going to learn more and more about it. They are going to learn that some concepts are smaller than they initially thought, just as they will learn that some concepts will be more complex than they thought. The scope is definitely going to change, and it will change constantly. When is the last time you built the project you started? Change happens all the time. Embrace or get ulcers. (That awesome one-liner courtesy of Jared Richardson.)

We have a number of tools available to us as agilists that should also help drive the sales process. The concept of a minimal marketable feature (or minimal viable product or minimal value feature, pick your phrase) which is the minimal amount of work that needs to be done to deliver value to your customer. Or the value story, where the business decides the value of a story in dollars prior to making it a project, then prioritizes the work to satisfy the value story. Both those concepts are going to support an iterative development process.

Building Software

A couple of comments to the prior estimation rant brought up finishing a basement. This steps into one of my biggest pet peeves about our industry: We build software, we’re not basement finishers. We don’t build houses. We don’t build bridges. We don’t build skyscrapers. We create software. Software is soft, it is mutable, and built correctly it can be changed at a low cost. The SOLID principles are solid as an acronym only because each and every principle is concerned with lowering the cost of change. They are about KEEPING software soft. The practice of building software is a knowledge creating process. It’s not a repetition of the same process with the same materials on a different job site.

In the context of my estimation rant, the number of unknowns in building a software application compared to the unknowns in framing out a basement wall are what leads to the waste of estimations. Take a small feature and develop it. Don’t estimate it, code it. At the end of that feature you’ll have learned more about the system, you’ll have created some value by delivering the feature, and you’ll have an actual time it took to build the feature.

The size of the East River didn’t change while they were building the Brooklyn Bridge. The size and shape of my basement didn’t change as we finished it. But the scope and size of my project changed TODAY as we found a better way to display data to our users. And it will likely change again tomorrow.

Are we agile or not?

The traditional way to start bidding was with, “I have this idea and this much money; I want it done by Tuesday? Can you do that?” Teams would clamor for the business, put a bid in to win the project, get the business, then spend weeks in a detailed contract negotiation detailing what the deliverables would be. When development started and the actual scope got out of hand, they would change control the hell out of it to keep it profitable.

But if we move to an agile bidding process, we can start the conversation with, “I have this idea and this much money, how much of my idea can I get?” Then we can prioritize some features, possibly very large features, and get to work on it. Line three of the agile manifesto: Customer collaboration over contract negotiation. Which is not to say we don’t enter into a contract, we most certainly will. However the conversation in determining what can be delivered to satisfy the customer's business need should lead to that contract, not be hindered by the contract. Your contract is there to protect both parties, but it should not be written down to the detail level that allows one or both parties to hide behind it in order to “win” the engagement.

Obviously trust is going to be a big factor here, as you just can’t say, “We’ll do it all agile like! Trust me!” Trust will need to be built, and the easiest way to build it is to be open and honest with all your communication. Be professional. Start small and build it from there. If there is no trust between you and your client there is no contract out there that will force it to happen.

A friend and colleague was working on a project recently where they are doing that incremental trust building, introducing agile, and having their ups and downs. In one case they proposed an approach to solving one of the client’s problems, and client replied with: “Your competitors have proposed a solution, and they already know and have priced out what they will need to build, whereas you just proposed an approach.”

That is a pretty straightforward response, and one that fits directly into traditional project bidding. So my friend’s reply was definitely not traditional: “Nobody knows exactly what you need built; not you, not them, not us. The difference here isn’t that they have a solution, it’s that we are not lying to you to try to win your business.” Open and honest communication.

Last Word on Estimation

I was in attendance at Agile Dev Practices West recently and got to see Linda Rising’s keynote address “Deceptions and Estimating: How We Fool Ourselves.” Linda had many studies and examples of how we as humans are overly optimistic at most things in life: How we drive, what we eat, and how we estimate software. We have learned that we are so bad at estimating software that we will spend extra time on the estimation in order to get it as accurate as possible, only to fail at it again.

Why do we keep spending money on an estimation that is wrong? Sometimes wildly wrong? Doesn’t it make more sense to spend money on building it?

Moving The Blog

2011-06-07T00:00:00-07:00

Moving The Blog

With the Estimation Rant quickly becoming my most popular blog post and generating a good discussion in the comments, Blogger decided that was the day to start doing random deletions of comments and later posts. I have been leaning towards moving off the Blogger platform for a while, but being lazy and it mostly working, I didn’t move anything around. Since “mostly working” went out the window, it was time to move the blog.

But where to? I’ve always wanted to have a bit more control over where my content lived. I used the FTP upload option on blogger which kept the content on my own hosted server, but they discontinued that a couple years ago. I thought about moving to an installed WordPress blog, but that whole lazy thing kept me from pursuing that one too far. What about the blog hosted on WordPress? Why leave Blogger if that’s the choice.

Then I stumbled upon Jekyll. Followed a few links to some other Jekyll sites then to how github pages works and made my decision. My content lives on github rather than in some database somewhere, and it exists as plain html files. The power and storage of github behind a blog being served up as plain HTML files? Awesome! Publishing by typing git push origin master? Geek points out the wazoo!

Setting Up The Jekyll Site

Step 1 was to toy around with Jekyll some and see what was involved. Essentially do a quick spike of Jekyll and see if it was going to work. About an 3 hours into my spike, I had an html template in place, four of five test blog posts, and an about page. Decision solidified. I laid out the steps between where I was and where I wanted to be to get it launched and went to work. If you're the kind that flips to the back of the book to see how it ends, it took me roughly two weekends to complete the move and get it published.

The first hurdle I ran into was running Jekyll plugins on github. I had added a plugin to generate category links for me based on the categories in my blog posts. Pretty straightforward, but not handled by base Jekyll functionality. Everything worked fine locally, push to github and no categories. Looked around some, find the right page of the manual to complete my RTFM, and found that github doesn't run any code in the _plugins directory as it is untrusted code. Seemed a good enough reason to me, and the fix was pretty simple. Generate the site locally, add the categories directory that gets generated to the root directory of the project, then git push origin master and the categories are there. (I’m not sure this is the best solution, but it is a solution.)

Migrating From Blogger

This was the real PITA for the whole move. There were a couple suggestions on how to automate the move, but I had no luck with either of them. In the end I settled on doing it all by hand, which really wasn't that hard. Copying from the blogger dashboard into markdown required very few edits. If I was moving more than the 60 or so posts I had, I would have probably found a way to script an import or something. I figured I could copy/paste my way through it quicker than scripting it out, so brute force won the day.

The smallish edits I had to make were what you would expect. Recreate some formatting - bold, italics, headings, etc - add the images back in, and add the links back to the posts. My earlier blog posts were easy as I was really lazy back then with few headings, links, and images. My more recent ones where I have decided to add a few more pieces of flair took a little longer to recreate in copy/paste mode.

That said, if I had it to do over, I would probably brute force it again. If I had closer to 100 posts to migrate, I would probably opt for creating some kind of migration script.

Migrating the Comments

The few comments I had on the blog I didn't really want to lose. What seemed to be the obvious choice here was to migrate to Disqus. They are everywhere, manage threads, help keep down spam, and hit right at my price point of free. The migration was a little trial and error for me, though.

My first try was to just import them from Blogger. Disqus has an automated way to do that, it took all of 4 minutes to complete the process. However, I had no good way to link my newly imported comments back to they’re original blog posts. Disqus will relate comments to posts in one of two ways, a unique identifier you provide them or the blog post url. I had no way to give them a unique identifier, and the url for each post was about to change.

After a little more research, I found that Disqus provides some tools for more complex blog migrations to keep your posts and comments linked up. (I'm telling you, the people at Disqus have thought of EVERYTHING!) So I redid the import to blogger, but instead of just importing the comments I installed Disqus as the commenting system on the existing blog. Then I had to do a quick CSV file to map the old url to the new url and upload that to Disqus. About an hour later, the comments appeared on the new blog. (The new blog was still not "live." It was running on local host and at timwingfield.github.com, but the comments were there.)

Still On the Todo List

Sunday I "pushed the button" and swapped the DNS around to point at github rather than at blogger, and about an hour after that switch the DNS had refreshed to the point that I was seeing the new blog. But now that I have the level of control over my blog that most geeks like to have, I’ve got plenty on the todo list.

I still want to add some more features to the index page, starting with getting a comment count and link under each post to go directly to the post. I would also like to revisit that publishing the categories thing from above. Initial thoughts are I will end up with some little rake script or something to handle it, but may do some more looking. A dedicated mobile interface would be nice. Jekyll has the ability to publish at a given time, so I will need to spike that one out to see what I need to do.

One week into this little experiment and I am liking it. I feel like I'm more in control of my content, I have a better comment system than before, and publishing is git push. Big fun!

Estimation Rant

2011-05-12T00:00:00-07:00

Estimation Rant

Estimation is a bad word on dev teams. We have learned from many painful estimation debacles to the point we cringe when we hear the word, "Estimate." In many software endeavors estimating is a necessary practice, at least on some levels, to get the thumbs up to start writing software in the first place. But just because we have done estimating activities often, does not mean we are good at it.

Disclaimer: I am discussing estimation in the context of delivery, not sales. Clients everywhere want to know when something will be done before they commit money to it, which is why many talented sales people drive fancy cars.

Failing Into the Hours Trap

The very first failure of many estimating exercises is estimating your tasks, stories, and features in hours - or days or weeks or years. Any unit of time measurement is likely going to get you in trouble, but we will stick with hours for our example. Yes, hours fit neatly into a column in Microsoft project, but for estimating a development effort your setting yourself up for failure as soon as you choose hours as your unit of measure.

The first trap in using hours is we are all going to base that guesstimate on the 8 hour work day. If you commit to 8 hours, you are essentially saying that you will have that feature done in a day. Your manager is definitely hearing "one day" when you say 8 hours. If you could sit and code for 8 hours straight, maybe that estimate would be worthwhile. But how often do you get to code 8 straight hours? All kinds of things happen that derail that 8 hour day of uninterrupted coding. The stand up, other meetings, lunch, nature will inevitably call, and there's a better than average chance a Nerf war will break out in many team rooms.

The second trap of hours is they really only get used as a measurement when you go over your estimate. For example...

Let's take a developer on our team, we'll call him Jeff. In our estimation meeting, the team has determined that feature #1337 will take 16 hours to complete. Based on our previous trap we all just heard, "Two days." Jeff pulls feature #1337 off the board Monday morning and gets to work. Wednesday afternoon, he moves it to dev complete. Whoa, that feature just took 24 hours to complete! Come on, Jeff, you're 8 hours over the estimate? How will we ever make that time up?? We're on a deadline here!!

Sorry...all accusations are purely hypothetical.

The next Monday morning we're back at work, and our trusty developer Jeff looks on the board and sees feature #1355 on the board estimated at 16 hours. He pulls the card into the development queue and gets to work on it. At the end of the day he's done. 8 hours into his 16 hour feature he moves it to dev complete. Way to go Jeff!! You rock! Best developer ever!!

But hold on a second. Our rock star dev has missed his estimate by 50% in both cases. In one he's the villain and the other the hero? He goofed by 50% but thanks to "beating the hours" on the second feature that gets lost. In reality we should be asking Jeff why he missed each estimate. That will help us learn where we as a team missed and how we can apply that to future guesstimation exercises.

The Cost of Estimation

During a lunch conversation at a past conference I listened to a gentleman tell us how he was contracted to do a 6 month estimation on what it would cost to build a certain piece of software. Two weeks into the contract, one that was paying him quite well, he went to his stakeholders and said, "The amount of money you are sinking into the estimation contract will never be returned to you. You will never get $1 back from it, how about I just start building the software and we'll see where we are in 5 and a half months?" They went for it, and he won the development contract 5 and a half months later.

The estimate means nothing to the actual delivery of the software. One of my former managers used to say, "The effort is the effort is the effort." The iron triangle of software is scope, timeline, and quality. We're allowed to fix any two of them, but the third has to be flexible. (It's scary how many times quality is the one that gets forced to flex.) Our estimate won't change any of the three points on the iron triangle.

All Is Not Lost

Fear not, there are ways to get your software written without falling into estimation traps, and giving those outside the team a reasonable idea of when something will be delivered.

First up is story points. Story points are a representation of the level of effort the team thinks it will take to complete a story. Story points can be anything. I have seen teams use numbers such as 1, 3, 5, and 8 as their points, and other teams will use t-shirt sizes such as S, M, L as points. One team I saw REALLY wanted to drive home the fact that story points are relative, so they went with duck, unicorn, and elephant as their sizes. Using any of those units of measurement illustrates that story points are used relative to each other rather than to a fixed value such as hours. Humans are very good at doing comparisons, so we don't know exactly how big a unicorn story is, but we know an elephant story is bigger.

Another way to step away from estimations is to move to a continuous flow system. Get yourself a Kanban board, get rid of iterations and iteration commitments, and start tracking the cycle time on the completed side of things. There are a few challenges with going this way, the first being that you will not have a reasonable idea of your cycle time until you have pulled a few stories through the system. Additionally sizing may still come into play because stories have this habit of never being exactly the same size. But, get through a few cycles, get some actual times on features from concept to completion, and you'll be handing your managers actual times from which they can plan future work. It may take a little time to get the data, but there isn't a manager in an IT department anywhere that wouldn't love to hear, "This story is sized as a small for our team and small features take us about 2 days to complete. Come back Wednesday, we should have it for you."

The last way to get rid of estimation is just to get rid of estimation. Like the story where the gentleman stopped researching on the estimation contract and just started writing code, just write the freakin' code! That could make for some difficult conversations at some point, but if your 4 person dev team is in a 2 hour estimation meeting every iteration, that's 8 hours you could have spent writing code towards a deliverable.

</rant>

How We Do a Retrospective

2011-04-21T00:00:00-07:00

How We Do a Retrospective

There is no one right way to do a retrospective, there are many good techniques...and a few bad ones. Utilizing more than one technique is a good way to get different conversations going with your team, and expose different areas that could use a little fixin'. That said, I do have a "tried and true" technique that we've used on a number of teams over the years. It's usually pretty good at getting the conversation going, and can be done in 30 minutes or less to keep you from being stuck in "yet another meeting."

First things first, at the start of any retrospective you should review the action items or results from the previous iteration's retrospective. Have the people assigned to each item report how it went and what got accomplished. Nothing gets a retro off to a good start like saying, "Remember that problem we had last week? It's fixed!"

A Few Supplies and a Little Preparation

We're going to need:

Three colors of sticky notes. Regular square ones will work fine. For this example we're going to use purple, yellow, and green.
A box of pens, preferably all the same kind. I like to use sharpies because big pens on small paper ensures we get short items on each card rather than essays. Using the same pen also keeps things a little more anonymous.
A whiteboard. In the absence of a whiteboard the big easel sheets would do the trick.
A timer of some kind. I picked a timer up for about $200...it also makes phone calls, surfs the web, plays Angry Birds and sends text messages and email. It's high end for a timer, but it does the trick.

For the prep work, take our three colors of sticky notes and split them up so each member of the team has a few of each color. The number really doesn't matter, but we usually end up with 6 to 8 of each color for each person. Give each member of the team their own little pile of sticky notes and a sharpie.

Gather The Data

The colors signify good, bad, and confusing items from the previous iteration. Since we went with purple, yellow, and green we'll say that purple = pain, yellow = confusing, and green = good. Set the timer for 5 minutes and have the team write as many items as they can think of for each color from the previous iteration. They should do this on their own, writing their own thoughts down, we'll collaborate and discuss later. If your team is smaller and iterations are pretty short, put less than 5 minutes on the clock.

When the time is up, have each team member walk to the white board and stick their notes on the board. No order to them, just get them on the wall. Once all the stickies are on the wall, take a couple of volunteers to group them by subject, not by color. We're not looking for all the bad things that happened in one cluster, we're after what was good and bad about a given subject to the team. Aim for 4 to 8 categories, and try not to get them too broad. Once you have your categories, circle them and put a one or two word title above the cluster. It should look something like this...

Discuss

We've got things broken down, next up we have to decide what we're going to tackle. Best way to do this is to Dot Vote. Dot voting is an old stand by in agile. Each team member gets 2 or 3 votes and they place a dot next to the category they want to discuss. If they think a category is very important they could put all three of their dots next to that category. We do want each team member to use their votes though, abstaining isn't allowed.

When everybody has voted we'll discuss the top two vote getters and try to pull an action item or two out of each category. Do a quick run through of each sticky, set the timer at 10 to 15 minutes, and get to discussing. Try to involve everybody in the discussion as well. Since everybody contributed to the stickies on the wall it should be easy to get the quieter folks to speak up as they likely added a note to the category.

What Are the Goals Here?

Goal numero uno in this set up is to get everybody to put stickies on the wall with what they thought went good or bad or confused them during the last iteration. By doing this we have everybody involved in the retrospective right away, and increases the likelihood of them speaking up during the discussion.

The second thing we're after is discussing categories of issues rather than smaller issues raised by one person. The goal of any retrospective is to look back and see what we can do to make the whole team better, not just what the loudest, type A personality, Alpha-Dev wants fixed to make his life better. By categorizing everybody's issues we can compare what everybody thinks, discuss the broader issue, and derive a good actionable, assignable action item from that.

Some Issues: Learn From My Mistakes

Doing this, or any, retrospective style 6 or 8 or 10 retrospectives in a row will stop yielding good results. That happened with one of my teams and we kind of got in a rut. Once in that rut the retrospective became an "Airing of Grievances" (minus the festivus pole) and we weren't getting good action items. In reality, we were getting bad attitudes towards the retrospective and incremental change was not coming our way.

One particular retrospective we had done the categorizing and completed our voting and a sticky note from one member of the team had not made it into a category we were going to discuss. In order to get it discussed, the owner of the sticky moved it into a category we were going to talk about. It was posed to the team if we should leave it, and the consensus was it wasn't there for the voting, it shouldn't go in now. The offender wasn't too happy with this decision and slapped it back in to be discussed...at which time one of us removed it, tore it up, and threw it away. Team over individual in the retro. Always.

As noted earlier, and solidified with my first issue above, this isn't the only way to do a retrospective and it shouldn't be used iteration after iteration. However, it does get the conversation going and it will usually yield an item or two that your team wants out of its way. Give it a shot the next time you have a retrospective.