AgileIQ Blog

Code Reviews Bad - Pair Programming Good (or "Don't throw it over the wall, collaborate!")

by Steve Bement

I've had two jobs recently with clients who were not in the habit of pair programming. They did, however, have some strong procedures established for doing code reviews. Developers were not allowed to commit code to the main branch without first completing a code review. The code review consisted of creating a patch file containing all your changes, and submitting that file to other developers for review.

I learned from these two experiences (and others) how bad code reviews really are compared to pair programming.  Here are four disadvantages I have found:

1) Problems are found later, when they are more expensive to fix.

It is well documented that the later a bug is found the more expensive it is to fix.  Before submitting something for a code review, a conscientious developer will have designed a solution, coded it, written unit and integration tests for it, and probably done some manual acceptance testing as well, all in preparation for checking in.  If a problem is found in a subsequent code review, that whole process has to start again, at least to some degree.

By contrast, pair programming finds those problems earlier on in the life cycle, thereby requiring less rework to fix.  In his book on test-driven development James Grenning talks about the physics of TDD, and concludes that "If a bug lives for less than a few minutes, is it really a bug?  No, it's a prevented bug.  TDD is defect prevention" (See "Test-Driven Development for Embedded C", p. 6).  Pair programming is the same thing - defect prevention.  You find problems earlier, when they are cheaper to fix.

2) Context switching is required, which lowers productivity.

Code reviews don't happen instantly.  They take time.  Other developers are busy.  What are you going to do while you are waiting for the review to complete?  Hopefully you are not going to sit around doing nothing - you are going to start on the next story.  Then the next day (or after several days, in some situations I have been in) you are going to receive feedback from the review.  In general you can respond in one of two ways: you can defend the code the way it is, or you can agree to make the suggested change.  Either way, you need to get back to the state the code was in at the time of the review.  But you have since moved on; you have made other changes to the code.

Sure, there are strategies for handling this.  You can create a patch file for your current changes and revert them.  You can create and work in a separate branch for each story.  But there is overhead in these approaches.  In addition to the context switching of the actual code, there is the mental context switching in your head.  You have moved on to other problems, but now have to get your brain wrapped around the previous issues again.  I suspect that of the two types of context switching, this one (the mental one) has the greater cost.

With pair programming, on the other hand, you are finding and addressing problems right while you are in the midst of them - no context switching required.

3) Quality is lower, because of resistance to changing working, tested code.

When asked what he thought of code reviews, I heard one developer say "It just feels like it's too late".  In talking further, what he was getting at was that by the time the code review happens, all this work of coding and testing has already been done.  To suggest that we tear it all up and rework it doesn't seem all that productive at that point.  Sure, if something is really broken it will have to be addressed, but otherwise, people tend to want to leave it as is.

Another aspect of this is that even if some changes are made to fix a problem, they often tend to be band-aid solutions, because you are now retrofitting existing code; the end result won't be of the same quality as a pair working together from the beginning.  It's like the difference between building a house, then having an inspection, and then fixing the problems the inspector found, versus building a house with an inspector alongside you the entire time.  No band-aids placed over things, just quality code from the ground up.

4) Bad feelings can arise between team members.

This one is less common than the others, but I have seen it happen.  While we would like to think that we are  all objective-minded and don't become emotionally invested in our code, that isn't always the case.  And after designing, coding, and testing it we are more invested in it than if it was still just in the idea phase.  In a code review, it is our working, tested, finished product that is being critiqued.  When pairing, there is still a lot of critiquing going on (probably even more than in a code review), but it is happening earlier in the process; usually in the idea phase when we are less invested in a specific solution.  Overall, code reviews can feel more adversarial than pair programming (which feels very collaborative).

It's all about collaboration - don't just write something and throw it over the wall for a code review. Pair program!

Work Harder

by James Rosko

A manager I once worked with got out of an executive meeting, walked over to development, and said, “I’ve been talking with the VPs and everyone has to work harder.”  Fred, the manager, continued by saying, “We’re going to have to be creative about how to get all this work done.”  I took Fred aside and said asked him, “by ‘creative,’ you mean work more hours don’t you?”  He replied, “Yes, I mean work more hours.”

Before you criticize Fred, let’s try to understand what it means to “work harder,” “be creative,” and more importantly how a development organization should respond.

From a laborer point of view, working harder means move faster, take shorter breaks, push through the pain, and work more hours.  All of these seem intuitive...  Before college, I worked at a greenhouse.  When my greenhouse boss said to work harder, he’d then add, “move faster,” “get back to work,” and “this needs to be done today.”

At the time Fred made his appeal, our two Scrum teams worked on two major projects.  I asked Fred, “What are some specific things a software development organization can do to work harder?”

From a programming point of view, typing faster doesn’t solve much because a developer invests substantial time in reading code, discussing tools and frameworks, and choosing names for things. However, a few programmers I know might benefit from a refresher course in typing.

I suppose developers can take shorter breaks, but the the Pomodoro Technique suggests an optimal work/break schedule.  Essentially, it prescribes how long you should engage in a focused activity before taking breaks, and how long each break should be.  As you repeat the technique, the schedule changes.

According to Fred, working harder also means working more hours to complete the projects.  Working more hours gives a diminishing return on investment and should only be used in exceptional cases.  It does not increase long term productivity.  I consider working overtime an Agile antipattern.

Now that we’ve established that the traditional definition for “work harder” doesn’t fit for a developer, let’s address the goal of what is needed by working harder.  After all, working harder is a means, not an end in itself.  As Fred himself said, the goal is to “to get all this work done.”

The “get it done” phrase is popular among managers.  I believe managers say this when they know what they want done but don’t know how to increase organizational productivity.  The Agile development process increases organizational productivity over traditional models by prescribing  team focus (swarming), immediate results (low work-in-progress), high morale, and other best practices like pair programming and high quality (see XP programming).  

When we adjust the speed at which we deliver software at the same cost, quality traditionally suffers.  Following Agile/XP practices, we can attain high quality over the long term by focusing development effort on the highest-priority project first.  That way, the business gets the most important project completed soon, with high quality, and the lesser important projects done a little later.

I told Fred working overtime might give us the appearance of getting more done, but we wouldn’t actually be delivering as much high quality software.  Instead, we should focus on the highest priority project first and use XP programming practices to obtain high code quality at a sustainable pace so that we can continue to meet business objectives.

In the end, the executives realized the project dates they committed to weren’t in line with what the business was able to deliver.  Following Agile and XP practices, the development organization got the highest priority project shipped first, a big win for the company, while at the same time kept reasonable commitments and working at a sustainable pace.

Goal Setting and Appraisals in the Agile World

by Jayaprakash Puttaswamy

As a practitioner of the agile way of working, most of my actions, techniques, and experiments were driven through “common sense” and the “ground realities” of the team, team members, and organizations I have worked with.

I would like to describe one such experiment where I attempted to change the way individual and team goals are set, and change the way people get appraised against those goals in large product organizations. It was fairly successful and worked as an important element that drove effective agile adoption.

Traditionally, most companies have their performance management model built on age old principles and frameworks that don’t adapt to the organizational changes. More concerning is the way organizational goals and an individual employee or team goals are linked to each other. I have seen many loopholes in aligning individual goals with organizational goals. The disconnection exists at various levels.

While this is a story about companies with traditional approaches towards software development, could you imagine what happens when such companies try adopting Agile? They utterly fail because of lack of attention to this aspect of goal-setting and appraisal models. In fact, agile trainings and initiatives drive the employees in one direction and annual goals and appraisals drive them in exactly opposite direction. This is because the measurement metrics for both aspects differ and don’t complement each other.

In my experiment I mentioned above, I dealt with the above situation more as a change agent than a scrum master or a development manager. Let’s look at a couple of example goals before and after agile mindset.

Goal setting examples

Sample goals and their measurement metrics set for a Sr. Software Engineer before agile adoption strategy was changed (click images to view larger versions):

Goal 1:

Goal 2:

Goal 3:

Goal 4:

The above goals were not only unclear and difficult to achieve in an agile environment, but also very difficult to measure and appraise the employee.

The funny part was about goals for other roles. For example, the goals for a Software Engineer were 90% the same as above (literal copy/paste) with one or two items missing. The goals for a Tech. Lead were also same, with the addition of a couple of new items on management aspects!

Now, let’s look at how I reorganized and redefined the same goals for same Sr. Software Engineer role as part of a strategy to adopt agile better.

Same goals and their measurement metrics redefined and reorganized after agile adoption strategy was changed:

Through the above examples, I would like to convey to the readers of this article that changing the way goals are set and appraisals are conducted can significantly affect the effectiveness of agile adoption at an organization level.

Here are the three aspects to be considered while revisiting “Goal setting and Appraisal strategy” in the agile world:

1. Performance management model

• There has to be a “Team component” that ties all individuals to focus more on collective outcome, and it has to be considered a major piece of the pie in bonus/increment.
  
  
• Individual employee goals should be aligned with organizational goals to suit the agile mindset.

2. Gathering input for Appraisal

• A 360-degree survey should be conducted to get transparent feedback from each member about every other team member.
  
  
• More open evaluation techniques should be used while measuring agile practices maturity.
  
  
• Team-level feedback should be collected from the Product Owner and ScrumMaster based on their observations of the team over a period of time (across multiple sprints). They could reveal valuable insights in terms of improvement in team’s self-organizing ability, commitment exhibited during demos, and quality focus shown in terms of “definition of done” adherence.
  
  
• Key agile metrics like sprint velocity and burndown charts should be considered for team evaluation.

3. Providing feedback more frequently

• Instead of waiting for formal annual or semi-annual performance review meetings, key stakeholders and managers can meet the team and individuals one-on-one after every sprint or every alternate sprint. They could use this opportunity to make course corrections if the goals are off-track for any team member or for the entire team.
  
  
• Also, based on empirical data and changes in organization priority, goals can be refined or revised once a quarter or once after every sprint release.

Join us at Scrum Gathering Atlanta, May 7-9

by Pam Dyer

The Scrum Alliance regularly hosts Scrum Gatherings in various cities around the world. These conferences are attended by Scrum community members who share experiences, exchange information, and collaborate about Agile best practices. SolutionsIQ is a Silver Sponsor of next week's global event, May 7-9 at Atlanta’s Marriott Buckhead Hotel and Conference Center, and several members of our team will be giving presentations:

Bryan Stallings: Agile Release Planning by Example

Stakeholders readily establish release expectations, but many teams do not know how to plan beyond the next few weeks! This interactive tutorial is for team members, customers, and other stakeholders who know how to plan from iteration to iteration but don’t yet do release planning. A successful release planning event produces powerful and insightful results that enable teams and their stakeholders to anticipate what is likely to be delivered, in what timeframe, and with what risks. The stories, photos and exercises covered in this session will prepare attendees to create a release plan with their own teams.

Dhaval Panchal and Valerie Morris: Coaching Smells

How do you spot an agile coach? Are you an agile coach? How do you know? How do others view you? Some of your answers to these questions may be coaching smells. Agile coaching necessitates humility, curiosity, courage, and an open mind to learning. It demands discipline in servant leadership. Dhaval and Valerie will share what coaching smells are and how to identify them.

Dhaval Panchal: The Scrum Murder Book

When detectives begin an investigation they sometimes create a “Murder Book” that contains all of the notes, findings, and errata commonly collected in a murder investigation. They use it for bringing new investigators up to speed as well as for capturing progress on the case. So the question is: What if we kept a Murder Book for our Scrum teams? What artifacts would we keep in our book? Who would we show it to? How would we use it? In this workshop, attendees will build their own Scrum Murder Books together and commit a little agile crime.

Download the full program

If you're planning to attend the conference, please say hi to Bryan, Dhaval, and Valerie!

Bottlenecks and Value Stream Mapping in Agile

by Joe Justice

A bottleneck in Agile work is probably what you think. It is the area of least flow. Optimizations made elsewhere can't increase the overall flow of the system unless the bottleneck is addressed first. We discover bottlenecks via Value Stream Mapping.

A value stream map can grow in complexity to model complex relationships, but here we only need a very, very simple implementation: To get what we need, it's simply the flow of a product from idea to customer, divided up any way you like along that flow, with a number of days where that division is actively adding value written over the number of days the product is in that division. You may have done this already in your work.

Here is an example from Team WIKISPEED: Converting our halogen headlights to LEDs. The LED headlights start with researching the road legal laws for headlights, then researching headlights that meet the spec, then purchasing, then mounting them, then wiring them, then testing them for compliance with the road-legal specification. In that flow, lets say we find out that one headlight is burnt out at the end during test. We can move testing to right after purchasing to avoid wasted work. We also found the "researching LED headlights that meet the road legal specification" task on our Scrum board/Kanban board hung out in "doing" for 17 days, but actually only had 1 hour of research done. Finally, 17 days later, and we were able to move it to done. We've recognized an opportunity to increase flow by calling for a swarm, adding a resource, or escalating the priority of that task.

Where we find work queing up in a given division, we have found a bottleneck. In this case, maybe the research was waiting for the Product Owner to give more information about whether we were assuming EU or U.S. light distribution patterns initially. One way we can help alleviate the bottleneck in this case is by moving the Kanban board somewhere both the team and Product Owner see while they are working, and adding a red box above the backlog labeled "waiting for Product Owner feedback". This might help the Product Owner have enough information to prioritize their work based on what the team needs to flow.

When done well, a Scrum board, a sprint planning board, or a Kanban board can be a value stream map of the team's part of the overall business flow, updated during each daily standup meeting. When this happens, the ScrumMaster is armed with the information they need to select the right retrospective tool and guide the team's continuos improvement to the very high levels of performance for whcih Agile is becoming famous.

Agile and Value (Part 2)

by Dan Williams

In the agile world, incremental delivery of value to the customer is the ‘mom and apple pie’ of countless Certified ScrumMaster training courses and books. What is the value and how is it measured and when is it communicated to management?

In my previous post on Agile Value, I referenced Software by Numbers. (For additional information on the authors and the approach introduced by this book see their website). It introduced an approach to quantifying value using the concept of Minimum Marketable Features (MMF). In the second edition of Jim Highsmith’s book Agile Project Management, he introduces the key concept of linking competitive advantage to early software delivery.

He states that, “Ultimately customer value is delivered at the point-of-sale, not the point-of-plan.” He says, “The agile value ‘Delivering Value over Meeting Constraints’ provides a focus for rethinking how we measure performance on projects.” He explains that though cost and schedule are important, these constraints should be secondary to delivering value to the customer.

The concept of incremental delivery of measureable value to the customer is consolidated in the Agile Triangle of Value, Quality, Constraints, a replacement for the so-called iron triangle of Cost, Schedule, Scope used in traditional project management.

Value Point Analysis is Highsmith’s recommended method to address the what, how and when of delivering value to the customer. After first favorably citing Denne and Cleland-Huang as pioneers in this space, he then disagrees with their approach as overly complex.  As an alternative, Highsmith introduces Value Points as an analog to Story Points to measure the delivery of Value to the customer.

The when is during Release Planning. After sizing the Epics, Themes, Features and User Stories using story points for relative sizing, keeping in mind that story points are an indicator of cost and can be easily calculated, value points are a relative sizing used an indicator of benefit delivered.

The what, or calculating the monetary value of Value Points is suggested by using the Net Present Value (NPV) of the Revenue Stream used in the business case to capabilities delivered based on percentage of the delivered already calculated.

The how example  he gives is for one Capability, composed of several user stories, which delivered 14% of the release value, and would be worth $350,000.

When the iteration for the Capability was underway, the $350,000 would be divided by the total number of Value Points calculated for all the stories – assume 125 – to give a monetary value of $2800 per point. An individual story that was estimated at 15 value points would then be allocated a value of $42,000.00. The graph below illustrates the comparison of feature cost to value point estimation based on the NPV value derived during the Business Case construction during project Initiation. Management now can measure the incremental ROI delivered:

Value and Cost Delivery

Management requires performance measurements to safeguard against Risk and Cost overruns. Even more important is to measure Value delivered which promotes early releases and early business benefit. To perform Value and Cost delivery we need to do the hard work of up front planning and delivery tracking during the iteration cycle. My next post will continue with more mechanics on value and cost measurement and tracking.

Scrum: Tracking Impediments

by James Rosko

On a Scrum team, an impediment is anything that prevents the team from being productive. Ideally the ScrumMaster is responsible for tracking and resolving all impediments. However, when there is no ScrumMaster, teams often turn to tracking tools like Bugzilla, JIRA, Mantis, and Team Foundation Server.

I've tried a few different techniques for collecting questions and impediments during a sprint: Spreadsheets, issue tracking tools, Post-it notes, the notes app on my smartphone, etc. Every time I've attempted to use an issue tracking tool to organize impediments, I come back to the same conclusion: It adds a level of separation between the scrum team and the Product Owner that prevents direct communication and mutual understanding.

The Agile Manifesto says it best, “Individuals and interactions over processes and tools”.

When there are a lot of questions and impediments it usually means the story is not well scoped or is too big and should be broken into smaller stories. Sometimes teams work on many stories at once instead of one story at a time. The term for this is Work in Progress (WIP). Just like in the Lean Software Development, I encourage Agile and Scrum followers to limit the WIP so that several stories are not partly completed at the end of the sprint. Limiting the WIP also allows everyone on the scrum team to have a mutual understanding of answers from the Product Owner, a core concept in Scrum!

In Scrum, there is a dedicated role called the ScrumMaster who is responsible for resolving all impediments and making sure the scrum team (Dev and QA) have direct access to the Product Owner and their delegates. I’ve seen some ScrumMasters use a tool or a spreadsheet but normally they just use a Post-it on the task board so that everyone can see. If the answer is also put onto the same Post-it, there’s no need for an extra tool; the existing Scrum process has a built-in way to manage answers to questions & impediments.

Agile Delivery of Customer Value

by Joe Justice

WIKISPEED uses Agile methods, such as Lean, Scrum, XP, and Kanban practices, to increase the speed of automotive development and manufacturing. The Agile Manifesto is perfectly compatible with this, and its 12 principles are exactly appropriate for building cars as well as software. More than one client, implementing Agile for non-software-centric teams, has asked for a version of the Agile Manifesto which does not reference software, in order to socialize it across their organizations. This is how WIKISPEED inherits from the Agile Manifesto and its 12 principles to maximize customer visible value across non-software-centric organizations:

We are uncovering better ways of delivering
customer visible value by doing it and helping others do it.
Through this work we have come to value:

Individuals and interactions over processes and tools

Delivering customer visible value over comprehensive documentation

Customer collaboration over contract negotiation

Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

We follow these principles:

Our highest priority is to satisfy the customer
through early and continuous delivery
of customer visible value.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.

Deliver customer visible value frequently, from a
couple of seconds to a couple of months, with a
preference to the shorter timescale.

Business people and the delivery team must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Customers obtaining value from our delivery is
the primary measure of progress.

Agile processes promote sustainable development.

The sponsors, delivery team, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity -- the art of maximizing the amount
of work not done -- is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

All credit to the Agile Manifesto authors (and my heroes): Manifesto for Agile Software Development and Principles behind the Agile Manifesto.

Agile and Value

by Dan Williams

I am interested in how to deliver and measure value when using an Agile perspective. I use the term perspective when referring to Agile rather than method or process because I believe Agile is concerned primarily with the promotion of certain values concerning people, work, quality, and value.

My personal interest in this area began several years ago when trying to quantify the delivery of business value, doing more than merely comparing Cost and Schedule a la PMI’s methods. To my way of thinking, Value has to mean more than what something costs. When I say I value something or some service, I usually do not mean what the item or service cost me, but what I get in return. Cost is interesting and might prevent my acquiring whatever it is, but it is not equal to value.

Jeff Sutherland does a good job of summarizing the core perspectives concerning Agile and the delivery of Value. He says, “The Agile Manifesto established a common set of overarching values and principles for all of the individual agile methodologies at the time. It details four core values for enabling high-performing teams. These are:

• Individuals and their interactions
• Delivering working software
• Customer collaboration
• Responding to change”

The core values emphasize people, their interactions, collaboration, and responsiveness to the dynamics of the business environment as the starting points for the delivery of value.

Agile, within the context of software development and delivery, attempts to deliver different kinds of Value, and this may be the start of the confusion. These are at least:

• Respect for persons
• A context of collaboration enhancing the work environment
• Flexibility and responsiveness to reality rather than wish fulfillment
• High-quality work engendering a feeling of satisfaction in the worker and value delivered to the customer

For a business adopting Agile practices, value delivered should be measured.

Business value may be understood in a variety of ways: Increase of income, reduction of cost, and the addition and retention of customers. How would we measure whether Agile was delivering on these goals? Here are some suggestions which will be fleshed out in my next blog posts.

Agile User Stories Exercise: Walk the Dog

by Dhaval Panchal

This is a simple technique with a marketing twist to its name. This title came to me while coaching a team that was struggling to behave cross-functionally and were paralyzed at delivering working software at the end of their sprint. It is a simple mental discipline that I have often used in crafting good user stories and I wanted them to walk their user stories with me.

Everyone is not an expert at analyzing business requirements against technical complexity, but most have had practice walking a dog. So lets ‘walk the dog’, plus this is much cooler than ‘lets walk the user stories’.

Metaphors only go thus far, but a cool title goes much farther. For me, a fancy title, acts as a trigger that allows me to break from the ongoing chain of discussions and engage in an exploratory exercise.

I have used this technique a few times to address primarily two types of challenges -- here are these stories:

Stories ‘not-done’ at the end of sprint

This team was formed of team members that were experts at their part of the code. This was their second sprint as a team and they were struggling to cross-train. To their product owner’s credit, he was creating user stories that were truly vertical slices of functionality that represented end-to-end implementation of features. Their main challenge was that in their two week sprints they were unable to meet ‘definiton of done’  (fully integrated and tested) on these user stories.

In response the team was asking the product owner to further split these user stories in two to three horizontal slices that could be integrated in later sprints. The product owner, was rightly pushing back since that would mean that none of his features would be developed end-to-end in a sprint. As their coach, while I was supportive of the Product Owner’s judgement, I was not sure whether I truly understood the team’s problem. I wanted to try an exercise of discovery with the group, and was concerned whether the group would allow for space and time to go with it.

So I christened ‘walk the dog’ technique. “Sounds like its time to walk the dog,” I said. ‘Sounds cool,’ said some one in the group, others looked perplexed, and afew others perked up.

So I asked the team to bring all their user stories from the current sprint. Starting with the first one, I asked them to walk me through the changes in code base that they will have to make in order to implement this story. I clarified that changes were considered only at the component level and not at the individual class file level. Then we picked another user story and did the same for that user story. At the end when we were done with all the user stories in the sprint, the picture looked like this.

We all stood back and after a few private moments of reflection, one of the teammembers asked why we are modifying on so many components in the same sprint? – bingo!

After this short diagraming exercise where the team literally walked each user story (the dog) through the changes in our components, the team was able to realize that the problem was not with the way user stories were split, but it was the lack of focus created by too many moving parts. The team was then able to rationalize why they were still trapped in their silos and why they were facing so many integration problems.

Earlier the team was asking the PO to split user stories along components so that they could manage complexity within their sprint. This exercise revealed another approach for the team. By limiting technical diversity for their in-sprint user stories, the team was able to reduce complexity within their sprint and also deliver vertical slices of valuable functionality for their product owner.