Blog

Continuous Digital & Project Myopia

Reprojects-2017-09-11-10-56.png

This seems a little back to the future… those of you who have been following the evolution of Continuous Digital will know the book grew out of the #NoProjects meme and my extended essay.

I think originally the book title was #NoProjects then was Correcting Project Myopia, then perhaps something else and finally settled down to Continuous Digital. The changing title reflected my own thinking, thinking that continued to evolve.

As that thinking has evolved the original #NoProjects material has felt more and more out of place in Continuous Digital. So I’ve split it out – Project Myopia is back as a stand alone eBook and you can buy it today.

More revisions of Continuous Digital will appear as I refactor the book. Once this settles down I’ll edit through Project Myopia. A little material may move between the two books but hopefully not much.

Now the critics of #NoProjects will love this because they complain that #NoProjects tells you what not to do, not what to do. In a way I agree with them but at the same time the first step to solving a problem is often to admit you have a problem. Project Myopia is a discussion of the problem, it is a critique. Continuous Digital is the solution and more than that.

Splitting the book in two actually helps demonstrate my whole thesis.

For a start it is difficult to know when a work in progress, iterating, self-published, early release book is done. My first books – Business Patterns and Changing Software Development – were with a traditional publisher. They were projects with a start and a finish. Continuous Digital isn’t like that, it grows, it evolves. That is possible because Continuous Digital is itself digital, Business Patterns and Changing Software Development had to stop because they were printed.

Second Continuous Digital is already a big book – much bigger than most LeanPub books – and since I advocate “lots of small” over “few big” it makes sense to have two smaller books rather than one large.

Third, and most significantly, this evolution is a perfect example of one of my key arguments: some types of “problem” are only understood in terms of the solution. Defining the solution is necessary to define the problem.

The solution and problem co-evolve.

In the beginning the thesis was very much based around the problems of the project model, and I still believe the project model has serious problems. In describing a solution – Continuous Digital – a different problem became clear: in a digital age businesses need to evolve with the technology.

Projects have end dates, hopefully your business, your job, doesn’t.

If you like you can buy both books together at a reduced price right now.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Definition of Ready considered harmful

Small-iStock-502805668-2017-09-6-12-58.jpg

Earlier this week I was with a team and discussion turned to “the definition of ready.” This little idea has been growing more and more common in the last couple of years and while I like the concept I don’t recommend it. Indeed I think it could well reduce Agility.

To cut to the chase: “Definition of ready” reduces agility because it breaks up process flow, assumes greater role specific responsibilities, introduces more wait states (delay) and potentially undermines business-value based prioritisation.

The original idea builds on “definition of done”. Both definitions are a semi-formal checklists agreed by the team which are applied to pieces of work (stories, tasks, whatever). Before any piece of work is considered “done” it should satisfy the definition of done. So the team member who has done a piece of work should be able to mentally tick each item on the checklist. Typically a definition of done might contain:

 

  • Story implemented
  • Story satisfies acceptance criteria
  • Story has been seen and approved by the product owner
  • Code is passing all unit and acceptance tests

Note I say “mentally” and I call these lists “semi formal” because if you start having a physical checklist for each item, physically ticking the boxes, perhaps actually signing them, and presumably filing the lists or having someone audit them then the process is going to get very expensive quickly.

So far so good? – Now why don’t I like definition of ready?

On the one hand definition of ready is a good idea: before work begins on any story some pre-work has been done on the story to ensure it is “ready for development” – yes, typically this is about getting stories ready for coding. Such a check-list might say:

 

  • Story is written in User Story format with a named role
  • Acceptance criteria have been agreed with product owner
  • Developer, Tester and Product owner have agreed story meaning

Now on the other hand… even doing these means some work has been done. Once upon a time the story was not ready, someone, or some people have worked on the story to make it ready. When did this happen? Getting this story ready has already detracted from doing other work – work which was a higher priority because it was scheduled earlier.

Again, when did this happen?

If the story became “ready” yesterday then no big deal. The chances are that little has changed.

But if it became ready last week are you sure?

And what if it became ready last month? Or six months ago?

The longer it has been ready the greater the chance that something has changed. If we don’t check and re-validate the “ready” state then there is a risk something will have changed and be done wrong. If we do validate then we may well be repeating work which has already been done.

In general, the later the story becomes “ready” the better. Not only does it reduce the chance that something will change between becoming “ready” and work starting but it also minimises the chance that the story won’t be scheduled at all and all the pre-work was wasted.

More problematic still: what happens when the business priority is for a story that is not ready?

Customer: Well Dev team story X is the highest priority for the next sprint
Scrum Master: Sorry customer, Story X does not meet the definition of ready. Please choose another story.
Customer: But all the other stories are worth less than X so I’d really like X done!

The team could continue to refuse X – and sound like an old style trade unionist in the process – or they could accept X , make it ready and do it.

Herein lies my rule of thumb:

 

If a story is prioritised and scheduled for work but is not considered “ready” then the first task is to make it ready.

Indeed this can be generalised:

 

Once a story is prioritised and work starts then whatever needs doing gets done.

This simplifies the work of those making the priority calls. They now just look at the priority (i.e. business value) or work items. They don’t need to consider whether something is ready or not.

It also eliminates the problem of: when.

Teams which practise “definition of ready” usually expect their product owner to make stories ready before the iteration planning meeting, and that creates the problems above. Moving “make ready” inside the iteration, perhaps as a “3 Amigos” sessions after the planning meeting, eliminates this problem.

And before anyone complains saying “How can I estimate something thing that is not prepared?” let me point out you can. You are just estimating something different:

 

  • When you estimate “ready” stories you are estimating the time it takes to move a well formed story from analysis-complete to coding-complete
  • When up estimate an “unready” story you are estimating the time it takes to move a poorly formed story from its current state to coding-complete

I would expect the estimates to be bigger – because there is more work – and I would expect the estimates to be subject to more variability – because the initial state of the story is more variable. But is still quite doable, it is an estimate, not a promise.

I can see why teams adopt definition of ready and I might even recommend it myself but I’d hope it was an temporary measure on the way to something better.

In teams with broken, role based process flows then a definition of done for each stage can make sense. The definition of done at the end of one activity is the definition of ready for the next. For teams adopting Kanban style processes I would recommend this approach as part of process/board set-up. But I also hope that over time the board columns can be collapsed down and definitions dropped.

Read more? Join my mailing list – free updates on blog post, insights, events and offers.

Documentation is another deliverable and 7 other rules

8295173-2017-08-30-13-43.jpg

“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.

Principles of software development revisited

BeachSpainLite-2017-08-15-10-04.jpg

Summer… my traditional time for doing all that stuff that requires a chunk of time… erh… OK, “projects” – only they aren’t well planned and they only resemble projects in the rear-view mirror.

Why now? Why summer? – Because my clients are on holiday too so I’m quiet and not delivering much in the way of (agile) training or consulting. Because my family is away visiting more family. Thus I have a chunk of time.

This year’s projects include some programming – fixing up my own Twitter/LinkedIn/Facebook scheduler “CloudPoster” and some work on my Mimas conference review system in preparation for Agile on the Beach 2018 speaker submissions.

But the big project is a website rebuild.

You may have noticed this blog has moved from Blogger to a new WordPress site, and attentive readers will have noticed that my other sites, allankelly.net and SoftwareStrategy.co.uk have also folded in here. This has involved a lot of content moving, which also means I’ve been seeing articles I’d forgotten about.

In particular there is a group of “The Nature of Agile” articles from 2013 which were once intended to go into a book. Looking at them now I think they still stand, mostly. In particular I’m impressed by my 2013 Principles of Software Development.

I’ll let you can read the whole article but here are the headlines:

Software Development Principles

  1. Software Development exhibits Diseconomies of Scale
  2. Quality is essential – quality makes all things possible
  3. Software Development is not a production line

Agile Software Principles

  1. Highly adaptable over highly adapted
  2. Piecemeal Growth – Start small, get something that works, grow
  3. Need to think
  4. Need to unlearn
  5. Feedback: getting and using
  6. People closest to the work make decisions
  7. Know your schedule, fit work to the schedule not schedule to work
  8. Some Agile practices will fix you, others will help you see and help you fix yourself

The article then goes on to discuss The Iron Triangle and Conway’s Law.

I think that essay might be the first time I wrote about diseconomies of scale. Something else I learned when I moved all my content to this new site is that the Diseconomies of Scale blog entry is by far my most read blog entry ever.

I’m not sure if I’m surprised or shocked that now, four years later, these still look good to me. I really wouldn’t change them much. In fact these ideas are all part of my latest book Continuous Digital.

I’m even starting to wonder if I should role those Nature of Agile essays together in another book – but thats bad of me! Too many books….

Join Allan Kelly’s mailing list to get free updates on blog post, insights and events.

What if it is all random?

iStock-512907832Small-2017-08-10-12-37.jpg

What if success in digital business, and in software development, is random? What if one cannot tell in advance what will succeed and what will fail?

My cynical side sometimes thinks everything is random. I don’t want to believe my cynical side but…

All those minimally viable products, some work, some fail.

All those stand-up meetings, do they really make a difference?

All those big requirements documents, just sometimes they work.

How can I even say this? – I’ve written books on how to “do it right.”
I advise companies on how to improve “processes.” I’ve helped individuals do better work.

And just last month I was at a patterns conference trying to spot reoccurring patterns and why they are patterns.

So let me pause my rational side and indulge my cynical side, what if it is all random?

If it is all random what we have to ask is: What would we do in a random world?

Imagine for a moment success is like making a bet at roulette and spinning the wheel.

Surely we would want to both minimise losses (small bets) and maximise wheel spins: try lots, remove the failures quickly and expand the successes (if we can).

I suggested “its all random” to someone the other day and he replied “It is not random, its complex.” And we were into Cynefin before you could say “spin the wheel.”

Dave Snowden’s Cynefin model attempts to help us understand complexity and the complex. Faced with complexity Cynefin says we should probe. That is, try lots of experiments so we can understand, learn from the experiments and adjust.

If the experiment “succeeds” we understand more and can grow that learning. Where the experiment “fails” we have still learned but we will try a different avenue next time.

Look! – it is the same approach, the same result, complexity, Cynefin or just random: try a lot, remove failure and build on success. And hang on, where have I heard that before, … Darwin and evolution; random gene mutations which give benefit get propagated and in time others die out.

It is just possible that Dave is right, Darwin is right and I am right…

Today most of the world’s mobile/cell telephone systems are built on CDMA technology. CDMA is super complex maths but it basically works by encoding a signal (sequence of numbers, your voice digitised) and injecting it into a random number stream (radio spectrum), provided you know the encoding you can retrieve the signal out of the randomness. Quite amazing really.

Further, provided the number sequences are sufficiently different they are in effect random so you can inject more signal into the same space.

That is why we can all use our mobile phones at the same time.

Put it another way: you walk into a party in London, in the room are Poles, Lebanese, Germans, Argentinians and the odd Brit. They are all talking in their own language to fellow speakers. Somehow you can hear your own language and join the right conversation. Everything else is random background noise.

Maybe the same is true in digital business and software development…

Perhaps it is all complex but it is so complex that we will never be able to follow all the cause and effect chains, it is so complex that it looks random. Dave is right with Cynefin but maybe there is so much complexity that we might as well treat it as random and save our time.

Back to CDMA and London parties, faced with apparent randomness there are useful strategies and signals can still be extracted.

Perhaps the way to deal with this complexity is not to try and understand it but to treat it as random. Rather than expend energy and time on a (possibly) impossible task accept it as random and apply appropriate strategies.

After all, if we have learned anything from statistical distributions it is that faced with actual and apparent randomness we can still find patterns, we can still learn and we can still work with, well, randomness.

Blogger, Blog move & Comments

Frank_Sinatra_Hollywood_star-2017-08-7-15-15.jpg

“And now, the end is near
And so I face the final curtain
My friend, I’ll say it clear
I’ll state my case, of which I’m certain”
My Way, Paul Anka/Frank Sinantra
(public domain picture from WikiCommons)

Don’t panic!

I’m not going away, this blog is not finishing.

But it is changing. And with the change there will be some loss.

Blog entry 1 appeared in April 2005, and after 12 years on Blogger this blog is moving and that move has a downside.

I’ve always been happy on Blogger but in the last few years I’ve been operating three website: the blog on Blogger, allankelly.net – a static site written in RapidWeaver and my commercial site, Software Strategy (www.softwarestrategy.co.uk).

This means my efforts have been split between three sites, and Google has seen me as three sites. Given that my web presence is part of marketing my training and consultancy that might not have been the smartest move.

So last month I decided to merge the three sites and adopt a new corporate identity. Most of the move has been done, Software Strategy is now doing to allankellyassociates.co.uk, the blog is mostly moved – thanks to the great work of the folks at CMS2CMS, highly recommended – and here in lies the problem….

CMS2CMS have done a great job of moving the blog posts, images and comments. But they can’t move all the comments. That is because around October 2014 I switch the comments from Blogger to Google+. The comments on Blogger, before October 2014, can, and have, been moved across, but the comments on Google+ can’t – so all comments left since October 2014 are lost. I regret the decisions to switch to Google+ comments massively.

So many of the comments over the few years (I’m not sure exactly how many!) are about to be lost when the Blogger blog is set to redirect to allankellyassociates.co.uk.

In order that the comments are not lost entirely here are some of my “greatest hits” as PDF files with comments and the view count according to Blogger:

I could go on, I’m sorry I can’t save more comments, it is sad looking now at all the comments, far more than I thought there were. I’m also amazon by how the blog has grown, from early posts with, maybe, a hundred views to a regular audience of thousands and sometimes tens of thousands.

And I completely blame Google and G+ for this, on Blogger Google are quite supportive of blog exports but there is nothing equivalent on Google+.

O, the third site, allankelly.net, this is mostly an archive of my writing down the years and it too will disappear inside www.allankellyassociates.co.uk in the very near future – most of the content is already moved.

Programmer’s Rorschach test

The picture above, I recently added this picture to Continuous Digital for a discussion of teams. When you look at it what do you see:

An old style structure chart, or an organization chart?

It could be either and anyone who knows of Conway’s Law shouldn’t be surprised.

When I was taught Modula-2 at college these sort of structure charts were considered superior to the older flow charts. This is functional decomposition, take a problem, break it down to smaller parts and implement them.

And that is the same idea behind traditional hierarchical organizational structure. An executive heads a division, he has a number of managers under him who manage work, each one of these manage several people who actually do the work (or perhaps manage more manager who manage the people who do the work!)

Most organizations are still set up this way. It is probably unsurprising that 50 years ago computer programmers copied this model when designing their systems – Conway’s Law, the system is a copy of the organization.

Fast forward to today, we use object oriented languages and design but most of our organizations are still constrained by hierarchical structure, that creates a conflict. The company is structurally decomposed but our code is object oriented.

The result is conflict and in many cases the organization wins – who hasn’t seen an object oriented system that is designed in layers?

While the conflict exists both system and organization under perform because time and energy are spent living the conflict, managing the conflict, overcoming the conflict.

What would the object-oriented company look like?

If we accept that object oriented design and programming are superior to procedural programming (and in general I do although I miss Modula-2) then it becomes necessary to change the organization to match the software design – reverse Conway’s Law or Yawnoc. That means we need teams which look and behave like objects:

  • Teams are highly cohesive (staffed with various skills) and lightly coupled (dependencies are minimised and the team take responsibility)
  • Teams are responsible for a discrete part of the system end-to-end
  • Teams add value in their own right
  • Teams are free to vary organizational implementation behind well defined interface
  • Teams are tested, debugged and maintained: they have been through the storming phase, are now performing and are kept together

There are probably some more attributes I could add here, please make your own suggestions in the comments below.

To regular readers this should all sound familiar, I’ve been exposing these ideas for a while, they draw on software design and Amoeba management, I discuss them at greater length Xanpan, The Xanpan Appendix and now Continuous Digital – actually, Continuous Digital directly updates some chapters from the Appendix.

And like so many programmers have found over the years, classes which are named “Manager” are more than likely poorly named and poorly designed. Manager is a catch all name, the class might well be doing something very useful but it can be named better. If it isn’t doing anything useful, then maybe it should be refactored into something that is. Most likely the ManagerClass is doing a lot of useful stuff but it is far from clear that it all belongs together. (See the management mini-series.)

Sometimes managers or manager classes  make sense, however both deserve closer examination. Are they vestige from the hierarchal world? Do they perform specialist functions which could be packaged and named better? Perhaps they are necessary, perhaps they are necessary for smoothing the conflict between the hierarchal organization and object oriented world.

Transaction costs can explain both managers and manager classes. There are various tasks which require knowledge of other tasks, or access to the same data. It is cheaper, and perhaps simpler, to put these diverse things together rather than pay the cost of spreading access out.

Of course if you accept the symbiosis of organization and code design then one should ask: what should the organization look like when the code is functional? What does the Lisp, Clojure or F# organization look like?

And, for that matter, what does the organization look like when you program in Prolog? What does a declarative organization look like?

Finally, I was about to ask about SQL, what does the relational organization look like, but I think you’ve already guessed the answer to this one: a matrix, probably a dysfunctional matrix.

Exciting: Something different for those Leading & Managing Agile

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month – Anniversary Edition (1995a, p.276)

This is one of my favourite quotes about software development.

Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:

  • Management is still needed in most software teams
  • Even if you don’t have dedicated managers there is still management work to do; and without dedicated management that management work gets spread around so in a self-organizing team more people need to do management work

I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.

So now I’m going to do something about it.

Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.

Why don’t people take the time to learn management skills the way they do technical skills?

A few days in the classroom learning about Java is great, why not spend a little time learning about management?

Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.

Now I’m partnering up with Learning Connexions to offer just this course – I’m more excited about this than anything I have been in a while!

It’s going to run this autumn, September to December, half a day every two weeks.

In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone – me included! – to learn from one another.

Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.

Here are the hypothesis I’m testing:

  • Software development can be improved if software management can be improved: current software managers, aspiring software managers and software engineers will all do a better job if they take time to pro-actively learn about key issues in the software industry.
  • People will learn more and deeper if it is organised as a little and often.
  • Encouraging self reflection and group discussion about topics and real life problems will enhance learning.

The hypothesis you would be testing by coming along are:

  • I will learn more by discussing key topics with a cross section of my peers
  • An investment of six-half says and a little less than £1000 will pay back in increased effectiveness, productivity, organization, focus….

More information on the workshops on the training pages. (Yes, this is the new website.)

I hope, I very much hope we can make this work…. – please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback – comment here or mail me direct, allan@allankelly.net.

And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!

Exciting: Something different for those Leading & Managing Agile

HeadacheiStock_000014496990SmallLeft-2017-07-20-10-29.jpg

“Some readers have found it curious that The Mythical Man Month devotes most of the essays to the managerial aspects of software engineering, rather than the many technical issues. This bias … sprang from [my] conviction that the quality of the people on a project, and their organization and management, are much more important factors in the success than are the tools they use or the technical approaches they take.” Frederick P. Brooks, The Mythical Man Month – Anniversary Edition (1995a, p.276)

This is one of my favourite quotes about software development.

Those of you who followed my management mini-series last year might remember some of my conclusions, specifically:

  • Management is still needed in most software teams
  • Even if you don’t have dedicated managers there is still management work to do; and without dedicated management that management work gets spread around so in a self-organizing team more people need to do management work

I can’t remember if I said it in that series or in another post: the quality of management in software development is often poor.

So now I’m going to do something about it.

Part of the problem is that very very few software engineers ever take time to learn about management. Sure they learn about Java, BDD, AWS, CSS etc. etc. but most people learn “managing” by watching the people who had the job before them. Unfortunately that tends to propagate poor management.

Why don’t people take the time to learn management skills the way they do technical skills?

A few days in the classroom learning about Java is great, why not spend a little time learning about management?

Now most readers probably know that I provide training, usually agile training to teams, but I have long felt that simply offering a two day training course for current and future managers wouldn’t be enough. I’ve long dreamt of offering a course that ran over a series of weeks, that allowed people to mix classroom learning and discussion of topics with hands on practice and, perhaps more importantly, reflection and group discussion.

Now I’m partnering up with Learning Connexions to offer just this course – I’m more excited about this than anything I have been in a while!

It’s going to run this autumn, September to December, half a day every two weeks.

In each session I’ll present some material but more importantly we’ll have discussions between people doing work. We’ll try and apply the material to real work. I expect group discussions will go beyond the stated subjects and allow everyone – me included! – to learn from one another.

Not only is this a new course it is a new way of approaching learning in work. Since it is new the course we are going to keep the price down. We’re running it on Friday afternoons so hopefully it won’t interfere with the usual work week too much.

Here are the hypothesis I’m testing:

  • Software development can be improved if software management can be improved: current software managers, aspiring software managers and software engineers will all do a better job if they take time to pro-actively learn about key issues in the software industry.
  • People will learn more and deeper if it is organised as a little and often.
  • Encouraging self reflection and group discussion about topics and real life problems will enhance learning.

The hypothesis you would be testing by coming along are:

  • I will learn more by discussing key topics with a cross section of my peers
  • An investment of six-half says and a little less than £1000 will pay back in increased effectiveness, productivity, organization, focus….

I hope, I very much hope we can make this work…. – please get over to Learning Connexions and book Leading & Managing Agile today. Even if you cannot attend I’d love to know your thoughts on this, please give me feedback – comment here or mail me direct, allan@allankelly.net.

And apologies, I’m going to be talking more about this in the next few weeks as I put material together and get more and more excited!

A new blog home

After over 10 years blogging on Blogger I’m moving.

Actually, for the last 10 years I’ve been running three websites. The blog, AllanKelly.net and my company, commercial, site, SoftwareStrategy.co.uk. This kind of made sense once upon a time but it has increasingly meant that all three sites were a little neglected.

My plan is to merge all three sites into this one eventually. Hopefully that will also benefit my Google rankings but, it also means I need to keep all those inbound links!

This is going to be a gradual process…