March's AgileNorth - Applying Agile Software Practices to Consultancy Projects

This month's AgileNorth was a short presentation and following discussion on Applying Agile Software Practices to Consultancy Projects.

The 20-odd slides were presented by Simon Monk, CTO of Momote (Momote's wikipedia page). Momote offer products that allow the development of mobile applications that will run on any device from a consumer Java phone to a Windows Mobile PDA.

Simon has worked in an agile development way for some time and now wants to create a consultancy group that can work in an agile way. Momote are 6 months into offering consultancy services and have a small XP team for the main development of their MX platform. At the moment they have one consultant but are growing that team to three or four in the very near future.

Momote don't want to follow the traditional consultancy process which was described as:
* lengthy (and therefore costly) detailed requirements gathering
* Big Design Up Front - BDUF
* Severe project management - Gant charts, Microsoft Project, etc.
* Waterfall model of software projects - development, testing, delivery

They hope to offer a new way where they have happy customers & consultants, real & accurate project estimates and much more flexible requirements (so that the customer actually gets what they want rather than what was captured in the initial requirements capture session). They hope that the client still gets the security of fixed priced contract but with added flexibility and feedback that the agile approach can provide.

Momote wants to try and capitalise on the following agile practises:
* low cost estimates - requirements gathering takes about a day not weeks
* task estimates
* velocity & tracking
* flexible scope - customers are allowed two significant changes
* customer involvement

They have come up with a simple way to categorise projects to be able to give 'ball park' estimates to clients as part of their non-chargeable requirements capture phase:

Cost	Small	Medium	Large
Requirements	2 days	4 days	5 days
Development	10 days	20 days	40 days
Handover	3 days	4 days	5 days

As part of the output of this phase they produce a five to six page requirements specification which includes the initial project plan on the back page. They then follow up with the client by the use of weekly web-based review meetings. These meetings allow the client to review the work done so far, see how the actual productivity of the consultant matches against the estimated throughput and provides an opportunity to change the work plan for the following week.

They have found that a minority of customers are "too busy" for the weekly update meetings and just want Momote to produce what was initially discussed, but so far most clients have been very accepting of the 'new way'. In fact it was mentioned in the discussion section after the presentation that the weekly meetings seem to be key to the whole process working well.

A few software tools were mentioned in the discussion that followed:

Trac

Trac is an enhanced wiki and issue tracking system for software development projects. Trac uses a minimalistic approach to web-based software project management.

I've blogged previously about:
Installing Trac on Linux (Debian Stable)
Creating a Trac instance on Debian Linux

Trac plugins

Confluence

Confluence is an enterprise wiki that makes it easy for your team to collaborate and share knowledge.

Jira

JIRA is a bug tracking, issue tracking, and project management application developed to make this process easier for your team. JIRA has been designed with a focus on task achievement, is instantly usable and is flexible to work with.

HttpUnit

HttpUnit emulates the relevant portions of browser behavior, including form submission, JavaScript, basic http authentication, cookies and automatic page redirection, and allows Java test code to examine returned pages either as text, an XML DOM, or containers of forms, tables, and links.

Watij

Watij (pronounced wattage) stands for Web Application Testing in Java. Watij is a pure Java API created to allow for the automation of web applications.

Technorati Tags: AgileNorth, Consultancy, Simon Monk, Momote, Andrew Beacock

January's AgileNorth - Theory of Constraints (TOC)

The first AgileNorth of the new year was kicked off by an active session on the “Theory of Constraints” run by Kevin Rutherford and David Draper.

It was a re-run of a session from the Agile North conference - I'm not a Bottleneck, I'm a free man!

The Theory of Constraints (TOC) is a management philosophy that aims to continually achieve more of the goal of a system. Every system or process must have at least one constraint, which prevents the system from achieving a better result relative to it's goal. In order to increase the performance, these constraints must be identified and removed one by one.

There is a five-stage process to go through to follow TOC once you have clearly identify what the goal of the process is, e.g. better quality, more widgets, less wastage:

1. Constraint
   Find the largest constraint that is holding you back from achieving that goal. Note: you are not trying to fix any and all problems or possible optimisations that you find, just the largest key bottleneck.
   
2. Exploit
   Try to optimise the bottleneck to get maximum performance, e.g. remove any unnecessary tasks (timesheets, walking across the factory floor, etc.) from a worker who's duty has been highlighted as the bottleneck.
   
3. Subordinate
   Move some of the constrained worker's tasks to other people/processes to free up the key worker to allow the bottleneck to be removed.
   
4. Elevate
   If the above “free changes” (exploit and subordinate) don't help remove the constraint then introduce a “costly change” e.g. training, additional staff, etc.
   
5. Repeat
   If the constraint has now moved, go back to step one and repeat the process.
   

The focus is always on one constraint at any one time – never attempt to address more than one problem area.

The main part of the evening was spent doing a practical exercise that demonstrated the Theory of Constraints quite clearly. The goal was to maximise the number of paper hats and boats pairs made in a short period of time. There were 6 of us attending so we formed a circle and were given different roles perform:

• Analyst – received paper of differing sizes from the supplier and was told whether it would be a hat or a boat
  
• Designer – would perform some of the critical early folds
  
• Developer – did most of the folding of the paper
  
• UI – added pictures to the sides
  
• Tester – ensured that the made objects stood up, had the correct design, was neat and tidy, etc.
  
• Production – checked quality and released 'product' - hat/boat pairs.
  

The first round started and we immediately noticed that all the paper was stocking up by the developer who was starting to rush and make mistakes, most of the rest of us were sat around doing nothing. Therefore the 'constraint' was the developer. We struggled to see how we could 'exploit' the developer so we 'subordinated' some tasks: we decided to ensure that it was clear whether the item was to be a hat or a boat (this had caused confusing during the first round) and would pass the paper to the developer in order, hat – boat – hat -boat to ensure enough 'product' was released.

On the second round we noticed that the bottleneck was still with the developer, the boats were taking nearly twice as much time to make as the hats. We decided to 'elevate' the constraint by 'training' the UI guy to take over the creation of the hats so that the developer could concentrate on the more complex boats. This time most of us were sat doing nothing for longer and yet we were able to get more products out the door – we were more productive whilst doing less work!

With the 'training' complete ;) we performed the third and final round and this time came out with some very positive results. This time the constraint had moved to the designer who was having to reject certain paper sizes due to it being too hard to make the hats and boats. This showed that if we had given the 'supplier' a template for the source paper we could have removed this bottleneck and sped up even further.

Here are the results of the three rounds:

Round	1	2	3
source paper	12	10	12
completed products	1	2	3
wastage/work in progress	10	6	2

It was a very interesting session and I think we all had some fun as well. It would have been good if we had more some spare time at the end to discuss possible ways in which you could spot the bottlenecks in a software environment. I enjoyed the active format and Kevin and David ran the session very well.

Technorati Tags: AgileNorth, Theory Of Constraints, Andrew Beacock

Agile North Conference 2006 Report

Today was the annual Agile North conference held in Preston, Lancashire. It was a one day event with three different session tracks going on at once. Obviously there were lots of sessions that I wanted to attend but the ones that stood out the most were "Dealing with Customers" and "Storytelling with FIT".

The day started with a keynote speech from Rachel Davies who is a member of the Agile Alliance. It was great to finally meet a "face" of the Agile Alliance and to hear about how they formed and what their focus was. Rachel was a good presenter and kept the audience captured for the duration of her talk.
There was also a good amount of discussion in the Questions & Answers part at the end of her talk.

I had two key "take aways" from her talk:

• Don't stick rigidly to the process if situations are changing
  
• Get hold of a copy of "Waltzing with Bears" book

Dealing with Customers by Charles Weir of Penrillian

Charles held this session as a goldfish bowl (scroll down a bit) discussion forum and it worked really well. I've never seen it before and it was interesting how it really held the discussion to the inner circle rather than multiple conversations starting up at once. Charles was an excellent moderator and ran a very tight, focused discussion group.

My key take aways from his session were:

• If multiple stakeholders are involved, get them to fight it out over the available (and normally very limited) resources
  
• Gaining an onsite customer was very difficult so one company moved the development team to the customer (and located them in the middle of a call centre!)
  
• Sometimes there is too much customer communication to the point of communication overload
  
• In cases where no onsite customer was permitted, some teams resorted to more covert measures to access "real users"
  
• Customers could get an update from the team by listening in to the daily standup.
  
• To stop onsite customers disturbing developers, various "busy working" tokens were used to mark the times of day when the developer was coding rather than available for discussion.
  
• It was generally agreed that when a developer was working on multiple projects at once it was more productive to get one project completed before moving on to the next. The perceived progress if both projects were worked on at once was misleading and productivity was actually reduced.

Storytelling with FIT by Steve Freeman (M3P) and Mike Hill (Mandu)

This session ran for the whole afternoon and covered what FIT was and how to implement acceptance tests in FIT as well as some very interesting exercises around the ideas of capturing, explaining and communicating requirements. Steve and Mike were an excellent double act, I particularly enjoyed their customer/developer role play around the capture of a large number of quirky requirements.

The predominant message that came across was that communicating requirements is hard work and requires lots and lots of communication between the customer(s) and developers. They require a domain language to effectively communicate, should focus on the "what" rather than the "how", readability is very important - use examples and descriptions to explain tabular data.

Again, here are my key take aways from this session:

• For the specification to provide real meaning it needs to include both explanations and examples
  
• It needs concrete acceptance criteria so that the developers know when they are done
  
• When using FIT the real benefit comes when both customer and developer work together to create the FIT tests - they are "communicating" requirements
  
• Production and collaboration are the important points when using FIT to create acceptance tests.
  
• FIT test documents can be written in HTML, Word or Excel format (HTML is best as far as developers are concerned as it can be version controlled correctly).
  
• One cost of FIT is the refactoring of the tests, this is not easily automated due to class, method and member names appearing in both the fixture code and the test HTML pages.
  
• Full test coverage is binary - you either have it or you don't. It means that all code has a purpose and allows you to move quickly by giving you confidence in the codebase.

It was an excellent day and I'm really fired up to try and get FIT running our acceptance tests, I've been wanting to automate some of the testing for a while and JUnit never felt quite right. Can't wait to get into work tomorrow... ;)

Technorati Tags: Andrew Beacock, AgileNorth, FIT, Charles Weir, Steve Freeman, Mike Hill

Ruby on Rails at June's AgileNorth meetup

Tonight was June's AgileNorth meetup and the topic was Ruby on Rails. It was hosted by David Draper who did an excellent job of introducing Rails in an easy to digest way even though he has very little Rails experience himself. Just shows what a good trainer can do!

He demo'ed a shortened version of Curt Hibbs's Recipe Cookbook tutorial using the RadRails plugin for Eclipse as his IDE. David started by creating the database in mysql (note: just the database - no tables) and then used RadRails to create the initial 'cookbook' application environment. He used the 'migration' feature of rails to create the database tables which were auto-generated by ruby code - this was one feature of rails that I was not aware of and was particularly impressive (for me at least!).

He used the scaffolding tools of rails to auto-generate the recipe & category models, the cookbook and category controllers and all the associated views. All of this was done in little steps so that he could show the changes that were made to the code at each stage. I lot of this I had seen before as I ran through the 'Four Days on Rails' last Christmas but it was a nice refresher on the power of Rails.

Following David's walk-through we had a thirty minute discussion around the benefits of Rails and how to introduce Rails to systems with an existing database structure - could it be used to map onto this schema rather than creating a Rails-friendly one from scratch?

I really enjoyed this evening's talk, David did an excellent job if giving a brief overview of how to get kick-started with Rails, and it has re-energised me to think about how I can introduce it in some aspect at work.

Note: I've tagged quite a few of the items discussed with the 'agilenorth' tag over on del.icio.us.

Technorati Tags: AgileNorth, Ruby on Rails, RadRails, David Draper, Andrew Beacock

Stripping requirements down to the bare-bones

Jason Fried of 37signals posted recently about how they choose the essential vs. non-essential requirements for v1.0 of their products. This got me thinking that:

a) what a great idea, it makes perfect sense
b) how many client-driven projects would allow such a thing to happen?

With agile development and the process of release & iteration planning in particular, essential requirements would be moved in front of non-essential ones, so maybe when dealing with external client-driven projects the first iteration (or so) would produce the 37signals' v1.0 release?

Technorati Tags: Jason Fried, 37signals, Agile, Release Planning, Iteration Planning, Andrew Beacock

Summary of January's AgileNorth Meetup

Update 19/01/06: Phran Ryder informs me that my unnamed pair is in fact Stephen Hutchison.

---

Monday night was the January meetup of the UK north-west AgileNorth group. It was again kindly hosted by Katie at computing department of the University of Central Lancashire, Preston. There were 11 attendees, and like last time it was run by Murray Tait (with laptop and software setup provided by David Draper).

We continued off from last time with more coding dojos, the first being a simple problem of reversing a sentence. Given "AgileNorth meets once a month" we had to produce "month a once meets AgileNorth" (maybe we could call this "Yoda-speak").


David Draper & Charles Weir took to the laptop to be the coding pair mainly responsible for typing in the code to implement the unit tests and referring to the JavaDoc where necessary. The rest of us were communicating to the 'customer' (Murray) and deciding what the next unit test should be (which was also noted down by Murray). This exercise ran from 7:00 till 8:00 and we managed to satisfy to the customer that we had provided a complete solution including what to do with symbols and numbers, double-spaced words, etc.

We had a quick coffee break and then dived into the next dojo that ran from 8:15 till 9:15. It was to write a 10-pin bowling scoring system and the customer was Isobel Nicholson, with Ant Grinyer making a note of the next unit tests. We did ok on this one, I was pairing at the laptop with ???? (sorry I have no idea of your name! please post it to the AgileNorth mailing list) Stephen Hutchison. At first I was running the unit tests for the previous dojo, and that got quite confusing! :(

We managed to get basic scoring working per frame (a frame was two balls), and managed to get 'spare' scoring working correctly. We were about to start moving onto strikes but ran out of time. We struggled with this one on how to start, it felt like we wanted to write a large object framework of balls, frames, game scores, tries, etc. without ever having a failing test. Even the initial failing test was tough to get started on. Once the first test was written and a very stupid "return 5;" implementation done we started to pick up speed - I really like writing that first immature implementation to get some working code out and a green bar to give me a boost.

From my point of view it was good to get through a couple of different dojos in the evening (admittedly we didn't finish the second one) as it mixed up the pair programmers, and mean that different people were leading different sections of the problem domain. I also enjoyed meeting quite a number of new faces, and coding Java with 10 other people watching my every keystroke on a projection screen is a very strange feeling!

Technorati Tags: AgileNorth, Kata, Dojo, Pair Programming, Java, Murray Tait, David Draper, Isobel Nicholson, Ant Grinyer, Andrew Beacock

Summary of last night's AgileNorth meetup - "The Game of Life Kata"

Last night was the November meetup of the AgileNorth group. It was kindly hosted by the computing department of the University of Central Lancashire, Preston. They provided a sizable room, with great presentation facilities and even sorted out some tea, coffee and cakes!

There were 10 attendees in total (which was double the size of the first meetup that I attended), and the session was run by Murray Tait & David Draper. The topic was "The Game of Life Kata".

So what is a code Kata?

A Kata is an exercise in karate where you repeat a form many, many times, making little improvements in each. The intent behind code Kata is similar. Each is a short exercise (perhaps 30 minutes to an hour long). Some involve programming, and can be coded in many different ways. Some are open ended, and involve thinking about the issues behind programming. These are unlikely to have a single correct answer. - Dave Thomas

A number of acceptance tests for the rules of the game were provided by Murray and a very bare-bones class that would make up the game itself. The aim was to pair-program the implementation of the game by making the tests pass, and swapping coding partners every 20 minutes or so.

The session went well, with everyone getting stuck in to the design of the game and what rule should be implemented next. Without internet access or a selection of Java in a Nutshell books some aspects of Java caused us to slow down at a number of points during the evening.

It was interesting to see a number of different viewpoints on how far you should implement the feature in question. If the test passes even with a trivial implementation that you know is not a full-blown solution is it ok to leave it at that?

Time passed very quickly and we stopped at one point for quite some time for a valuable discussion about the game board setup and what parts of it we were testing. We pressed on without really resolving the issue and it continued to cause us problems as we got further through the tests. This taught us that as soon as we have a question regarding the requirements we really should down tools and get with the (on-site) customer to get to the issue ironed out.

The end of the session was soon upon us and so we had a 5 minute wrap-up to discuss what we had learnt from the session. Most of that is covered above, but it was also mentioned that although the concept of the problem was simple to understand, due to the acceptance tests using arrays and ints, the implementation was bogged down in for loops, if statements, 1's & -1's rather than allowing us to progress at a higher level (and therefore faster) through the rules and complete the Kata in the time provided (7:00-9:30).

It was decided that we would continue with this Kata at the next meeting, maybe splitting the group into the two 'drivers' at the keyboard implementing the current feature whilst the rest of the group discusses the next step and any design decisions that may need to be made.

I'm looking forward to it already!

Technorati Tags: AgileNorth, Murray Tait, David Draper, Andrew Beacock

Is there such a thing as agile jokes?

In the true spirit of KISS (Keep It Simple, Stupid) here is a joke that had us all chuckling in the office this morning (well it is a Friday after all):

A man goes to the Zoo.

The only animal there was a dog.

It was a shitzu.

Technorati Tags: Keep It Simple Stupid, Joke, Andrew Beacock

A new agile blog by Gavin Hope

Kevin Rutherford posted recently about a new blog by a British agile developer called Gavin Hope. His name seemed strangely familiar, and then it dawned on me - he was one of the presenters at the Agile North conference that was held last month.

He presented a session titled "Fitting Agile Teams in a non Agile Organisation" along with his colleague Lindsay McEwan. His session was the best one of the day as I was concerned, I was impressed by Gavin's enthusiasm for trying to take a traditional development team through the transition to a truly agile one. I'm looking forward to seeing what he has to say about his team leading experiences over the next few weeks and months...

Technorati Tags: Gavin Hope, Kevin Rutherford, Agile North, Andrew Beacock

Feedback from yesterday's AgileNorth conference.

Note: This is a long post as I've tried to get down all my notes, please skip this post unless you really want to read all my view of the AgileNorth conference!

---

These are my notes from yesterday's AgileNorth conference held in Preston in the north west of the UK. It was a full day and to be honest, I was knackered! It's funny how listening and talking all day really tires you out. There were approximately 50 people, which seemed about right for the size of venue.

What is Agile? by Kevin Rutherford

The day started with introductions from Phran Ryder (chairman) and Katie Taylor (secretary) covering the format of the day, followed by the day's keynote from Kevin Rutherford, who ran his discussion as a number of agile iterations.

We all added 'requirements' (topics to potentially cover) to the board, then Kevin suggested a number of them that he would get through in the first 'iteration' (10 minute speaking block). It covered a whole host of topics, but two key factors jumped out at me:
* Measure and track the number of running, tested features completed per week (or month) so that you can track how well you are doing with some real 'hard and fast' data.
* Create an interface to management that gives them all the data that they need to do their job, but allows you to do XP within your team.

Fitting Agile Teams in a non Agile Organisation by Lindsay McEwan & Gavin Hope

This session was the main one that I was interested in when signing up for the conference and they didn't disappoint.

They started with a look at how to get a 'team' together that really gels as a team, noted that the environment is very important, they moved into a separate room from the rest of the development department and created their own workspace.

The whole team's work revolves around the 'task board', a large pin board where tasks and stories 'to do' were pinned on one side, and then moved to the 'done' side once completed. It gave a very easy way to see where everyone was up to, and what was outstanding. They have daily stand up meetings where the cards are moved so that everyone is aware of what is being worked on.

They have a 1-hour project retrospective at the end of each iteration (each iteration lasted 2 weeks) to review both technical and personal issues that had surfaced during that time. This allows the team to correct any problems early on before they become big issues. A recommended book was "Project Retrospectives: A Handbook for Team Reviews" by Norm Kerth.

Time management was driven by the task board, items are either to do or done, there is no "90% complete" concept. The daily stand up meeting includes task tracking progress. Only one task is worked on by a developer at any one time - this stops tasks backlogging with one person if they get stuck on a different task.

The whole team are involved in the planning meeting so that all parts of the team are aware of the requirements and features. The tasks are broken down into 2-4 hour lumps, this allows easier tracking and monitoring of the team's 'velocity'. A graph of the time spent delivering business value is derived from the completion of the task cards, this is then used to estimate the number of tasks the team can handle during the next iteration. They suggested that if you get someone who is hung up on the code in a perfectionist way - "the code's just not quite right..." then a good question to ask is "Who is the judge of quality?" - it could be the end user, the support team, etc. Maybe 'good enough' is ok in this situation.

They had major problems trying to implement the 'on-site customer' idea, it just didn't work for them. What was happening was that the customer was reporting a problem to sales, and they would report a solution to technical. What the customer got was usually not what they wanted. They are now trying to gain access to the real customer problems by putting their staff on placements at their customer sites.

They had problems initially with customer support requests. They were tracking the amount of time the requests where taking to resolve, this lead to support tasks being looked upon as "getting in the way of real work". Their solution to this was to add the support request as a regular task to the board, and then track how many support tasks were being completed each week. They then factored the average number of support tasks per iteration into the planning for subsequent iterations.

15% slack time was added to each iteration for continuous improvements and planning for the future. Recommended reading was "Slack" by Tom DeMarco and "Lean Software Development: An Agile Toolkit" by Mary & Tom Poppendieck.

Managing Agile Projects by Jim Sutton.

Jim's presentation focused on how and why his company needed to go agile and some of the difficulties faced when trying to do so. The title lead me to believe that it was going to be more 'down to earth' on how to manage the team on a day to day basis.

None the less it was a good presentation, here is a list of the items that I pulled from it:
* Break the cycle - do one thing VERY differently!
* Try the daily stand up meeting
* Have a "cut the crap" card that can be held up when discussions get too woolly
* Use 2 week iterations, monthly is just too long
* Sales and marketing departments are still very non-agile, this can be a problem

Refactoring by Ivan Moore & Duncan Pierce.

This was my 'developer' session of the day, where Ivan and Duncan along with the 20 (or so) audience performed a live refactoring of some very poorly written java code. Ivan was using Eclipse to edit the code, and was quite a wizard at using the refactoring tools on offer. It was mostly a discussion-led session with not a lot of things to note down but I learnt a lot about using the refactoring tools and how to spot code that was ripe for refactoring. Suggested reading was "Working Effectively with Legacy Code" by Michael Feathers and the "Refactoring Workbook" by Bill Wake.

All in all it was a fantastic day, and really re-energised me into 'the agile way'. Now I need to figure out how to introduce agile and XP into the company I work for...

Technorati Tags: AgileNorth, Kevin Rutherford, Lindsay McEwan, Gavin Hope, Nonlinear Dynamics, Jim Sutton, Ivan Moore, ThoughtWorks, Duncan Pierce, Amarinda, Andrew Beacock

Off to the AgileNorth conference tomorrow

I'm off to the AgileNorth conference tomorrow, which is "a conference for local technical and business staff who wish to learn and share their experiences of becoming and being agile."

It's a 1-day event in Preston in the north west of the UK covering a range of topics including "What Is Agile?", "Test Driven Development", and "Refactoring". I'm particularly looking forward to the "Fitting Agile Teams in a non Agile Organisation".

I'll let you know how it goes...

Technorati Tags: AgileNorth, Agile, XP, Andrew Beacock