Archive

Engineering

Learn Through Delivering

In my previous post I talked a little about the role of language and vocabulary in shifting focus – from being busy, to attending to folks’ needs. The word ‘deliverable’ emphasises, unsurprisingly, delivery. But what does it mean to “deliver” in the context of i.e. software development?

Inspect and Adapt

For me, delivery is the opportunity to close the feedback loop. To gain some insight into whether what we’ve been working on has been useful to our stakeholders. And to adjust our sights – and ways of doing things – in the light of that information.  So the defining aspect of any and all “deliverables” is that deliverables, by this definition, must be delivered to stakeholders and they must be able to try them out in as near as possible to real-world situations so as to provide meaningful feedback.

Cadence

Just how often might we deliver something for our stakeholders to provide feedback on? That depends on how short we want our feedback loops to be. Myself, I prefer a maximum feedback loop length of two to three days. Whether your teams are in a position to dance to this rhythm, or something slower, kind of depends on your stakeholders and how quickly they can look at, and respond to, each delivery. Keeping deliveries small can help here, by keeping what they have to look at, and their responses, small too.

Artefacts

Of course, there will be things we create, produce – things for our own consumption, like documents, design artefacts, intermediate transformations leading to deliverables, and so on. I choose to call these non-deliverables “artefacts” (or even “non-deliverables”) – to distinguish them from the deliverables on which we intend to seek feedback.

May I invite you to trial a change of perspective – from learning through doing, to learning through delivering – as soon as you have the opportunity?

– Bob

 

Tasks – or Deliverables

In most every development shop I’ve seen, folks’ planning vocabulary has been founded on the task as the unit of work. Long ago, at Familiar, we discovered that a different vocabulary offers some key advantages. Ever since then I’ve found that a planning vocabulary when deliverables are the default unit of work suit me much better.

Some Key Advantages

  • Planning in tasks encourages (subconsciously for the most part) busywork (a focus on activity).
  • Planning in deliverables encourages a focus on outputs (ands thus, closer to outcomes).
  • Deliverables are closer to what stakeholders seek (i.e. having their needs attend-to, or even met).
  • Tasks are generally one stage further removed from needs than are deliverables.
  • Deliverables are, to a degree, ends in themselves – tasks are means to ends (and hence more disconnected from outcomes).
  • I find it easier and more useful to quantify aspects of deliverables than aspects of tasks. YMMV.

Mayhap a focus on outcomes directly would be a further step in the right direction, but for most of the development groups I’ve seen, a single leap from tasks to outcomes might have proven infeasible.

May I invite you to trial a change of vocabulary, and of focus, next time you have the opportunity?

– Bob

 

Nine Aspects Of Top Developers

topdevs

Ask a hundred people what’s their definition of a “top software developer” and you’ll likely get a hundred different answers. Many definitions may cluster around “someone who can make the computer jump through hoops”, i.e. a technical virtuoso of some sort.

Personally, my definition of a top developer is somewhat different. My definition is someone who:

  1. Understands people and how they – as e.g. users – might find joy in interacting with software.
  2. Understands people and how best to get along with them – e.g. in a team, a business – to create “solutions”.
  3. Understands people and their needs – and how to attend to those needs by e.g. writing software.
  4. Understands herself or himself – e.g. her or his own biases, tastes, limitations and capabilities.
  5. Looks to improve themselves and – together with other people – the way their work works.
  6. Has a broad range of life experiences to draw upon for e.g. inspiration and insight.
  7. Is widely read and informed – and especially, not just technical books, articles, blogs, etc..
  8. Is different and thinks different – to the other people around them. A.k.a. Diversity.
  9. Seeks out and takes ownership wherever and whenever folks’ needs aren’t getting met.

Technical virtuosity, aptitude, coding talent, experience, domain knowledge, numeracy, ability to learn quickly, etc. are all nice-to-haves, but not core to being a “top developer” – at least, from the perspective of e.g. folks paying their wages.

Bottom Line

My bottom line: I’d regard someone a “top developer” if they are highly effective in attending to folks’ needs. Although, just the idea of labelling someone “top”, or not, makes me feel uneasy for its implicit judgmentalism.

“it’s not what you say, or know, or even who you are, it’s what you do that matters.”

I guess my definition is just one amongst that hundred.

– Bob

Further Reading

The Three Virtues ~ Cf Larry Wall

Business Development

The word “development” in the phrase “business development” has always meant something very different than in the phrases “product development” or “software development”. The term “business development” is generally taken to mean finding new customers, building customer relationships, and such like. And thus responsibility primarily resides in the Sales & Marketing silo.

Maybe this is one reason why the idea of “developing” a business, in the same sense as developing a product or a software system, is pretty much unknown to business folks. Many’s the time I have invited business folks to consider the merits of taking a “development”approach to the construction and evolution of their business, only to receive little response other than a sea of blank faces.

Which makes me sad, because there’s an enormous amount of “development” practice, expertise and skills available to apply to the challenges of developing a business or other organisation. I’d say that some 80% of the know-how involved in developing products or software systems is directly applicable to “developing” an organisation.

Have you ever suggested to business folks that “development” know-how could have a massive impact on their bottom line? Or otherwise effectively meet many if not all of their core needs? What kind of reactions have you seen?

– Bob

Further Reading

What, Exactly, Is Business Developoment? ~ Scott Pollack
Prod•gnosis In A Nutshell ~ FlowchainSensei

Out Of House FlowChain

When I conceived of FlowChain, some six years ago now, my immediate context was development shops with their own in-house developers, and other supporting staff.

But it strikes me that with just a few adjustments, it’s also suitable for organisations that sub-contract out most or all of their development projects to third parties.

These adjustments centre around arranging for the various third parties (assuming, in the likely case, that there’s more than one) to each contribute staff to the “Pool” (see diagram). These arrangements include:

Commercial

How will the third parties be paid? Some UK government functions use function points as a measure of “work done”, with a set price for each function point “delivered”. See: Output-based contracts. I can imagine other contractual arrangements, too.

Social

How will the third parties’ staff integrate or form healthy relationships with the in-house commissioning staff (a.k.a. product owners)? Will there be shared spaces? Regular visits to and fro? Some more technical forms of communication (Twitter, chat, video conferencing, etc.)? Remember, each backlog item is sized for two to three people working together for two to three days.

Tooling

Third parties remain free to pull items from the backlog as they see fit (just as with in-house FlowChain), and use their own tools, languages, etc.. I foresee some advantages in having a common code repository, coding and other standards, agree requirements around test suites, and so on.

Delivery Into Production

Maybe the organisation contracting the third parties has its own Ops department. In this case the interface between development (teams, third parties) and Ops would probable best be standardised and agreed (like an API). If the third parties have their own Ops folks, then they can do DevOps in their own space and time, and serve the “production” services – or even micro-services – they each operate, directly to users.

Shared Backlog

For clarity, this variant of Flowchain retains the enterprise-wide backlog, with user stories, improvement stories, etc. being prioritised by some black box (or white box) prioritisation algorithm, committee, manager, or whatever. The only real change is in how the Pool is constituted. Note: I see no particular reason why the general FlowChain principle of “ANY unassigned development folks from the Pool can coalesce around each new top backlog item” cannot stand, here.

There may even be emergent advantages in having e.g. developers from different third parties coming together to collaborate on specific backlog items. How weird would that be? Again, policy would guide folks’ actions here.

Who would “manage” the backlog?  This could be done by a small in-house staff, or itself subcontracted out to one or more third parties. Note: the backlog in FlowChain is largely self-managing, in any case, given an effective prioritisation algorithm or approach.

Flow

Flow (of e.g. software into the hands of those whose needs are being attended to) remains the key objective of the whole approach.

Growing An In-house Capability

For organisations without an in-house development capability, this approach provides a simple(r) path to establishing and growing an in-house development capability. In-house developers can be added, one by one, as and when circumstances (budgets, priorities, etc) allow. These new folks can work alongside – and learn from – third-party staff already used to Pool working, and the balance between in-house and out-of-house staff, skill sets, etc. adjusted dynamically as needs dictate.

Drawbacks

The key drawback I foresee is in the matter of dev-ops integration (DevOps). This could prove more difficult, in the case where developers, etc. are out-of-house and Ops in-house. This seems a special case of the issues of outsourcing and offshoring, generally. But I’m sure a bunch of smart developers and smart ops can work this out, especially with some help and guidance.

– Bob

No Testing

Testing. Checking. Inspection. Exploration. Learning. Everybody has a different understanding of what testing is. And is not. (Hint: AFAIC, it’s NOT “QA”. And it’s NOT “TDD”).

I’m not going to upset people by offering my own definition. I make no claims to be an expert on testing.

When I’m a customer, I know I don’t want to pay extra just for a product that works as advertised. By extension, I’d not want to pay for testing. I want a product that “just works”. And if asked to pay more, I’d have to enquire skeptically “why can’t you people build it right in the first place?”.

Some years ago now, David Anderson wrote a blog post asserting that “All testing is waste”. I concur. But is it necessary or unnecessary waste (Type I or Type 2 Muda?). And does that categorisation depend on the capabilities of the team(s) – the developers – building the software? If the developers can’t deliver software with the intended levels of defects (which could be non-zero, btw) then maybe testing is a necessary waste, to compensate for that inability. And maybe it’s cheaper and more humane to employ less capable developers, bolstered by testers, than to have capable developers who can meet intended defect levels reliably.

So, do we have to test, despite the customer being unkeen to pay for it? Despite it adding little or no value from the customer’s point of view? Or can we find other, more economic and humane ways to meet the needs testing currently addresses?

Needs

“Testing” is one strategy for getting folks’ needs met. Some of their needs, at least. We might imagine there could be other strategies for getting those same needs met.

What needs does testing address? And who has these needs?

  • Testers need to continue earning a living in their chosen profession, to feel belonging in a community, to earn the respect of their peers for a job well done, to continue their self-development and learning, to add value and make a difference.
  • Customers need stuff that works (that meets their needs), for a price they’re willing to pay.
  • Companies making stuff need to safeguard their reputations and revenues.
  • Managers generally need to appear capable of delivering new products which meet the company’s and customers’ needs, whilst also controlling margins (costs vs returns).
  • And of course every individual may have their own particular personal needs, too.

Strategies

My question is: “Is testing the best strategy for meeting all the above needs?”. It may be the best known. The most widespread. The default. But is it the most economic? The most humane? Indeed, what are the dimensions of “best” here? Or even of “reasonably effective”?

“No Testing” attempts to flag up these questions. No soapbox. Just open enquiry.

– Bob

 

 

 

 

 

Things We Could Be Doing

I’ve spent much of my career exploring the world of knowledge-work, and especially the world of software and product development. I’ve seen many businesses, most of whom share a common view of the way work should work, the way to design products, the way to find and organise people to staff the business, and so on. I’ve seen how these common approaches fall way short in terms of results. And I’ve seen, or imagined, other, less common ways which could make a huge difference to the success and profitability of businesses everywhere.

There’s a whole passel of things we could be doing, that we’re not, presently. We could be…

Creating Environments Better Suited To Knowledge Work

Most “environments” in which I have seen folks trying to get work done are woefully ill-suited to doing effective knowledge work. Very few businesses seem to understand even the interplay between environmental factors and outcomes. And fewer yet, those who have actually created and sustained effective working environments.

Aside: By “environment” I have in mind various aspects:

  • Physical – the floor layout of the office space; the decor, lighting and general ambience; the architectural style of the office buildings; the situation of the office buildings themselves (city, parkland, countryside, wilderness); facilities (shared spaces, dining, leisure and recreation, etc).
  • Technical – webtone; the choice of hardware, OS, tools; and so on.
  • Social – how people generally relate to one another and treat each other.
  • Dynamics – High-energy or plodding; stressful or laid-back; studious or action-oriented; high-risk or safety-conscious; etc.

Reliably Designing Products Which Buyers Crave

We know now that people don’t buy products or services on rational bases. Rather, they buy on emotional bases, and then, maybe, use rationality to justify those decisions, post-hoc. Why then do so many businesses still spend so much time and effort designing their products to appeal to rational buyers?

Designing “Whole Products”

Most businesses cobble together new products and services, conducting a more or less random walk through their vertical silos for each new product development. And then stuff these new products into the existing silos in the hope that sales and profits will accrue. We could be recognising that development of new products is the lifeblood of most organisations, and organising along those lines.

Organising Around Flow

One common strategy for businesses has long been managing to reduce cost. Much more effective would be to manage (e.g. constraints) so as to improve flow (of new products to market, value to customers, or of needs, to all stakeholders).

Having Everyone On the Same Page

Most businesses I have seen have folks running around like headless chickens, hither and yon, with precious little alignment or general understanding of common goals, strategies, and so on. Many tools, techniques and other means to get and keep folks on the same page exist. Few business use any of them. Nor realise the cost and other impacts of such chaos.

Improving The Effectiveness Of Our Businesses

More-or-less random local improvements seems to be the best most businesses aspire to. We could be systematically and progressively improving our businesses on a near-continuous or continuous basis. We only have to look as far as e.g. Toyota to see the stupendous rewards this can bring in the long term.

I see very little of any of the above happening in any businesses. After all these years, I still wonder why. How about you? Would you be willing to share your perspective?

– Bob

 

 

%d bloggers like this: