Embrace Change, But Never Force Change

Being on new projects brings lots of new opportunities for learning, especially when dealing with lots of new people. I consider myself one of the more experienced agilists on our current project and I realise that the way I am used to working on projects will be fundamentally different from one that hasn’t had my experience. I like things to be fast, dynamic, self-empowered and interesting but this isn’t always the case for everyone.

As I further refine my skills as an agile coach I like to approach projects with an observe-advise-implement mantra all based on developing trust and getting the most effective results for the project, team and business. It’s all a very tricky balance to maintain as often these goals are not aligned with each other.

One of the benefits of being fresh on a project is that you can bring a different perspective and suggest improvements to parts that others may have already developed a thick skin towards. One of the things that, as a new person, have to change is the way in which you worked on previous projects.

I heavily disagree with evangelists that need to apply the same practices on their current project simply because it worked on their previous project. As a change agent to a project, you want to avoid changing things simply because it’s not the way that you’re used to working. Applying the same practices from previous projects may never work because you are dealing with different people with different skills and strengths.

A better approach is to highlight any weaknesses or inefficiencies you might see incrementally and suggest alternative practices that might work better since there might be a plethora of them to choose from. You want to get as much of the team involved as possible with making a decision since people resent having change forcibly thrust upon them.

As a process coach, you need to respect that everyone has different abilities to cope with change and like with most good things, introduce them incrementally.

The Anti Screen Saver

Build information radiators are useful for improving the visibility of the state of the build – bright green if it’s good, or bright red if it’s broken. On our current project we’ve been trying to assemble all the hardware to get some lava lamps going, but in the meantime we’re using a very old PC and its tiny CRT monitor to glow bright green or red.

A problem we had was the Power Options settings turns off the monitor after 20 minutes of (in)activity and it’s been too difficult to get Administrator privileges for the machine. Although not necessarily the most ideal solution, the most amenable one for Friday was a small program that moves the mouse cursor every the minutes. Get the results here if you want.

Usage:

java -cp MouseMover.jar <number of minutes each time you want the mouse moved>

Jumping through too many hoops just to complete one loop?

Feedback Loop of Java ProgramsOne of the benefits you get with consulting is that you get to see a variety of applications, processes, and in agile projects, different build pipelines. I take the developer loop very seriously, because how quickly you can get feedback determines how quickly you get serious things done. Different testing strategies are an important way of improving the amounts of feedback (as long as you can still write meaningful tests). Another technique is the ease with which you can configure various libraries, integration points and environments. Even splitting the build into various stages where failing earlier is more appropriate can help you get better feedback.

Feedback Loop of Interpreted LanguagesThe ultimate feedback loop I’ve seen in Java is the “change-compile-run test” loop. Anything more and you will decrease your feedback cycle and adversely affect how fast you can develop. Anything less than this is unacceptable – skipping the “run test” stage doesn’t do anything to validate that what you wrote actually works. On a side note, in an interpreted language, the loop is even tighter, simply being “change-run test”.

J2EE’s “Enterprise” Feedback Loop
I’ve worked on numerous J2EE systems that were all business successes. As a developer though, it still makes me cringe thinking about the feedback loop, and how long it takes to make a change to a class, or one of many, many XML files, jar up something several times, and then actually test it.

Feedback Loop of J2EE Applications

Optimising Your Build Loop
Visualising your build process is an excellent way of seeing exactly how many hurdles you have to go through to get any decent feedback. Even better is trying to work out which things you *really* need in a build and removing anything that just doesn’t add any value. I try to aim for the simplest and fastest feedback that you can get using the above diagrams as the ultimate goal. Give it a go!

It’s Never Been About The Hours

StopwatchI started at a new client yesterday, and we had a great conversation on my thoughts about working overtime. Anyone who has worked with me in the past knows that as a principle, I heavily dislike working overtime. I think I provided some pretty good reasons and thought I’d write about it.

I am a big believer in the “Sustainable Pace” concept because I think that quality software development is a limited resource. Even though I dislike working long hours, they’re inevitable because of various reasons, and when I’ve worked long hours, and witnessed other working long hours, I’ve observed developers get tired, and when they get tired, they get sloppy. For a project that will be running for a long time, you really don’t want that.

The reason I think of it as a limited resource is because if you have ever done solid software development, you will find it requires constant judgement, thinking and in general just solving problems and puzzles all day. It requires a large number of micro decisions and is a tiring exercise with a physical limit for how well you can sustain this before quality starts to suffer. Imagine playing sudoku all day long and see how long it is before your brain starts to tire (and I just did that with the amount of flying I recently went through!)

Of course some people handle this differently. Some developers I know, prefer to spread out this thinking with various breaks of checking email, surfing the web, etc. I’ve heard of stories where some developers will do these bursts in a series of several consecutive long days, but have lots of down time in between. These developers should never be confused with developers who are just lazy and continually check email, surf the web, or better yet “work from home”. I also think that the latter developers have no pride in their work and should not be in our industry.

I do agree that in some circumstances, it is important to be able to tap into “extra hours” and that it should be exceptional circumstances. The illusion that needs dispelling is that there are no “extra hours”, and that at some point, developers will need to rest and to be effective.

I suggest to business people who I’ve worked with that it is better to maximise the value you can get out of the limited resource, instead of trying to mine more of the resource. Oh, and did I mention that maximising business value is what agile is about?

Testing According to the Capability Maturity Model

  1. Initial – You don’t test or manually test in an ad hoc manner
  2. Repeatable – You start building test suite(s) that can be run repeatably
  3. Defined – You automate your test suites and run them in a continuous integration environment
  4. Managed – You start observing metrics from the tests such as how good the coverage is, how long it takes to run and how difficult they may be to write
  5. Optimising – You start to make changes to your code to make it easier to test, and you use the tests to highlight areas that need refactoring or a redesign. You start running Test Driven Development or Behaviour Driven Development to enhance the testability of your code.

After applying the CMM to way I execute testing, I find it interesting that the practices that emerged from the agile community are heavily biased towards the higher end of the CMM. There’s definitely a message here.

Disclaimer: This list was created by myself and does not reflect any official source associated with the Software Engineering Institute (SEI). It was written by me in terms of thinking of how I have seen testing executed and then trying to describe it in terms of the CMM.

A Retrospective Timeline

The retrospective timeline is a useful exercise for gaining a better understanding and a richer context for a particular retrospective. This means that this exercise becomes less useful when you do retrospectives more frequently and especially useful when doing a retrospective spanning longer periods or you run retrospectives less frequently.

Goals
The timeline aims to give a very visual overview of the events that occurred during the period for which you are doing the retrospective. The facilitator should use distinct and bold colours to identify distinct events so that it is easier to interpret the results. The timeline is a great way of determining trends over time for periods in the project and a useful mechanism for getting a feel for how the team felt throughout the course of the project.

When To Use It
As mentioned earlier, the timeline retrospective is useful for refreshing the memories of participants and you might find it useful in the following circumstances:

  • For projects that are run without any intermediate retrospectives
  • For projects that require more formalised processes (i.e. not necessarily uber-agile)
  • If you need to communicate a more complete perspective for outside parties that may require reporting to
  • If all participants did not necessarily work on the project during the entirety of the project (people rolling on or rolling off)
  • The end of a project retrospective

The Fundamentals (Part One)
There are two major parts to this exercise. The first is noting all the events. Make sure that everyone has access to different coloured pieces of paper where:

  • Green represents good events
  • Yellow represents significant or memorable events
  • Orange represents problematic events
Retrospective Timeline Colour Chart

The types of events that you might want to consider suggesting include things like when people rolled on or off projects, when things kicked off, when someone in the business made a decision that affected the team in a great way, when the team did achieved something really amazing, etc.

Get everyone to scribble each event down on separate pieces of paper and then get them to tack it along a standard timeline along a whiteboard or several sheets of paper stuck to the wall. This is where sticky notes or lots of blu-tack helps. It should look something like the following:

Events along a timeline

It is a good idea for you to get everyone to explain events, especially if the participants may not have full knowledge of what was going on. The significant events help to put things into context and might answer a few of the puzzling questions some people might have about the project, and the good points help to identify strengths while the problematic points should lead you to discussing action items. I find this exercise is most useful for first putting context for a retrospective spanning a large time and then using other exercises to draw out further conclusions. It is a good mechanism just to get the discussions flowing within the team and allows the facilitator to try to put different perspectives on things.

The Fundamentals (Part Two)
The reason you want to reserve some space underneath the timeline is for the second part of this exercise. In this part, you split the remaining area into two sections where you get the team to fill in how they felt about each event or how they felt in general for that period. You can try to limit them by getting them to put three dots per significant period (week/month) or perhaps one per event posted, with the idea that you want to get a general feeling for the overall morale of the team. You should end up with a scattergram that looks like the following:

Team morale along a timeline

Once the team has finished plotting all their points, you can then try to draw a trend through them that helps to establish a real idea of how the project went such as below:

Trends during the timeline

Trawling The Timeline
The visual nature of the timeline allows you to easily draw out a number of trends from the project. Large concentrations of a particular colour may attract your attention to a certain period and it would be worthwhile trying to pinpoint its underlying cause so you can attempt to replicate (or avoid) the same circumstances in the future. The general trend at the bottom may or may not coincide with the events above the line so there might be another discussion point for explaining why morale might be low even though there might be lots of green or why it is high even though there were problematic events (maybe it was a good team building experience or people were growing and learning).

Agile Mythbusting

Yesterday I ran a session for another group at my current client introducing them to agile. The first part of this session helped me get a better understanding of what they thought of, or had heard about, or applied about agile and during this I noticed a few comments they touched on (and I hear numerous times from other people) that I thought might be worth sharing. I have found that when people observe and even when people practice some of the agile practices, it can be easy for them to incorrectly draw the wrong conclusions. Here’s a few of them and my thoughts on each:

Being agile means we don’t have to write documentation
I have never heard any agile coach nor practitioner ever say this, nor encourage this form of thinking. The agile manifesto states a value is “Working Software over Comprehensive Documentation”, with the thinking that people would rather some delivered instead of being given a document telling them what they could have had instead. You will find people trying to avoid writing comments in code because most of the stuff people write is redundant (it tells someone what the code does, when they can read the code right there and then – if it can’t be read, then maybe you have a bigger problem at hand). There are situations where comments are invaluable (libraries APIs given to external parties, or even commenting why something may not be obvious to a reader because of some bug/library/performance reason). I have found that sometimes having general diagrams with some descriptive phrases and a brief narrative is much more useful than any 300 page document might give. Consider that an hour spent in a conversation about what someone wants can be more productive than an hour spent writing and then another hour spent reading a document hastily put together.

Being agile means we don’t do design
Avoiding Big Design Up Front (BDUF) is a popular term but so easily abused. Not practicing BDUF is not about not doing *any* design and is even worse for a justification of a *poor* design and is a very big judgement thing. We have found that some good discussion about an approach helps (whiteboarding might be involved) can be useful, but in reality the implementation will be greatly different from the original design. It is sometimes better to just do things, and refactor to patterns or a better design (otherwise referred to emergent design) because you cannot anticipate everything. UML and class diagrams may help for *communicating* ideas, but not a great idea for trying to generate the code from it as the code tends to move faster than what the diagrams can keep up with.

Agile doesn’t work with old projects
There is no reason why inheriting someone else’s code automatically implies you cannot apply agile principles. You might find that some of the practices might be more difficult to implement such as talking to the people that originally wrote the code, or find the system difficult to test, but it shouldn’t stop you from trying. It does not mean that when you get new requirements, you cannot involve the customer more, it does not mean you cannot write your tests first and it certainly does not restrict you to release changes early and get more feedback. If you find there are problems, the old project is unlikely the cause and is more likely other processes such as the release procedures or the way your operations team works. Blaming agile or the project is not the answer.

Agile is no different from other processes, we do testing in RUP (etc)
I’ve never heard any agile practitioner say that testing is not executed in other processes. Testing in agile is different because there are different levels of testing and there is an expectation for the testing to start as early as possible. By focusing on testable, releasable and value-added units, more things can be achieved by the team such as getting better feedback, and getting more value earlier rather than in one big bang at the end (that may or may not happen).