Conversation Patterns: Don't Confuse a Need with a Feature

This article is part of my work on Conversation Patterns for Software Professionals

---

I have used an Inverted User Story presented in User Story Template Revisited during some workshops with teams and I want to add a tip.

How to recognize you discovered the right benefit or problem to be solved. Well, you can't. You should stay aware of a conversation flow and test a timeliness of stakeholder needs. So the core need driving a user story doesn't escape your notice. Try to implement the Heart beat design pattern in your mind :)

But you should distinguish between "need" and "feature". A Stakeholder often confuse these two. For example:

As a Logged user I want to generate salary report so that I will know who is a VIP

Without a wider context it's difficult to validate the story. But, "I will know who is a VIP" is probably a feature, not a need. It's because it points a system feature, but not a stakeholder benefit or problem to be solved.

I want to score under this is my supposition and I would fire up my Heart beat pattern asking a stakeholder about a need details.

In general you may use following heuristics to recognise stakeholder need:

• Benefits you discover, mostly fits to the template: I want to achieve...[benefit]
• Problems to be solved you discover, mostly fits to the templates: I want to avoid....[problem to be solved]

The 'e' Letter Problem

I was inspired by Crista Lopes and her presentation to write this post. However, I found an analogy between her thoughts and my job, I recommend watching this presentation.

So, would you try to write a book or at least blog post without using words with the 'e' letter in the middle of a word? (In Polish it would be probably the 'a' letter). What implications it would cause? Would it be a challenge to express yourself giving the 'e' letter a miss?

Well, I think some of expectations about software development methodologies or techniques are similar to the 'e' letter restriction I mentioned:

• How to estimate this requirement? But I only have three-words explanation and that's all?
• How to start writing a code? But requirements will be precised soon ('soon' becomes 'now' when we will decide it is 'now')
• How to refactor 10-years old code during a weekend?
• How to deliver a software in 50% of time estimated with 50% of developers needed?
• How to start *DD with a team not experienced enough?
• How to accomplish more projects than our current capacity?
• How to motivate people with a pay cutting at the same time?
• How to boost our effectiveness without changing anything?
• etc.

There is no magic in the world. All methodologies and techniques have its own preconditions. These must be guaranteed before start. But we do repeat the same mistake over and over again. We want to write a book without the 'e' letter.

Software delivery organisational anti-patterns

It's good to have some electrical engineering background before reading this post ;P

I am confused every time I am asked what is the best way to manage requirements or which one is better: use cases or user stories, or how to ensure software quality by testing or how to evolve architecture properly, or does the *DD works, which design patterns are most wanted, what is better: agile or RUP. These are tricky questions, especially asked a consultant as I am.

Let's me try to explain what is a tricky part in these questions.

From IT point of view, the only goal of IT-Business collaboration is software delivery and nothing more. I like this term "software delivery" because it simply explains what we are responsible for. To achieve this goal we developed many tools which makes our work more effective. These tools address some difficulties we faced with when we collaborate with business people.


It is very important to notice these tools (show on the figure above) are not either-or dilemmas. You take whatever works and fits to a project context. Please read carefully at least:

• Writing Effective Use Cases by Alistair Cockburn
• Introducing BDD by Dan North
• Decisions, decisions by Dan North
• Specification By Example by Gojko Adzic
• Domain Driven Design by Eric Evans
• The Object Primer or agilemodeling.com by Scott Ambler

and you will see the tools are not competitors. Use stories are not compete with use cases, TDD is not competes with test-last approach, Scrum is not competes with free-style processes, DDD is not competes with simple anemic model, testing is not competes with test-free approach (really).

There is no "better", there is no "the best". Every single tools covers some aspect of IT-Business collaboration on software delivery. And everyone causes some benefits and consequences. But, you are responsible to choose a tool according to the project context. So yes, you should familiarize yourself with all of them.

The Source of All Evil

Problems start when one want to build a business around software delivery.

To scale the business one have to scale software delivery process to be more efficient.
So, one takes some of the tools and tries to compose The Process, for example: Analysis -> Architecting -> Implementing -> Testing -> Maintaining. So, tools becomes The Process steps and one builds teams around this steps.

You may say: ok it's old-school waterfall process. But, even organisations declaring agile approach have at least Analysis and Testing Departments. The rule is: the larger organisation is the more presented solution is applied. Where is a trick?

Software delivery is atomic. The only responsibility is to deliver software that is satisfying business needs and that's all. But scaling a software delivery we split this atomic thing into steps in a sequence.

We assume we may also split the Responsibility into small responsibilities of every single step. Moreover, we assume that Responsibility of whole software delivery is the superposition of the small responsibilities. In general it is not true.

You know, organisations where software is developed by programmers and tested by testers I may observe a lot of problems with a code quality and tension between Software Development Software Quality Departaments. Why? Because software developers are focused on their own responsibility and testers are focused on their own one.

Software Developers assume that testers will find all bugs and they are less motivated to test their own code. As a result tester have more and more work with bugs. And this a vicious circle.

One more example. Organisations where analysis is done by analysts (God, I'm trembling ever time I hear "Project Management Center") and development is done by developers, mostly have problems with requirements quality. It is happen that people don't know how to implement a requirement.

I think that problems listed above were caused by splitting what is unsplittable by the definition. Software delivery is unsplittable, it is atomic. We may use all tools to deliver better, faster or simpler. But we cannot split that tools into steps in a sequence. It doesn't work in that way. Once again: problems were not caused by the people or lack of competences. Problems were caused by the organisational anti-pattern.

Decoupled teams

Better idea is using tools around software delivery without splitting them.

Do you see the difference? Regardless of tools used the responsibility stays constant.
Ok, that was a metaphor but what about real world solution.

Solution is many stable Development Teams. A Team is responsible for delivering a complete working product. Moreover, there is no any dependencies between teams. A team is atomic.

Yes, I know there is more question than answers. How large a product should be? How to cooperate with other teams? How to build and develop a team? And so on, and so on.

The truth is we are in alpha-phase if about scaling agile teams on large projects and organisations. Some inspiration you may find in Disciplined Agile Delivery by Scott Ambler. Absolutely great case study is Scaling Agile @ Spotify. I believe the answer is out there and it will come soon.

Maturity is the Key

Do you know why: architecture, leadership, agility, effectiveness are so widely discussed? Because nobody know what they exactly are:) Or precisely: these are as complex as these mean different for different people and every point of view gives us some useful knowledge.

We coach development teams and looking in the past I may observe some interesting fenomenas. Let' see (important: I'm writing about Poland):

8 years ago

Nowadays

Some heard about XP A leader aka PM was non-technical quy Some heard about GoF Patterns There was no terms "clean code", "implementation patterns" well known Some have read "Code Complete" When we talked about programmer soft skills we were understood as weirdoes

Teams declare using Scrum or "our own adaptive agile framework" Most leaders do have a technical background "patterns" is one of most discussed word in many meanings Software Craftsmanship movement encourage to searching for better ways to do what we do and to improveme the craft Honestly, there is so many books about "patterns", "agile", "software craftsmanship", "good enough", "code readability" I cannot handle it Soft skills are widely discussed, but narrowly applied :)

So, we see the craft is changing. Software developers are changing. Nowadays, trainees or couchees are more experienced and educated then eight years ago. Some problems from the past are not problems anymore. But, we are faced with some new challenges.

What I want to say? According to Manfred Spitzer learing takes time (esspecially if we talk about social and soft skills). It is trivial, but not understood enough. We want to get skills and knowledge RIGHT NOW!. But it is impossible. Learning starts with acting based on simple procedures and lead up to contextual knowledge and contextual skills.

The crux is learning takes more time than average project length. Sometimes one expects to learn, let' say, "patterns" in four-days training. One also wants to apply its correctly in the project which is coming soon. But during a four-days training one will get a seed and an individual is responsible for its growth.

So, conclusions:

• Software Craftsmanship is a lifelong challenge
• See your learning goals from the five, ten or more years perspective...
• ...but be aware that every single line of code is a small step leading you to some learning goal? Do you like this goal?
• It is impossible to apply "patterns" or whatever always correctly
• Yes, you will smell the code from time to time.
• Make the failure faster :)

Conversation Patterns for Software Professionals

This article is part of my work on Conversation Patterns for Software Professionals

---

Real understanding of our stakeholders needs comes with a conversation. So we want to develop and share the best ways to do it.

Some readers of my book (in polish) and clients as well found its content very usefull. They encourage me to translate it into English. I have thought about it for a year, but couldn't decided.

So, I sent a proposal to couple international publishers and I am waiting for feedbacks. Regardless of their decisions I'm to gonna translate the book as Conversation Patterns for Software Professionals in the form of website conversation-patterns.com (guess what my inspiration was? :))

Having the book written I noticed that conversating with domain experts, users or clients is still difficult for a software professional. It is not a piece of cake to have a good conversations. So, the conversation-patterns.com and some of posts from this blog are intended to challenge it. I've already written two entries on the subject:

• A User Story Template Revisited - its abot how small change in a user story structure you use might cause quality difference
• A Buffer of Useless Answers - it about of application the Drilling Question Pattern. It will help you to obtain quality answers from your stakeholder.

I have also a vision of a community around Conversation Patterns. There is a lot technical stuff we know. But a real understanding of what have to be done comes with a conversations. So, my dream is finding ways to do it effectively.

That is early stuff so any feedback is welcomed.