Posted on

Quick agile diagnostic

Allan Kelly Associates from Allan Kelly Associates

Tactics

My online agile diagnostic will quickly captures the most pertinent facts about your agile team. I can then do an brief review of actions which can help the team meet your aims and objectives.

The quickest way to explain the agile diagnostic is to take it. At the end you can schedule a conversations with me – no fee, no obligation. (If you are really short of time just schedule the conversation!)

10 minutes online agile diagnostic

The post Quick agile diagnostic appeared first on Allan Kelly Associates.

Posted on

Purpose over Backlog

Allan Kelly from Allan Kelly Associates

Backlogs are a good idea. Backlogs ease the transition from the old “requirements up front” world to the new more dynamic agile world. Backlogs provide a compatibility layer for agile teams to interface to more traditional project management and governance. Backlogs even allow you to take a stab at done date!

Backlogs allow you to even out work between the quiet periods and the busy times. Backlogs give you a place to store good ideas which you can’t do just now. And because stakeholders can see their request is not forgotten they don’t need to shout for it today.

Listen to Allan Kelly reading Purpose over Backlog

Yes backlogs are good. I’ve seen them work well myself and I’ve taught many teams to effectively use backlogs.

But – you knew there was a but coming didn’t you? – but…

Backlogs have problems, too many teams are labouring under the Tyranny of the Backlog, they have become backlog-slaves and practice something we might call BLDD – Back Log Driven Development.

(To be clear, when I say “backlog” I am primarily thinking of the product backlog – the long list of all the things the team (might) do in the future. This is different to the sprint backlog (iteration backlog). The sprint backlog is a shorter list of things the team aims to do this iteration. I am using Scrum terminology but the ideas are pretty much “generic agile” and I’m thinking more broadly than Scrum. Many implementations of Kanban feature a product backlog of sorts so while Kanban is less prone to these problem it is not immune.)

1) Lump of Work Fallacy

There is usually an assumption that the backlog represents all the work to be done – an impression reinforced by early implementations of Scrum. In the short term that leads to agile teams being seen as inflexible and prioritising process over need because new work is not allowed in.

In some cases teams even struggle to get started on work because a big-up-front requirements gathering and analysts activity is required to create a backlog. In the worst cases that work is even estimated and end-dates forecast before a line of code is cut or developers hired.

In the longer term it is simply unrealistic to assume the backlog is fixed. Even with more and better analysis it is impossible to foreseen future requests. The agile adage “it is in doing the work that we understand the work” cuts both ways: coders understand what they need to build and customers/stakeholders/analysts understand what they want.

Work will arrive after you begin, any system that does not incorporate that truth will fail one-way or another.

2) Bigger then you think

Not only does the backlog grow with completely new work the work in it changes – and grows. There are many reasons this happens: new opportunities appear, hidden ones become clear, requests require more work than expected and so on.

Humans are very bad at estimating, especially about the future, and, it turns out, they are also very bad at estimating time spent in the past. If you want accurate forecasts you need to invest in them, you need to make structural changes and you need to use statistics.

However, because of the lump of work fallacy and the belief that humans can make estimates, poor end-date projections get made and when they are missed (because they were wrong to start with) everyone gets upset.

3) Fallacy of Done

Backlogs come with burn-down charts and an assumption that there is an end; and that end is when everything is “done.” The team will be done when the backlog is empty. That assumption is baked into BLDD, traditional project management and even governance.

I have long argued that software is never done. I’ll accept that I might be wrong, but in the digital age, when business runs on digital technology (i.e. software) your products are only done when you business is done. The technology is the business, and the business is the technology. Stop the backlog growing, stop growing you technology and you kill the business.

4) Backlog Bottomless pit

Put all those reasons together and the backlog becomes a bottomless pit. In the early days of agile, when I managed teams myself, the backlog would often sit on my desk, written out on index cards and held together with rubber bands. I could get a sense of how big the backlog was my looking.

Today everyone uses electronic tracking systems. Not only do these allow an infinite number of items they rob us of perspective. To paraphrase Comrade Stalin: “2 outstanding backlog items is tragedy, 200 is a statistic.”

5) Backlogs obscure strategy & purpose

With so many backlog items it is easy to get lost – you can’t see the wood for the trees. Arguments over what will be done next start to resemble deciding who should get a lifeboat place on a sinking ship, add in the demands “when will you be done?” (plus explaining why the date has changed) and “the bigger picture” gets lost.

In Back Log Driven Development the sense of purpose and strategic goals is lost as teams struggle with the day-to-day demands of just doing stuff.

6) Powerless product owner (i.e. backlog administrators)

Tyranny of the backlog seems worst were product owners lack real authority and skills. They are little more than backlog administrators. They spend most of the week adding requests to the backlog, then passing a few chosen items to developers in planning meetings. A vicious circle develops, the product owner can’t win so people trust them less, their authority wanes, and the backlog spirals.

Few organisations give product owners the power needed to get a grip on this situation. Indeed, many product owners are plucked from the ranks for development or support and given a battlefield promotion to product owner but lack the skills required. (See The problem with Product Owners.)

A solution?

For years I’ve been suggesting teams throw away the backlog – you will not forget the important things. But then how do you know what to do?

Take a step back, start with your purpose, your mission, the reason you team, your company, your organisation exists. What should you be doing? How can you fulfil that purpose and sever your customers?

This is where I see a role for OKRs and jobs to be done. Both these techniques – together, or separately – can be used as story generators. Every time you need to more work, more stories, you return to your OKRs and ask “what can we do now to move us towards our objective?”

When writing Succeeding with OKRs in Agile I became more and more convinced this is the path to take. Increasingly I sum this up as Purpose over Backlog.

Step 1: Clarify your purpose – what is your overarching reason for existing?
Step 2: Clarify how your existing strategy builds towards that purpose, and if you don’t have a strategy create one.

Repeat steps 1 & 2 annually.

Step 3: Think broadly, set your OKRs as a team so you build towards your purpose by following your strategy.
Step 4: Spend the next 12 weeks executing against those OKRs

Repeat steps 3 & 4 every 3 months.

Step 5: In each planning meeting take stock of what you have done and progress against OKRs
Step 6: Ask “what do we need to do next to move towards the OKRs?”

Succeeding with OKRs in Agile

Repeat steps 5 and 6 every 2 weeks

And if you are Kanban’ing then keep steps 1, 2, 3 and 4, adjust 5 and 6 as appropriate.

Having finished, completed, published Succeeding with OKRs I really wish I had been clearer in the book. The ideas are there but with time they have become so much clearer… maybe I need another book.

Buy Succeeding with OKRs in Agile at Amazon today.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Purpose over Backlog appeared first on Allan Kelly Associates.

Posted on

Best seller – Succeeding with OKRs in Agile

AllanAdmin from Allan Kelly Associates

I’m delighted that my new book Succeeding with OKRs in Agile went on sale at Amazon yesterday. By this morning it was the number #1 best seller in Amazon’s IT Project Management category – and not doing badly in Computer Programming and Business Management & Leadership either. (Although the publisher has some power over which categories a book is in it is still a black-art.)

It is hard to express just how great it is to see the book in the number #1 slot. While I hope it stays at #1 for a while I expect it will drop down before long.

Print and audio versions of the book are in the works and should be released in the next few weeks so if you would rather read a physical version or listen, watch this space as they say.

The book has taken a little under a year to write and a few more months to make production ready. The wonders of LeanPub mean many readers have already been enjoying early versions of the book. If you would like to read the book on iBooks or as a PDF then LeanPub is the place to buy from.

I recorded the little video below to explain why I wrote the book.

The post Best seller – Succeeding with OKRs in Agile appeared first on Allan Kelly Associates.

Posted on

Technical Debt: Engineers, you are not alone

Allan Kelly from Allan Kelly Associates

Listen to Allan read this blog

I don’t read many books about software or technology these days, I tend to read outside the domain: economics, business and management – which after all is much of what I do in the technology world these days.

Recently I’ve been reading Winning now, winning later by David Cote and find really interesting. He hardly mentions software and never mentions agile but he is giving me a new perspective on technical issues, particularly technical debt (or technical liabilities as I prefer to call them). He talks about issues which have similar characteristics to tech debt but are completely different, legal issues for example. He sees these issues as conflicts between short-term thinking and long-term thinking.

Cote’s argument is that short term actions should support, not conflict, with long term goals. I agree. It might not be easy but if actions in the hear-and-now conflict with longer term goals then the chances of reaching those goals is diminished.

Cote is writing about his time as CEO of Honeywell – a US industrial conglomerate if you don’t know. Unusually Cote is honest about many of the dirty problems the company faced when he took over – a lot of business books glossy over such problems or talk about “challenges” or “opportunities”.

For example, Cote describes how Honeywell managers were chasing numbers and targets every quarter. They had no time for long term improvements because they were so busy “making the numbers”. One of his managers cut down a forest to sell as timber in order to make the end of quarter numbers. Sales people would give products away to new customers or offer large discounts at the end of the quarter. However customers knew this would happen so delayed orders until they were sweetened.

Making the short term numbers meant the company undercut itself so lost revenue next quarter. Management time was spent finding accounting tricks to “make the numbers” rather than improving the business. And since targets ratcheted up the next quarter was more difficult and required more diversions.

Other examples included legal cases Honeywell was fighting: spending time and money on lawyers, building up bad will with customers, politicians and local people. This in turn made it more difficult to get support when the company needed it.

I read these examples, and others, and I hear an engineer saying “Technical debt.” That is exactly what it is.

A software engineer who does a dirty job on a code change because they feel under pressure stores up problems for themselves and future engineers who need to do the next change. Which is exactly the same as a factory which dumps waste into a lake as a quick fix and then needs to clean up the late later.

Actually economists have a term for this: externalities. These are the costs which are forced onto other payer, e.g. the factory saves money on waste disposal but the local government has to pay to clean the lake. I’ve long thought a lot of “technical debt” could be considered an externality because it pushed the cost onto someone else.

Today it is probably harder than ever to escape these cost – in code, in law, in financing – because there are more and more people out there looking for these things. Environmentalists look at waste in lakes, society expects companies to pay if they pollute and courts make companies pay. Smart investors will look closely at a firms accounts and discount the firm, or short them, if they see dubious practices.

This is Cote’s argument: in the short term it might save or generate money to fight legal cases (deny deny deny), sell off forests, discount sales and such, but, in the longer term – and the longer term might just be weeks – it will costs. And when it costs it will damage growth.

Doesn’t that sound just like technical debt/liabilities?

Naturally it is hard to see a company that chases numbers, pollutes and fights all legal claims caring about the quality of code. Engineers will have a hard job fighting for technical excellence there.

Cote argues, and I agree with him, that it doesn’t have to be this way. Acting responsibly and thinking about tomorrow – whether that is pollution, sales, accounting, code quality – will make it easier to grow later. Just because it is difficult to act in a manor that meets todays needs and make the world better for tomorrow does not allow use to ignore it: all of us need to think harder and find a solution that doesn’t mortgage tomorrow.

And sometimes the right answer is to accept the slow path, take it on the chin, pay the cost you’ve been avoiding. For Cote that mean settling legal cases and accepting some costs, for software teams that means doing the refactoring, rewriting a module or just saying No to more changes.

As I’ve said before: in software the long term comes along very soon.

As as I’ve blogged before there is no such thing as quick and dirty, only dirty and slow.

We might talk about debt/liabilities but really we are talking short-term v. long-term, a pay-day loan v. investment. Engineers have an unfortunate habit of talking about technical debt as a binary good v. evil debate with no other options.

Finding these less obvious paths which satisfy the short-term and long term is hard(er) but also offers the opportunity for higher, and longer, term improvement, something which is itself a competitive advantage.

Subscribe to this blog by e-mail and download Project Myopia ebook for Free

The post Technical Debt: Engineers, you are not alone appeared first on Allan Kelly Associates.

Posted on

New podcasts and video

AllanAdmin from Allan Kelly Associates

Before Christmas I recorded a couple of new podcasts which went live this week. The first was with Luke Szymer for his Align Remotely podcast series and focused on the topic of my new book, Succeeding with OKRs in Agile and is release in two parts. Luke also has a new book, it is timely and well worth reading – as is anything Luke writes – also called Align Remotely.

The second podcast was with Ian Gill of Agility by Nature. This was a casual, wide ranging, conversation.

Finally, the video above: Living Continously with Agile and Digital.

From time to time I also give private presentations to companies. Sometimes there are existing conference or user group presentations, sometimes this is new material. While companies generally pay me for these presentations I always feel the need to share further. So, after removing any client specific references I’m re-recording these and posting them on YouTube in a Private Presentations playlist.

Subscribe to my blog newsletter and download Project Myopia for Free

The post New podcasts and video appeared first on Allan Kelly Associates.

Posted on

Words I avoid using: should, empower, commitement

AllanAdmin from Allan Kelly Associates

For the record there are a few words I avoid using if I can.

Should: “we should feed the starving millions”, “we should create world peace.”

Should is useless.
It is also a declaration of what should be but also an admission of defeat, we give up immediately, we don’t even try.

Empower and empowerment: “I will empower the team”

It was Henry Mintzberg who alerted me to the problems with this word: empowerment is a loan. Empowerment is not real power, not real authority.

That I empower you means “I have the power, I am going to lend it to you… but I am still responsible and if you screw up I’m taking right back.” Thats why I prefer to talk about devolving, distributing and even sharing authority.

Commitment: “The Scrum team committed to delivering 20 points”.

Actually my dislike of commitment is usually confined to software teams and older implementations of Scrum specifically.

First commitment tends to be one sided: the development team are expected to commit but not their customers. And in an environment were the team is not completely independent (i.e. there are times when it needs non-team members to do something) it is unfair to ask them to commit.

This is very true in large companies where teams are often restricted by a multitude of rules, demarcation lines and restrictions. Such teams don’t have the power to commit on their own, they need others – and superiors – to join in making thing happen.

Second, because of those problems the word “commitment” itself has changed meaning. Originally when a team said “We commit” it meant “We are going to make this happen, come hell or high water, we will do everything in our power to make this happen.” Over time, because the team couldn’t move heaven and earth due to company policy, commitment has become devalued. Today, “commitment” has come to mean “This is the work we plan to do this sprint and we will try out best (but don’t get your hopes up too high).”

I’m sure there are some more words I avoid using but less often, I’ll make a note of them next time I’m temped and report back.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Words I avoid using: should, empower, commitement appeared first on Allan Kelly Associates.

Posted on

Warning signs of a failing outsourcer

Allan Kelly from Allan Kelly Associates

It is 2021 and unfortunately on Friday I felt the need to repost “Dear Customer, The Truth about IT“. Little has changed in the 10 years since I wrote the original – if I was writing it today probably the only thing I would change is “IT”, I’d write “Digital” (I should probably also change Manchester United but …).

Unfortunately the vast majority of supplier’s are engaged on the basis of their marketing materials, sales pitch and promises. This tells you nothing about their actual ability to deliver working software. The suppliers can all hire great marketing people and use the same words. They can hire and incentivise the best sales people, and they can all take you out for a good meal, a round of golf or to a strip-club. (O, and they can all find a few “satisfied customers” to provide a testimony.)

The only real way to know if a supplier can deliver is to see them in action. So how can you tell things might be going wrong? What are the warning signs?

With help from Mike Burrows and John Clapham I’ve came up with this list of early warning signs. We were thinking in the context of a client-supplier (outsourced) relationship but many of them apply if you are working with internal teams too.

Staffing

1) Supplier loads teams up with extra managers: test managers a speciality
1.1) Team members don’t make decisions and defer problems to managers: there is a manager for every problem
1.2) Offshore teams have parallel management hierarchies
1.3) Suppliers feel the need to mark all your managers with their own manager (who is then duplicated offshore)

2) Inverted staffing pyramids (few devs at the bottom, lots of managers, BAs & other non-coders above)

3) People get swapped by suppliers with little notice
3.1) Short term substitutions are made: I once saw a supplier bring in a temporary SAP HR consultant to cover the usual consultant’s 2-week holiday. There was no way the substitute could come up to speed in that time let alone contribute positively.
3.2) People bait & switch: the people you meet first met didn’t last long, they were substituted for inexperienced people
3.3) “I can do that” – you get people new to their role, you get who they have available, people with experience in one role fill another role; a project manager plays coach, a delivery manager plays scrum master

4) Part time assignees (particularly managers): work a few hours a week on the project, see 1.1.

Get ready

5) Long running “set up” phases
5.1) You spend longer pondering the future than the time it takes to create the future
5.2) A lot of time is spent agonising about infrastructure changes rather than just doing them
5.3) Team advocates for, and does, investment in infrastructure and “reusable code” before anything is usable is actually delivered

Reporting not delivering

6) Supplier does not deliver working software

7) Supplier does not deliver working software every two weeks

In 2021 delivering working software to production every two weeks, or at least usable, potentially releasable software, is table stakes. The best teams deliver multiple times a day. If the supplier can’t deliver something by the end of week 4 you have a second rate supplier. Get out now.

8) Reporting hours done rather than demonstrating working software and stories

9) “Watermelon report” Green on the outside when everything inside is Red; impressive looking reports which don’t distract from the fact that nothing, or very little, was actually complete
9.1) Claiming stuff is done when it hasn’t finished testing
9.2) A Definition of Done which leaves work not-done – Mike has a good post at agendashift.com/done.

Other warning signs

10) You invest as much time in their org design as your own, if this starts to include people performance monitoring and management what are you gaining over using your own people?

11) Suppliers always say yes: no push back and no negotiation, feedback and scrutiny of your requests are signs they are paying attention to your needs. It you ask for the impossible it is better the supplier tells you so than accepts what you ask for. Ideally you want a supplier who can highlight the difficulties with your suggestion and work with you to achieve something akin to what you want even if you have to rethink your request.

12) Your own people are disenfranchised/disgruntled/frustrated by the arrangement. Particularly noticeable where people are expected to work in a different time zone to suit the other partly and when outsourcer staff are elevated (faster, smarter, etc) over the existing people.

In most of these cases the supplier is working around their own constraints rather than putting your needs first.

Subscribe to my blog newsletter and download Project Myopia for Free

The post Warning signs of a failing outsourcer appeared first on Allan Kelly Associates.

Posted on

Dear customer, the truth about IT

Allan Kelly from Allan Kelly Associates

10 years on I feel the need to repost this classic letter from the IT industry to our clients.

Audio version, read by Allan Kelly.

Dear customer,

I think it’s time we in the IT industry came clean about how we charge you, why our bills are sometimes a bit higher than you might expect, and why so many IT projects result in disappointment. The truth is that when we start an IT project, we don’t know how much time and effort it will take to complete. Consequently, we don’t know how much it will cost. This may not be a message you want to hear, particularly since you are absolutely certain you know what you want.

Herein lies another truth, which I’ll try to put as politely as I can. You are, after all, a customer, and, really, I shouldn’t offend you. You know the saying “The customer is always right”? The thing is, you don’t know what you want. You may know in general terms, but the devil is in the detail – and the more detail you try to give us beforehand, the more likely your desires are to change. Each time you give us more detail, you are offering more hostages to fortune.

Software engineering expert Capers Jones believes the things you want (‘requirements’, as we like to call them) change 2% per month on average – thats close to 27% over a year once you compound changes. Personally, I’m surprised that number is so low.

Just to complicate matters, the world is uncertain. Things change, and companies go out of business. Remember Enron? Remember Lehman Brothers? Customer tastes change. Remember Cabbage Patch Kids? Fashion changes, governments change, and competitors do their best to make life hard. So, really, even if you do know absolutely what you want when you first speak to us, it is unlikely that it will stay the same for very long.

I’m afraid to say that there are people in the IT industry who will take advantage of this situation. They will smile and agree with you when you tell them what you want, right up to the point when you sign. From then on, it’s a different story; they know that changes are inevitable, and they plan to make a healthy profit from change requests and late additions at your expense.

While I’m being honest, it is true we sometimes gold-plate things. You might not need a data warehouse for your online retailer on day one. Yes, some of our engineers like to do more than what is needed, and yes, we have a vested interest in getting things added so that we can charge you more.

It is also true that you quite legitimately think of features and functionality you would like after we’ve begun. You naturally assume something is ‘in’ when we assume it is ‘out’. And, in the spirit of openness, can you honestly say that you’ve never tried to put one over on us? (Let’s not even talk about bugs right now: it just complicates everything.)

Frankly, given all this, it is touching that you have so much faith in technology to deliver. But when IT does deliver, does it deliver big. Look what it did for Bill Gates and Larry Page, or Amazon and FedEx. Isn’t it interesting that when the IT industry develops things for itself, we end up with multi-millionaires? When we develop for other people, they end up losing money.

How did we ever talk you into any of this? Well, we package this unsightly mess and try to sell it to you. To do this, we have to hide all this unpleasantness. We start with a ritual called ‘estimation’ – how much time we think the work will take. These ‘estimates’ are little better than guesses. Humans can’t estimate time. We’ve known this since at least the late ’70s, when Kahneman and Tversky described the ‘planning fallacy’ in 1979 and went on to win a Nobel Prize. Basically, humans consistently underestimate how long work will take and are overconfident in their estimates.

To make things worse, we have a bad habit we really should kick. Between estimating the work and doing the work, we usually change the team. The estimate may be made by the IT equivalent of Manchester United or the New York Yankees, but the team that actually does the work is more than likely a rag-tag bunch of coders, analysts and managers who’ve never met before.

Historical data – data about estimates, actuals, costs, etc – can help inform planning, but most companies don’t have their own data. For those that do have data, most of it is worse than useless. In fact, Capers Jones suggests that inaccurate historical data is a major cause of project failure. For example, software engineers rarely get paid overtime, so tracking systems often miss these extra hours. Indeed, some companies prohibit employees from logging more than their official hours in their systems.

So we make this guess (sorry, ‘estimate’) and double it – or we might even triple it. If the new number looks too high, we might reduce it. Once our engineers have finished massaging the number, we give it to the sales folk, who massage it some more. After all, we want you to say “yes” to the biggest sticker price we can get. That might sound awful, but remember: we could have guessed higher in the first place.

Please don’t shoot me: I’m only the messenger.

We don’t know which number is ‘right’, but to make it acceptable to you, we pretend it is certain and we take on the risk. We can only do this if the number is sufficiently padded (and, even then, we go wrong). If the risk pays off, we get a fat profit. If it doesn’t, we don’t get any profit and may take a loss. If it’s really bad, you don’t get anything and we end up in court or bust.

The alternative is that you take on the risk – and the mess – and do it yourself. Unfortunately, another sad truth is that in-house IT is generally even worse than that provided by specialists. For a software company development is a core competency – such companies live or die by their ability to deliver software, and if they are bad, they cease to trade. Evolution weeds out the poor performers. Corporate IT on the other hand rarely destroys a business – although it may damage profits. Indeed, Capers Jones’ research also suggests specialist providers are generally better than corporate IT departments.

Sales folk might be absent, but the whole estimation process is open to gaming from many other sources and for many other reasons. The bottom line: if you decide to take on the risk, you may actually increase risk.

I know this sounds like a no-win scenario. You could just sit on the fence and wait for Microsoft or Google to solve your problems with a packaged solution, but will your competitors stand still while you do? Will you still be running a business when Google produces a free version?

Beware snake oil salesmen selling off-the-shelf applications. Once people start talking about ‘customisation’ or ‘configuration’, you head down a slippery slope. Configuring a large SAP installation is not a matter of selecting Tools, Options and then ticking a box. Configuring large packages is a major software development activity, no matter what you have been told. The people who undertake the configuration might be called ‘consultants’, but they are really specialist software developers, programmers by another name.

There really isn’t a nice, simple solution to any of this. We can’t solve this problem for you. We need you, but you have to work with us. As the customer, you have to be prepared to work with us, the supplier, again and again in order to reduce the risk. Addressing risks in a timely and cost-effective manner involves business-level decisions and trade-offs. If you aren’t there to help, we can either make the decision for you (adding the risk that you disagree), or spend your time and money to address it.

You need to be prepared to accept and share the risk with us. If you aren’t prepared to take on any risk, we will charge you a lot for all the risk we take on. Sharing the risk has the effect of reducing the risk, because once the risk is shared you, the customer, are motivated to reduce risk. One of the major risks on IT projects is a lack of customer involvement. You can help with that just by staying involved.

Ultimately all risk is your risk: you are the customer, you are paying for the project one way or another. If it fails to deliver value, it is your business that will suffer. When you share risks, when you are involved closely, risks can be addressed immediately rather than being allowed to fester and grow.

Finally, you may have grand ambitious, but we need to work in small chunks. I know this may not sound very sexy, but software creation works best when small. Economies of scale don’t exist. In fact, we have diseconomies of scale, so we need to work in tiny pieces again, again and again. If you are prepared to accept these suggestions, then let’s press ‘reset’ on our relationship and talk some more.

Yours sincerely,

The IT Industry

Dear Customer was first publishing this blog nearly 10 years ago, a polished version became famous in Agile Journal (now Agile Connection) a few months later and forms the prologue to Xanpan, 2015.

Subscribe to my blog newsletter and download Project Myopia eBook for Free

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

Posted on

My story, my why

AllanAdmin from Allan Kelly Associates

I thought I’d open 2021 year with a personal story of how I got where I am today (no, I’m not in San Francisco, although that is the Golden Gate in the picture)

Allan Kelly on the north side of the Golden Gate bridge, 2001.

I started programming when I was 12 (ZX81 then BBC) and then led a very successful career into my 30s – including a spell in California. Increasingly I found the code was not the challenge, I could make the code do what I wanted. The problem was the way we were managed, or mismanaged, the things we were ask to do and the way we were organised.

So began my journey into “management”. Determined to be a better manager than those I had worked for I took myself back to school. During a year in business school I learned a lot of good stuff, I discovered “organisational learning” and I reconnected with my dyslexia.

“Agile” was just breaking at the time and in agile I saw the same ethos of learning I was getting so excited about. The reports of agile teams I read described the best aspects of the developments I had worked on. For me, managing software delivery and enhancing agile are the same thing.

My mission became to help my younger self: help technologists deliver successful products and enjoy satisfying work. Most of what I do falls under the “agile” banner but really it is about creating the processes and environments were people can learning, thrive and excel.

When people are getting satisfaction from their work delivering great products, businesses succeed and grow. And as software has come to underpin every digital initiative my work has expanded.

For my latest blog posts, give aways and special offers on books and training subscrbe to my newsletter – and as a thank you download my Project Myopia eBook for free

The post My story, my why appeared first on Allan Kelly Associates.

Posted on

The “people problem” problem and the great agile divide

AllanAdmin from Allan Kelly Associates

“Its always a people problem.” Gerry Weinberg, The Secrets of Consulting, 1985

The great, unspoken, divide in agile is between those who believe the individual is all powerful and the centre of everything, and those who believe the individual is the product of the system.

Weinberg’s “law” is taken as unquestionable truth by most people in the agile community. Whatever the conversation, whatever the problem a wise old-sage will stand back and say “It’s always a people problem.” And in a way they are right.

People made the modern society and economy. People work in organisations, people make the rules, people enforce the rules, and ultimately someone in that organization made it the way it is. If only those people would act differently, make different rules, if only those people had greater foresight.

The problem is, once people have put all the pieces together the result is a system, not necessarily a technology system but a system of rules, norms, standards, accepted practices and “the way things work around here.” Which puts me in mind of Winston Churchill:

“We shape our buildings, and afterwards our buildings shape us.” Churchill, October 1943.

Yes, people shape our organisations, our processes and our culture, so it is always a people problem. But people are as much prisoner to those decisions as they are controllers of those decisions. Changing those things means changing the system, while that change needs to be made by people – and therefore is a people problem – the power to change that is distributed.

For example, Donald Trump has tried to change the US system in so many ways during the last four years. Often he has been frustrated by the rules of the system. He’s made some changes, and some of his actions will create changes in future. Some of us are glad the system constrained him, others are unhappy. Despite being the most powerful man in the world Trump was constrained.

So while it is “always a people problem” in that people created the system and operate the system doing something about isn’t just a case of asking the system operators to do things differently.

This is the great agile divide.

There are many, perhaps most, in the agile community who believe that every change, every improvement, is rooted in people. People are the centre of agile and all energies should be directed to help them do great work and create a system they can work within.

Then there are others who believe that it is the system which needs to be centre stage: because people work within a system.

Watch Stockless production and ask yourself: in the first simulation, when the waste is piling up, is there anything the men on the production line can do to improve it? I don’t think so because they are inside the system and the system is controlled by others.

I see the great divide again and again in the “agile” advice given out. The community doesn’t recognise the divide but every speaker, writer, consultant and coach is biased one way or another. Actually, “coaches” tend to put people first while “consultants” work with the system. Regurgitating “its a people problem” hides the divide.

Generally I align myself with the second group – its one of the reasons I associate with the Kanban community. But the process group has a problem.

In the days before agile there was a widespread belief that one could define the process, turn the handle and everything would be alright. That logic led to much of what fell under ISO-9000, TickIT, CMM(I) and other “process improvement initiatives.” I suffered under some of those regimes and I see the scars on others.

The problem was that this thinking lead to process experts who decided the process for others to follow, and process police who enforced it. So again, it is a “people problem”. But those process people are as much prisoners to the process as prison guards are. (I don’t want to be one of those people but I probably look like one of them on occasions.)

So, where does that leave us?

I no longer agree with Jerry Weinberg: people may create the problem, people may be key to fixing the problem but fixing a system is more than people.

I see my role, as an Agile Guide, as creating systems people can thrive in, where are not just cogs in a process, places where people can do their best work, where people problems can be seen and addressed. The system needs changing to respect the people, equally, those people deserve respected and involvement while changing the system.

Subscribe to my blog newsletter and download Project Myopia for Free

The post The “people problem” problem and the great agile divide appeared first on Allan Kelly Associates.