Ballot Debris

Thoughts on Agile Management, Leadership and Software Engineering

Professional Scrum Development with Microsoft Visual Studio 2012

clock August 26, 2012 08:53 by author Chad Albrecht

I thought I would give a shout out to Richard Hundhausen in anticipation of his new book.  I’ve been helping to review the book as he is writing it and this is going to be a phenomenal piece of work!  It will likely release in October and will surely be a staple for many of my coaching engagements.  Pre-order yours today!

Professional Scrum Development with Microsoft Visual Studio 2012

Vodafone360’s Team Board

clock June 3, 2012 07:52 by author Chad Albrecht

This is very cool!  Flow of work across the team board with computer generated Burndown and column sums.

Scrum Master or Scrum Enforcer?

clock May 9, 2012 07:03 by author Chad Albrecht

To quote the Scrum Guide, part of the Scrum Master’s role is to “ensuring Scrum is understood and enacted.”  This is often interpreted as “enforcing” Scrum. I have found the use of "enforcement" to be challenging. I have seen it create adversarial environments. You will he Development Team members talk like this: (snotty tone) "The Scrum Master said we can't do that! (laugh)!”  This is certainly not health behavior.  But what should be done about it?  Instead of enforcing Scrum, the Scrum Master should coach the team to follow the rules of Scrum. If the team wants to make a change to Scrum, use powerful questioning and dialog to discuss.  If the team still wants to make changes even after the discussion, the Scrum Master may want to allow it as a learning experience.  The Scrum Master will want to visibly track this as a team dysfunction (team whiteboard, wiki, sign in the team area, etc.). Then, during the next retrospective have the SM talk about the issues that arose by modifying Scrum.  What does the team want to do to address these issues?  Can we try bringing the Scrum concepts back in?

Certainly shuhari applies here, but sometimes keeping the team positive and talking is better than enforcing the rules.

Is Branching a Dysfunction?

clock April 29, 2012 05:32 by author Chad Albrecht

I have done source code branching with a ton of teams.  The pattern looks pretty much the same independent of what type of branching the team is doing.  “We are doing some work that we don’t want other teams to see or get impacted by.” So it goes the team creates a branch to work on a PBI/feature, test some ideas in a Spike or begin the next version of the product.  Work sails along swimmingly  until the team has to merge the code with mainline (which happens 90% of the time).  This is where all hell breaks loose.  The team, working in isolation, has created a large amount of code that will no longer integrate with the changes that have happened along the way.  At this point code is rewritten (not just refactored), new ideas are brought into the mix, tests are rewritten and so on.  For those of you that have been through this, you know what I mean.  Are there ways of dealing this this chaos?  Sure!

  • Work can minimized with regular forward integrations from the mainline.
  • Keep the branch duration short.
  • Use Design by Contract techniques coupled with unit and integration tests starting on day 1.
  • Etc.

I posted at the beginning of last year that you should always branch with caution.  Having given this topic a bit more retrospection, I believe branching to be dysfunctional. Here’s why.  We know that as a product moves forward the knowledge about it moves forward as well.  As two teams (or more) work in isolation,  this knowledge diverges at what appears to be an exponential rate (you can even assume linear and get to the same place).  When a branch is merged back to the mainline all the knowledge and assumptions are merged as well.  This is where we have a problem.  The teams need to “catch up” with each other’s knowledge.  From observation, the trick here seems to be to keep the teams collaborating on ALL the code ALL the time.  That way, knowledge and assumptions are shared and merge conflicts are eliminated. This is the basis of Continuous Integration (CI).  The teams should work together on a single mainline with the code being built and tested in near real-time.  Keep the builds fast and consider multi-stage CI or Build Pipeline techniques as the number and type of tests grow.

The question at this point is, “How do I keep unfinished work out of my releases?”   There are a couple answers/approaches here.  The first is to use Feature Toggles.  The concept here is pretty simple, as you begin working on a feature include a config switch that allows you to turn that feature off or make it invisible.  Other approaches include the use of authorization to include/exclude features in releases and in modular applications (portals) include/exclude the widget.  Along with the ability to turn chunks of code on and off, you will want to make sure you have a comprehensive set of tests and the corresponding automation.

As you begin to walk down this path you will see that you are actually on your way to Continuous Delivery (CD).   While a full CD approach is not for everyone, it does offer some really great ideas for keeping you product in a “always shippable” state.


UPDATE 8/27/2012: Fellow PST, Ryan Cromwell started a discussion on regarding this post.  Check it out!

KISS Retrospectives

clock February 27, 2012 10:51 by author Chad Albrecht

There are a ton of ways to handle retrospectives.  Esther Derby and Diana Larsen discuss a bunch of them in their book “Agile Retrospectives” published in 2006. While many of the techniques that the authors mention in the book are good for creating dialog (Force Field Analysis, Five Whys, Circle of Questions, etc.), they can often produce a hefty set of action items.  I have seen teams walk away with 70 action items that they wanted to work on in coming Sprints.  Inevitably, teams with this many items to work on feel like they are trying to eat and elephant all at once.  In these cases, and with new teams that I coach, I suggest borrowing an idea from the Theory of Constraints (ToC) and limit your Work in Progress (WIP).  To make this simple, I suggest limiting the number of action items you take away from your retrospective to one.  While it may seem like a small amount of things to work on, it gets teams in the habit of improving at least one thing every Sprint.  Many teams find that fixing the highest priority items will often make lower priority items moot.  If you are struggling with creating a culture of continuous improvement, try a KISS retrospective and pick only one thing to work on in the next Sprint.

ALM Chicago

clock January 17, 2012 12:48 by author Chad Albrecht

I will be presenting my “Agile Economics” deck at ALM Chicago on February 23rd.  Here is a summary of the talk:


The software development industry in embracing Agile in a big way. But why? Most certainly it allows a higher rate of success, encourages better collaboration, use of tools and does a better job embracing change. But why do the techniques work from a economics and finance standpoint? A number of people have tried to provide an answer to this question, but they often come in the form of complex equations and long discussions of finance models. In this presentation, Chad Albrecht will provide some very easy to understand economic models that provide a basis for why Agile outperforms traditional techniques. Additionally, Chad will demonstrate a side-by-side cost model of an Agile vs. Traditional project. If you are considering Agile in your organization and have partial or full P&L responsibility, this presentation will provide you with many valuable tools.


UPDATE  4/15/12:  Here is a link to a video of the presentation.

The Weak Team

clock January 10, 2012 07:33 by author Chad Albrecht

I’ve been using and experimenting with Scrum, XP and other Agile ideas since the late 90’s.  One pattern I’ve seen at least a few times is the idea of the “weak team.”  This happens when a manager takes a larger group of people (20-30), throws a problem at them and says, “Self-organize!”  While many times this works well, other times you will find the talented team-members pooling together and abandoning the less skilled or more junior team members to form the “weak team.”  As a leader, what should you do?  First, you have to ascertain if the members of the “weak team” simply lack skill or if there are interpersonal issues which are getting in the way.  As I mentioned in my last post, if the issue is simply skill you can choose to train them.  If the issues are intrapersonal, throw your coach hat on and get busy.  Once you have a plan of attack to address the issue of the “weak team,” you have to decide how to turn the “weak team” into the “strong team!”  You can do this by adding stronger team members to the existing team or redistributing team members to other teams.  This should be done in cooperation with the Product Owner to ensure that you have the right cross-functional talent on each team.

Scrum, Skill and Dead Bodies

clock December 13, 2011 07:17 by author Chad Albrecht

There is a misunderstanding of Scrum and other processes and frameworks that anyone that follows the “rules” will be successful. Simply write some code in a two week Sprint and show it at the Sprint Review and magically all problems disappear. The people that believe this are missing a few key points. 1) Creation of complex software takes skilled people. 2) Leadership is required (notice I am not saying management is required). 3) Both the leaders and team members must be willing to admit they were wrong for continuous improvement to take hold. I used to make the assumption as it relates to the first one that leaders understood they needed talented people to build software. I was wrong. To go back to my opening premise, many leaders think process can replace skill. This is like taking a group of high-school students, putting them in a hospital operating room and saying, “OK, self-organize and perform brain surgery on this patient!” Try as they might, without the proper training, experience, coaching and knowledge all you will end up with is dead bodies. The moral of the story is put skill before process. If you have a team member or members that lack the skill to write loosely coupled, refactorable, unit-testable code you have three options, train them, move them to another team where they have skill alignment or fire them. Don’t kid yourself into thinking there are other options.

Simple Scrum Diagram

clock October 24, 2011 12:11 by author Chad Albrecht

Over the last few years I have found myself drawing the same Scrum diagram on the whiteboard over and over again.  A simple, no-frills, diagram that shows the basic ideas of Scrum.  This is that diagram.



Using the ‘Release’ Concept in Agile

clock January 18, 2010 11:42 by author Chad Albrecht

I’m spending quite a bit of time these days helping organizations implement Agile methodologies.  As such I hear the same set of questions and see the same set of issues over and over again.  One of the issues I see quite often is the “long sprint.”  To explain what I mean by this I’ll use a hypothetical conversation with a Team Lead new to Agile.


Team Lead: “How do you deal with the fact sprint planning and reviews take so long?”

Me: “How long is long?”

Team Lead: “Sometimes a week!”

Me: “How long are your sprints?”

Team Lead: “Usually 3-6 weeks.”

Me: “How did you determine that 3-6 weeks was a good length?”

Team Lead: “Because we couldn’t spend 2 weeks out of every month not coding!  We use longer Sprints to avoid spending so much time in review and planning.”


For those of you that are experienced in Agile, you should see a few problems here.  For now, let’s just focus on the “long sprint” concept.  The “long sprint” seems to manifest in organizations that are always sprinting.  First off, this is in direct conflict with the name sprint.  Sprints should be just that, a focused exertion of energy over a short period of time…2-3 weeks max.  So how do we solve our Team Lead’s issue with spending too much time in review and planning and not enough time writing code?  Enter the “Release.”

A Release is a means of building larger blocks of functionality in multiple Sprints. (usually 4-6)  Some Agile methodologies (XP) implement this concept directly, others do not. (Scrum)  There are many reasons to use the concept of a Release, a select few are:

  • Some features just might not fit into a two week Sprint.
  • Allow team to perform work in parallel to development.  In general team members can do work other than sitting in sprint review and planning sessions.  This is because these sessions are lighter weight and involve fewer people.  You simply review implemented sprint functionality ensuring it meets the needs of the stakeholder and grab the next chunk of the prioritized Product Backlog. (ok, a bit more than that, but you get the point) These two sessions should not take more than 3 days.
  • Reduce the overhead of delivering software to production every 2 weeks.
  • Reduce the information overload caused by releasing every 2 weeks.
  • Define a delivery pace more inline with that of the organization. (the rope in the Drum-Buffer-Rope of Throughput Accounting)

The next logical question is “Do we create a Release Backlog?”  I agree with Mike Cohn in this case and would say no.  I do however, use the concept of a Release Plan or Release Roadmap.  According to Mike a Release Plan contains:

  • Graph showing historical velocity.
  • Prioritized Product Backlog. (including some big user stories, "epics")
  • A predicted range of where we will finish. This should be either a date-range for a fixed-scope project or a functionality-range.
  • Personnel assumptions. (Team members and availability)
  • Velocity assumptions. ("we’ll go about half speed during December because of holidays and time off")

I would also add the following:

  • A Vision Statement.  (“We want to add the shopping cart functionality and connect it to PayPal”)
  • Estimated Release Value as I discuss here.

Using the concept of a Release in Agile organizations can be an extremely effective way to increase efficiency through the elimination of waste.  I will try to post more on this topic in the future.  As always, let me know your thoughts.

Further Reading:

Extreme Programming Release Planning:

Mike Cohn on Release Planning:

Mike Cohn on why there should not be a release backlog:

Kelly Waters on Release Planning:

About me...


I am a leader, entrepreneur, software engineer, husband, father, pilot and athlete. Over the last 17 years of my career I have built numerous successful companies and software development teams. This amazing journey has taken me all over the world and allowed me to work in a number of diverse industries. I have had the privilege to meet and work with thousands of unique and talented people. As you will see from my blog I am a strong believer in Agile techniques and the Kaizen corporate culture. I am always looking to grow myself, my teams and the companies I am partnered with.

Contact me... View Chad Albrecht's profile on LinkedIn Follow Chad Albrecht on Twitter Subscribe to this blog

Professional Scrum Trainer

Professional Scrum Developer Professional Scrum Master I Professional Scrum Master II Professional Product Owner I Professional Product Owner II Certified ScrumMaster



<<  October 2015  >>

View posts in large calendar


Download OPML file OPML

Sign in