Category Archives: agile

How does testing fit in?

Posted on by
Reply

Unfortunately it was just Miquel and me at this meeting to discuss testing and how testers fit into an agile project. The discussions were based around Agile Testing by Lisa Crispin and Janet Gregory. I’d managed to read about half of it, while Miquel had managed a little less.

Miquel started off by saying that he found the book quite hard to read a possibly and little repetitive. I agreed that it seemed to be longer than it needed to be. Miquel did like the mind maps that appeared at the start of each chapter though.

ponte vasco da gama by rolhasWe talked about the idea of having the tester be a bridge between the customer and the developers. I liked this alternative approach to the traditional idea of having testers simply being the last line in the chain before software goes into production.

For me, the most important part of the book was the idea of the testing quadrants. They act as a checklist which make it easy to consider what kinds of testing you are or are not doing and if you are doing enough. There are 4 quadrants, along 2 axes. Tests are either business or technology-facing and either support the team or critique the product. There is a diagram in this blog posting which describes it a little more.

Other things which I found interesting were “Wizard of Oz” testing (p138), Ripple Effects (p143) and Exploratory Testing (p197).

Wizard of Oz usability testing is a prototyping technique where a paper mock up is animated by testers simply using pieces of paper. So it is like traditional prototyping but with the addition of a limited amount of interactivity rather than just a static picture.

The idea of “Ripple Effects” is to try to avoid unexpected knock-on effects of changes made to a system. The idea is to explicitly run through a checklist of existing areas of functionality and consider any impacts. This very simple thing is done to avoid the shortsightedness that can sometimes arise when an agile project focusses on each story as it comes up without considering the larger picture.

Finally, I liked the comparison between Exploratory Testing and the Agile Manifesto as explained by Michael Bolton. Since I didn’t know too much about Exploratory Testing before reading this, it was intriguing to see the parallels. There is an article by James Bach at Stickyminds that explains the concepts quite well.

Meeting 20 – Agile Retrospectives

Posted on by
1

We had a meeting last night at the Lamb and Flag to discuss Agile Retrospectives by Esther Derby and Diana Larsen. I was joined by Miquel, Steven, Mick, David and newcomer Graham.

Half of us had not read the book, so I explained the structure of it: The first three chapters explain what retrospectives are, how to structure and run them. The next five chapters are essentially a set of patterns. Each chapter contains a series of activities that can be carried out at each of the stages of the retrospective. The book ends with a chapter on larger scale release and project retrospectives and a closing one on supporting the changes that come out of the process.

Miquel commented that the book seems to expect you to be able to get through quite a few activities in quite a short time. Graham agreed and pointed out that many of the activities seemed too long to fit into a one or two hour iteration retrospective. I thought that this was because the emphasis is on the longer activities in the middle of the session, while the beginning and end are quite quick.

Overall Miquel thought it was a well-structured book. Graham liked the way that it gave examples so that you didn’t spend too long just thinking about theory and principles. He also thought that most of the text could apply to situations outside of agile software development. Everyone seemed to agree on this. From my perspective, the main thing to come out of the book was the five stages that a retrospective is comprised of: Setting the Stage, Gathering Data, Generating Insights, Deciding what to do and finally Closing the Retrospective. When I saw Diana Larsen talking about this at JAOO she mentioned something which isn’t in the book. That is that you need to ensure that people do the “Gather Data” stage. Technical people tend to jump to the “Generate Insights” stage and business people tend to jump to “Decide what to do”.

I thought that something that was missing was some sort of diagram to show the connection between activities. Appendix C shows which ones you can use at which stage, but it doesn’t show which ones should follow other ones. It would be helpful to had something as simple as a list, giving a one line description and which other activities it is associated with.

Mick said that when he first heard about Retrospectives he was confused about how you could solve all of your problems in half an hour. It was only later that he realised that you don’t solve all of your problems, you work out what they are and how you can start moving in the right direction. The next retrospective allows you to see how you are doing and possibly change course.

Miquel pointed out that it is suggested that the retrospective facilitator role should rotate through a development group. Having read the book though, he thought that it seemed to be quite a skilled job, so maybe this would be difficult.

Graham asked about the minimum size of team where these techniques would be useful. I suggested that even on a team of only two people it would be useful having time out from the day-to-day work to think about things. David said that going to the pub with the team could also serve the same purpose. Graham was uncertain if this would just be forum for moaning in the absence of the formal process. I agreed and said that it is fine saying at the pub “We need more tests”, but it is much better to say “We will achieve 90% test coverage in these packages within the next month”. David suggested that Big Visible Charts showing progress would be a good way to keep these targets in people’s minds.

We then drifted off into more general topics. I liked David’s story about his boss showing up around noon declaring “We need to make sure people come in earlier!”.

Interesting note: if you look carefully at the cover of the book you’ll see that the compass has the letters N,S,W and O on it. So I think it is a German compass. Strange!

Meeting 14 – Agile Estimating and Planning

Posted on by
Reply

A modest turnout for this meeting, with just me, Miquel, Steven and Mick discussing Mike Cohn’s Agile Estimating and Planning. For some reason, the Lamb and Flag was absolutely packed despite it being early on a Wednesday evening. Perhaps it was end-of-exams time, or the warm weather, but it took us a while to find a table.

The general feeling was positive. Steven found the book simple and well structured. Each chapter encapsulated a single concept very well. He gave this as an excuse for why he hadn’t finished it, because he’d read one chapter and then put it down. Twenty-odd chapters meant he hadn’t finished it. Miquel thought it was one of the most practical of the books we have covered, which I agreed with. I’m planning to use the ideas in my forthcoming project.

We then moved onto to discussing specific points in the book. Mick said he was a little worried by the ideas given for splitting user stories, particularly the part about removing cross-cutting concerns. Steven responded by saying that you do get situations where a story hides a multitude of extras that could be split out into other stories. He talked about the example of doing the login screen and moving out the complicated password complexity and failed-login aspects into a second story.

Miquel asked the question about which units we preferred for estimating story size. Everyone agreed that story points were the best. Mick made the point that the author plainly agrees, but does a good job of advocating the alternative. This seems to be a theme of the book. Mike Cohn explains at least a couple of ways to do things, gives the pros and cons of each and says what his preferred option is. He doesn’t proclaim that there is one right way.

I asked about the roles that the author talks about, especially the difference between customer and product owner. Mick said that the latter comes from Scrum. In Steven’s view the product owner needs to have some technical knowledge whereas the customer just needs the product.

I pointed out the diagram on p85 which suggests the order in which stories should be tackled. (High Risk/High Value, Low Risk/High Value, Low Risk/Low Value). I mentioned that Alistair Cockburn suggests starting with some Low Risk/High Value stories in the first iteration before following the same pattern. His idea is that you need to get the team to gel, so getting an early win is important. Steven made the point that perhaps Cockburn’s approach is tackling a different risk – that the team will not gel. So it still follows the philosophy of tackling high risk areas early on.

We then looked at the section on project economics. I was pleasantly surprised by this. I thought it might be a little dry, but it turned out to be interesting. I don’t much like the international currency symbol though. Because it is unfamiliar the figures just don’t look like money. I pointed out that despite the fact that Mike Cohn wants to avoid being US-centric (which is laudable) he still uses American sports and non-metric measurements in his examples. Mick found that the economics section just hammered home the point that agile doesn’t live in a bubble and that you need to get large parts of your organisation on board.

We then moved onto velocity-based vs commitment-based planning. I didn’t quite understand the author’s arguments in favour of the latter. Several other people chipped in and the general consensus seemed to be that story points correspond to a spread of actual story sizes. This means that if you are only a picking a small number of stories the sample size is so small that this distribution may not even itself out. So you are better off breaking the stories down into hours at this point to try to get a better idea of their true size.

I pointed out the diagrams used to explain time- and feature-based buffering (p198) in the book and why I thought they weren’t quite right. After sketching some alternative versions I think I convinced everyone. The main problem is that time is something you usually want to minimize while features are something you want to maximize. My versions of these diagrams are here (click for readable versions)
Buffered FeaturesBuffered TimeBuffered Time and Features

We also looked at the idea of using Gantt charts to communicate agile planning. Mick thought that this was a good acknowledgement of the fact that you sometimes have to change what you do to fit in with the rest of the organisation. I like the idea of subverting one of the tools of traditional project management for agile ends.

Finally Miquel talked about the different styles of burndown charts and why he didn’t like the bar style. He maintained that it doesn’t communicate very well. The traditional burndown might not show stories added, but at least it shows predicted completion date very well.

Meeting 13 – Agile Software Development: The Cooperative Game

Posted on by
1

I’m tempted to say that the turnout was a little ‘lean’ after last month’s meeting with the Poppendiecks. This time around there was just me, Tom, Steven and first timer John to discuss Alistair Cockburn’s Agile Software Development: The Cooperative Game (2nd edition).

Tom admitted that he had skipped the first few more abstract chapters, although skimming through them during our meeting he was interested to see that these early parts had more pictures and photos. He liked the book and the way Alistair Cockburn never says “This is what you should do” but found that there were times when he seemed to go into more detail than necessary in describing certain techniques. John had not read the second edition, but had previously read the original. He liked the idea of software as a cooperative game and had tried out the “information radiator” idea at work.

Steven on the other hand wasn’t so keen – he found that the book was too long. This mirrored my feelings. I really liked the first edition, which changed the way I thought about software development. But all of the extra material really weighs it down and obscures the central message. In particular, chapter 5.1 (i.e. the extra material added onto chapter 5) is almost 100 pages in length and could almost be a new book in itself! As with the first edition, I like the way the author does not say “I have come down the mountains with the tablets, here is how you make software”.

Looking into more detail at the material, Tom said he liked the idea that you should force yourself to develop in increments even if you can’t deliver that way. Recent real project experiences have led him to believe that it is worth doing incremental development even if you have to go through this kind of pretence. He also liked the sine waves on p167 showing healthy and unhealthy patterns of requirements and code stability. This also resonated with real project experiences.

I was interested in the section about motivation “Rewards that preserve joy”. I found the idea that praise could be demotivating to be a counter-intuitive one. We discussed how to give pride-in-work, pride-in-accomplishment and pride-in-contribution which are what the author suggests. I mentioned the idea that was mentioned by the Poppendiecks that you should try to run your corporate projects like open source ones, which give rewards other than monetary ones. Tom said he thought that the book contained a stereotype of open source development and that many developers in the high-profile projects are actually paid to do their work these days. John suggested that perhaps you shouldn’t give praise because once you’ve won someone’s approval, you don’t feel the need to do it again.

We then moved on to discuss the idea in the book that rather than mandating coding standards and so on it is better to have an archive of examples which follow these rules. Then newcomers can quickly get up and running. John mentioned the story where Alistair Cockburn copied some Smalltalk code and ended up using the MVC pattern quite by accident.

I mentioned that I like the idea of having a project charter (p182) which helps everyone pull in the same direction by making it clear what the priorities are and what trade-offs can be made. This reminded me of some of the ideas from Lean where you need to make it clear what value is being created by a project.

The discussion moved onto more general topics of Agile, many of them about John’s environment where there is no test driven development or continuous integration. He said that creating an installer was hard work, to which I gave him the standard agile suggestion on this: do it often, so that you have to become good at it.

Meeting 10 – Ship it! A Practical Guide to Successful Software Projects

Posted on by
4

Bravely, many of us ignored Valentine’s day to discuss our latest choice of book, Ship it, which is another book from the Pragmatic Programmers. Six of us were in attendance this time, Tom, Chris, Graeme, Dave, Steven and Andrew.

We opened the discussion by talking about our initial reactions to the book. Chris liked the concept of considering the various techniques one uses to develop as habits. Steven felt it was his favourite book thus far. Dave was curious about the idea that they suggested where you could end up checking your IDE into your source control system. Graeme thought that this was a good framework to hang other methodologies off. We talked about methods for tracking issues and bugs. Dave recalled trying post-its for a day, and said that in his experience whiteboards could work to an extent, but it really was bug-tracking software that worked best for him. Steven added that he couldn’t check up on a whiteboard when he was out visiting clients for instance, but that a proper bug-tracking system was mobile as well in that sense. Using Trac also allows Steven and Dave to view the timeline of progress and check-ins, and that almost becomes a blog in itself. Chris saw that an actual blog is something he sees as being used (in how it is described in this book) as a means of external update for the customer, although Steven pointed out that he shares his bug-tracking with his customers.

We moved on to discuss the main development methodology described in the book. Chris pointed out that although they claim to be somewhat agnostic in terms of having a favourite methodology, on p107 they state “Being agile means you must adapt whatever isn’t working to better suit your particular needs”. They are Agile!

Steven had found Tracer Bullet Development as outlined in Chapter 4 “what I’ve always done, without ever knowing what it was called.” It didn’t appeal so much to Chris. Page 111: “A different development team works on each layer, and each team assumes that their layer exists on a different computer. This means that all communication between layers is over the network”. He felt that there are massive overheads in your code if you develop always assuming this. Tom and Steven disagreed that it was as explicit as that, and saw it as a conceptual idea to bear in mind during development. Graeme felt that if it was the case, it would mean you were covered should you wish to separate the layers out at a later stage.

Chris dug a bit deeper into it, feeling that it did mean for a lot of extra work, as you would need to serialise and de-serialise objects between layers. Tom pointed to the diagram of the layers model on page 121, and said that it looked to him a lot like the old Enterprise Java Beans layers model. Chris saw that it went against Martin Fowler‘s first law of distributing data objects: Don’t distribute your objects. He was also curious about how TBD allowed collaboration over the definition of interfaces. Steven pointed out that their approach to interfaces went against the shared ownership of code principle that Agile observed.

Dave saw this method as designing in a vacuum, his analogy being that it would be like drawing a character for a video game without having an idea of the environment it was going to be placed, the resolution and screen size. Tom didn’t like the idea of using Lego bricks to serve as objects when discussing the design, and bemoaned the lack of stories. He also agreed that the lack of crossover between areas seemed somewhat un-agile.

Chris noted that he did find the “do the hard bits first” idea appealing. Graeme pointed out it was like Agile/XP in some ways, but it certainly didn’t fit with what they would do in a first iteration of development, where they would both aim to provide working code, rather than simply pick the tough areas to develop.

There was then a discussion about how testing was dealt with in the book, and how members of the group found testing did and didn’t work. Steven found it quite inspiring how they showed so many different types of tests for different reasons. Tom pointed out that a lot of people seem to end up writing their own build systems, or altering existing ones substantially. It does seem to suggest that a lot of people are not happy with what is presently out there. Graeme noted that the book only offered 3 or 4 possible build systems, and Steven bemoaned that we were all lucky with Java, and that he had it far worse finding testing tools for dealing with C/C++ development. Chris and Tom pointed to Rake as something they had found very flexible for build systems, more so than Ant.

Steven thought that the methodology for code review in the book was wrong, the idea that you don’t check in until you’ve been reviewed. Graeme said that it prevented other people finding and solving issues in your code at an earlier stage, and Steven noted that they do make a slight reference to pair programming as being a possible solution for such issues, but that they don’t really push it. Dave thought that code reviewing to this extent was utter overkill.

We then briefly discussed stand-up meetings, and the project logs, before drifting into an extended discussion of where we learnt to code initially, and bemoaned the lack of opportunities for people to learn in the same manner as we did.

Take Home points from the evening:

Tom

  • Lots of very similar practices and tools that I use, but there are also many contradictions.
  • Their own experiences are interesting but they don’t always link them to well-known practices or methodologies.

Chris

  • Hmmm, do you really need to worry about different layers on different machines?
  • They don’t signpost where the ideas come from e.g. “This idea comes from Scrum”.

Steven

  • Tracer Bullet Development – Layers on different machines seems over the top and complex.
  • Define interfaces – why can’t a developer on one layer change other layers?
  • Do risky/complex code first.
  • Tests – Fish-eye tests?
  • Rule – don’t stare at a problem for any more than thirty minutes before asking someone for help (a concept suggested by Chris).
  • Testing – split into different kinds of tests for different occasions.

Graeme

  • The basic diagram for their suggested infrastructure is very useful, basis of whole book, and a good methodology for development I suspect.
  • Very good set of specific solutions at the end of the book for dealing with a wide array of issues that may arise from implementing their methodology, more practical than other approaches we have read about.

Meeting 7 – Practices of an Agile Developer

Posted on by
Reply

The same six people showed up for this meeting as last time: Adrian, Graeme, Miquel, Steven, Tom and me. Most of us had read the whole book, with just one or two of us not quite getting to the end.

Miquel started the discussion by saying that overall he thought it was a good book, covering a set of things which could be characterised as Common Denominators from Scrum, XP, Domain Driven Design etc.

Having not read DDD, Adrian was interested to know which parts mirrored that book. Graeme mentioned the Project Glossary, which has many similarities to Eric Evans’ Ubiquitous Language. (Later on, I pointed out that Command-Query Separation mentioned in the ‘Tell, Don’t ask’ section is like Side-effect free functions also mentioned in DDD).

Adrian said he found it less evangelical than other agile books, XP Explained in particular. He was especially keen on the ‘How Does it Feel?’ sections. Miquel agreed that he liked them too. Graeme also mentioned that he felt it had a moderate feel to it. Later on in the discussion he likened the ‘How Does it Feel?’ sections to unit tests. You know if your practice is working if you get the right output.

Steven was a little worried that it might be a little simplistic and that you only needed to read the chapter summary to know what was going to be said.

Talking about things that we didn’t like, Miquel felt that the keeping of a project log would be difficult and that this idea was a little Utopian. Adrian admitted that he used to do this, but didn’t do anything so formal any longer. I suggested that it would be difficult to write a good enough log that it would be useful for others encountering similar problems later on.

I pointed out the section where it says that there are no roles in Agile projects, which seemed a little odd to me. Adrian thought that they meant rigidly fixed roles. Graeme pointed out that there is discussion of the Lead Programmer being the Architect, but otherwise this topic is rather fuzzy in the book.

Adrian suggested that there was a similarity to XP Explained v2 with its Primary and Corollary practices. I didn’t feel this, it felt more like a collection of practices but without an overarching structure. Graeme pointed to the section at the end where there is discussion of introducing Agile. This part does seem to suggest that some practices should be brought in before others. He went on to say that some of the practices seemed to be merely teaching good manners.

I pointed to the section where there is discussion of using an automated issue tracking system. I felt this was interesting as many agile practitioners are very keen on paper based systems. Adrian suggested that if you are in a situation with a large number of bugs coming in then you’ll need something like Bugzilla, but that your aim should be to reduce the bugs so much that it is no longer needed. Tom said that in his previous job they’d used Bugzilla and it had worked well and Graeme mentioned its use in Open Source.

Adrian brought up the question of whether it was a good or bad thing that this book uses less of the Agile Jargon than others. I said that I thought the Jargon was useful in a similar way that Pattern names are useful. It gives a handle to make discussion easier. However, I thought that perhaps toning this down was fine for a book aimed at beginners, such as this.

We then moved on to a discussion about the things in the book that seem like good advice, but are not really agile. Adrian highlighted ‘Tell, Don’t Ask’, ‘Cohesive Code’ and ‘Substitute by Contract’, while Tom pointed out ‘Useful Error Messages’.

I mentioned the advice to ‘be the worst member of the band’, which is easier said than done. Adrian said that he’d seen situations where people were not hired because they would be too good and would threaten the existing lead programmers.

The next topic was Pragmatism versus Agility, since this book comes from the Pragmatic Programmers. Steven suggested that being Agile is about being pragmatic so only doing what is needed today. I suggested that this book is almost a sequel to the original Pragmatic Programmer book. Adrian had an interesting take on the difference between the Pragmatic and XP philosophies. He suggested that the former was more about making things better in your current environment, where XP tends to take the opposite approach of trying to change your environment to make things better.

We rounded things off by talking about where this book sits in relation to others. Graeme thought that this book had a different focus to others such as XP Explained in that it focusses heavily on the individual. Adrian said it was a book to give someone who was sceptical about agile and said that he would be giving a copy to his manager.

Meeting 6 – XP Explained

Posted on by
1

This past Thursday we met up at Far from the Madding Crowd again, to discuss Kent Beck’s Extreme Programming Explained. The intention was to see how the second edition had changed from the first, as a couple of us had already read them both once, and found there to be something of a change in tone. In attendance were Adrian, Steven, Miquel, Chris, Tim and Graeme.

Adrian kicked off proceedings by suggesting that in re-reading the second edition, he had found it very different to his first reading, in that it didn’t seem as different in content as he had thought. The tone however was what was different, possibly pitching the ideas to a different audience. Some of whom might have for instance “tried paired programming, and it doesn’t work”, and thus dismissed Extreme Programmings concepts altogether, where they may still have much of value to learn from it. Chris agreed that it had a more relaxed done, possibly even less evangelical. He pointed out that Beck shows examples of where projects he had brought XP to had failed, and worried that if he can’t persuade people to work more fully with it, who can? Steven felt that the practices described were the same, but that it was the values and principles that were now more muted.

We then looked at some of the inconsistancies we’d come across. Chris mentioned the example about planting marigolds next to strawberries. “Planting them together is a practice. Companion planting is the principle” (P15). He felt that surely this was the same thing. Miquel showed us the concepts of Team Continuity (P63) and Shrinking Teams (P64), and noted that keeping a team together was contradicted by the idea of shrinking a team when a member was no longer needed for an exact task. Graeme also observed that this went against the principles of safety and job security that were exposed earlier by Beck. Adrian added that he had never seen shrinking teams work in action, which Steven agreed with, having seen in his experience that projects always expand to meet their resources.

We then discussed the practises of XP. “Practices are a starting point only”, Chris pointed to, which seemed a less rigid approach than previously taken. Adrian wasn’t happy with this, and felt that the starting point was to define the values. We also looked at the statement that energized work “can’t be proved with science”. Miquel pointed to page 59, where it said that it should be possible in some way to make it more effective. He questioned if Beck proved it, is XP a silver bullet? Graeme added that he was disappointed that there were no examples from the XP community in the book, which may have added to his proof somewhat. Miquel added that without proof, it is hard to persuade a boss that less hours can be more productive.

There was then a more general discussion of the two books. Adrian felt that the tone of the first edition was almost “this book can improve your life!”, whereas the second was somewhat more muted. It also seemed to suggest that the second had less work to do in persuaded the wider developer audience of some of the principles, that alternate ways to the waterfall method of development were generally accepted, if not practised. He particularly liked the idea of having a quarterly cycle atop the iterative cycle, this brings a different perspective to the process, lets you look at the wider picture. Chris had found the first a revelation, that finally there was another way. Tom said that he was slightly sceptical of the test-driven design style, that in particular he sometimes need more code just to know what results he will get in the end. Adrian pointed out that he had had good results with using unit tests in Perl. Miquel added that individual tests should ideally be no more than 5 or 6 lines long, and that perhaps if your tests are too long, that they aren’t always the right tests.

The next topic was estimating and timings. Chris didn’t quite see why Beck had changed from using points in estimations to using time, as if the timings on a project changed, it was much more work to change all the timings, whereas with points it is just a matter of changing the budget, and leaving the same points values on all the stories. Adrian’s present role involves him having to estimate in time, and he did feel he was more accurate with it. Tom’s experiences were that points were more accurate for him, he said that when they were converted into times they looked wrong, but would often be very accurate. Miquel moved onto the allocation of stories, and warned that he felt people would tend to cherry-pick stories, and that the last-picked stories could be the worst. Steven pointed out that different people were suited to different tasks, and that choosing the most suitable for each individual may be better anyway. We then compared some of the build processes we used.

There was then some more general discussion about points in the book. We looked at the Primary and Corollary practices, with Adrian being surprised that real customer involvement was considered corollary. The corollary practices seemed to be the harder to sell to none-XP people, and also harder to implement. It also seemed that problem-solving using the 5 whys method seemed a bit random, although Adrian pointed out that the message may well be to question more intelligently. There was a general feeling that this also improved where the whole team was involved. Steven noted that he felt as he developed more as a programmer, he learnt that the team beyond the programmers was more important. Miquel said that maybe XP has application to disciplines other than just programmers. Adrian agreed, and said that it was better to get the other roles working in an XP manner if at all possible.

In conclusion though, we agreed that we had taken a very critical approach to reading and discussing the book, and that overall it was very inspiring to most of us.