One way to estimate using relative sizing is to use the T-shirt sizes; small, medium, large and x-large. Too many sizes may confuse the developers and the team, so it is wise to stick to three or four sizes. You always estimate with more than one developer in the room, so that there can be a good debate about confusing issues. The skills and experience levels of the developers are not that important. It may even be good to have a wide spectrum.

Start by writing up cards with S, M, L, XL for each of the developers in the room. The Business Analyst or the Product Owner then explains the stories, one by one, and the developers estimate by putting forward one of the cards, simultaneously so that one does not influence the other. Whenever there is a mismatch in their estimates they discuss and debate the point in the room and re-estimate straight away. Usually it ends up with a consensus, as debates clear up the confusion. Always estimate with the end-users and stakeholders in the room to clear up any doubts.

At the end of this exercise all the stories would have been classified into the different size buckets. Now what? Sample and work out the time required to develop a small, medium, large and x-large, respectively. Start with one from each size bucket and break them down into developer tasks, at the minute level possible. It is not too much to break down to a task level of even an hour’s work. Then estimate each of these minute tasks to calculate how long it will take, in real hours, to develop a small, a medium and so on.

Sampling is quite important in this process. It is good to start with random samples and then move on to boundary samples. From each bucket, pick ones that seem to be the largest and the smallest. Estimate these. How much do they vary? Is the smallest medium larger than the largest small? By how much? What is the variance within each bucket? Can the smallest and the largest in mediums still be called mediums?

Depending on the results of the above analysis, the buckets and the stories in them may have to be rearranged.

Once this exercise is over, we can now apply the real estimates from the samples to all the stories in a bucket to get an overall estimate of the size of the project. It is now time to step back and take stock of the budget, cost-benefit, approvals, schedule, road map and so on before progressing any further.

I started the day with a session I proposed and co-facilitated on Behaviour Driven Development (BDD) and Acceptance Testing. We covered a good amount of ground on the troubles getting people into the BDD mindset and appropriate acceptance tests.

Our discussion turned towards some particularly tricky problem banks were having with acceptance tests on their larger system towards the end which surprised me but was an interesting discussion of BDD at scale. The discussion reminded me how grateful I am for the tools available in Ruby that make testing so much easier than it is for people in the Java world.

We had an eye-opening session on the limits of testing and the use of skilled testers in the testing process. The difference of opinion between the people from smaller outfits vs the large banks was quite dramatic with the smaller outfits being much happier to move quickly with as light a testing overhead as possible whilst the banks had large test teams dedicated to going through the applications at length.

Interestingly, the dedicated testers had a very poor opinion of the testing abilities of developers, I wonder is partly due to developers being more relaxed in their coding when they know there is going to be a high level of dedicated testing around to pick up the errors or if it is simply that organisations that are concerned enough about testing to hire testers happen to be those that require a more bug-free approach than the normal small organisation that can react quickly to issues.

The final talk of the day was Nigel McNie talking about his start-up’s use of continuous deployment. He’d put a lot of effort in the implementation at his start-up and was able to build on a lot of stuff with practical examples of how he implemented it. Eric Ries had talked about continuous deployment at Webstock this year and Nigel’s examples made it seem significantly more realistic than Ries’s mention of it.

By using feature flags that go around code that is related to that feature Nigel can have a test suite that tests both states of the flag and if the tests pass the code goes straight to live. So every feature that he has developed so far has made its way onto the server in a latent state, when he wants something to go live he just changes the variable or it can just be set to a time. If issues occur in the site his time to fix is very low as he does not have to wait for deploys or releases and relies on a comprehensive set of automated tests to cover for him.

Overall Citconf was both useful in terms of technical things that I’ve taken away from it and very interesting in terms of meeting the dedicated testers who are present at so many organisations but don’t seem to come to the conferences or events that I do.

Some wiki entries from the conference.

More information on some of testing and CI tools we use at 3months:

• Behaviour Driven Development (BDD) – Cucumber & RSpec
• Continuous Integration (CI) – Cruise Control

What impacts or solutions to digital longevity does technology innovation present?

I say lucky because the other members of the panel are people who are held in pretty high regard: chaired by Colin Jackson, with Nat Torkington (impressive bio in case you haven’t heard of him), Andreas Rauber (Vienna University of Technology), Don Christie (President of NZOSS, founder of Catalyst IT), and Oded Scharfstein (Ex Libris).

I’m not and have never pretended to be an Archives expert, but since this was a technology session and I was representing a web development company (3months) I was comfortable enough. It’s the second panel I’ve been on, the first a panel hosted by Beyond Recruitment on Agile practices.

The start of the panel was to be a 5 minute “position statement” on each of the panel member’s views on the question, which turned out to be the entirety of the discussion. Although I was there from a web technology point of view, the subject had me thinking about creativity in the digital domain and licensing (especially Creative Commons licensing). Seems like a stretch, but here’s the short version of my position:

Part A: Systems

• There’s an awful lot of digital content being created. Too much to print out and store on acid-free paper and lock in a store somewhere (I think we all know this).
• We can’t decide which digital content will be of importance in the future so can’t selectively store it in this way.
• Given that we can’t store everything offline, we have to store it digitally.
• The traditional problems associated with personal digital content are going away: hard drive failure leading to loss of photos doesn’t apply when all of your data is heading into the cloud.
• Even with online storage, some of it will fail and many of the formats in use now will not be in use in the future (another common concern).
• Shared open systems can solve the format change problem once for a large number of users/organisations (music site BandCamp as an example lets users upload in the open FLAC format and download in FLAC and other current proprietary formats such as MP3).
• Content stored in open systems (non-proprietary and publicly accessible) will outlive that stored in closed systems because it will be accessed and replicated and will often store data in an open format.
• Open systems themselves can be duplicated and replicated legally because of the nature of the licensing used (i.e. free software).

Part B: Content

• Technology can enable openness of the technology but only content authors can enable openness of the content through open (permissive) licensing.
• Open licensed content will be stored in more places because the licensing makes it legal to do so (Creative Commons licenses, for instance).
• Open licensed content enables collaboration and remixing/adaptation of content.
• Open licenses content will be shared more, because it will be reused more, because it is allowed to be reused.

Part C: Reuse

• The default position, archiving content under copyright (here’s an example from Archives NZ), creates the danger of a read-only culture (even if made publicly viewable).
• A permissive licensing culture in archived material would enable archived material to have genuine social benefit [yes, just my view], going on to be remixed and adapted for artistic, academic and commercial reuse.
• Open content in open systems will be duplicated more because it can be both legally and technically.
• I believe that open content in open systems will outlive proprietary content stored in closed systems.

A truly open archiving and record keeping environment would result in public information being stored in public systems for public reuse. The archivist would become more like an observer, watching content flourish and harvesting the results as needed but not trying to control or gate-keep the content, where it is located or how it is used. This environment, where content is primarily reused and remixed, may even result in losing the original record in some cases, but is this really an issue? Not for me: the record still serves a purpose.

An example:

ccMixter is a community remix site for music and audio. It’s a model for collaboration that traces the source document and it’s journey through different interpretations. The ccMixter model would be interesting to apply to other endeavours:

• Upload the original record/content
• License it in a way that it can be adapted on and remixed (in a range of ways that CC licenses support)
• Maintain the original record and ensure its traceability
• View adaptations of the content (which come with constantly refreshed formats)

Imagine a world where every public record was open and resuable in this way, where individuals and organisations could extract whatever value they wanted out of public records, and where digital continuity also meant reuse and remixing. I might be dreaming, but this might also be the only way to ensure the digital continuity of our public assets in a sustainable and useful way.

I made some changes to my slides and the general format of the talk so that we could get through more stuff. I focused more on scaffolding the app up initially and then working on some basic stuff to relate movies to reviews and work with the two in combination. The scaffolding approach was definitely a lot more successful than going with building the app up from scratch in terms of getting to a point where stuff could happen sooner.

In general it felt much smoother than my last practical session on Rails and I think we covered enough material for people to be able to get started with Rails decently. Having consistent versions of Ruby and Rails is particularly good when you’re trying to run something with a large group of people and when things go wrong you can often broadcast the fix to everyone.

The big problem this time wasn’t the content but the lack of anything big and impressive looking. It’s relatively easy to explain to people who’ve worked with large apps in PHP or J2EE why the architecture and style of Ruby and Rails is good and avoids problems they will have come across.

For students who haven’t worked on (m)any large apps, doing some basic functionality in Rails just looks like a bunch of really simple stuff and they’re not impressed or excited by simple things. It seems I have to try and strike a balance between informative teaching and showing off tricks to convince people that stuff in rails is cool.

I’m not willing to take a “here’s some magical code for you to copy paste and now you’re an awesome programmer” approach to it as I think that leads to a bit of a cheap high, I certainly don’t want people to be encouraged towards cargo culting code. I do give people code to copy out but only after I’ve explained the function and goal of each piece(with the exception of some config stuff).

I’m currently considering, for the next time I do something like this, either spending 15 minutes going nuts on the projector and adding as much functionality as I can very quickly with lots of integration with other services, or spending a few minutes showing how intolerably horrible some of the other solutions to these problems might be. The showing off idea is probably better, but pulling out scads of bad code to insult might be more fun for me.

In the end, the biggest sale will probably come later on if they happen to want to do something that could use Rails. As long as people have the groundwork they’re much more likely to pick it up then, a project is really what you need to do to learn Rails properly anyway.

[Thanks to Breccan for re-posting from his personal blog.]

Both conferences had a clear aim of inspiring participants to do cool things. Linux conf did this with things like open source in schools or open source in space, practical things that were very cool if you happen to be an open source geek. Webstock, on the other hand, painted its inspirational message with a broader brush, from talking about the possibilities of future technology to encouraging people towards founding startups.

There was a much wider selection of subject matter available at Linux conf it was easy to move from one talk that gives lots of practical advice that you can put to use the next day to another that sparks a group of individuals into campaigning against internet censorship. The fact that it was an open source event was particularly noticeable when you saw how many people end their talks with links or pleas for potential contributors to their projects.

Webstock didn’t have as wide range a of talks being mostly singled streamed, but it’s speakers were of a uniformly high quality and particularly entertaining even when they weren’t talking in your own areas of interest. Their speeches generally focussed on the encouragement to do something cool or motivational rather than the geeky focus on particular things of Linux conf.

Something more unique to Webstock was the presence of a number of speakers who were just cool. Rives, a spoken word poet, was a particular highlight for many attendees. His connection to the web was a little tenuous and his site couldn’t be called an example of web best practices, but as a speaker he was brilliant.

The only particularly practical talk I went to at Webstock was John Resig talking about jquery. Jquery is already our favoured javascript framework and his talk covered a range of the functionality that had recently been released and he had not yet got around to documenting.

Comparatively, there were large numbers of practical talks at Linux conf by a large range of industry experts. From current happenings in postgres to the importance of documentation in open source projects or the legal status of patents. Linux conf was particularly useful throughout.

In the next weeks after Linux conf I was able to actually apply a large number of things I had learned in the course of the conference. From useful new database management techniques to mentoring our summer of code student there had been talks that were on the things I come across daily.

Webstock may not have been as directly useful, but it certainly was motivational. With most conference goers coming out feeling motivated and excited by the future. It certainly was enjoyable and making sure people that excitement about technology and the web is going to cause them to be more productive anyway.

I enjoyed both conferences because I happen to occupy a happy medium that occurs between the Webstock target audience and the Linux conf one. It did surprise me just how different they were though both in style and type of attendee. I recommend both conferences, but you do need a reasonable level of technical exposure to enjoy Linux conf while Webstock isn’t something you should go to expecting to get direct benefits. Check out Rives though; he stole the after Webstock discussion.

Appendix: The Swag

Of course, the defining aspect of any conference is the swag. Webstock mostly focusses on its very pretty bag, which is very good although somewhat lacking in useful items inside it. It also suffers from the velcro closing mechanism that makes it impossible to open the bag without drawing everyone’s attention. It’s possible this effect is intentional to make sure everyone is aware that you have a cool Webstock bag.

The Linux conf swag was significantly more varied in terms of including a reasonable supply of writing materials, a usb key and a clock. Writing materials in particular were an excellent addition over the little pads that floated around Webstock. The Linux conf bag  also has proper little magnetic closing things.

Breccan is a developer at 3months.

Here’s the deal: command-and-control approaches will destroy your projects and decimate your portfolios while you’re waiting for results that will rarely surface. If you dictate process to a project team you will get a team who can adhere to process and will be able to demonstrate all sort of reasons for failure relating to the project. Dictating process amounts to telling a team what to do, when and how. In this kind of environment the PM learns to allocate tasks, determine their order and execution and control which practices the team can or can’t adopt. The team learn to follow instructions and success depends on the PM being able to control everyone in the team to the right level. While this can happen in pseudo-Agile settings, it’s more common in waterfall environments. It can lead to success of a sort, but isn’t repeatable and is very much personality driven.

Where does the high cost of failure come in? In a waterfall or control-based Agile-like process, the PM can report that the project is under control while they work hard to plan and dictate tasks, interactions and processes to the team. A waterfall or control-based Agile-like process will demand an entire cycle of the process before failure becomes apparent, meaning that the available time and money have been spent before a project’s financial sponsors are aware of an issue.

If these structures and behaviours lead to hiding waste through confusion, properly enabled Agile teams eliminate waste through transparency.

The alternative is to enable teams: if you enable the team to tackle product development and guide them with good starting practices, they will adapt and improve as they succeed and typically deliver great and innovative products. Enabled teams understand that they are jointly accountable for delivering a good product and that they need to collaborate to reach the end. Agile coaches and facilitators who assist these teams know that their job is to guide and challenge the team, ultimately making sure the team has everything they need to succeed.

Agile is not about following a process, a check list or a flowchart. Agile is about Done, about completion and about products being more important than processes. Organisational adoption of Agile is about enabling teams, coaches, facilitators and managers to view the team as a vehicle for successful product delivery.

Shanan Holm is Projects Director and Agile Consultant at 3months.

I have noticed a few discussions recently about the ‘scrum diagram’. I will be posting mainly in response to these 3 blogs: David Harvey – The Scrum picture is wrong, Karl Scotland – A New Lean And Agile Picture , Andy Brandt – Scrum picture is quite right. I will be collating these ideas into this post to offer an analysis/ pro’s and cons of current diagrams and create a discussion to (hopefully) find a solution.

Brief background, I am a designer/front-end developer at 3months and a certified Scrum Master, what I have to offer is experience in design, illustration and experience working in an agile software development team.

The Original Scrum diagram

A Visual Introduction to Scrum

(Mike Cohn and Mountain Goat Software)

After reading David’s article on The scrum picture is wrong – in reference to this diagram above, I started off thinking how I could incorporate David’s ideas into an improved, polished diagram. The main issue David has with the current (most used) scrum diagram is the lack of people and the focus on only one of the deliverables – the product or ‘potentially shippable product increment’.

He suggests the diagram should illustrate benefits to the team, product and client.

“..I worry about what happens when we surround ourselves with process pictures which (1) don‚t include people, and (2) only tell half the story…”

Pros

• Colours
• Mention of daily scrum
• Easy to talk about when presenting

Cons

• Lack of people – Where is the team? Where is the client?
• No product vision

Agile Project Management with Scrum – Ken Schwaber

Pros

• Shows people
• Shows product vision
• Daily scrum
• Feedback loop

Cons

• No retrospective (not technically a must in Scrum but it’s common practice)
• Not clear that the outcome is a ‘potentially releasable product’
• No visible end to the process

The Process Model for Scrum

(Scaling Software Agility – Best Practices for Large Enterprises by Dean Leffingwell)

Pros

• A detailed overview of scrum process

Cons

• No product vision
• Lots of text

Scrum for Team System

Pros

• Lists preparation tasks, but probably isn’t necessary

Cons

• Does not flow well
• Interestingly the first step from the large prep section takes you to more prep rather than getting you going
• Daily cycle feels a little hidden
• Artefacts and people feel like an adjunct to the cycle rather than part of it.

A New Lean and Agile Picture

Karl Scotland’s blog post A New Lean And Agile Picture offers this diagram which focuses on 2 inputs VISION and REALITY and 2 outputs PRODUCT and TEAM.

Pros

• Minimal – but whilst minimal it is very open to interpretation
• Easy to remember
• Shows benefits to client and to team

Cons (*taken from comments on Karl Scotland’s blog)

• *inputs should say VISION and TEAM
• *outputs should say PRODUCT INCREMENT and TEAM CAPABILITY
• No break down of the actual Scrum (or other) process

A new and improved Scrum Diagram?

My first attempt at this focused on combining the positive aspects of these main diagrams, especially Mike Cohen’s and Karl Scotland’s diagrams.

Feedback from my team members

• Sprint backlog should be within in cycle
• Try visually indicating that the product back log ‘feeds’ into the sprint
• How about move the daily scrum to the center of the cycle?

and now for the latest version….

This work is licensed under a Creative Commons Attribution-Share Alike 3.0 New Zealand License.

So there we have it,

• Vision + Team as inputs
• Product + Team Capability as outputs
• An Initial Product Backlog that feeds into the Sprint Cycle
• Within the Sprint Cycle we have all the tasks that make up a sprint – planning, sprint backlog, product increment, sprint review, sprint retrospective, updated product backlog

and at the core of cycle we have the Daily work!

Kelly Cheesman is an Interaction Designer at 3months.

Next on the list will be designing new business cards for Shanan Holm and Mike Lowery – our agile consultants.

Kelly Cheesman is an Interaction Designer at 3months.

Why are Test Drive Development (TDD) practices so often considered a waste of money?

As an Agile champion (self proclaimed) I have been banging on about the benefits of TDD for a number of years. Never really from a developer angle, more from the PM and management point of view, yet only the developers ever seem to listen.

Perhaps I have never really had the best arguments to win people over and management have been stuck in the test last point of view. I decided to write this post given some recent experiences on a project that went live with zero defects (doubtless there are some still to be found), with more scope than the original contract specified and 10% under budget. Sounds like a good argument to win people over to me.

This is not a boast about the team’s prowess or my coaching contributions – just the facts. These facts were brought about in part by:

• Great teamwork
• Good architecture
• Clear product vision
• An effective product owner
• Well understood Agile practices and beliefs

However in this case the steady pragmatic application of test first practices and tools (such as Cucumber and Rspec) made a big difference.

We developed the product (a web based transport management tool for a logistics company) in about 500 hours and about 100,000 lines of code, again nothing special. What was great was that we found 66 bugs throughout the entire four-iteration project and of those only seven were found by the customer.

Why do I think that writing our test first made a significant difference? Here’s an example of where it helped: halfway through the project the product owner changed the product in a way that forced us to change and re-factor a significant amount of of the previous work. However as we could run the tests after every code commit it was so easy to see where code developed earlier was impacted and needed rework. In the end we had two regression bugs that our automated tests did not find – the rest were picked up during development. For this fact alone writing our tests first saved us (and our customer) a significant amount of time and money. I shudder to think what things would have been like should we have done the testing manually and after development.

The project was not resourced full time either. This meant that team members might not do anything on the project for a couple of days. The necessary warm up time to remember where you were in the project is reduced as you can write the tests for the scope you need there and then and get straight into development.

We also included automated checking for valid HTML. This was something we hadn’t done before with automated testing and it made it much harder to accidentally commit broken HTML without noticing. It also made it easier for developers without much experience writing semantic HTML to do so and overall helped keep our commitment to good HTML.

For those of you driven by more by financial gain than engineering practices look at it this way:

Less bug fixing = more time spent on chargable work.

Happier customers (from fewer spec errors etc) = more follow up work (that’s free marketing).

Development teams understanding the project quicker = faster time to market = happier customer, more follow up work and ultimately more money in the bank.

So the next time you start a project and say no to TDD think about all of the advantages to your organisation you are leaving behind. And if you haven’t tried TDD before reading this post, give it a go and thank me later.

Mike Lowery is an Agile Consultant and Scrum Master at 3months.