Archive for March, 2009
Bitter Scrum: A Task Board Gone Wrong
Sunday, March 22, 2009
I remember reading Bruce Tate’s books on Java
In much the same vain of Bruce Tate’s books, I give you a Scrum anti-pattern. Most Scrum teams will use a daily task board, either real or virtual. The task board contains a Sprint’s user stories and the associated user story tasks in the form of cards. It’s normal to see a few columns across the board along the lines of, “To Do”, “In Progress”, “To Verify”, “Done”, etc. The idea is for a team member to put his name on a task card and then move the card into the appropriate column. This is done throughout the day and especially at the daily Scrum. Below is an example of a Scrum task board.
Pretty simple. Below is the task board gone wrong. The difference is subtle and deserves an explanation as to why this is wrong.
Notice the extra column, “Today’s Work”. Having additional columns isn’t an issue, but this particular column presents a problem. The way the team uses this task board is to move tasks to “In Progress” when they’ve started work. But, since the team will sometimes start a task but then need to start on something else, the team decided they needed a column that showed what was in progress currently, thus the “Today’s Work” column. For example, in the daily scrum yesterday, Joe said he’s going to get Task A done. Joe moves this task to the “Today’s Work” column. Today, Joe tells the team in the daily scrum that he needed to start work on Task B for another story to help it keep moving forward, so he moves Task A to the “In Progress” column and makes sure Task B is in “Today’s Work”, as he didn’t finish that task yet. The problem is that we have impediments hiding under the “In Progress” column now. Rather than Joe saying that he was impeded from completing Task A, he moves it to a column (“In Progress”) that makes it seem like all is fine. All might be fine, but how do we know? It would be better to mark Task A as impeded. Joe could then make it clear to the team why he made the decision to not complete Task A in order to start on Task B. Everyone would see that Task A is in progress and it’s impeded (as opposed to simply “in progress”). The Scrum Master can help the team tackle this impediment.
Impediments aren’t inherently bad, but hidden impediments are. The task board gone wrong makes it far too easy to hide impediments while also making it difficult for the team to tackle properly. We all struggle with identifying impediments, so it’s important that we make sure our management tools are setup to help us make impediments visible and hard to miss.
Topics: Agile | 5 Comments »
Agile – Culture or Characteristic?
Sunday, March 8, 2009
Jeff Patton says agile is a culture. Rob Lally says no it’s not, it’s a characteristic. Both make compelling arguments. Jeff points out that agile is ultimately a culture which promotes certain processes and practices, whereas Rob argues that agile isn’t a culture unto itself but a quality an organization can adopt and make part of its own culture.
Agile has a strong culture. Jeff makes this argument clear with vivid examples of language, legends/stories/myths, values/norms/taboos, beliefs/attitudes, rituals/ceremonies, etc. But, does having a strong culture make agile a culture all unto itself that an organization needs to adopt as its own in order to succeed with agile? I don’t think so and this is where I agree with Rob. Agile is not a culture an organization adopts, rather it is a quality organizations can choose to add. Although, I never thought Jeff was arguing that an organization needed to replace its culture wholesale for that of agile’s, as Rob positions his argument against. I interpreted Jeff’s argument more along the one I was making in my 10 Questions to Think About Before Adopting Agile post, which was an organization’s culture needs to align with that of agile in order to realize success.
Rob makes an interesting observation in regards to selling agile as a culture:
Presenting Agile as a culture is something I’ve seen many times, and it puts more people off. Agile zealots, a club I was a member of a decade ago, try to sell Agile as a culture in a way that reminds me of Mao and his Cultural Revolution; they want to come in to your organisation, declare your culture to be bankrupt and rip it out, replacing it with an idealised regime of their own.
I don’t think there is any escaping the scary part of agile. Strong cultures are often scary to those looking from the outside in, whether those cultures belong to agile, lean, open source, religious groups, political groups, social clubs, etc. Those of us advocating agile need to be sensitive to this fact, but there is no escaping it as Rob seems to imply.
In the end, I think the most important takeaway in both Jeff and Rob’s posts is what they agree agile is not – a process or a set of processes. Those that see agile in this way and attempt to adopt it as such are almost certain to fail.
Topics: Agile | No Comments »
Quote from EC: “We’re going to have to do this the old fashioned way.”
Monday, March 2, 2009
This was my eight year old son’s comment to himself while playing the LEGO Batman video game. I looked up and asked him what he meant by that. EC sighed audibly and then proceeded to guide Batman towards a bulldozer in order to plow everything and everyone in its path.
Topics: EC Quotes | No Comments »
Get Off of My (Enterprise) Cloud
Sunday, March 1, 2009
Cloud computing may save the universe, but it won’t be saving the enterprise’s universe any time soon. At least that’s what I’ve gathered over the months of reading and hearing about cloud computing ad nauseam. The enterprise needs security, reliability, manageability, etc. and these are not available in the cloud today. I’m a bit puzzled. When did the “cloud” inside the enterprise become so resilient, manageable, and secure?
I won’t argue that solutions like Amazon’s EC2, Google’s App Engine, Microsoft’s Azure, Salesforce.com’s Force.com, etc. are ready for the enterprise today. What I will argue against is this perception that services within an enterprise’s internal IT control are superior in almost every way to the cloud computing alternatives. For example, an eWeek article from July 2008 on hosted email and considerations that should be made in regards to reliability:
It’s important to evaluate the processes that potential hosted e-mail providers have in place for ensuring reliability, to discuss the sort of SLAs (service-level agreements) with which these providers are prepared to back their offerings, and to see how these provisions and guarantees stack up against what you are prepared to provide in-house.
Solid advice. Do we do the same for email hosted internally? When gMail or other popular hosted email solutions go down it’s a crisis that gets publicized like no other. Next time email at work goes down, be sure to check TechCrunch, CNet, and other tech publications for further info. I understand the scale of email in the cloud has no comparison, even compared to the enterprise. The enterprise might be talking hundreds of thousands of users, while email by Google, Yahoo!, and others is measured by the millions of users, hundreds of millions even. But, if email goes down within a company it is no less problematic for those users.
I think expectations need to be re-examined in regards to cloud computing. I hate the hype around the cloud as much as anyone, but let’s not pretend all is good with services provided behind the corporate firewall. Compare realities, not false perceptions.
Topics: Cloud Computing | 3 Comments »
Review The Tests, Then The Code
Sunday, March 1, 2009
Last week I was talking with one of the developers at work and he was telling me about improvements his team was making in regards to (informal/desk check) code reviews. I told him that was great and then followed that up with a recommendation on how to improve even more. Next time there is a code review, start with the tests. This will do two things: 1) Stress the importance of having tests 2) Make the review go quicker, as the tests will either be there and make the intent of the code clear or they won’t be there and the review is postponed until tests are in place.
I know I’m not the first to make this suggestion, but I felt it was worth repeating. Code reviews do have value, even when you pair program. At least, I think they do. Pair programming provides two sets of eyes on the code at the time of creation, but it’s surprising what someone who hasn’t seen the code before will find during a review.
Oh, and if reviewing the tests during a code review doesn’t make the intent of the code any clearer, then I suggest the team investigate behavior driven development (BDD). I’m becoming quite partial to the Cucumber framework for BDD, as I like it’s emphasis on user stories with acceptance tests/examples written in plain text and backed by executable steps.
Topics: Agile, Software Development | 1 Comment »