Blog - Allan Kelly

Stating the obvious: Pre & Post conditions and TDD

Agile / allan kelly / April 21, 2017

Can you have an epiphany more than once?

Well I did. In early January – perhaps the result of all the Christmas drink – I had an epiphany and wrote this blog post. As I finished writing the post I realised I’d said it all before… Something old, Something new:

Requirements and Specifications.

Still, I think the message is worth repeating…

Back in the early 1990’s everything was better, the Cold War had ended, the world seem be fighting just wars, I was having fun at University and my lectures were convinced that formal methods – logic based VDM-SL to be specific – were the silver bullet to software development. And so I spent three years being schooled to write pre and post-conditions on every function I wrote.

Actually, this made sense to me at the time and I continued it long into my professional career. I still find it useful to think like this although I long ago gave up actually writing them as comments. That was one of the failings, if you just wrote them as comments then they aren’t enforceable and they can easily become another piece of documentation which doesn’t match the code.

An improvement to this, and the way I used to write a lot of C++ code was to use assert. So my code would look something like this:

std::list<std::string>

extract_reviewers(std::map<std::string, int> *votes_cast) {

// pre

assert(votes_cast != null)

assert(!votes_cast.is_empty())

…

This was an improvement but you needed to execute the code to make it happen. And that meant powering up the whole system.

So today I’m writing some Python, and my app just crashed, and I looked at the code and its obvious that the function in question shouldn’t have been called. “Arh… there is a test I missed somewhere…”

And it dawned on me… probably again…

When I write a test for a function I’m writing executable pre and post conditions. Here is the code:

self.assertEquals(dedupvotes.retrieve_duplicate_report(self.c.key), None)report = dedupvotes.generate_duplicate_vote_report(self.c.key, 1)self.assertFalse(report.has_duplicates())voterecord.cast_new_vote(submission_keys[1], “Allan”, 1, “One”, VotingRound)voterecord.cast_new_vote(submission_keys[1], “Grisha”, 2, “Two”, VotingRound)self.assertFalse(report.has_duplicates())voterecord.cast_new_vote(submission_keys[1], “Allan”, 1, “One”, VotingRound)self.assertTrue(report.has_duplicates())

See?

In the test setup I setup the pre-conditions. I may even test them.

I call the function, generate_duplicate_vote_report, and I check what happens, the post conditions.

(OK, it is not the most polished code, the refactor step has yet to happen.)

What has happened here is that I’ve moved the policing of the pre and post conditions outside the function. In VDM the pre and posts were comments wrapped around some imaginary code. In C++ the asserts top-and-tailed the method, with TDD the pre-and-post it in a special function. And the test harness allows just that code to be tested.

I was always taught to write the pre and post conditions first. Indeed, in VDM there was no actual code so you could only write the pre and post conditions. In other words: I was writing the tests before the code.

And now I write this, I remember I have made the same point before. When I made this point before I was discussing TDD’s younger, but possibly wiser, brother, BDD. If you want to have a read it is Something old, Something new:

Requirements and Specifications. That essay is also included as an appendix to Little Book of Requirements and User Stories.

What does this prove?

Perhaps not a lot.

Or perhaps that TDD and BDD are the logical continuation of an old, 1970’s at least, approach. They have a longer lineage than is commonly recognised and that in turn increases their credibility.

It also reminds me of 1994 when I was working in the dungeon of a small company in Fulham. Myself and another programmer, Mark, were racing to deliver a C++ system to a client and save the company. We were writing test harnesses for our code and I was writing pre and post conditions. In retrospect his tests were better than mine, mine often needed a human key-press, I think his might have been added to the build to.

In retrospect too, we came perilously close to Test Driven Development but we didn’t think it was anything very special, we didn’t name it, we didn’t codify it and neither of use made much money out of it.

Stating the obvious: Pre & Post conditions and TDD Read More »

What does a CTO do?

Agile / allan kelly / April 12, 2017 / cto, entrepreneur, mvp, start-up

The last few years have been good to me, I’ve enjoyed giving advice to teams and companies and helping people get started with better ways of working, ways of working which usually go by the name of “agile” but the name is the least important thing. But…

I’ve been questioning if I want to keep doing this. Like most of us do from time to time I’ve wonder if I need new challenge, if I should join something big, more continuity and… as you might guess from my posts on Mimas I’ve kind of missed being closer to building something.

From time-to-time people have suggested I take on a CTO role – and certainly my ego likes the idea, it sounds important! – but, seriously, I think I’d like to give it a go. But that leads me to a question of my own:

Just what does a CTO do?

This is something I’ve pondered before because while I’ve met a good few CTOs in my time I can’t really see a consistent pattern to describe what they do. Everyone knows what a CFO does, they look after the money so a CTO should “look after” the technology but… how do you do that?

Before I come up with even more questions lets try some answers.

First up, lets be clear, not all CTOs are code-centric. I know organization where the primary role of the CTO is to understand the technology domain and code – software – is secondary. Take telecoms for example, the CTO in a telecoms company may actually be an expert in telecoms technology. Software may well be something someone else looks after, although the two need to work closely.

Such examples seem to becoming less and less common, perhaps that is just another example of software eating the world. CTOs are increasingly about the code…

Some CTOs are programmers, some CTOs are the only programmer.

This view seems common with non-technical entrepreneurs and in job-adverts for start-up companies. Maybe it is because these companies can’t afford to pay senior salaries that they hand out grand job titles instead. Or maybe it is because the founders really don’t understand technology and anyone who can code looks like a god to them.

I worry about these companies because the attributes which make the first “CTO” attractive (code god willing to work for peanuts and therefore young and mortgage free) are most definitely not the attributes you want a CTO as the company grows.

CTOs should most definitely be able to code – even if this was sometime in the past. And many CTOs I know, and have know, do continue to code. That is good when they are part of a team.

A CTO is also in part an architect role – and hence they should code from time to time. The CTO may well be the Chief Architect or Chief Engineer although such a role is more about building shared understanding not mandating plans.

And since software design is a copy of organizational design the CTO needs to understand Conway’s Law and organizational form and structure. Organizational architecture is as important as software architecture, they are symbiotic.

Some CTOs have a lot of say in organizational structure. Many CTOs run the technology development group – all the programmers and testers, and possibly analysts and project managers, report to the CTO. As such the CTO is the Chief Technology Manager.

But not all CTOs do this. Some CTOs are actually further down the organization. And some CTOs leave the running of the technology group to someone else – the Vice President of Engineering or Director of Development. Again the CTO may work closely with this person but the CTO fills more of an advisor or expert role rather than a management role.

Such expert CTOs may well be on the board, they may well have the ear of the CEO but they leave the day-to-day operation of development to someone else. And some don’t, some are deep in the detail.

Perhaps as more businesses become truly digital, and technology and business become truly one, then CTOs running development operations will become less common and CTOs as experts will become the norm.

CTOs need to keep their finger firmly on the pulse of technology – what is happening, whats new, what is taking off, what is going down, what are Apple planning? And Amazon? And Microsoft?

But actually understanding the latest technology may well be less important than understanding how that technology changes business, changes competition, changes organization and structure. Manager-CTOs may well put that understanding directly into action but Expert-CTOs will educate others in the organization, from new recruits all the way up to the board.

CTOs also have a role in recruitment and forming the development culture. If CTOs think quality is important the engineering staff will take quality seriously. And if the CTO says, like one I knew once, “I’d rather it was on time with bugs than late and working” then every engineer will know within about 5 minutes.

While CTOs may not interview every candidate for a role they will certainly interview some of the key roles. More importantly the CTOs needs to work as a cheer-leader for the companies recruitment campaigns. Finding good engineers is hard, a CTO who gives the company a profile and makes it a place people want to work will help a lot.

CTOs often have a role to play too in sales. They are wheeled out to meet potential customers, talk technology and show the company takes the client seriously. When a company is R&D heavy the CTO doesn’t do much pre-sales but then the company makes a living selling products or services to other companies CTO as pre-sales is very important.

And it is perhaps at the highest levels, the board, the other CxOs, that the CTO role is unique. Almost by definition each CxO (Chief something Officer) is a specialist in their own field: the CFO knows about finance and the CMO knows about marketing. Although the CEO should be more of a generalist they come from another function so once upon a time where specialists. The COO (operations) may be another exception although this is often post held by the soon-to-be-CEO so it is a training post. (In my experience, the CSO role (chief strategy officer), when it exists is used to sideline someone before helping them leave).

In the CTO the other CxOs have a peer they can talk about the technology implications for their business. It is here that the CTO has the opportunity to influence the rest of the company and help them maximise the benefit of technology.

The common theme in all of this is the CTO leads the thinking of others. To use a rather over-used, and perhaps equally vague term, the CTO is a thought leader around technology. The CTO helps others in the organization understand not so much the technology itself as the implications of technology for the business. (And that implies the CTO needs to be a good communicator.)

That of course is provided the CTO has those opportunities, that they are at meetings and senior meetings, if “CTO” is simply a grand title for a programmer then they have little influence.

Summary

The title CTO should be reserved for roles which are more than just programming
A CTO should be able to code
A CTO should understand software architecture and will be one of the architects but probably not the only architect
The CTO needs a firm understanding of Conway’s Law
The CTO needs to understand organizational structure and play a role in designing the organization
Some CTOs are technology experts while some or powerful managers with their own department
CTOs need to keep abreast of the latest technology development
The CTO may well be the most senior pre-sales consultant in the business
More importantly the CTO need to understand the implications of technology and how business is changed by technology
A CTO helps to guide other company executives in their use and understanding of technology
Ultimately the CTO is a “thought leader” – they guide the thinking of others.

Given that it is pretty obvious that very few, if any, individuals can fill the role. Any CTO will inevitably be good at some things and not so good at others, as humans they will inevitably flawed.

And me?

Do I still want to be an CTO? – well yes but actually, I’m not concerned about the title, call me what you will – Chief Engineer is a title I’d love too – but what I’d love is a role which allows me span boundaries: as someone who understands technology, can code, can architect, knows how to align business with business structure and technology architecture; as someone who knows the importance of knowing what is being build will meet customer needs.

If you know of such a role I can always be tempted, until then, I’ll stick to consulting.

Post script

In the nearly 6 years since I wrote this blog little has changed. Well, perhaps one thing has changed: entrepreneurs have learned of MVPs. Now the world if full of potential start-up founders who don’t understand technology but know they want an MVP. Or at least, what they think is an MVP. So now, entrepreneurs want a CTO to build an MVP, preferably tomorrow and preferably for no money. (I’ve found myself in this trap once or twice.)

Maybe things have got worse?

Now, as every good product manager knows, and as every entrepreneur should know, where there is a problem there is a need, and where there is a need there is an opporunity. Indeed, I recently discovered William Dvorak and his company MVP Engineer. I’ve not had a chance to work with Bill yet but we’ve corresponded and I like what I see. So, next time someone tells me they want a CTO to build an MVP I know where to point them.

What does a CTO do? Read More »

Mimas: What it does

Agile / allan kelly / April 10, 2017

My last entry I discussed some of the lessons I learned coding the Agile on the Beach submission and review system, Mimas (feel free to have a play). For completeness I’d like to tell you what the system does and what I want to do next for the system:

For the speaker….

What you get is a fairly basic form to submit a proposal. You receive an e-mail confirmation and at some later date notification of the outcome. You should also receive a link to the scoring and comments your submission received – that is, if the organiser wants to send it.

Before I go on, it is worth pointing out that Mimas is build around the assumption that conferences have tracks, e.g. software coding track, product design track, etc. Submissions are tied to a conference track, reviewers are asked to review all track submissions and final decisions are made on a track-by-track basis. Since tracks are configured when the conference is set up they are largely fixed. That could change in future but right now they are fixed.

For the reviewer…

Reviewers are assigned to one or more tracks and asked to review the submissions in the track. They get a list of all the submissions and for each one can score the submissions from -3 (don’t want) to +3 (really want.) That is round one. The conference organisers can then decide which submissions to shortlist for round two.

In round two reviewers are asked to rank the shortlisted submissions – from 1 at the top to… well however many are shortlisted, 5, 6, 10, 16 – whatever.

For organisers….

Creating a conference goes without saying! – They can configure it too: maximum number of submissions per speaker, max number of co-speakers, tracks, talk types and durations, expenses options, e-mail templates, e-mail ccs & bccs and a few other bits.

But all organisers are not equal. There is a permissions system which allows the conference creator can decide just what other organisers are allowed to see and do. They also get to decide who the reviewers are and assign them to tracks.

Most of what the organisers see are reports which slice and dice the submissions in different ways but those with the correct permissions can do some other things:

Move submissions between tracks
Review submissions and reviewer scores
Shortlist submissions from round one to round two
Decline and accept submissions
Export submissions data
Send bulk (personalised) e-mail to submitters
And of course change permissions for other organisers

What happens next?

There are two “big” changes I’d like to make…

I want to revise the way the system handles review so that rounds become configurable. Right now there are two rounds of reviews: one a scoring system, -3 to +3 and a second ranking round. I want to allow conference organisers to decide how many rounds of voting there should be and select the type of round they want. That will allow me to configure scoring (e.g. 0 to 5 instead of -3 to +3), add some more types of voting (e.g. multi-criteria), configure rounds and allow speakers to be anonymised.

The other big change, which comes from reviewer feedback, is to allow private comments. At the movement all reviewer comments on submissions are shared with submitters. But reviewers want the ability to make comments that are not shared.

This is a difficult one, I’d like reviewers to be open and share all their thoughts but some reviewers don’t like that. And because of that they find the system less useful. If I was Apple maybe I’d just say No, thats the way it is. But I’m not Apple and I need to meet client expectations.

Technically, I want to change the e-mail handling system, again. Although this is in its third version I’ve seen better ways of doing it. This is classic refactoring, each time I’ve change the way the e-mail system works I’ve seen a better way of doing it. Submitters and reviewers won’t see much change but improving the architecture will allow me to make enhancements more easily in future.

The other technical change I should make concerns testing. I really should look at ways to bring more of the UI under test – or at least run “bigger” tests. While there are lots of fine grained unit tests increasingly I find it necessary to manually test how the system hangs together, e.g. when I make changes to mail handling. This is because actions happen in the UI which cause quite a lot of stuff to happen below.

There are many more small changes I want to make to the system but they would probably take longer to describe than to write about!

So the last question is: is this worth while?

If the system is only ever for Agile on the Beach then probably not. It works.

If the system is used by other conferences then some of these changes, perhaps all, are worth doing. But then, maybe until I make those changes none will use it!

A classic dilemma.

If the system is my own little play thing then yes, all these changes are worth doing because I enjoy coding it! But enjoying doing something is different from it being commercially worth while. Financially I’m certainly better off doing something else. But if I value a hobby then it is worth doing.

Another classic dilemma.

One might ask: has it been worth doing so far?

Improved the AOTB submission and review process: Definitely!

Refreshed my programming: Yes

My own personal learnings: Yes

Created an option for others: Yes

Financial returns? No

Its just a shame that the first four don’t pay the bills!

Another classic problem.

Mimas: What it does Read More »

10 Lessons from coding the Mimas conference submission & review system

Agile / allan kelly / April 7, 2017

The picture above is the documentation for Mimas, the conference submission and review system I wrote for Agile on the Beach. The documentation is three A4 sheets (2 state diagrams and one short paragraph of an assumption) plus an A3 object model – actually the database object model. All stuck to the wall in my office.

That is all the paper documentation, there are over 100 unit tests too which form pretty good documentation and have allowed me to continue changing the live system. There is also a physical stack of cards on my desk which form the backlog, although the most important changes I need to make are firmly logged in my brain.

A couple of my blogs have mentioned Mimas before but in this entry I just wanted to share some lessons about the system and my first serious programming effort in years.

For the record the system runs on the Google AppEngine, it uses standard Python AppEngine libraries, e.g. webapp2 plus a light coating of BootStrap on the UI – thanks to Sander Hoogendoom for that suggestion – and SendGrid for mail but apart from that is pretty much free of libraries. It comprises 8500 lines of Python including 3300 lines of test code. There are another 2400 lines of HTML which contains about a hundred lines of JavaScript. The JavaScript gave me an interesting insight…

I like to think I know Python but I don’t think I know JavaScript, the JavaScript I used here was 50% scrapheap challenge and 50% programming. On the few occasions I did anything more than a simple function I found I spent an inordinate amount of time getting it to work. I kept putting this down to not really knowing JavaScript – plus perhaps being a bit snobby about JavaScript not being “real” language.

But, fairly late in the process I realised why JavaScript took so much time and why Python was so fast: The Tests.

The Python was properly Unit Tested. When I needed new functionality in the server end I built it test first. And it just worked. Time and time again I surprised myself how quickly I got things working.

Not so in JavaScript, I kept avoiding it and when I did something it just took too long which made me dislike JavaScript all the more.

But… when I came to UI I’d let myself off about the unit tests. I never set up a test framework. And so I never unit tested my JavaScript either. I slowly, lately, realised a lot of my JavaScript mistakes would never have happened if I had unit tested it. And I’d also wager my UI development generally would have been faster if I had properly unit tested it. UI tests take longer, manual tests take longer, it takes longer to find out something doesn’t work and to try something else. Fail fast, fail cheap.

Lesson 1: Be even more honest with unit testing.

Lesson 2: Yes unit testing the UI is more difficult but that shouldn’t be an excuse for not trying.

To some degree I would defend myself by saying I was really new to JS and a lot of the webapp2 UI ideas and was just learning. But that begs the question: would I have learned faster with tests? At some point, before today, I think I would have done.

Although I didn’t unit test the front end I did keep a strict front-back division and pushed as much logic as I could not the back.

Lesson 3: I was already (subconsciously?) compensating for where I knew I was weak.

(By the way, Python support for mocking and stubbing is good but can someone in the Python community please document it properly? Its still a bit of magic too me.)

One of the reasons I avoided third party libraries was because of the time it took to get them working. Take dragular – for example, it is a JS drag and drop library which claims to be “so easy it hurts the brain.” I couldn’t get it to work.

I spent a couple of days with it. (I could really do with drag and drop in one part of the system).

Then I gave up and in a day knocked together a non-drag and drop alternative – not as good but it works.

Lesson 4: Even ready to use code libraries have learning curves, sometimes that learning curve is longer than doing it a different way. The cost of reuse.

Something else I relearned: those really trivial bits, the bits you easily convince yourself you don’t need to test? Like getters and setters.

Well, if you do the tests you may well find they were so trivial you didn’t pay attention and got them wrong.

Lesson 5: Unit testing the most trivial stuff can actually be the most valuable.

I say I relearned this because I learned it with a previous development a year or two back and comparing notes with James Lewis found he’d had a similar experience!

In general I’m impressed by the Google App Engine. There are some places I got stuck and a couple of things which just don’t seem to work or are not really good enough (__init__ constructors and NDB come to mind.)

Mail handling caused me a lot of problems. In some ways I can’t blame Google for this ‘cos their documents discourage you from using their own mail handling system. When I eventually did cut across to SendGrid not only was the change far easier than I expected but it also solved some other issues I had.

Lesson 6: Sometimes we resist changes which are actually good for us.

Live running the system caused surprisingly few problems. The only real problem we had in live was hitting a Google quota limit. It turned out this was a quota limit around mail sending and was eventually force the move to SendGrid.

But… The Google docs on quota limited a far from clear. Or rather, the Google diagnostics are far from clear. The logs told me I’d blown a quota but not which one. It took a lot of hunting, and some guesswork, to find it was mail – not the number of mail messages but the frequency. Even then I got it wrong because the Google quota allowances have changed over time, not only is a lot of old information still on the web but some of the limits aren’t clear or seem to contradict one another.

Lesson 7: Select may not be broken but sometimes it hard to know exactly what isn’t working.

Overall, I managed again to prove Hofstadter’s law but in part that was because I enjoyed myself so much! Really, I’d forgotten how much fun coding, and seeing the code work, is. Quite possibly, I spent too much time coding last year and not enough doing paid work.

And perhaps, this is what non-coders don’t like about coders. They see programmers enjoying their work and they fear the programmers are doing more because they are enjoying themselves. And maybe, they are right. But that isn’t a reason to make programming miserable!

In the first few weeks of coding I kept a very sharp focus on “Only what do we need for Agile on the Beach” but at some point I let myself go and enabled it for other conferences. But at that point I actually found it easy to change the system because it had been built well and built with tests.

Lesson 8: It is really hard to keep a focus on just what you need for now

Lesson 9: If you focus on good engineering broadening it out will come naturally; if you focus on broadening it out you’ll forget the good engineering.

This made me wonder if I could work as a programmer again. I can still program but I’m under no illusions: I’d never get past the CV filtering let alone an interview. Firstly nobody would hire me because I haven’t commercially programmed for over ten years. But, more importantly I don’t have the libraries or other related technologies.

To pick a Python job at random, here is the one that came up first just now on JobServe:

+ Exceptional Python knowledge/experience

No, I’m not an exceptional Python programmer

+ Java, C/C++

My Java is very very rusty, my C++ just rusty but worse, I’m a C++98/2003 guy, I’ve no idea whats in 11 let alone 14.

+ Flask and/or Django

None

+ Agile, TDD, CI/CD

I’m rumoured to know a little about Agile, and a tiny bit about TDD but CI or CD… never really done it.

Fantasy over.

Lesson 10: Middle age ex-progammers may try to recapture their youth in code.

In my next entry I’ll say a thing or two about what Mimas does, but try it yourself. I’ve also set up a little site to publicise it – ConfReview.com.

10 Lessons from coding the Mimas conference submission & review system Read More »

Stockless Production from HP – a Kanban video

Agile / allan kelly / March 31, 2017 / 1 Comment

Some years ago when I was doing my masters degree I was shown a video called “Stockless Production” which was filmed at HP in the early 1980s. It was a brilliant illustration of Kanban, or Just In Time, or, as they liked to call it Stockless Production.

Its brilliant, the video quality is poor and the sound is even worse!

I few years later I found the video on the internet – it can be hard to track down. Although some experts exist elsewhere on YouTube I’ve never seen the whole thing there.

I often show the video as part of my work coaching and training teams. I use it either as part of a Kanban introduction or for teams already doing Agile a la Scrum to help them think about flow and quality.

Last year I paid to have subtitles added to the video. I’ve uploaded it to YouTube and in the hope that many more people can enjoy the film, have a little laugh and learn.

Many thanks to Brian Barnes at Osmium films for help with the subtitles.

A word on copyright: I’ve not made this available before because I have no idea about copyright. You can tell from the fashion (and lack of women managers) that this is at least 1981 and it is even conceivable its out of copyright.

I have made efforts to track the copyright down and failed. I believe that at some point the video – and copyright I guess – was passed from HP to Motorola University. I read somewhere that the video actually had an HP or Motorola part number. Given that the HP of this video no longer exists (it has split twice, first HP and Agilent, then HP into Hewlett Packard Enterprise and HP Inc.) and that Motorola no longer exists (and that it also split multiple times).

Stockless Production from HP – a Kanban video Read More »

AOTB 2017 – notes on submission selection & review

Agile / allan kelly / March 25, 2017

Phewww… Agile on the Beach isn’t for another 3 months but in one way its just ended for me. So it is a good time to share a few notes, specifically about speaker selection.

Background

My role in Agile on the Beach centres on the speakers. In the early days I hand picked the line-up but for the last 4 (or maybe 5) years we’ve run an open call for papers. I write the CfP, I run the CfP process, I talent spot (and encourage submissions), I respond to (potential) speaker queries, I run the review processes.

This year the CfP opened at the star of December and earlier this month we published the full line-up, so the majority of my work for the conference fell in that period. The majority of this blog will focus on our selection procedure and provide additional feedback for those who submitted.

Those of you who are thinking of attending AOTB 2017 will also get an insight into what happens behind the scenes. And anyone – all of you I hope! – who are thinking of submitting to a future Agile on the Beach or any other conference may well learn something useful.

Everyone who submitted should have notification by now – accept or decline, please let me know if you don’t. For those we didn’t accept I’ll shortly send an e-mail with more information on how your submission faired.

It helps to understand the AOTB review and voting procedure (a blog from couple of years back). This year I widened the scoring system from -2 to +2 to -3 to +3 in an effort to spread out the scores bit, I’m not sure it helped through.

Another change was the addition of four new reviewers who are not on the conference committee. This removed some of the workload from the committee and, I think, made for better reviews. It also meant that no submission had fewer than 4 reviews and some as many as 7.

The big public change to Agile on the Beach 2017 is a move from September to July – a move forced on us by changed in the academic calendar at Falmouth University. But behind the scenes our organization changes have been even bigger – partly because we had 3 months less to organise 2017.

One big change is Mimas – more information on my Conference Review mini-site.

After several years of an ad hoc system of managing reviews I bit the bullet last summer and created our own conference submission and review system. I’ll blog more about this soon but right now let me say, like every other software development it seemed to take longer than expected!

However it has massively simplified things. I think next year, with the system in place and far less work needed, my life will be better. But, it has been work – and I’m so glad I did it test first!

Anyway, what can I tell you about the submissions themselves and the reviews….

About the submissions and reviews

There were over 320 submissions from over 220 potential speakers. With so many submissions I’m worried that we will loose out on fresh voices, I’m also worried some of the true experts will be deterred from submitting.

For each track round 1 reviews reduced this to a shortlist. For each track we decided a cut-off score, submissions which scored above this were on the shortlist and those below marked for decline.

We then did a double check, there were several sessions below the cut-off which held promise – e.g. interesting speaker or a novel topic – which we added to the short list. We specifically looked at all the submissions which didn’t make the cut-off but had been given a 3 score (the highest possible) by at least one reviewer. Most of these were then included on the shortlist as well.

And one or two, certainly no more, which were removed from the shortlist.

We also moved a few sessions between tracks in both rounds when we thought they were better in another track. But, with so many submissions we rely on those submitting to make intelligent choices on which track is most appropriate.

For 2017 the track shortlist cut-off score was:

Agile Business, 60 submissions, 9 speaking slow, shortlist threshold score: 8
Agile Practices, 57 submissions, 4 single slots available, shortlist threshold: 8
Product Design, 22 submissions, 4 single slots available, shortlist threshold: 7
Product Management, 38 submissions, 5 single slots available, shortlist threshold: 6
Team work, 83 submissions, 5 single slots available, shortlist threshold: 7
Software Delivery, 54 submissions, 9 single slots available, shortlist threshold: 9

(When a double is chosen then two single slots are combined.)

I was particularly happy to see more submissions in the Software Delivery track this year.

We had lots of very strong submissions from very strong, experienced, speakers. There are a few names we’ve declined this year who I find it hard to believe we said no: Judith, Karl and Steve spring to mind.

We also had quite a few weak submissions were the potential speaker only gave a few words of synopsis and biography – some even left the bio blank. I marked a lot of submissions down because the synopsis and/or bio did’t really say much. Some of these weren’t much more than a title and a list of bullet points.

Now quantity shouldn’t be a substitute for quality, less is more and so on, but… in a number of cases there wasn’t enough information to make a judgement so the submission was marked down. It also puts a question in my mind as to how interested the speaker is: I’m probably investing more time in reading and thinking about the proposal than they put into writing it.

If you want to speak the competition is fierce. You need to put really effort and thought into you submission.

Of course some synopsis go the other way and are too long, you bore before you get to the end. Similarly for biographies, not too much but not too little either.

Some synopsis spend all their time talking about the problem they will examine and said very little about the solution. Others seem to jump into solution without saying why – that is particularly true of talks which involve a brand-name tool or technique. (Sessions dealing with specific tools, especially commercial tools, are seldom scored highly by AOTB reviewers.)

There is an art to writing a synopsis: describe the problem (not in too much detail) and say something about the solution (without giving it all away), while at the same time being engaging and leaving the reader wanting to know more.

A few speakers – all from the USA interestingly – didn’t seem to read the call for papers. They requested speaking fees and/or proposed sessions which didn’t match our topic areas. I wonder if some people just fire off submissions to every conference?

To be clear: we don’t pay speakers.

We do sometimes give keynotes honorariums but we choose the keynotes, we don’t ask for keynotes in the open submission system. Normally we have already agreed our keynotes before the we call for speakers.

(If you know of someone you think would be a good keynote for AOTB please drop me a mail.)

As always those who requested long-haul airfare tended to get marked down. We don’t set a budget for speakers but we do keep an eye on costs, we have paid long-haul fares on occasions in the past but we can’t afford to pay many. This year both our keynotes are long-haul.

I can’t see any way around this. Its unfair but is a genuine constraint.

This year we did offer speakers the option of paying their own long-haul airfare and we would pay in country travel costs.

And similarly double sessions tended to get marked down. Again unfair but hard to avoid. We are aware of this problem and we do create some doubles space (the bonus track) but it is still a trade-off.

This year we seemed to have a lot of talks about “mechanical scrum” and “failing Agile”. Maybe this is a sign that Agile has come of age. These sessions didn’t score highly largely because they spent most of the synopsis setting out the problem rather than discussing solutions.

Failing Agile is well… a fact of life. It is only interesting when we can learn something from it – something not to do, or something to do differently, something to prevent or rectify the failure.

What will I want to do differently next year?

I hope to add a few more independent reviewers.
I’m thinking of designating track leads for reviews, these will weed out the clearly unsuitable submissions and help with the shortlisting.
Mimas will have a few tweaks but for AOTB it is essentially done.

So advice for those anyone thinking of submitting in future:

Read our Call for Papers: yes, I know it is long but we give a lot of information
Choose your track carefully: your changes of selection are much better if you submit into one of the more specific tracks (Software Delivery, Product Design and Product Management) rather than the three more general tracks (Business, Practices, and Teams.)
Put some effort into the synopsis, especially the short synopsis, tell us a bit about the problem but not too much, and tell us something about what you are going to say. The long synopsis isn’t as important but is useful for giving more detail.
Don’t take “long” synopsis as literally, it does not need to be very long. If you have a strong short synopsis then just leave long blank.
Watch your timings: some speakers gave detailed timing breakdowns (to the minute), on the whole these aren’t believable and people got marked down. However some speakers were just too ambitious in their contend and reviewers didn’t believe they could cover it all.
Double sessions really need to be outstanding, and they need to be interactive. No lecture based double has ever been selected.

I hope some of that is helpful to at least some of you.

AOTB 2017 – notes on submission selection & review Read More »

What do you mean… Done?

Agile / allan kelly / March 20, 2017

The Monday status meeting is drawing a close. Doris the development manager was keen to start working through a file of resumes on her desk, Sarah the lead developer knew her pair Jo had started coding without her, Peter the product manager was on a flight to Madrid in a couple of hours, but Pat… Pat the Project Manager was a stickler for the agenda.

“And so,” concluded Doris, “the development team are now able to do weekly releases. All we are waiting on now is for Pat to tell us the customers have been informed and we will commence weekly releases – which means you can get your new features and fixes to customer even faster.”

“Actually,” Liz chipped in, “the new pipeline means we can do daily releases or even story releases. There is no need for us to batch work up into occasional releases.”

“Yes, yes, thats very good”, started Pat “however our clients have signed off on a roadmap and release plan that shows fortnightly releases, I’m negotiating with them for one week releases, some have agree. But right now we have a bigger issue to discuss…”

“Come on Pat” interrupted Peter “most of them will be only too happy to have their feature requests and fixes a bit earlier”

“Thats as maybe but there is a process we have to follow. Many of them run their own change management groups and the more frequent releases will cause them problems. In fact I know one change manager at a multinational who would rather we reverted to monthly release. But, as I was saying, there is a bigger issue we have yet to discuss.”

Doris and Liz gave each other known looks, they knew what was coming.

Pat’s face hardened, “When, ladies and gentlemen, when will we be done?”

And so an age old game commenced…

“What do you mean done exactly?” asked Doris.

“You know perfectly well what I mean by done Doris, how long have we worked together?” Pat paused. “Today is March 14, the project plan had us completing on January 31 which means we are nearly two months late. Luckily I’d built in four weeks contingency but we are now overdue and I have to raise an exception report and request an extension from the board. The first thing they will want to know is: How much longer? When will you be done?”

“Hang on,” Peter was rattled, “you agreed with using the contingency, we could have called it done when we made the January 28 release but you yourself agreed that we should continue, I distinctly remember you saying you saw ‘revenue enhancing’ opportunities in the backlog and that everyone expected the contingency to be used anyway.”

“Thats as maybe Peter, but we need a line in the sand, this can’t go on forever.”

“What do you mean can’t go on for ever?” asked Liz nervously, “Do you know something we don’t?”

“Liz, I’m privy to all senior board instructions and I can assure you there are no redundancies in the pipeline”, Doris, ever the diligent manager, knew Liz was had suffered and unexpected Christmas redundancy at her last employer and there were still scars.

“Well technically Doris, the whole team will be released back to the pool at the end of this project. However I fully expect them all to be immediately assigned to the next project which starts the day after this one ends.” Pat didn’t have Doris’ knowledgeable touch. “Which leads me to ask again, when will you be done?”

Liz was proud of their delivery pipeline: “If you are so keen to be done then we can be done on Thursday. The next release is scheduled for 3pm so we can call it a day then. In fact, if you want we could say we were done three days ago and start right now on the next thing.”

“Pat,” started Peter, “there are features in this project and features in the next project, its all the same product, frankly, I don’t care where you draw the line. Its all stuff to me, and the customers don’t care as long as they get their stuff.”

“Thats as may be, but we have a process to follow and its not about meeting a date its…”

“Not meeting a date? A minute ago you told us it was!” Like most of the programmers and testers Liz found Pat annoying.

“The date is important, Liz, because the later the date the greater the cost and the board have ordered us to reduce costs. When the new project starts we will have a new cost code and a new budget. So when, please, when will it be done?”

Doris was about to point out that it was all the same money no matter what code it was spent under but Liz got in first.

“How much money have we left? Lets just keep coding till we run of money.”

“Liz, I repeat, we have to cut costs, that will not cut costs.”

“Then why don’t we pick up the remaining features and put them in the next project then?”

“Liz, that is amoral! That would hit the next project with scope creep before it starts, it would increase the costs and risk it not hitting its deadline.”

“But Pat, the next project can meet any deadline because it will release weekly. When we run out of time or money we just call it done. It is all a question of what Peter prioritises.”

At the mention of his name Peter felt he needed to intervene: “Pat, really, what do you mean by done? If its date then Liz is right.”

“Peter, there were certain promises made about what was to be delivered in this project.”

“Yes Pat, and we’ve met them.”

“No we haven’t.”

“Do your mean the features the McAnderson consultants put in the original BRD? The ones that never even made Should Have list, and which I dropped the day I was appointed 12 months ago?”

“No, not them, but I can quite clearly see a, what do you call it, ‘backlog’ of work to be done in the Pira tracking system.”

“Actually, Pira is out of date, we don’t keep it up to date” chirped Liz

“Well you should, its in your role and responsibility document Liz, I think it quite specifically say Team Leader should…”

“OK, OK, there is work to be done” agreed Peter, “but… it is low value work we only mark it as Must these days because Should is full of rubbish. I’m more than happy to de-scope it, there is much more valuable work right at the start of the next project.”

“I would also point out,” continued Peter, “that all the remaining backlog is work that was added after the project began, what you call scope-creep. If you just look at the work McAnderson identified – and which I didn’t remove – then we were done six months ago.”

“Peter, its not my job to decide what is in or out, that is up to you and Harry the CEO, my job is to manage getting it done. So I repeat, when will you be done?”

But Doris was on the war path: “Actually Pat, it is my job to manage the development work, and I have to ask you again what do you mean by Done?”

“You don’t mean date because you extended the date and could request an extension again. On the other hand we could be done on Thursday or last Thursday. Date is a meaningless criteria.”

“You don’t mean when will the staff be released because nobody is being fired and they are all going to work on the same code base and product, in the same office, the next day.”

“And you don’t mean scope, the ‘what are we building’, because McAnderson gave us the wrong stuff to start with, everything they asked for has either been done or cancelled. Peter is happy to move work to another project and even happier to dump stuff altogether.”

“And if, heaven forbid, we were seeking to maximise value then we would immediately jettison everything left in this project and start the next one now because all the remaining work has less value than 80% of the next project.”

“So Peter, before you ask anyone ‘when will it be done’ again, can you please explain just what you mean by ‘done’ ?”

Sometimes the obvious isn’t so obvious, readers of a similar age to myself may well remember the scene in Flash Gordon where on of the baddies says “What do you mean, Flash Gordon approaching?” What do you mean, Done?

What do you mean… Done? Read More »

Whats Next? – Agile disruption

Agile / allan kelly / March 5, 2017

A question from a LinkedIn follower, I thought I’d share my answer with readers:

“Hey Allan,

I’m giving this a shot reaching out to you. I recently was exposed to agile in the workplace (I am in a field now that I did not study) and am learning more about the process. My company introduced it to me. I have found a couple notes pulling it back to you with your experience. My questions are:

– What do you think is next after Agile?

– Where should I start with learning about this?

And do you have any advice for me, I am just now being exposed to software/electronic development and this process and would like to be able to contribute to our company?

So first things first: great you have set about reading up on it yourself! Ultimately Agile is all about learning and taking it on yourself to learn more about it is a great first move – you will go far!

What is next after Agile? – Cynical me thinks that people who ask that question are hoping agile will go away or looking to leapfrog it to the next thing. When posed inside a company I wonder if it is a form of resistance or obfuscation. Still … I do think “what next” about myself…

At a day-to-day level the next thing is already here: Continuous Delivery, although for those of us who started with Extreme Programming (XP) this is very much “back to the future.”

What is next after Agile? – that is a question that has been asked many times in the last few years. I’ve taken a stab at it myself over the years – like my “Future of Agile” presentation from 2009. In retrospect that presentation was both right and wrong on two counts. It was right because it has become clearer and clear over the years that Agile is Lean, Agile Software Development was our Lean revolution. Over time Agile has absorbed more and more Lean ideas.

The presentation was wrong on the first count because Lean has not, and I think will not, displace Agile. The Kanban insurrection has done a great in breaking the Scrum hegemony but Agile is here to stay – albeit infused with more and more Lean. (Take my own Xanpan for example.)

More significantly I was wrong because the thing that comes after Agile is not a replacement for Agile, rather it builds on Agile, Agile is building block – or as I put it a couple of weeks ago, Agile was the midwife.

Consider Toyota, they have been “lean” for decades, what came after “lean” for Toyota? It isn’t “Lean 2.0” or “Super Lean.” Lean enables them to do things like the Prius. Lean allows Toyota to pursue their strategy, Lean allows Toyota to produce almost as many cars as VW with half the workers.

Increasingly I don’t even think Agile has even replaced “waterfall” (aka “traditional”) software development. Big corporations still largely practise a form of waterfall with an Agile vinaigrette dressing. I don’t like it, it drives me nuts but fundamentally the vast majority of large corporations that exist today are incapable of pure Agile because they have been built for a different world.

That doesn’t mean they can’t borrow some things form Agile, it doesn’t mean Agile techniques can’t help them be better than they are but it does mean they will never truly be Agile – but then, it is wrong to say every company must be truly Agile, or be truly Agile in the same way. (For those Agile folk who can stand the madness there is good money in selling unsafe fast cars to the middle aged.)

But what does this mean for the future?

Well… traditional incumbents are increasingly vulnerable from Agile disruptors – companies which challenge them with new products and services which are only possible when technology is build in an agile fashion.

And that is what comes next: Agile Disruption.

Only we don’t call it Agile Disruption, its called Digital.

This is happening now… our technologies are making all sorts of new business opportunities possible but exploiting those opportunities are only available to the Agile company.

Only with an Agile process can firms truly harness the power of modern tools like Amazon Web Services, Ruby and Clojure, etc. etc. Processes designed in 1970 are a poor fit for 2016 tools and technologies. Its a bit like an airline using the operating processes it had for DC-3s when introduced Boeing 777s.

As computers get more powerful the opportunities they can address are greater, if a company can turn that opportunities into money they have a business. To understand this you have to consider Moore’s Law: Computing power doubles every two years.

The computers of today can address problems twice as complex as those two years ago.

The computers of today can address problems four times more complex than four years ago, eight times more complex than six years ago and 16 times more complex than eight years ago.

To put it another way, the next increment of Moore’s Law will increase computer power by more than all the previous increments added together.

You get the picture?

I was recently inside a large bank. It takes them over a year to get a new idea into production. If I recall correctly, 27 months is more normal, that is over two years. In other words, processing power has doubled in the time it takes the bank to get out of bed.

So Agile isn’t going away but the focus will be elsewhere. This is playing out in a number of ways.

Right now being Agile is table stakes. Continuous delivery is cutting edge but will soon be the minimum required. (If you are competing with Amazon it already is, if you aren’t competing with Amazon today just hope they aren’t eyeing your market.)

The discussion of “digital business” is the obvious one. Another is the rise of the #NoProjects/#ProjectLess movement I’m closely associated with. Underpinning both of those is continuous delivery.

Which means, if you want know more about what happens next:

Start keeping your eyes open for anything to do with digital business – most of it is rubbish but among the noise there is some good thinking
Read #NoProjects/#ProjectsLess
Learn about Continuous Delivery

A word warning here: I’m guessing you work in more traditional company. As you open your mind to all of this you are likely to make yourself unpopular with your colleagues as you try to implement these ideas and warn them. Unfortunately most existing companies have a Mayor of Rotterdam problem.

And naturally, keep reading my blog!

Whats Next? – Agile disruption Read More »

How (not) to impress a potential CTO

Agile / allan kelly / February 28, 2017

The other day I was at an event for start-ups and entrepreneurs – no, not the “Agile for Startups” event I’m speaking at in a couple of weeks, for once I was in the audience. Half way through the organisers decided to do a type of speed networking – so we could get to know each other, find employees, find clients, find investors, whatever.

One of the people I got to spend a few minutes with was an entrepreneur on the hunt for a CTO. As I often, usually (always!) find at these sort of events, there are far more potential non-coding entrepreneurs than there are “techies” to go around. Such events seem to be populated by non-techies hunting techies.

As soon as she heard I code she saw an opportunity… and she blew it. So for the benefit of other entrepreneurs hunting techies…

What she said was:

“Our product is 80% built, we had an intern last year and now we need someone to finish it.”

I also ascertained that: the start up was her and her business partner and as yet they had no customers. So I could also deduce that they had not validated the product Lean-Startup style, they had built and now were looking to “finish” it and find customers. So their start-up strategy already posed question.

When I asked “what is the technology stack?” she didn’t get the question at first asking and then said “I don’t know, its not my area.”

So whats’s wrong here?

“80% built”

That shows how little they understand about IT products, it ain’t never finished. Once you start using it people want changes, people see opportunities, digital business models depend finding new ways of using technology to create value.

If it was “finished” then… where is your business? – in a digital business the product is never finished.

Any CTO they hire is going to spend most of their time educating the founders – probably why they need a CTO in the first place!

But think for a moment, what if she is right? What if it is 80% done? Then the remaining 20% does not represent a lot of work for the new techie/CTO to do.

“an intern”

OK, there are some students who are awesome coders. Some of them are wasting their time at University, they should just go and earn big money. I was probably one of these people, I went to University and my degree has helped me later in life but…

The chances are this intern is better than average 20-something coder who has left behind a big mess – without unit tests. The CTO they hire is going to spend the next few years cleaning up that mess.

Lets put this together:

This is has not been validated in the market so it is a technology play
The founders not only lack technology skills but lack an understanding of technology business
A technology play by non-technical entrepreneurs just sounds like trouble

What lessons can we draw form this?

1. Firstly don’t confuse wanting a CTO with wanting a programmer. I think this lady and her partner do need a CTO and they do need a programmer, they may even be the same person – and I certainly hope any CTO remembers how to code. But… in trying to sell the role to me she was very confused.

2. They do need a CTO because this is a technology play. But I don’t think they see that, they see the need for a coder. They need to think more clearly.

3. She needs to recognise that “80% completed by an intern” is not a good sales pitch to any programmer (let alone CTO) worth their salt. It plays down both the amount of work to do, the challenge and promises a big mess to clean up.

4. Not knowing the technology stack is criminal: it is the most basic question any techie is going to want to know – a PHP Lamp stack is completely different to a Java AWS stack – and it is the most basic filter when recruiting technical staff. True it is not so important if you are hiring a CTO for a company with 50 developers but in a small startup the technology and business strategy are intimately connected.

Finally, yes, I could be tempted by the right opportunity to be a CTO – even a coding CTO – maybe one day…

How (not) to impress a potential CTO Read More »

Every project is test driven in the end

Agile / allan kelly / February 24, 2017

Let me give you the punch-line and then explain myself:

As soon as testing starts every “project” becomes a test driven.

If there is no formal testing period then that phase begin the moment customers/users start using the product.

I’ve recently been watching a slow motion train-crash, I had no power to avert the train crash and those I could alert didn’t want to hear me. So I was thinking: what will happen in the end?

The project has been forced on the organization by external authorities. Even if it wasn’t the budget allocated means it is too big to fail, it will take careers with it so it must succeed. It will be an exercise in pass the parcel with everyone attempting to show they did what was expected to avoid blame.

Anyway… in the end, I thought, they will enter a testing phase, as with all testing phases it won’t be just a test phase it will be a test-fix-test-fix until such time as the organization runs out of the will to continue. Just like every traditional project.

Which, when you think about it, means that when this project enters testing it will become Test Driven.

Sure the project will spend months “designing” and “implementing” but the project is so big nobody can understand it. Only when the parts are brought together, and the deadline is close, will people do what it required.

At that point they will be test driven.

Up onto that point all the planning, designing, implementing and what not is just shadow play, people avoiding doing what is needed.

This argument can be extended to every traditional project where testing is left to the end.

Between the start of work and the start of testing work might be done but how much of this is usable, how much of this is finally included in the solution is anyones guess. Once testing all work is test driven.

All software development is test driven, in the end.

Every project is test driven in the end Read More »