Category Archives: agile

Standups are a waste of time

A bold statement, I know.

But get this, in the many teams and projects I’ve been on, the progression of realization always goes like this:

Standup is at 9.00am –> People can’t seem to get here on time for standup. It’s important, let’s all be more responsible –> (People still roll in right before standup) Why can’t people make it to standup on time? (And by on time we don’t mean running in right when it is happening) Should we change the time? What can we do? –> Standup is now at 9.30am –> (People still roll in right before standup) –> Standup is taking too long. We should keep our updates to only things that are relevant to the larger audience –> Now that we have the team split into functional teams, why don’t we have separate standups? –> (What people say at standup is still useless and irrelevant even in a smaller setting) –> Back to Square One.

The original manifesto of standups has been to follow 3 questions:

  1. What did I accomplish yesterday?
  2. What will I do today?
  3. What obstacles are impeding my progress?

This might seem like reasonable and fairly relevant things to say. But as smart as we think we humans are, we really aren’t. And we trick ourselves into think that although this process has done good things for us thus far, it will continue doing the same. The main goal of standup is to disseminate important information amongst team members so they they know what the goals of each day should be. If we spend the first 15-30 minutes of the day rambling, what is the point of it?

Here’s a radical thought? What if we didn’t have standups? That would require people to talk to each other frequently, maybe also sit next to each other, and be more collaborative. It’s definitely harder in a larger team setting (i.e. > 10-15 people) but we should always reevaluate process when it ceases to benefit us and requires a lot of time and effort to upkeep.

– Edited Mar 10th 2013, 10.52pm

Please don’t get me wrong, I’m not saying that standups are entirely useless, but that if utilized in the right way it could be useful, but if it isn’t working out we should think about what other things we can do instead of following process for the sake of it.

Setting up svn update in CruiseControl

It’s been a while since I’ve had to set up CruiseControl from scratch because most of the time either the project is so deep into quicksand that continuous integration is the least of their problems, or there already is a CI server up and running, or the team has decided to use another CI tool.

One issue I had while getting it up and running is configuring CI to do an subversion update before doing a build. Make sure that the cruise config file has the following lines in a specific project:

<svnbootstrapper localWorkingCopy="projects/${}" />

<modificationset quietperiod="0">
<svn LocalWorkingCopy="projects/${}" />

All the modificationset tag does is only check your repository if there are modifications but does not actually update the local working copy in your CI server. The svnbootstrapper is the one that does the actual update.

The documentation for svnbootstrapper was a little confusing because it says that it “Handles updating a single file (typically build.xml and/or from a Subversion repository before the build begins” and doesn’t specifically say that it would also be able to update entire directories.

I’d be curious to hear if people achieve the same results differently.

If anyone out there is on a Java project and starting to set up a CI build, I would actually recommend Hudson. It is free, and extremely easy to setup and you don’t even have to worry about xml configuration files. You’ll be up and running in 15 minutes or less.

Feedback: Now is better than later

In his book Extreme Programming Explained, Kent Beck says:

Extreme Programming (XP) is about social change. It is about letting of habits and patterns that were adaptive in the past, but now get in the way of us doing our best work. It is about giving up the defenses that protect us but interfere with our productivity. It may leave us feeling exposed.

Whether we like it or not, change is inevitable. One of the ways of dealing with change is practicing rapid feedback. There are a few things we can do to obtain as much feedback as we need, as often as we need it.

1. Fast unit tests
Yes, I’m a nazi about tests. But I believe and know for a fact that they are my first line of defense when it comes to creating working software.

2. Continuous integration
An addition on top of automated tests is a build that runs at every checkin, and preferably a fast build too.

3. On site customer
I want to waste as little time as possible waiting for emails to be answered or specification documents to be updated. I want to walk up to my customer and be able to ask a question and obtain an answer immediately.

4. Retrospectives
This is a practice that allows a team to learn from the mistake they made in the previous iteration, and take steps to address those mistakes so that they keep improving over time.

5. Frequent releases
Working software is the best tool for obtaining feedback. The faster you get your software out to your customers the better. That way we can adapt to the changes that are needed and progress accordingly.

Story points and Estimation

What I think story points are:

  1. Allows developers to estimate how much effort a particular task would take, relative to other tasks.
  2. Allows project managers/iteration managers/scrum masters/etc to have an idea about how the team is doing, and plan for future iterations.

Story points shouldn’t be:

  1. A target to be met, i.e. “We need to finish 300 points this iteration”. That sends the wrong message to the team and to management – that points are an accurate and the only representation of progress, the more points completed means the more work is done.
  2. Something that developers should be worrying about, i.e. “Oh, I can only do 7 points this iteration.” or “That’s too big of a task. That will probably put us over the line of how many points we can achieve this iteration.”

Story points are a tool for estimating how large or small a particular task might be. We have to keep in mind that any number that we come up with is an just estimate and shouldn’t be treated as the holy grail of truth. What happens when we are in the middle of working on a story and we realize that the initial estimate was incorrect? Going back and changing estimates can get quite hairy at times. Mark suggests that we should just treat it as part of the process that some stories will take longer than expected and others less than expected. The more you estimate, the better you will get at it.

Test Driven Development – 10 years later

Michael Feathers and Steve Freeman have a really good video talking about the phases TDD went through over the last few years. I just want to highlight the summary of their presentation.

  1. Professionals test their code.
    And when they say ‘test’, I truly believe they mean writing automated tests. Nothing manual.
  2. Separate what from how.
    What you’re testing should be set apart from how you’re testing it. For example, my colleague Mark recently spoke a little about how setting up a test correctly can sometimes turn into noise and reduce the readability of your tests. One way to avoid the noise is to use Builders.
  3. Automatic tests confirm features.
    I’ve heard people say things like, “I had to go back and test some of the features from last iteration because something broke this iteration”. If we had a suite of automated tests (be it functional, integration or unit), we could avoid situations like that.
  4. It’s a change in culture.
    And it still is, surprisingly. Even after test years, TDD is still a lesser known truth in some organizations. Heck, even the understanding of what a unit test is in shockingly lacking.
  5. “Working” isn’t good enough.
    A lot of times we say things like “I tested the code, and it’s working.” So what exactly does ‘working’ mean? Does it conform to the business’ expectations? Does it perform well? Another colleague of mine, Phil, wrote about the 3 Things Agile Teams Should Care About – what does it mean to be done?. Let’s forget about being Agile for a moment and just focus on getting a particular functionality working the way as the business expected consistently.
  6. Listen to the tests.
    What should you do if the tests are failing when you run the build? What should you do when the tests fail on the continuous integration build? We should listen to them. Tests are a feedback mechanism. They ensure the integrity of our system and we need to make sure that we pay attention to them at all times.
  7. A working system provides feedback.
  8. Focus on intent.
    What is the intent of the test that you’re writing? Is it expressed clearly in the method name? Are we just testing getters and setters or are we testing the behavior of the code?
  9. When you’re lost, slow down.
  10. It’s not only about testing.
  11. Legacy code is code without tests.
  12. Understand the principles behind the practices.
    Agile advocates individuals and interactions over processes and tools. Behind every practice is an intent. We should understand the intent first instead of blindly following the practice lest we fall into the trap of using a practice for a sake of using it.

Book Review: Lean Software Development – Build Integrity In

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

Chapter 6: Build Integrity In

What I Learned

  1. Perceived Integrity is affected by the customer’s whole experience of a system: how it’s advertised, delivered, installed, accessed; how intuitive it is to use; how well it deals with idiosyncrasies; how well it keeps up with changes in the domain; how much it cost; how timely it is; how well it solves the problem. The measure of perceived integrity is roughly equivalent to market share, or mindshare. If you had to rebuild your computer tomorrow, how many products would you load? If your bookmarks were wiped out, how many would you add back immediately?
  2. Conceptual Integrity means that a system’s central concepts work together as a smooth, cohesive whole. The components match and work well together; the architecture achieves an effective balance between flexibility, maintainability, efficiency, and responsiveness. Conceptual integrity is a prerequisite for perceived integrity.
  3. The key to achieving integrity is through detailed information flow, from customers and user to developers and between the upstream and downstream processes of the development team. In line with the Agile Manifesto – Individuals and interactions over processes and tools, Customer collaboration over contract negotiation.
  4. Refactoring and continuous improvement is of utmost importance. This is a tribute to Pat Kua after he complained that I missed out that part in my review of Clean Code. No code (or product, or practice) comes out perfect the first time we write it. We start with something that works, learn from its weaknesses, and improve on it. Pat talks about the red-green-refactor practice in TDD (Test Driven Development) which is basically starting out with a failing test (red), making it pass (green) and then making the code better (refactor). This practice can also be extended to be applied to iterations, where we have retrospectives (refactor) to figure out how we can do things better in the next iteration, etc.
  5. Testing – my favorite software topic of all times. Developer tests assures that the code does what the developer intended it to do. This includes unit, system, integration tests, etc. Customer tests assures that the system will do that customers expect it to do, and are run throughout the development, not just at the end. Customer tests are sometimes also known as acceptance tests. So why are tests important? Why are some people so obsessed about thoroughly testing a class or a feature? And why should they be run throughout the entire development process and not just at the end? Wouldn’t it be better if we dedicated a 50-person team of testers for 3 months after the development is done? Tests are invaluable because:
    1. They unambiguously communicate how things are supposed to work.
    2. They provide feedback on whether the system actually works the way it is supposed to – and we would ideally want this feedback as soon as possible, not at the end of the project.
    3. They provide a scaffolding that allows developers to make changes throughout the development process – I recently just bought Michael Feathers’ Working Effectively With Legacy Code (and I’m quite excited about it) and read the chapter on Testing and he says that tests act less like a safety net to catch you when your code goes bad, and more like a cloak that wraps around the code and keeps bad things from seeping out to other parts that you’re not currently changing.

    If you are running tests manually anyway, going through the motions of making sure the system still works as it should every time you change a piece of code, wouldn’t it be great if we could turn those motions into a test and build a test suite that gets automatically run every time we check in? It turns out, we can!

Book Review: Lean Software Development – Eliminate Waste

Lean Software Development: An Agile Toolkit for Software Development Managers Lean Software Development by Mary and Tom Poppendieck

I picked up this book wanting to know what the hype was about Lean and how its principles can be applied to Agile software development in general.

Chapter 1 Eliminate Waste

What I Learned:

  1. Anything that does not create value for a customer is waste.
  2. Learning to see waste.
    The 7 Wastes of Software Development.

    • Partially Done Work – e.g. Writing requirements for stories that might or might not be played in the near future.
    • Extra Processes – How much paperwork is necessary? A good test for paperwork is to see if there is someone waiting for what is being produced. Consider writing customer tests instead of requirements.
    • Extra Features – Developers have the tendency to want to write cool code, just in case. But extra code means extra effort for maintainability, it increases complexity and is also a potential failure point. Code that is not used could also become obsolete
    • Task Switching – Dividing someone’s time between a project management role on one project and a developer role on another project seems like a time-saving move. But would that guarantee each project to finish within their timeframe?
    • Waiting – Delays are common in many software development environments. But does that mean it is okay for delays to happen? Delays keeps the customer from realizing value as quickly as possible.
    • Motion – When a developer has a question, how much motion does it take to find out the answer? Various artifacts move as well and each handoff of an artifact is fraught with opportunities for waste.
    • Defects – These are inevitable in software development but waste caused by a defect is the product of the defect impact and the time it goes undetected.

    3. Value stream maps show that non-development activities are the biggest bottlenecks in a software development value stream.

I do sometimes go about activities just for the sake doing them but rarely find the time to step back and assess whether it’s valuable to the customer or if I’m wasting time. Keeping an eye out for waste is a good tool to have and is related to a previous post of mine about delivering business value.

What makes you Agile? Help complete a survey to find out!

I recently wrote a post about whether or not we are practicing Agile the right way and what are the practices we have forgotten about or consciously left out because they made us feel uncomfortable.

Jurgen Appelo is running a survey that might give us an idea which practices are really “Agile”, and which Agile practices are really important and which ones are actually applied on how many projects. Please help out by participating! Jurgen’s survey is the first that doesn’t focus on coarse-grained methods like Scrum or XP but rather on 66 fine-grained individual practices.

Are we walking the Agile talk?

I recently watched this video of Uncle Bob. He asks the hard question, why are we still talking about XP (or Scrum or Agile for that matter) after 10 years? There are many organizations that claim to practice Agile and claim to be experts on it but there is always something (or a few things) missing and they continuously run into problems like painful deployments, constant broken builds, features not making releases on time, miscommunication between stakeholders and developers, etc. Issues like these are common to software development teams but Agile is supposed to help solve some of them.

So what are we missing? What are we not doing right?

In a recent conversation with a colleague, I posed these three questions.

  1. What have you experienced to be a project’s biggest pains?
    - lack of communication
    - broken software being deployed
    - dependency of 3rd party components in the build
    - long meetings to define and discuss stuff instead of just trying them out and seeing what happens
    - upfront analysis and having to redo it later
  2. Do you think those teams of yours were practicing Agile right?
  3. Do you think that practicing Agile right would help with the pain points you have experienced?
    I think we should cut the the meetings and try the set based concurrent engineering approach of lean, i.e. more prototyping. We need more people to care about the quality of what we produce. We should analyze as we need to, not up front. That would make the project more fun for people, more like they are producing something worthwhile. Colocated teams would improve a lot of things.

What are the things we should be doing to make sure that we’re practicing Agile properly? My colleague, Liz Keogh, recently wrote a post entitled What does “Not Agile” look like? and exhorts us to examine if we’re actually doing Agile justice. I think we’ve arrived to a point where we have talked about Agile enough and should actually be doing it right.

In Uncle Bob’s video, he points out a few things, and I paraphrase:

XP did not set out to conquer the business world, it set out to make it easier for a small team of programmers to do a good job. So what got left behind? The technical aspect of Agile. Scrum focuses on features, we have to go through the backlog, feature after feature, banging it all out, architecture and design doesn’t get attention. XP however is all about architecture and design. We improve on them iteration after iteration.

Who here has been significantly impeded by bad code? So why did you write it?

The only way you can get done on time is to refuse the mess. You want to go fast? Don’t rush. Seeming fast is not being fast. We are often seduced by the seeming fast. Refactoring is the act of changing the structure of a piece of code without changing its functionality. It shouldn’t be something we put on the schedule, we should be constantly doing it.

In this other video, Robin Dymond talks about how Lean helps to take Agile to the ‘next level’ and why organizations that fail to change will not have successful Agile teams. He also believes that organizations will need to reorganize around teams to get the most our of Agile.

Just hot off the press, my colleague Mark’s views on Lean and organizing teams for better efficiency.

I think that Agile is about weeding out the practices that don’t work and replacing them with ones that do. It’s all about embracing change and working towards a perfect software development environment, however far-fetched that might be. I think we should still try.

The architect said what?!

One of the many responsibilities of a software architect is to see and understand the big picture of an application. To be able to do that, the architect has to understand the functions of each component in that application, the interactions and dependencies between those components and ideally, have contact and knowledge of other applications within the organization.

A software architect in many software organizations can be likened to an army general who sits comfortably in a well-aired tent in the middle of an army camp. The territory of war is mapped out in front of him on a large table complete with miniature soldiers and canons. (Let’s just ignore the fact that I do not know any war-related vocabulary and go with the flow here) The general never climbs on the back of a horse to ride into battle but barks out orders from his leather chair.

I see a few problems with this situation. First, the general does not interact with the people under his command. The only contact they have with him are his orders. Second, the general has no interaction with the civilians who also have as much a part to play in this war as he does. All he knows about what is going on on the ground are through his spies.

In the same way, many software architects have no real interaction with the developers that are working with him/her except when there is a design discussion or when they are being told what to do and how to do it.

In one of my previous projects, I had the pleasure of actually pairing with the resident architect, or that was what they called him. He had a deep understanding of the application and all its components and could even point you to the line of code for a certain functionality. I found it exceptionally valuable to have him available for pairing in between his meetings and such.

Being a software architect means being able to have a 60-foot view while the developers are busy fighting small skirmishes on the ground. It is more than just dictating the design for a certain functionality or being able to draw pretty pictures on the whiteboard. Being connected with the code and the developers means you have a good view of the code at a 3-foot level so you can increase the magnification when you’re at the 60-foot level.

Architects were once developers too and should still be writing code! (and I mean production code, not just spike code)