Category: Agile

Summer is here so things are quiet. I’m not running any more workshops during the summer and will use the time to review what I’m doing. Still, I have started to create an initial programme of events:

• User Stories Masterclass on 14 September, half-day
• Agile Estimating & Forecasting, 21 September, half-day
• Maximising value delivered in Agile, 28 September, half-day

Tickets are not on sale but the events are listed on Tito so if you are interested register your interest today and as soon as tickets are on sale you will know. More details are on my Agile training pages – where you will also find some great reviews from people who have been on the courses recently.

I have lots of ideas for more online workshops so if there is a subject you would like to see please drop me a note (contact at allankelly dot net) and I’ll see what I can do – it would be great to know what people actually want!

I’ve not yet decided what to do about free tickets for the unemployed and furloughed. While I like offering these tickets – it feels like the right thing to do – I am getting high dropout rates from people who register for these tickets. The old case of people registering for something and having nothing to loose if they don’t turn up.

The post September workshops appeared first on Allan Kelly Associates.

Last year I had a surprise: the company I was working with introduced OKRs – Objectives and Key Results. I started off very cynical about how effective these were likely to be but …

Not only did I come to like OKRs and the OKR setting process I came to see how they plugged a gap in agile and how they can be powerful for agile teams.

So a few months ago I started writing a book: A little book about Agile with OKRs.

I stalled for a few weeks but I’m working on it again so expect more updates in the coming weeks. Please let me know what you think of the book, and if you are using OKRs I would especially appreciate your thoughts and stories – I might even include them!

(Yes the name is deliberately chosen to build on the success of my “Little Book about Requirements and User Stories”.)

The post Agile & OKRs – the next book appeared first on Allan Kelly Associates.

The lockdown hasn’t effected my work environment that much. This is a picture of my home office, my garden office, my “man cave.” I am very lucky. When I’m not on site with clients I spend most of my time working here. Still, I miss visiting clients and conferences – although I did squeeze in Agile on the Beach New Zealand in the closing days of the old world.

A friend of mine works for Canonical – the Ubunto Linux people. The vast majority of the people at Ubunto work remotely. So while my friend lives in New Zealand he works with a team spread out across the world.

Once or twice a year, his whole team co-locates. They all fly together and work together for a couple of weeks, a sprint. Then they return home and work remotely with each other for another six months, then repeat. Once or twice I’ve seen Tim as he works in, or passes through, London. But as luck would have it the week I was in New Zealand he was on his travels.

In all this talk of how wonderful working-from home can be I don’t think there has been enough discussion about what makes a good experience and what makes it bad. The Ubunto story highlights a couple of points which I think are missing from much of the current discussion over remote/home working.

Firstly the team are equal: they are all remote.

Over the years I have observed big differences in the way teams which are all distributed operate and the way teams with only one or two members operate. When the bulk of a team are co-located and only one or two are remote there is an unequal relationship. My intuition says teams are better off when they are either all remote or all co-located. When five of the team are co-located and a sixth member is remote then things are more difficult.

The way lockdown came about this year teams went from one to the other overnight, literally. Which also means it was very egalitarian. Everyone was in the same position. That can only be a good thing.

The second thing I take from Ubunto is that face-to-face time is still valued. In fact, as we unlock I expect home working will be more common, more remote tools will be used but we will value co-locating and face-to-face contact all the more.

Where companies keep people remote I expect we will see the emergence of deliberate co-location. This might be a two week block like my friend or it might be a few hours or a whole day. I can easily imagine benefit from an agile team coming together for one day a fortnight to close out a sprint, run a retrospective and then plan the next sprint. (That will have a knock on effect in the office market as companies stop renting offices for years and rent meeting rooms by the day.)

In fact this will be essential. It is easier to build social capital – trust, comradeship – when you are face-to-face. For the last three months we have been running on the social capital and experience teams built up over years working together. The social capital account now needs toping up.

Existing teams, existing social capital and egalitarian distribution helped people work during the lockdowns. As we slowly move back to our offices that is going to change and we will need to make deliberate efforts to replenish social capital, keep people equal and build new teams.

New teams will benefit from working together face-to-face to get to know one another. Build some social capital and norms.

New employees in particular will need time together. Especially those, like fresh graduates, who are new to work altogether. Such people need to learn how to work. Doing that in a distributed environment is a challenge.

Those new to the workforce face an additional challenge: space.

Home working is OK for me, I have a garden big enough for an office (and I had the money to buy one.) How many people have been working of their kitchen table? or bedroom? Mixing your sleeping space with your work space can damage sleep patterns and add to stress.

How many new workers have that space?

I remember when I was a fresh graduate finding my way in the world I lived in house shares. I had a room in a shared house with similar people. Some of them I counted as friends but not all of them. Some of them had bad habits. Going to an office for work was important, staying in the house – especially when they were all staying in! – would have been too much.

Then there is the question of broadband: I have 200Mb fibre to the door but many people make do with a lot less and that can be variable. Not that 200Mb comes cheap…

If a company expect someone to work from home then I think they should pay for good broadband internet. They should also provide the equipment – I have heard of only a few employers who have given staff money to buy equipment for home.

In February and March many people all over the world found themselves having to work from home. Its been a better experience than many expected but I know people are flagging, I know people keen to get back to the office. In future I expect we’ll value face-to-face contact even as many people stay at home.

In the coming months people aren’t just going to walk back to the office and pick up where they left off. Work will be more varied. But now the initial pleasure and surprise of working for home is over we need to have a conversation about what companies need to do to support working from home in future and how it can be made sustainable.

Subscribe to my blog newsletter and download Project Myopia for Free

The post The future of office working appeared first on Allan Kelly Associates.

🔊 Listen to Post

User Stories Masterclass, 29 June & Agile Estimating & Forecasting, 13 July

Discounts below

I was once responsible for coaching a Product Owner called Jac. It was product owner for an “enterprise product” – a product sold to big companies to use internally. Sprint to sprint Jac got to decide what got done. In my book Product Owner authority went further: what was to be done in future sprints, what kind of things would be done in months to come, and the “roadmap” where the product was going. But… Jac seldom met customers, Jac might talk to them on the phone when they had a problem but Jac didn’t talk to the more senior people who signed the purchase orders.

Being an enterprise product there were consultants in the mix too: installing the product on site, configure the product, train customers and hold their hands. They went to customer sites and they met all sorts of people. Naturally the consultants had a view on what the product should do, what should be developed next and what should be done in coming months.

And all a consultant had to do was name a customer “Anna at Credit…” or “The CFO of first…. told me” and you could just see the product owner being undermined. I used to groan internally, I hated it – I hated it for my PO – but they were right.

When you meet customers you carry extra authority.

Last week I did a webinar entitled to Agile London entitled “Product Owner Common Mistakes” (the PDF). Guess what common mistake number #1 was?

(I also did a webinar with Adrian Reed entitled “Everything you ever wanted to know about the Product Owner but were afraid to ask” which was a great chat and audience Q&A session.)

Product Owner mistake #1: Not meeting customers

And here I mean Customers, and/or Users, and/or Stakeholders, I mean: people – and it is people – who have expectations, needs or wants for your product. Even if they don’t know your product could help address those needs and wants.

And when I say “meet,” well yes, I really would like you to meet them, shake them by the hand and share a coffee. I think you are both more likely to open up, share more and understand more. If possible spend some time observing them work.

I’m not stupid, I know we all work from home now, I know physical meetings are more difficult than ever so please substitute “meet” with Zoom, Skype, WhatsApp or plain old telephone. But as soon as you can get out and meet people.

In meeting people Product Owners get two big benefits.

The most obvious benefit is that Product Owners understand their customers and their needs better. They can learn how the product could help more, or where the product trips them up. They can learn how the product is beneficial and valuable and how that value might be increased.

Product Owners will also learn things they might not like to hear, things which might not be said over the telephone: where the product stinks, what alternatives might be considered and where the product gets in the way.

“what the customer buys is seldom what the company sells” Peter Drucker

People don’t like giving bad news and it is easier to hide such facts phone call, let alone in an e-mail.

The second benefit, as described in my opening story is authority and legitimacy.

Product Owners are specialists in what customer problems need solving, how enhancements to the product can add value and therefore what needs to be done to the product. They can only do that when they meet customers.

Meeting customers brings authority, one can say “Anna at Credit Bank told me…”

Meeting customers brings legitimacy because most other people never interact with actual customers, or only interact with a small subset when they have problems.

And as my example shows: if a Product Owner is not meeting customers they leave themselves vulnerable to those who do. When someone else, like a consultant, comes along and says “Anna from … says… ” they have authority, if the PO can not say “Mez from … had a different perspective…”

Direct access to customers – speaking to them and visiting them – confers authority and legitimacy. Product Owners need that authority and the knowledge that comes with it.

User Stories Masterclass is running online again, 29 June NOW BOOKING

Use code BLOG_READER for 30% discount + 25% Early Bird discount

New online class: Agile Estimating & Forecasting, 13 July – NOW BOOKING

Use code BLOG_READER for 45% discount + 25% Early Bird discount

Subscribe to my blog newsletter and download Project Myopia for Free

The post Product Owner: meet the customer appeared first on Allan Kelly Associates.

🔊 Listen to Post

Final call: Adding Value to Stories, starts 5 June

New: User Stories Masterclass waitlist, 29 June – waitlist available

When started writing what became “Little Book of Requirements & User Stories” I thought I was writing a few thousand words about the relatively straight forward subject of User Stories in agile development. A “few thousand” became a dozen online articles for Agile Journal and a few tens of thousands of words in the book.

Now those same lessons form the basis for my online workshop “User Stories Masterclass”. Still I find new perspectives and insights on User Stories. I was wrong, there is more to the simple “as a… I want… so that…” than I ever thought possible.

But for once I think we need to draw some boundaries, we need to be clear on what User Stories are NOT.

User Stories are not promises or commitments. Stories are ideas. Stories are tokens for work that might be done. Little more.

Simply writing a User Story, even adding it to a backlog in no way commits anyone to doing anything. Indeed I regularly recommend deleting stories from a backlog. I hear from start-ups who tell me that 30% to 50% of stories are never done.

User Stories are not functional specifications, although if you add enough acceptance criteria they may start to look like that.

User Stories are not functional specifications because User Stories are not complete. They are intended as a “placeholder for a conversation” or “a token for work to be done”. If they were complete there would be no need for that conversation and they would be much more than a token. They are deliberately incomplete to allow the conversation to happen. If the story was complete what can a conversation add? There is more value in the conversation than the story.

User Stories are not unambiguous, or rather: User Stories may contain ambiguities. In the same way User Stories are not complete they can be ambiguous. Again, if stories were clean cut and unambiguous there would be little to talk about in the famous conversation.

And by the way, the User Story conversation is not necessarily a one-off event: if you have the conversation then later, say, during development or testing, then talk some more.

User Stories are not user documentation, a collection of stories does not make a User Guide. If you need to create a user guide then the stories might serve as a reminder of what the software does but using them as user documentation would make for a very poor user guide.

If the system you are building needs a User Guide then the act of writing the User Guide is probably a story itself, a token for work to be done:

As a new customer using the system for the first time
I want a guide to get started
So that I can quickly get the benefits of the new system

All the usual rules of user stories apply here: be specific about who is using the system and what they need, include a so that clause to explain why they want to do this, leave some space for discussion (do the really want a user guide or a quick start guide?) and ensure the story has value in itself.

Similarly, User Stories are not any sort of system documentation, e.g. architecture document, maintenance guide. Again these are work to be done and may be the subject of a User Story.

In general User Stories are not part of the contractual commitment a team enters into. User Stories are poorly suited to be contractual documentation. Because User Stories are not complete and because they are ambiguous they perform poorly when used contractually.

Similarly, User Stories are not good as a record of what has been done. They can be forced into this role if they are updated after they have been developed – and preferably delivered. But that requires more work.

As with any documentation – user guide, system guide, a record of what was done, etc. – you should always ask: what value does this documentation have? and who will complain if this document does not exist?

Documentation is not free. Indeed documentation is very expensive – both to write and to read. And documentation is itself work to be done. Which means: if someone is writing a document then they are not doing something else, e.g. if a developer is documenting the system they are not adding new functionality.

Even when there is a technical author on staff to write documentation other work is displaced. The money used to pay a technical author could be spent elsewhere, another programmer or a tester maybe.

Documentation is expensive. Documentation is another deliverable.

User Stories are not intended to form part of the deliverable. They are transient, they come into existence to represent work that needs doing. They change as understanding improves and can, even should, be thrown away when the work is done.

User Stories Masterclass is running online again at the end of June.

Rather one session a week this time the class will be one afternoon, or possibly one and a half afternoons. Tickets will be on-sale soon, in the meantime you can join the waitlist and be the first to know when tickets go on sale.

Subscribe to my blog newsletter and download Project Myopia for Free

The post User stories are not… appeared first on Allan Kelly Associates.

As most readers will already know – and everyone else will have guessed – Agile on the Beach 2020 isn’t happening. Gather than try and move the whole conference online we are running some smaller events. Two of these are now booking: an online talk and an online TDD workshop.

Sander Hoogendoorn will be giving his Agile on the Beach 2020 online on July 8 – yes, that is the day he would have been giving it live in Falmouth if you-know-what hadn’t happened.

Tickets are free to those who have bought Agile on the Beach 2020 tickets (which will be honoured at AOTB 2021 too) so just remember to register for a ticket.

For everyone else there is a £20 fee – but if you enter the code “AOTBSH2050” will get you a 50% discount.

But before Sander’s talk, AOTB’s sister organization Software Cornwall is running a Test Driven Development workshop with Kevlin Henney and Jon Jagger. Again there are free tickets for AOTB ticket holder but places are limited so book soon.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Sander Hoogendoorn @ Agile on the Beach Keynote – and discount appeared first on Allan Kelly Associates.

🔊 Listen to Post

My next online workshop is now available for booking: Adding Value to User Stories.

As with my previous online workshops this is a series of four 90 minute online (zoom) sessions delivered on consecutive weeks. And as before a few tickets are available for free to those who are furloughed or unemployed.

This workshop is for Product Owners (including business analysts and product managers), Scrum Masters, Project and Development Managers.

Learning Objectives

• Appreciate the influence of value on effort estimates and technical architecture at the story and project level
• Know how to estimate value for user stories and epics
• Recognise how cost-of-delay changes value over time, why deadlines are elastic by value and how to use Best Before and Use By dates when prioritising work
• Appreciate how values define value, and how this differs between organizations

Details and tickets on the EventBrite booking page. Alternatively you can book directly with me.

The post Adding Value to User Stories appeared first on Allan Kelly Associates.

🔊 Listen to Post

After years of shared #NoProjects advocacy I finally for to meet Evan Leybourn exactly two years ago. Over lunch in a Melbourne cafe we talked #NoProjects and how we were both moving on. It may have been a little pre-emptive and some might call it arrogant but we felt #NoProjects was triumphant.

Two years on and projects are still with us, projects aren’t going away anytime soon but the ideas behind #NoProjects are mainstream. The leading thinkers in the software/agile/digital space generally support the thesis – certainly nobody is arguing the case for projects. Cutting edge teams don’t use projects. The language of projects remains (unfortunately) but the supremacy of the project model increasingly looks like a historical footnote.

Two years on from that lunch and it is clearer than ever that the (digital) world is moving away from projects. This was really brought home to me last week when I joined an unconference organized by the McKinsey consultancy. Nobody said “#NoProjects” but nobody was talking projects. Nobody was advocating more project managers or new project management approaches. The CTO of a bank came pretty close to saying “#NoProjects” but why bother? – not saying it meant it was accepted.

#NoProjects is in your face. #NoProjects is an invitation to start a flame war. #NoProjects is confrontation in itself. #NoProjects is very negative. #NoProjects doesn’t tell you what to do only what not to do.

Back in 2013 #NoProjects needed saying, Josh Arnold, Steve Smith and myself started Tweeting it to death – Evan came later. (I think it might have been Josh who first used the tag.)

As much as I’d like to take all the credit we were just the public face of #NoProjects. We were far from alone. Woody Zuill and Vasco Duarte started the #NoEstimates movement about the same time. While in my mind #NoProjects and #NoEstimates are different things many people see them as two sides of the same coin.

I’d first heard Mary Poppendieck talk candidly about problems with the project model over dinner at Agile on the Beach 2011. Many, many, other people were reaching the same conclusion. Once you start looking at the project model, especially in an agile environment, the problems are easy to see.

The logic against projects can be overwhelming but exposing it was a career threatening move. Even today being an open advocate for #NoProjects means there are jobs you cannot apply for. None of the original names will ever be considered for a project management job.

Look around you today: The Project Manager role is being replace by the Delivery Manager role.

SAFe is a #NoProject model.

Spotify is a #NoProject model.

Continuous Delivery is a #NoProject model.

And my own entry: Continuous Digital is certainly #NoProjects (it was written to tell you what to do instead of projects).

Sure masochists can add projects to SAFe, Spotify and CD but why? These models work well enough without projects.

Even Government departments suggest funding teams not projects.

Today, at every conference and event you will hear people say “Products over projects.” There is a realisation that products last, projects end – who wants to work in a business that plans to end?

Again, to be clear: I’m talking about the digital world, what we used to call software or IT. I don’t know about construction, transport, policing or whatever other discipline you might want to draw a parallel with. I’m sure, some projects will always exist. Somethings do end. Even I will end one day.

That the IT/software/digital world can do better than projects is now recognised. Other management models create more valuable outcomes.

One might say that #NoProjects is heading into retirement. As Josh said:

“The first rule of #NoProjects is not to talk about #NoProjects.”

So don’t wave the red flag of #NoProjects and rub peoples noses in it. For your own benefit understand where the project model goes wrong. Use that knowledge to watch for problems such as goal displacement, commitment escalation, imaginary triple lock contracts, undercutting quality, control through planning, value destruction, cost of delay ignorance, Diseconomies of Scale of course, and unlearn the project funding model.

(If you haven’t already check out my own Project Myopia or Evan’s #NoProjects book.)

Then, set a course for a better world: call it SAFe, Spotify, Products, Continuous Digital, Continuous Delivery or whatever you like. Aim to harness the power of early release, evolving design, requirements and learning. Retool your governance process and management models.

Use the carrot not the stick.

Subscribe to my blog newsletter and download Project Myopia for Free

The post #NoProjects everywhere appeared first on Allan Kelly Associates.

This week has been a bit of a feast about Agile On the Beach. So here is a list of this weeks writing and some previous posts.

• Agile on the Beach – update on review process
• Notes on Agile on the Beach submissions
• Why does AOTB have its own submission system?
• Mimas is OpenSource: the Agile on the Beach submission and review system is available to other conferences and the Mimas source code is on GitHub under an MIT license.

And some older entries that explain us:

• AOTB 2017 – notes on submission selection & review
• Mimas: What it does
• Agile on the Beach voting procedure
• Do you know the way to Falmouth? (needs an update)

This possibly shows that AOTB takes up far more of my life than it should! ?

The post All about Agile on the Beach appeared first on Allan Kelly Associates.

🔊 Listen to Post

That picture above is Mimas, one of the moons of Saturn – yes, I’m still a bit of a “geek”. Mimas is the name I chose for the Agile on the Beach submission system I started developing about four years ago.

I am a bit surprised that Mimas has grown to over 10,000 lines – mainly Python and HTML, a very small amount of JavaScript and a super tiny bit of CSS. O, and 239 unit tests which now take about 8 second to run. (Like so many other systems the front end isn’t covered by automated tests. This hasn’t been a big problem, the tests I have giv great confidence.)

I’m not completely surprised by the fact that four years later we are still using it.

The code has lots of failings – doesn’t every system? – but I’m immensely proud of it as more than I’m embarrassed by it. I’m particularly proud of the way the system held up to 300 submissions and 55 reviewers this year. This was the most use it has ever had.

As of last month the system is also OpenSource – MIT License. You can browse the code – and tell me about all my failings: Mimas on GitHub.

The system itself runs on the Google App Engine here. Anyone can log in and create their own conference. Although this being the post-review period, and me having some time, I’m taking the opportunity to make some improvements. If it is down it won’t be down for long. Unfortunately Google are forcing a database upgrade (NDB to Cloud NDB) on a move from Python 2.7 to 3.x (which I should have done a while back.)

Once upon a time I thought that other people might like to use the system for their conferences but nobody ever has. The offer is still there.

I’d love it if anyone else wants to help with development on the system – but I’m realistic to know this is unlikely. (If you want to help there are a lot of places in the UI where a little JS or CSS could improve things. In the backend I know a few places that could do with changes too.)

For the record this is what Mimas does:

• Conference organisers create a conference and accept submissions.
• Speaker details are retained for future conferences as are talk details.
• Submissions are accepted into tracks, they can have co-speakers, formats and duration are configurable.
• Two rounds of reviewing are supported, these are configurable. AOTB uses scoring for round 1 and ranking for round 2.
• Reviewers can volunteer and be assigned (random) submissions to review.
• Conference permissions allow for different users to have different capabilities.
• E-mail acknowledgements, acceptances and declines are handled via SendGrid – you can also define custom messages via templates.
• Half a dozen or more types of report plus export to Excel capability.
• OAuth login currently supporting e-mail, Google and Facebook via Firebase.
• Share reviewer feedback and comments with submitters.
• Some conference branding.
• (There is an open speakers directory and tagging mechanism, I should either improve this or scrap it.)

I’m currently building out a scheduler so the accepted submissions can be organised in the system too. Its half done.

There are bunch of ways I could develop it further: it could support paper review rather than conference review, it could support shepherding, it could be used for reoccurring events, and a whole lot more.

Finally, it is surprisingly cheap to run on the Google App Engine.

Anyway, its OpenSource, its live, let me know what you think.

The post Mimas is OpenSource appeared first on Allan Kelly Associates.

🔊 Listen to Post

Anyone who has submitted to Agile on the Beach in the last few years will have used our submission system: Mimas. Like so many other conference we, or rather I, created our own system.

“Why does AOTB have its own submission system?”

Flippant but true answer: because nobody else (yet) has decided to share out system. I’m more than happy to host other conferences

Perhaps the actual question should be:

“Why create your own system when there are others out there?”

Yes, good question. Well, two (plus one) reasons really.

One: About five years ago when I got fed up of the Heath-Robinson combination of Excel sheets, Google sheets, HTML and a little Python that I was using nothing fitted. If I recall correctly Papercall was just started. While many commercial conference management systems had a synopsis module most of these didn’t do public call for papers and they cost money. I thought about using CyberChair/EasyChair but these are quite off-putting and needed hosting.

Things have changed a bit now so I might not make the same decision today.

Two: I was really very keen to give submitters feedback on their submissions and this was missing from most systems. This is an agile conference and agile is all about feedback so we should give feedback shouldn’t we?

Hillside’s Pasture can do this but is quite a niche system and I’m not sure it could handle the load we get. Similarly the Agile Alliance have a system for their conferences which gives feedback but having submitted I wasn’t impressed.

So that was then. What about today?

Having our own system has allowed us to do things we wanted: like a public review with over 50 reviewers this year. Or changing the voting system.

Of course that comes at a cost: my time to change the system, my stress in keeping the system up (a lot lately). O, there are some charges for the Google Cloud but these are trivial, a less than $1 a year and most of them are down to one report I run repeatedly during the review processes.

Those might be reasons for keeping Mimas but really my overhead should encourage me to kill it. Of course, I’ve grown to love my code and while I admit is stinks in places (the look of the UI) I’m proud of it.

But, the over whelming reason right now for not moving to Papercall (or similar) is: Speakers.

There are more speakers and potential speakers than conferences. Possibly the money to be made from a conference submission system is not from the conference organisers but from the speakers who want to submit to conferences. A bit like advertising the service could be provide for free to conference organizers if submitters paid a subscription.

And I have met speakers who tell me the go to Pepercall (or whatever) and submit to conference X. Then look down the list of other conferences they fancy and make the same submission multiple times. That is valuable to potential speakers.

But, that ease of submission is a problem for organizers. Particularly organizers who want to give feedback.

Easy submission for speakers means more work for reviewers.

As a conference organizer I don’t want every Tom, Dick and Harry submitting to my conference. AOTB already has about 300 submissions a year, and as I’ve noted before some of these smell as if the submitter really doesn’t know much about us and hasn’t thought through the submission.

The interests of speakers and organizers are not aligned.

One way of solving this problem would be for conferences to share reviews. So if a speaker submits, say, to AOTB and Agile Cambridge and Agile Alliance then each conference can see what others thought of the submission. I could imagine that working.

I can also see obstacles. First of all: data privacy.

More troublesome I wonder if that would actually make it more difficult for new speakers to break in. The same old hands, with the same good reviews, would come to dominate the conference circuit and new ideas wouldn’t get in.

So there you go. AOTB has its own submissions system and I’ll tell you more about that next time.

The post Why does AOTB have its own submission system? appeared first on Allan Kelly Associates.

More notes on Agile on the Beach – this is going to go on all week, sorry but there is a lot to get on the record. Maybe only conference-geeks and those thinking of submitting to AOTB will find useful but I’d like to get it on the record and this is my blog ?

First off the Agile on the Beach is pretty much the same every year. Unfortunately it has grown over the years as we try and share more information with those submitting. I expect most conferences have the same problem.

Problem #1 the call for submissions is too big, problem #2 people don’t seem to read it. Actually, it is not just that people don’t read it but some people who submit don’t seem to know much about the conference.

The wrong track, Gromit

For example: lots of submissions are put against the wrong track. Many people seem to just submit to whatever track the system defaults to (and this year it looks like Agile Business was the default.)

While we can, and do, move sessions between tracks we don’t do this methodically. With nearly 300 submissions it would be too time consuming to review every session and decide which track it should be in.

Plus, some people deliberately want their submission in a particular track. Last year we had a talk on technical debt submitted to the business track. Before I moved it I happened to ask the submitter why he had gone there not software. His reply: “We deliberately did this because we want to raise the issue with managers.”

Some reviewers will mark sessions down because they are in the wrong track. That is a little unfair but understandable.

Where is Falmouth again?

One problem that seems to growing is people not knowing where the conference is. To be clear: Agile on the Beach is in Falmouth UK – lookup Falmouth on Google maps.

Falmouth is five hours by train from London. Seven hours from Manchester. Nine from Newcastle Upon Tyne.

You can fly into Newquay airport from several UK airports but you are still nearly an hour by taxi from Falmouth.

Both last year and this year we’ve accepted people who then, when they look at how long it takes to get to Falmouth pull out.

What is your conference about?

But that is not the worst.

Every year we get a few submissions, mostly from the USA , which are totally inappropriate, something like “Calisthenics for a younger look.” OK, I guess calisthenics helps make your body agile but did they stop reading at the conference name?

Mostly with some hint that the person who filled in the form is not the speaker. I suspect the semi-famous person has a PA who just submits to everything they can find.

We don’t pay

Similarly we get a clutch of submissions – again mostly from the USA – where in the synopsis the speaker say: “My feed is $1,500 plus travel expenses.”

AOTB only pays speakers a travel allowance, and we say that in the call for submissions.

OK, we do actually pay keynotes. But we choose the keynotes, usually in advance of the call for submissions. Don’t call us, we’ll call you.

During the year we get a few people – again largely Americans – who e-mail us to say: “I can keynote you conference blah blah blah…. my fee is blah blah.”

I can’t blame them, they are only trying to make a living. One day someone who we find interesting might even contact us!

(Ummm… maybe I should do it myself rather than waiting to be asked to keynote…)

I am …

A new one this year: round 1 was blind, no bibliography details. The hope was this would help new speakers and increase our diversity.

Some speakers chose to self-identification: they gave their names in the synopsis “I this talk Adam Jones will be talking about…” or even a mini-bio in the synopsis: “Sally Smith will draw on her long experience working as Agile Coach with companies such as blah blah blah”

True we didn’t tell people not to do this. Blind reviewing was an experiment so we didn’t really have any rules. But, some reviewers took a dislike to this – I can see comments which say “Would vote higher but speaker gave their name”

Please please please answer me when I call

Finally, AOTB has a two stage acceptance process.

If you get accepted you get a mail from me saying:

“Congratulations… here is the boring admin details, now confirm you can speak by clicking on this link….”

We know that a) some people can’t get to Falmouth, b) schedule change between submitting in December and acceptance in February, c) people forget they submitted, d) something in the admin details isn’t to their liking, d) some other reason.

Result: some people who submit can’t make it. That is why we ask for confirmation.

If you are accepted I need your reply. And the quicker I get it the better.

If I don’t get a reply after a few days I chase: repeat e-mails, Twitter, LinkedIn, SMS and if I need to I will pick up the phone and call you.

This year one speaker was impossible to contact, no phone number, no Twitter, no LinkedIn. My e-mail may have been going to spam. With a heavy heart I switched them from accept to decline.

Apart from this taking up my time it also delays the work of the rest of the committee, the website, the publicity, ticket sales and everything else. Until we have the programme in place a lot is on hold.

Your submission is important to us, please hold

Plus, we don’t say: “Sorry, your submission was not accepted” until we have our programme in place. When we loose a speaker we make an immediate substitution. It doesn’t seem right to tell a lot of people (about 240) that they are not speaking at AOTB and then a few days later say to one or two “O sorry, can we have you after all?”

We only send the sorries once we have all our speakers confirmed. So, if someone doesn’t reply, and we can’t get hold of them, we have no choice but to wait and try again. Which means everyone else has to wait which is not fair either.

Overall our system works. It is not perfect but I don’t think any system is perfect.

The post Notes on Agile on the Beach submissions appeared first on Allan Kelly Associates.

“Dear Customer, the truth about IT projects” was originally published in The Agile Journal way back in 2012. Unfortunately the essay has stood the test of time and is still regularly re-discovered online.

A couple of weeks ago I recorded an audio version of Dear Customer which I have now posted online. You can find links to the original publication and of a PDF of the essay at the same site.

O, and the essay forms the prologue to my Xanpan book, but newsletter subscribers probably know that because they downloaded a free copy of Xanpan when they subscribed!

The post Dear customer, the truth about IT appeared first on Allan Kelly Associates.

🔊 Listen to Post

My last post on hierarchy generated a fair bit of interest – both online and offline. Once it is pointed out people recognise there is a positive side to hierarchy, it is not so much “hierarchy bad, no hierarchy good” as it is “how much hierarchy?” and the culture around that hierarchy.

But there is something else I have to say, something that has been bugging me for years. Look at the picture above, it is a structure chart, this one from Wikipedia (public domain). I suspect few people below the age of 40 have seen one, this is the way I was taught to design software at University. A structure chart is like a flowchart but horizontal, not vertical.

Look familiar?

A structure chart looks a lot like a hierarchy chart. Compare the picture above with the (fantasy) organization chart on my previous post.

Structure charts are used when doing structured programming, a technique used in procedural programming. So Pascal, Modula-2, Algol, even C. In this world (experienced) programmers spend a lot of time thinking (and worrying) about layering. They aim for layered systems, these are drawn as dependency diagrams which – can you guess? – look a lot like hierarchies too.

While all of these techniques still have relevance, in our modern world things have changed. Primarily, procedural programming has given way to object-oriented programming. In OOP the object is the thing: the object is an idea, code and data reside in the object. We build our systems with self contained objects (well ideally).

Sound familiar?

I like to talk about Amoeba teams, similar ideas emerge under names such as Feature teams, or stand-alone, or even Spotify Squad. The repeated idea is that teams have a purpose and contain the people and skills they need to pursue that purpose.

In the 1970s and 80s we had procedural programming, structure charts and hierarchies. The organizational form of hierarchy matched our programming model. In the 1990s we switched to object-oriented programming and now our organizations are playing catch up in switching to “object oriented teams” (if I can coin a new expression, which naturally abbreviates to OOT).

Conway’s Law strikes again!

OOP changes how you design software, it also changes how organizations structure themselves. While OOP changes the way programmes are structured and reduces the way programs are layered (and dependencies managed) it doesn’t do away with a structure. There is still a framework in place. Similarly, OOTs don’t exist in isolation, they need to exist in a framework – a hierarchy of sorts.

(And of course modern UI models and micro-services means main() isn’t always the top of the program any more!)

Conway’s Law implies that a hierarchical organization will adopt procedural programming, which was true in the 60s and 70s. New companies, start-ups, born in the OOP age natural structure as OOTs. Existing companies first see tension because the two models rub against one another.

Then reverse Conway’s Law (Yawnoc as it is sometimes called) would suggest companies move towards OOT – which of course we see with all the big companies adopting “Spotify.”

Which raises the question:

If stand-alone/self-contained teams, and reduced hierarchy, are the organizational structure which parallels object-oriented design and programming… what is the organizational form that parallels functional programming? How do you structure your teams when you are working in Lisp, Haskell or F# ?

What about concurrent (parallel) languages like Occam?
What organizational structure parallels message passing systems?
Or Data flow architecture? And quantum computing?

Like this post? – Like to receive these posts by e-mail? Xanpan

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Object oriented hierarchy? – a postscript appeared first on Allan Kelly Associates.

🔊 Listen to Post

Before this weeks regular post (In defence of hierarchy) a commercial, by me, for me ?

In March I’m going on tour, I’m speaking at Agile on the Beach New Zealand. I hope to call into Australia on the way, and I’ve been invited down to Wellington too.

My itinerary is not confirmed yet and ideally I’ll delivery some more talks – and charge some fees to make the trip more sensible. So if you know anyone in Australia or New Zealand who would like me to deliver some training or presentation please put them in touch, allan@allankelly.net.

Which makes it a great time to introduce my Fresh Ideas workshops.

These are short (2 to 3 hours) workshops which expand on ideas you will find in my conference presentations and books. So far these are:

• Value and the story: this includes an estimation poker exercise which is a lot of fun
• Continuous Digital: ideal for regular readers of this blog who want to share these ideas with their colleagues.
• Strategic capacity planning: this is largely an exercise extracted from my Strategic Product Owner course and builds on experiences with capacity planning

I’m also including two old favourites under here, maybe not entirely fresh but they fit the bill in other ways:

• Better User Stories: extracted from my Requirements, User Stories and Backlogs workshop
• Agile refresher: this features in my agile training and has been run a number of times as a stand alone exercise, it is a lot of fun and a way to start a conversation about getting better

As always, if you are interested in any of these get in touch – especially if you are in New Zealand or Australia.

The post New Zealand, Australia and Fresh ideas appeared first on Allan Kelly Associates.

🔊 Listen to Post

Hierarchy, it is one of those topics which provokes a reaction.

There are many in the agile community who believe hierarchy is a bad thing. Teams – and whole organizations are better off without hierarchy. It is simply(!) a case of finding better ways of organizing which don’t involve hierarchy.

Then there are those who acknowledge that hierarchy has been with us for millennia and find it hard to imagine how anyone could organise without it.

As a general rule the supporters of agile come down against hierarchy. I’ve been known to rail against hierarchy myself but at the same time I’ve long had my doubts that it is possible to remove hierarchy altogether. Rather I aim for less hierarchy and greater independence rather than the abolition of all hierarchy. I tend to keep this view to myself because a) it is subtle and b) I suspect I’ll loose a lot of agile street cred if people know.

So when I heard about a book called Hierarchy by John Child I immediately bought a copy. This is no easy read – Child is a Professor and so the style is academic rather than pop-psychology business blockbuster. So far I’m about half way through but the book raises many interested point that I’m still thinking through.

In particular Child highlights a number of benefits of hierarchy which deserve attention and I think are too often overlooked. Right now I want to capture my thoughts so far before I get into the arguments against hierarchy. So…

The benefits of hierarchy to an organization:

• Hierarchy has benefits were there is regulation
• Hierarchy helps large enterprises bring structure to their activities
• Hierarchy tend to develop in all societies whether they are intended or not, therefore imposing a hierarchy gives an organization a chance both to impose the order they want – and choose the leaders – and rather than accepting the hierarchy and leaders that emerge.
• Hierarchy allows for succession planning
• Reduce illegal behaviour: maybe not a big issue in your twenty-first century office but this can be an issue. It can also be a particular issue when people rise to the top of a hierarchy and find the organizational controls they had before are gone: they have nobody to report to. Could this explain some of the sexual and business mis-conduct that has been in the media in recent times?

Benefits to the individual:

• Hierarchy creates psychological safety, individuals know where they fit in and what is expected of them. They know who they need to pay attention to.
• Hierarchy reduces cognitive load and fear, in part because of the psychological safety it creates.
• Hierarchy provides a career model: people know what advancement in the organization looks like and those who want advancement can map out a course to achieve that.

Benefits to a team:

• Hierarchy creates clear areas of responsibility which enables team members and creates focus within the team.
• Hierarchy provides team members with a structures and helps them accept their position. On the whole people are accepting of hierarchy and accept the position. (Perhaps because they also know how they can advance their position.)
• Hierarchy allows a mix of strong and weak personalities to work together. While hierarchy can be used by powerful formal leads to suppress weaker staff hierarchy cuts both ways. Team decision making can be improved when hierarchy facilities equitable discussion between strong personalities.
• Formal hierarchy, with formal leaders, actually puts a responsibility on the leaders to ensure balance and allow weaker personalities to have their say. (While this can be abused when it is abused it should be clear to all concerned that the leader is not upholding their part of the bargain.)
• In a recognised hierarchy the senior people have a responsibility to moderate and listen to all. Where there is no hierarchy few may feel that responsibility and a single strong voice may dominate the weak.
• Where there is no hierarchy and multiple strong personalities the result can be conflict and disagreement. Without the hierarchy it can be hard to resolve such problems.
• Hierarchy provides for decision makers, perhaps one, perhaps more. Having recognised decision makers can make for rapid decisions: people know who to go to and that person knows they have responsibility. Conversely, where decisions are made by consensus decision making can be slow or absent entirely.

Recently I observed a team which made most decisions by consensus. But as one strong personality rarely agreed with the others any decision they didn’t agree with became a battle field. Most team members kept quiet and nothing changed. Sometimes another strong personality would try and force the decision through but this was usually unsuccessful. Only when several other team members were prepared to take sides. As a result consensus became a recipe for not changing.

Of these arguments the ones I find most interesting are those which concern the emergence of social hierarchy. I’ve certainly seen this – even in organizations with a formal hierarchy. Emergent leadership and hierarchy can be a good thing. They can also be a bad thing.

I can immediately think of several teams I’ve worked with were one of the developers – sometimes a relatively junior one at that – emerge as leaders and the team adopted a hierarchy oriented towards that leader. On one occasion that leader was me and I like to think I brought an order and structure which was beneficial. But I’ve seen other occasions were the leader who emerged was at odds with others in the organization with the result of tension.

I expect the idea of emergent hierarchy is immediately recognisable to those schooled in emergent design and behaviour. The question becomes: should organizations accept this? Or should they try to guide it?

In the extreme should an organization fight an emergent hierarchy which conflicts with the aims and goals of the organization? And is it worth the effort?

So far I have more questions than answers. I haven’t suddenly become an advocate for hierarchy but I now recognised this is not a one sided discussion. I plan to write another blog when I get to the end of the book and have had a chance to think through the for and against arguments.

In the meantime I’d love to hear your thoughts and comments, just add them below.

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post In defence of hierarchy appeared first on Allan Kelly Associates.

🔊 Listen to Post

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

Happy new year! – There is always a special responsibility that comes with the first blog post of a new year. Fortunately Tom Cagley of SpamCast fame asked me a fantasy question:

If there is one piece of advice you would give to CxO executives what would it be?

There is plenty of advice I’d like to give them, but one piece of advice?

One piece of advice which is generic and cuts across industry upon industry. One piece of advice for all those companies I know nothing about.

Tough. When I eventually came up with my answer I knew I’d have to explain it.

I had to think long and hard. I knew immediately that it would be something on the continuous digital theme. (One piece of advice for budding authors: don’t write long books, I knew this already then I mistakenly wrote Continuous Digital, that should have been four books.)

Eventually I came up with this:

“Planning has rapidly diminishing returns: plan less, do more, learn more, redesign governance to kill early and often.”

I believe this is universally true. Plan anything for long enough and you will eventually plan your way out of doing anything. When I run my Extended XP Game I regularly see teams plan their way out of good approaches to work.

Some planning adds a lot of value. But the rate of learning slows and continues to slow. At some point you aren’t learning more at all, and sometime after that your learning is counter productive. As economists say: there are diminishing returns on the investment.

A little planning adds a lot of value. But each extra minute of planning adds less value than the previous minute. Plan a little, do a little.

In our modern technology driven world two factors make this especially true.

One: learning by doing is faster with modern technology

Technology has advanced: Moore’s Law means I have over 100 times as much power in my MacBook Air as I did in the 6502 BBC Micro I learned to program on in the 1980s. That in turn had more power than the IBM Mainframes of the late 1960s.

That means our tools are more powerful: the Python I programme in today isn’t the most powerful language but it is a damn site more powerful than 6502 assembler and BBC Basic. Add open source libraries and that Python is immensely more powerful than writing in 1960s COBOL.

As a result things that tool months or years to create take hours and days. A week of planning for a OS/360 COBOL program that will take 6 months to write makes sense. A week of planning for a Python program I’ll have running in the cloud by the end of next week doesn’t.

And when I say planning I mean all aspect of planning: research, requirements, schedules, architecture designs and the rest.

Sure a bit of planning makes complete sense. I would be stupid not to make a coffee and think about what I was about to do. But planning is all about learning, is about experiencing the future a little bit. The power of our tools today means that future is a lot closer, and the most rapid way to learn about it is to create it.

Once I reach that future it makes sense to stop, review and plan again. The quickest way to learn is to alternate thinking (that is “planning”) and action (learning by doing.) Do something, see what works, then take time to reflect and learn.

Doing is learning too. The question at any given point is: what is the fastest way to learn? In the beginning that is planning, very soon doing becomes faster.

Two: cost of delay changes everything

Once you appreciate cost of delay you see the world differently (If you don’t know cost of delay look at my Time-Value profiles (Look at my article in Agile Connection or read Don Reinertsen’s Principles of Product Development Flow.)

Now remember: planning time is time, planning delays launch. Keep planning, analysing, talking to potential customers, drawing imaginary project plans or perfecting your architecture (before you start building) all delays the time you will get a product into the market.

That delay is bad because it increases risk: until your product is in the market you are at risk of creating a product nobody wants, or at least nobody will pay for.

That delay means your product will earn less money – thats cost of delay. Potential customers may have found other solutions, competitors may have got there first, or technology advances may render your product obsolete.

Lets be straight: I’m not saying No Planning. A little planning can be really really useful and valuable. So please plan!

What I am saying is: plan a little, do a little. Repeat.

Then stop, reflect, evaluate, and plan a little more before you do a bit. Alternate planning and doing. I’m not original in saying that, the Shewhart cycle (i.e. the Deming cycle or PDCA), says the same and so do half a dozen other approaches.

The problem is: many executives have been taught to plan plan plan. Nobody ever gets in trouble for planning too much and most failures can be traced back to a failure to plan more if you try hard enough. Ultimately, if you plan enough you will never have any failures because you will never do anything.

Which brings me to the last part of that executive advice: “redesign governance to kill early and often.”

Organizational governance is overwhelmingly based on the assumption that we know what we are doing. Only things that are very well understood will be allowed to start. That incentivises people to plan plan plan. And when something does get started there is a bias against closing it down (inertia and commitment escalation).

That needs to change. Since we can’t know in advance we need to be able to react once work is in flight.

Organizations need to be prepared to start work where the outcome is vague. Governance then needs to kill initiatives which aren’t showing promise. Put it another way: the early stage gates need less rigorous and the later ones more rigourous. If governance isn’t killing initiatives often then either governance isn’t working or you aren’t taking enough risk.

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Plan less, do more appeared first on Allan Kelly Associates.

To coincide with my new book, The Art of Agile Product Ownership, I’ve written a post which appears on the publishers website: Four Things Every Product Owner Needs.

The post 4 things every product owner need appeared first on Allan Kelly Associates.

🔊 Listen to Post

I am sure some of you have noticed that my blogs have been a less regular the last few months. That is because I’ve been busy on other stuff. So a break from deep thoughts and advice on the software world to mention some other stuff I’ve been working on.

For a start, available right now, my Little Book of Requirements and User Stories is now available in audio format to listen to. Full details – and the FAQ as a free download on my website. You will find links there to buy it on Audible and Apple (its cheaper on Apple, don’t ask me why.)

To my surprise Little Book has long been my best-seller so I teamed up again with Stacy Gonzalez – who voiced Project Myopia for me – to produce an audio version of Little Book. In the few weeks it has been available sales are already outstripping Project Myopia!

Second, as some know I’ve been working with Apress to turn The Art of Product Ownership from a LeanPub eBook into a full regular book. That should be out in October, you can pre-order it on Amazon now.

(And if you can’t wait, I’ve got a pre-copy edit version I can share with you provided you promise to write an Amazon review when the book is published. Mail me or use the contact form if you are interested.)

Finally, that picture at the top of the page. I’ve been working with Nicolas Umiastowski to create a playing card retrospective. These are based on my Retrospective Dialogue Sheets In our experiments they have given retrospectives another twist. More about these soon – and details of how you can get a pack (in the mean time get in contact if you are really keen to try them.)

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post New books and cards – stuff happening appeared first on Allan Kelly Associates.

🔊 Listen to Post

Some years ago I was managing a team at an internet TV pioneer. Shortly after a release our biggest customer – ITV – was on the phone complaining about a bug. Unfortunately one set of data fields were retaining their value when they should be wiped clear. It took a couple of months before we could include a fix in the release but we were confident we would make ITV happy.

A couple of hours after the fix went live ITV were on the phone. Why had we removed the daily cache? They weren’t just “working around” the bug, they were utilising it as a feature.

Sometimes it seems the problem you think you are dealing with isn’t the problem you are dealing with. Sometimes the way to solve a problem is not to fix the problem head on. Rather the solution comes from reframing the problem so that it is easier to solve. To put it another way: the problem you are trying to solve is knowing the problem you are trying to solve.

I sometimes think of this as “go and look at it from a different place”. Whatever you are looking at – problem, opportunity, objective, way of life – looks different if you go and stand somewhere else. The more different the place you stand in the more different the thing looks.

Clearly one way of solving a problem is to define it as not a problem: “it is not a bug, it is a feature.” As the story above shows, one person’s “bug” can be another person’s “feature.”

The question is then: is the reframing acceptable to others? – can others share the reframed perspective?

By way of example, lets apply this to agile.

A big part of agile is focus: small user stories, morning stand-ups and sprint planning all help create focus. Once you decide what you are going to tackle you focus on it, push other things out of the way and do it. And do it to completion.

You might call this “eating the elephant”: don’t eat it all at once, carve off a small piece, eat and repeat.

Pushed to either extreme this approach has bad side effects. Focus too tightly or too inflexibility and you might deliver a thing but not a thing which others recognise as a solution to the problem. But taking a view too broadly, or being very flexible, negates the way of working because you don’t deliver anything, – or the solution you deliver doesn’t please anyone (the “you can’t please all the people all the time” problem.)

Reframing can be a powerful technique but it can also work against you if other’s reframe the problem.

So, how do you know, or rather how do you frame and decide what your objective is?

Deciding what the problem is requires some imagination, it requires focus and flexibility – to stare at the problem but be flexible in how you see it. It also requires understanding and then the ability to communicate that understanding to others.

While I often hear people say “we should focus on the problem” I wish we could spend more time focusing on the problem of knowing what the problem is.

Reframing the problem is an inherently human thing. While machines may now, or in the near future, be able to solve many problems there is a problem of knowing what problem to present to the machine.

A big part of human work – often managerial work – is framing problems and deciding which to solve and which not to solve. Framing can make a small problem big, or a big problem small. That is inherently a human activity.

So, how do you know what problems to address? how do you know where to look for opportunities?

Now isn’t that a problem in itself? – surely we could set that up as an objective in its own right. Again it needs defining and framing and… So how does one decide to eat an elephant? And which elephant? And even, why eat an elephant at all?

It all becomes recursive. You can’t recurse for ever so hopefully sooner or later you need to come to the top – otherwise you have just reinvented paralysis by analysis. Detailed problem thinking needs to be combined with vaguer, even oblique, thinking.

To make this very real: I’m a big fan of metrics, they help focus, they help you know if you are going in the right direction. But I detest metrics too because they are a blunt instrument which can mislead so easily.

Metrics are great for focus but they need to be combined with a healthy dose of scepticism and oblique thinking. Metrics have limitations.

Sorry no solutions today. Just awareness of the problem of problems.

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post The problem of the problem appeared first on Allan Kelly Associates.

🔊 Listen to Post

Those of us who don’t code any more, and perhaps many of those who do, need Electronic Monks to help us with software development.

There is an old Douglas Adam’s book (Dirk Gently’s Holistic Detective Agency) which features an Electric Monk. The job of an electric monk is to believe things for you. In Adam’s story people have too many things to believe so they offload all that believing to an electric monk. In my mind I’ve always considered part of the monk’s work to include worrying. I can’t remember if Adam’s says this explicitly or just implies it. (And as I no longer have a copy of the book I can’t check.)

I’m currently very engaged with one client as an Agile Coach (although I sometimes wonder if “Shadow Manager” might be a better term, more of that another day). I regularly find myself staring at the board thinking about the work it shows and worrying about whether it will be done. Sometimes my mind plays “what if games” – “If that card is finished soon, then the other one could move down and…”

The same worry plays out when looking at the backlog showing work not on the board. Or when I’m talking to the Product Owner. Or indeed when I find myself talking to middle managers and others in the company who have an interest in the work the team is doing.

Basically, there is very little any of us can do to move the work through.

Sure I can call a meeting and talk about optimising our workflow. But I’ve done that a few times already.

I could call a meeting and emphasis how important the work is to the company. I’ve seen this done many times. Some non-coders – call them “the business” – seem to think “If only the coders appreciated how important this work was then they would do it faster.” I hated this when I was a coder and I hate it when I hear others saying things like “Do they know how important this is?” Business folk sometimes seem to believe coders sit around drinking tea and coffee for most of the day.

By the way, I almost wrote “and Testers” in that last paragraph but then realised testers CAN make work go faster: they can just drop their standards, turn a blind eye to issues, accept things they wouldn’t have accepted last week. Piling pressure on Testers is a more effective route to getting work done than pressuring coders. But in both cases it is probably just piling up more work.

Pressuring people to do work faster usually creates problems which come a back and bite you pretty damn quick. As I’ve said before: There is no such thing as “Quick and Dirty” … “Quick and Dirty” actually means “Slow and Dirty”

I could go to the coders and ask “Are you done yet?” – or as 5-year olds say in the back of a car on a long journey (or just any journey) “Are we there yet?” In both cases it doesn’t change the time it takes to get to the end, the answer doesn’t usually say much but asking the question will annoy parents and coders alike.

But if I do anything – like calling a meeting or asking “are we there yet?” – which involves distracting coders from working then I am slowing work down. It is self-defeating.

Yes there are things I can do to make work go more smoothly but once a piece of work is in flight there is little I can do. Most of the change I can make are to do with the way work happens. Or to put it another way: I can influence the climate work happens in but I can’t control the individual weather events which are the work items.

All I can do is worry. Thus my desire to offload that worrying to an electronic monk. Maybe more people in and around software developerment need to recognise they are in the same position.

Like this post? – Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

Check out my latest books – Continuous Digital and Project Myopia – and the Project Myopia audio edition

The post Are we there yet? appeared first on Allan Kelly Associates.

I hate the “building software is like building buildings” metaphor. For a start most software people know so little about physical building that they are comparing the messy world of software construction with a idealised image of what they think happens in construction.

The above is a picture from my back garden last week. Only a couple of weeks ago the back of this house looked much like the back of my house, except it had an small, ugly, 2m x 1m kitchen extension on it. And it had an over grown garden, a third of which houses this big extension while the rest of it is full of building debris.

The builders moved into this house less than six week ago. During that time they have: cleared the garden, cleared the house of remaining furniture, dug foundations, concreted foundations, built a two story side and back extension, ripped the roof off both this house and the ajoining house and replaced the roof while also constructing loft conversions on both houses. The roof came off on Monday and the new one was done by Saturday.

Builders – roofers and brick layers – go fast. Three years ago I had some work done on my house. I was well impressed with the speed the builders ripped the back rooms apart, tore down a wall, bricked up a door, and built a new wall.

Then it goes slow.

Once the actual “building” is done the wiring, plumbing, plastering, decorating and other fitting-out starts and o my, it goes so slow. Hold ups are regular as parts and people are not available when needed. There is a constantly changing cast of workers as specialists appear for a few days and then disappear.

I expect it will be four or five months before anyone is living in my neighbours house again.

During that time it goes slow, work people come in but it is hard to see progress. And the progress is far less clear than when a wall disappears, or a new wall comes into being overnight.

And so it is in software… usually.

The thing about construction – both physical and software – is that so often the most visible bits are actually among the most quickest and straight forward. These are the bits where not only can progress be made rapidly but visibly too.

But lots of time is spent on less visible bits – the tricky bits. The Devil is in the Detail as the saying goes.

When people say “How can is possibly take so long?” they are speaking from the experience of seeing the visible bits happen fast. The less visible bits, where the time is consumed, they don’t know what is happening during the less visible bits and have few memories to guide them – but they did remember it went fast last month!

When my house was being worked on I often felt like saying “why isn’t it done yet?”. The big changes, the heavy lifting, was done. How could all this other stuff? – the minor bits, the bits which didn’t require actual building – take so long?

Fortunately, software doesn’t need to be like this. There are alternatives. But working such ways means slowing down the early stages to deal with the detail as you go. Overall you get a more consistent (and sustainable) pace, and may well finish sooner but you loose the quick start that impresses people. Almost from day-1 they start complaining about the lack of progress.

Not being a builder I don’t know, but I do know I hired experts and I have to trust them. And I never tried to say to them “If this was software you would be done by now.”

(Now I’ve written this blog I remember, I’ve said something two years ago… Heavy Lifting is the Easy Bit. Worth saying again I think.)

The post Building software is not like building houses (thankfully) appeared first on Allan Kelly Associates.

Throwing mud at a wall is a metaphor I use again and again. As a description of what I do and as a metaphor for creating change in organizations.

When you throw mud at a wall most of it falls off immediately. Some will stick for a little while then falls off. A little sticks permanent. Perhaps too little to see. So you throw some more and the same thing happens. Sometimes it looks like no mud has stuck but actually a little bit has even though you cannot see it.

Every time the mud falls off it is sad, even depressing but you have to keep throwing. Thats all you can do really.

You keep throwing, the more mud that sticks the better the chances that more will stick next time. Gradually, slowly, sometimes imperceptibly the mud builds up. As long as you can maintain your energy, stamina and resolve, you keep trying.

It can be depressing. Sometimes you can stay positive and you give up. Perhaps you move on to another wall.

In this blog, in my books, in my tweets (thankfully vastly reduced recently) I throw mud. Yes, I am a mud slinger, some people think I doing it with bad intentions. But my intentions good, I see a world that needs to think differently.

And when I’m hired to help companies I see it much the same way. I throw a lot of ideas at people, I suggest lots of changes, I throw mud at a wall and most of my ideas fall off. Much of what I suggest gets ignored. No matter how much I talk I have no authority, people are free to ignore me.

Some places I’m very successful, some less so. When I’m inside a company I try to be a bit more directed with my mud throwing, and I limit the ideas I’m throwing. But still it is a question of stamina and resolve. Some places are just more receptive to new ideas than others.

And actually, this is my model for all organizational change. To my mind, all us “change agents” (yes I hate the term too) can do is make suggestions. Throw ideas at people, if they like the ideas, if they think the idea might help then they might adopt it. But they don’t have to. It is hard to force change on people, if you try they may say they will change, they may go through the motions but sooner or later – when your back is turned – the mud will fall off.

Individuals have free will. Most of them want to work as best they can. So if some “agile coach” turns up with an idea workers don’t think will work they are free to ignore it.

I’m not a great believer in authority: just because you are blessed with the title “Manager” (or “Director” or “Executive” or even “President”) doesn’t mean people will fall your orders immediately and without question.

The best way of getting your mud to stick, getting your ideas and changes adopted is to help people understand how such changes will benefit them as individuals. Benefit them in the work they do, the quality of their life-work balance and the pride they feel in work.

Conversely, there are some people, even some organisations, who are totally unreceptive to mud. They go out of their way to avoid it. It is hard enough throwing mud which doesn’t stick, but when people don’t want it to stick, well, I’m probably better off going elsewhere.

Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Throwing mud at a wall appeared first on Allan Kelly Associates.

Q: What is the difference between programming in college and programming in the real world?
A: Error handling

Do you remember when you were learning to program? Do you remember those text books you had back in college? And do you remember what they said about error handling?

As I remember it most of what they said about error handling was:

        /* error handling omitted for brevity */

Or perhaps:

        (* error handling omitted for brevity *)

Back in college error handling hardly got a mention, and if it did it was to abort the program. Yet in the real world 80% of what you program is error handling, or rather exceptions, the corner cases, what happens when things go wrong.

I’ve been saying this for years but this week I realised how shocking this was.

A couple of years ago a paper entitled “Simple Testing Can Prevent Most Critical Failures: An Analysis of Production Failures in Distributed Data-Intensive Systems” (2014, you know its an academic paper because it has 8 authors)) was momentarily famous on Twitter. I grabbed it and had a quick read but this week I had reason to go back and look at it again. In the process I found a 20 minutes video presentation by one of the authors.

To cut a long story short, the authors looked at the source code for large open source applications (Cassandra, MapReduce, etc) and software failures. Among various finding they reported:

• Finding 1: “A majority (77%) of the failures require more than one input event to manifest, but most of the failures (90%) require no more than 3” – so even if didn’t happen very often, they were difficult to simulate in system testing
• Finding 9: “A majority of the production failures (77%) can be reproduced by a unit test.” (Yes the reoccurrence of 77% is suspicion but I think it is an improbably but genuine co-incidence, please read the paper or watch the video before you fault the paper on this.)
• Finding 10: “Almost all catastrophic failures (92%) are the result of incorrect handling of non-fatal errors explicitly signalled in software.”
• Finding 11 “35% of the catastrophic failures are caused by trivial mistakes in error handling logic — ones that simply violate best programming practices; and that can be detected without system specific knowledge.”

The authors even created a tool to scan code for some of these problems. In many cases they found code like:

catch (…) {
        // TODO
}

catch (Exception e) {
        /* will never happen */
}

My old jibe about error handling looked very real.

This morning I pulled some old books off my shelves and was shocked by what I found:

First the book I was prescribed at not one but two University programming courses: “Problem Solving and Structured Programming in Modula-2” by Elliot B. Kaufman (1988).

I can’t find “Error handling omitted” in this book, my memory was wrong but the book is worse. I can’t find any error handling to speak of! I found one example which returns a boolean success/fail flag but there is no discussion of what to do with it. “Error handling” is not even in the index, let alone the table of contents – actually “Error” isn’t even there.

Each chapter ends with a “Common Programming Errors” section but this section is mostly about compile time errors.

Next I looked at the silver book, Wirth’s “Pascal User Manual and Report” (1991). I can only find two references to “errors” (nothing to exception). Both these references are in the report section and don’t say anything about how to program error handling.

As I looked at more old books I noticed how they just assumed everything worked well.

K&R is slightly better – “The C Programming Language” by Kernighan and Ritchie (1988) that is. Most of the examples here do check for errors, then printf. Sometimes that is it, sometimes there return 0 or break. On page 164 they say:

“We have generally not worried about exit status in our small illustrative programs, but any serious program should take care to return sensible, useful status values.”

In other words: Error handling omitted for brevity.

Moving away from the introductory books I turned to what might be the longest single volume technical book I ever read. A book I quoted as a bible, a book who’s author I still put on a pedestal: “Large Scale C++ Software Design”, John Lakos (1996). While John does say a bit more about error handling it does not feature in the index and there is no dedicated section to it. Looking at it now I am in disbelief, how could a book a large scale C++ not have at least one chapter on error handling?

Of the books I look at this morning only Kernighan and Pike’s “Practice of Programming” (1999) gave any coverage to error handling. And that isn’t saying much.

OK, these are all ancient books. Have things changed? – you tell me.

I hope more recent books, in more modern languages have got better – and my old (1999) copy of “Learning Python” (Ascher) contains a whole chapter on exceptions as does Stroustrup’s “C++ Programming Language” (2000).

But I am sure error and exception handling hasn’t got any simpler. I can’t believe that JavaScript, PHP, Swift, and simiar. have somehow made the problem go away. “Throw exception(blah, blah, blah)” might be a great improvement over “return -1” but I can’t imagine handling these cases has got easier.

Based on the “Simple Testing” paper improvements in training programmer in error handling need to be redoubled.

Like this post?

Like to receive these posts by e-mail?

Subscribe to my newsletter & receive a free eBook “Xanpan: Team Centric Agile Software Development”

The post Error handling omitted for brevity appeared first on Allan Kelly Associates.

The #NoProjects #NoEstimates workshop returns to London on 15 February with Duarte Vasco and myself.

Learning Connexions are taking bookings now, for a 10% discount use the code VASCO10.

The post #NoProjects #NoEstimates workshop discount appeared first on Allan Kelly Associates.

Learning Connexions and I are running my “Requirements Backlogs and User Stories” workshop next Monday – 3 December in London. They have set up a Black Friday discount code which is only good today and reduces the price by 20% – so just under £500 for a day (including lunch!)

The code is: BLUEFRIDAY2K18
And actually it works with all their courses not just mine.

As for the day itself, the title pretty much says it all. We do some exercises, we review some actual user stories, we value some stories and we talk a lot. I deliberately keep the classes small so that we have plenty of time to discuss the things attendees want to talk about.

Most of the attendees are Product Owners, Product Managers or Business Analysts. We also get a few developers and project managers along too. But whatever your role I’m sure you will learn something,

And sorry, if I’d known this a few days earlier I’d have included this in my last post.

The post PS A discount code for my December workshop appeared first on Allan Kelly Associates.

It is six years now since I introduced Retrospective Dialogue sheets to the world and I continue to get great feedback about the sheets. Now I’m running a little MVP with the sheets via Amazon, but first…

In the last few months Alan Baldo has translated the planning sheet to Portuguese and Sun Yuan-Yuan, with help from David Tanzer, has translated two of the retrospective sheets to German.

Thank you very much Alan, Sun and David!

I also updated the Sprint Retrospective sheet (above): version 5 has removed all references to software development. While can still be used by software teams it is more general. Actually, the sheet was largely domain neutral already which explains why it has been used in a Swedish kindergarten for retrospectives.

In the meantime I’ve been busy with an MVP experiment of my own – which has taken a surprising amount of work to get up and running – and you can help with.

I have made printed versions of the latest Sprint Retrospective sheet available on Amazon to buy. The sheets are still available as a free download to print yourself but I want to see if I can reach a broader audience by offering the sheets on Amazon. Plus I know some teams have trouble getting the sheets printed.

Right now this is market test, the printed sheets are only available in the UK I only have a few sheets in stock so this is a “Buy now while stocks last” offer.

If you are outside the UK (sorry) and want a printed sheet, or find stocks have run out, or want a different printed sheets please contact me and I’ll do my best.

Assuming this is a success then I’ll get more sheets printed, arrange to sell outside the UK, add more of the sheets to Amazon and make a renewed effort on translations. Pheww!

So now I need to ask for your help.

If you have used the sheets and find them good please write a review on Amazon – there are a few but there cannot be too many.

Conversely, if you have never tried a Dialogue Sheet retrospective please do so and let me know how it goes: I am always seeking feedback. Download and print for yourself or go over to Amazon and buy today – you could be the first buyer!

The post Dialogue sheets update – translation & Amazon appeared first on Allan Kelly Associates.

This blog post will be deleted in the next few days.

It really doesn’t say much but… some of you read this blog via an e-mail shot. So I think, if you are reading this blog you probably received it via e-mail.

But you shouldn’t off. I think I’ve transferred everyone from that list to my other list – which should be the only one from now on.

But as you can tell, I’m not convinced.

So, if you want to keep receiving this blog by email – and please do! – I suggest you subscribe to the other list

https://www.allankellyassociates.co.uk/newsletter/

As a thank you I’ll throw in a Free Copy of Xanpan.

And now, I’ll delete this post….

The post A blog post that never was appeared first on Allan Kelly Associates.

Over Christmas I was thinking, reflecting, drinking…

Once upon a time I was asked by a manager to teach his team Agile so the team could become Agile. It went downhill from there…

I turned up at the clients offices to find a room of about 10 people. The manager wasn’t there – shame, he should be in the room to have the conversations with the team. In fact half the developers were missing. This company didn’t allow contractors to attend training sessions.

For agile introduction courses I always try and have a whole team, complete with decision makers, in the room. If you are addressing a specialist topic (say user stories or Cucumber) then its OK to have only the people the topic effects in the room. But I am talking about teams and processes, well I want everyone there!

We did a round of introductions and I learned that the manager, and other managers from the company, had been on a Scrum Master course and instructed the team to be Agile. Actually, the company had decided to be Agile and sent all the managers on Scrum Master courses.

So the omens were bad and then one of the developers said something to the effect:

“I don’t think Agile can help us. We have lots of work to do, we don’t have enough time, we are already struggling, there is masses of technical debt and we can’t cut quality any further. We need more time to do our work not less.”

What scum am I? – I pretend to be all nice but underneath I allow myself to be used as a tool to inflict agile pain on others. No wonder devs hate Agile.

My name is Allan and I provide Agile training and consulting services.
I am guilty of training teams in how to do Agile software development.
I am guilty of offering advice to individuals and teams in a directive format.
I have been employed by managers who want to make their teams agile against the will of the team members.
I have absented myself from teams for weeks, even months and failed to provide deep day-in-day-out coaching.

In my defence I plead mitigating circumstances.

One size does not fit all. The Agile Industrial Complex* has come up with one approach (training, certification and enforcement) and the Agile Hippies another (no-pressure, non-directive, content free, coaching).

I don’t fit into either group. Doing things differently can be lonely … still, I’ve had my successes.

I happen to believe that training team members in “Agile” can be effective. I believe training can help by:

• Providing time for individuals to learn
• Sharing the wisdom of one with others
• Providing the opportunity for teams to learn together and create a shared understanding
• Providing rehearsal space for teams to practice what the are doing, or hope to do
• Providing a starting-point – a kick-off or a Kaikaku event – for a reset or change
• and some other reasons which probably don’t come to mind right now

Yes, when I deliver training I’m teaching people to do something, but that is the least important thing. When I stand up at the start of a training session I image myself as a market stall holder. On my market stall are a set of tools and techniques which those in the room might like to buy: stand-up meetings, planning meeting, stories, velocity, and so on. My job is to both explain these tools and inspire my audience to try. I have a few hours to do that.

As much as I hate to say it, part of my job at this point is Sales. I have to sell Agile. In part I do that by painting a picture of how great the world might be with Agile. I like to think I also give the audience some tools for moving towards that world.

At the end of the time individuals get to decide which, if any, of the tools I’ve set out they want to use. Sometimes these are individual decisions, and sometimes individuals may not pick up any tools for months or years.

On other occasions – when I have time – I let the audience decide what they want to do. Mentally I see myself handing the floor over to the audience to decide what they want to do. In reality this is a team based exercise where the teams decide which tools they want to adopt.

If a team wants to say “No thank you” then so be it.

In my experience teams adopting Agile benefit greatly from having ongoing advice on how they are working. Managers benefit from understanding the team, understanding how their own role changes, and understanding how the organization needs to change over time.

Plus: you cannot cram everything a team need to know into a few hours training and it would be wrong todo so. You don’t want to overload people at the start. There are many things that are better talked about when people have had some experience.

Actually, I tend to believe that there are some parts of Agile which people can only learn first hand. They are – almost – incomprehensible, or unbelievable until one has experience. That is one of the reasons I think managers have trouble gasping agile in full: they are too far removed from the work to experience it first hand.

You see, I believe everyone engages in their own sense making, everyone learns to make sense and meaning in the world themselves. In so much as I have a named educational style it is constructivist. But my philosophy isn’t completely joined up and has some holes, I’m still learning myself.

When I do training I want to give people experiences help them learn. And that continues into the work place after the training.

So I also offer coaching, consulting, advice, call it what you will.

But I don’t like being with the team too much. I prefer to drop in. I believe that people, teams, need space to create their own understanding. If I was there they wouldn’t get that space, they wouldn’t have those experiences, and possibly they wouldn’t take responsibility for their own changes.

One of my fears about having a “Scrum Master” type figure attached to a team is that that person becomes the embodiment of the change. Do people really take responsibility and ownership if there is someone else there to do it?

I prefer to drop in occasionally. Talk to individuals, teams, talk about how things are going. Talk about their experience. Further their sense making process. Do some additional exercises if it helps. Run a retrospective.

And then I disappear. Leave things with them. Let them own it.

Whether technical skills are concerned – principally TDD – it is a little different. Because that is a skill that needs to be learned by practice. I don’t tend to do that so I usually involve one of my associates and they are sometimes embedded with a team for a longer period.

Similarly, I do sometimes become embedded in an organization. I can be there for several days a week for many weeks on end. That usually occurs when the organization is larger, or when the problems are bigger. Even then I want to leave as much control with the teams as I can.

On the one hand I’m a very bad person: I accept unwilling participants on my training courses and then don’t provide the day-to-day coaching that many advocate.

On the other hand: what I do works, I’ve seen it work. Sometimes one can benefit from being challenged, sometimes one needs to open ones mind to new ideas.

If I’m guilty of anything I’m guilty of having a recipe which works differently.

And that team I spoke of to start with?

One day two some people did not return: that was a win. They had worked out that it was not for them and they had taken control. That to me is a success.

Most people did return and at the end, the one who had told me Agile could do nothing for them saw that Agile offered hope. That hope was principally an approach to quality which was diametrically opposite to what he initially thought it was going to be and was probably, although I can’t be sure, the opposite of what his manager thought Agile meant.

It is entirely possible that had his manager been in the room to hear my quality message I’d have been thrown out there and then. And its just possible I might have given him food for thought.

But I will never know. I never heard from them again. Which was a shame, I’d love to know how the story ended. But that is something else: I don’t want to force anyone to work with me, I don’t lock people in. That causes me commercial headaches and sometimes I see people who stop taking the medicine before they are fully recovered but thats what happens when you allow people to exercise free will.

O, one more thing, ad advert, I’m available for hire, if you like the sound of any of that then check out my Agile Training or just get in touch.

*Tongue in cheek, before you flame me, I’ve exaggerated and pandered to stereotypes to effect and humour.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post I am guilty of Agile training appeared first on Allan Kelly Associates.

German readers might recognise the image above as a Nuremberg Funnel. For the rest of you: the Nuremberg funnel represents the idea that a teacher can simply open a students head and pour in learning.

First off, a warning: this blog entry might be more for me than for you, but its my blog!

Still, I expect (hope) some of you might be interested in my thoughts and reflections on how training, specifically “Agile training” sessions. More importantly writing this down, putting it into words, helps me think, structure my thoughts and put things in order.

Shall I begin?

I’m not naive enough to think training is perfect or can solve everything. But I have enough experience to know that it can make a difference, especially when teams do training together and decide to change together.

One of the ways I’ve made my living for the last 10 years is by delivering “Agile training.” I don’t consider myself a “trainer” (although plenty of others do), I consider myself more as a “singer songwriter” – it is my material and I deliver it. I’ve actually considered renaming my “Agile training” as “Agile rehearsal” because thats how I see it. I haven’t because I’d have to explain this to everyone and more importantly while people do google for “Agile training” nobody searches for “Agile rehearsal.”

Recently I’ve been prompted to think again about how people learn, specifically how they learn and adopt the thing we call “Agile”. One unexpected experience and one current challenge have added to this.

A few months ago I got to sit in while someone else delivered Agile training. On the one hand I accepted that this person was also experienced, also had great success with what he did, also claimed his courses were very practical and he wasn’t saying anything I really disagreed with.

On the other hand he reminded me of my younger self. The training felt like the kind of training I gave when I was just starting out. Let me give you two examples.

When I started giving Agile training I felt I had to share as much as possible with the attendees. I was conscious that I only had them for a limited time and I had so much to tell them! I was aiming to give them everything they needed to know. I had to brain dump… Nuremberg funnel.

So I talked a lot, sessions were long and although I asked “Any questions?” I didn’t perhaps give people enough time to ask or for me to answer – ‘cos I had more brain dumping to do!

Slowly I learned that the attendees grew tired too. There was a point where I was talking and they had ceased to learn. I also learned that given a choice (“Would you like me to talk about Foobar for 30 minutes or have you had enough?”) people always asked for more.        

Second, when I started out I used to include the Agile Manifesto and a whistle-stop-tour of Lean. After all, people should know where this came from and they should understand some of the theory, right? But with time I realised that the philosophy of the manifesto takes up space and isn’t really important. Similarly, Lean is very abstract and people have few reference points. To many (usually younger) people who have never lived “the waterfall” it can seem a crazy straw-man anyway.

Over the years I’ve tried to make my introductions to Agile more experiential. That is, I want to get people doing exercises and reflecting on what happened. I tend to believe that people learn best from their own experience so I try to give them “process miniatures” in the classroom and then talk (reflect) on the experience.

These days my standard starter 2-day Agile training course is three quarters exercises and debriefs. My 1-day “Requirements, User Stories and Backlogs” workshop is almost entirely exercise based. I’m conscious that there is still more stuff – and that different people learn in different ways – so I try to supplement these courses with further reading – part of the reason behind printing “Little Book of User Stories” is to supplement “Agile Reader” in this.

I’m also conscious that by allowing people to learn in different mediums, and to flip between them they can learn more and better.

My own thinking got a big boost when I learned about Constructivist learning theory. Perhaps more importantly I’ve also benefited from exploring my own dyslexia. (Reading The Dyslexic Advantage earlier this year was great.)

Why is dyslexia relevant here? Well two reasons…

Firstly, something I was told a long time ago proves itself time and time again: Dyslexics have problems learning the way non-dyslexics do, but the reverse is not true. What helps dyslexics learn helps everyone else learn better too.

Second: dyslexics look at the world differently and we have to construct their own meaning and find our own ways to learn. To me, Agile requires a different view of the world and it requires us to learn to learn. Three years back I even speculated that Agile is Dyslexic, as time goes by I’m more convinced of that argument.

So why am I thinking so much about all this?

Well, I’ve shied away from online training for a few years now – how can I do exercises? how can I seed reflection?

Now I’ve accepted a request to do some online training. I can’t use my existing material, it is too exercise based. I’m having to think long and hard about this.

One thought is to view “online training” as something different to “rehearsal training.” That is, something delivered through the online medium might be more akin to an audio book, it is something that supplements a rehearsal. But that thinking might be self limiting and ignore opportunities offered online.

The other thing is the commercial medium. As my training has got more experiential and better at helping people move from classroom to action it has actually covered less. The aim is to seed change, although the classroom is supplemented the actual material covered in class is less; learn less change more! – Thats a big part of the reason I usually give free consulting days after training.

In a commercial setting where there is a synopsis and a price tag the incentive is to list more and more content. One is fearful of missing something the buyer considers important. One can imagine a synopsis being placed next to a competitor synopsis and the one with the most content for the least price is chosen.

So, watch this space, I will be venturing into online training. To start off with I’m not sure who is going to be learning the most: the attendees or the presenter! (O perhaps I shouldn’t have said that, maybe I’m too honest.)

If you have any experience with training (as a teacher or student), and especially online training, I’d love to hear about them. Please comment below or email me.

Read more? Subscribe to my newsletter – free updates on blog post, insights, events and offers.

The post Reflections on learning and training (and dyslexia) appeared first on Allan Kelly Associates.

“Working software over comprehensive documentation.” The Agile Manifesto

Some have taken that line to mean “no documentation.” I have sympathy for that. Years ago I worked on railway privatisation in the UK. We (Sema Group) were building a system for Railtrack – remember them?

We (the programmers) had documentation coming out our ears. Architecture documents, design documents, user guides, functional specifications, program specifications, and much much more. Most of the documentation was worse than useless because it gave the illusion that everything was recorded and anyone could learn (almost) anything any time.

Some of the documentation was just out of date. The worst was written by architects who lived in a parallel universe to the coders. The system described in the official architecture and design documents bore very little relevance to the actual code but since the (five) architects never looked at the code the (12) programmers could do what they liked.

Documentation wasn’t going to save us.

But, I also know some documentation is not only useful but highly valuable. Sometimes a User Manual can be really useful. Sometimes a developers “Rough Guide” can give important insights.

So how do you tell the difference?

How do you know what to write and what to forego?

Rule #1: Documentation is just another deliverable

Time spent writing a document is time not spent coding, testing, analysing or drinking coffee. There is no documentation fairy and documentation is far from free. It costs to write and costs far more to read (if it is ever read).

Therefore treat documentation like any other deliverable.

If someone wants a document let them request it and prioritise it against all the other possible work to be done. If someone is prepared to displace other work for documentation then it is worth doing.

Rule #2: Documentation should add value

Would you add a feature to a system if it did not increase the value of the system?

The same is true of documentation. If it adds value then there is every reason to do it, if it doesn’t then why bother?

Rule #3: Who will complain if the document is not done?

If in doubt identify a person who will complain if the document is not done. That person places a value on the document. Maybe have them argue for their document over new features.

Rule #4: Don’t write documents for the sake of documents

Don’t write documents just because some process standard somewhere says a document needs to be written. Someone should be able to speak to that standard an explain why it adds more value than doing something else.

Rule #5: Essential documents are part of the work to do

There are some documents that are valuable – someone will complain if they are absent! User Manuals are one reoccurring case. I’ve also worked with teams that need to present documentation as part of a regulatory package to Federal Drug Administration (FDA) and such.

If a piece of work requires the documentation to be updated then updating the documentation is part of the work. For example, suppose you are adding a feature to a system that is subject to FDA regulation. And suppose the FDA regulation requires all features to be listed in a User Manual. In that case, part of the work of adding the feature is to update the user manual. There will be coding, testing and documentation. The work is not done if the User Guide has not been updated.

You don’t need a separate User Story to do the documentation. In such cases documentation may form part of the definition of done.

Rule #6: Do slightly less than you think is needed

If you deliver less than is needed then someone will complain and you will need to rework it. If nobody complains then why are you doing it? And what value is it? – Do less next time!

This is an old XP rule which applies elsewhere too.

Rule #7: Don’t expect anyone to read what you have written

Documentation is expensive to read. Most people who started reading this blog post stopped long ago, you are the exception – thank you!

The same is true for documentation.

The longer a document is the less likely it is to be read.
And the longer a document is the less of it will be remembered.

You and I do not have the writing skills of J.K.Rowling, few of us can hold readers attention that long.

Rule #8: The author learns too

For a lot of documentation – and here I include writing, my own books, patterns, blogs, etc. – the real audience is the author. The process of writing helps the author, it helps us structure our thoughts, it helps us vent our anger and frustration, it forces us to rationalise, it prepares us for an argument, and more.

So often the person who really wants the document, the person who attaches value to it, the person who will complain if it is not done, and the person who will learn most from the document is the author.

Join my mailing list to get free updates on blog post, insights, events and offers.

The post Documentation is another deliverable and 7 other rules appeared first on Allan Kelly Associates.