Month: March 2019

Advice on splitting stories

One of the most common reasons we reject people interviewing for coaching or product ownership related roles is an inability to grasp the purpose and value in splitting stories effectively, especially lacking an understanding of vertical slicing.

This is also a commonly requested topic for me at the meetup or speaking engagements. Yet it is a topic I have struggled to effectively explain. The conversation often ends up as a narrow technical example on certain techniques, or difficult stories or becomes too abstract for people to apply. In short it is a large and complex topic.

But this video sums up the notion of story splitting and in particular vertical slicing and the ‘why’ behind the method so perfectly that I felt I had to share it.

“Successful problem solving requires finding the right solution to the right problem. We fail more often because we solve the wrong problem than because we get the wrong solution to the right problem.”

Russell Ackoff

Dr Ackoff sums up the issue with the analogy of the parts of a car, if you assess the purpose of a car to get you to a destination then an engine alone is worthless, even the best designed and most efficient engine cannot get you to your destination. Until it is connected to the minimal set of features to achieve the user’s purpose it is useless and remains useless.

Building any feature that does not work end to end adds no value, and building any feature that does not support the purpose of the user also adds no value. But more crucially it is often the interaction between layers or between components that is the most complex aspect of any development, be it a car or software. and the notion that we can build an engine, and a gearbox and fit them together later and expect them to work seamlessly is laughable. But I hear it all the time in software design.

A system must have an aim. Without an aim, there is no system.

W. Edwards Deming

We’ll build the database first then add the other layers, or we’ll work on an API layer 3-6 months in advance of the front end. It is as if we assume that the integration is the easy bit and worse is the assumption that we have anticipated every need of the user (and omitted everything they don’t need) before we design and build the interface, and before we ask for any feedback. And yet as software designers; planners; and project managers we repeat this error over and over, never learning from the pain of not using vertical slicing for splitting stories.

I believe our fundamental attribution error is the focus on the blocks of functionality (the components of the car) rather than the interactions, and rather than focusing on the purpose of the tool and user feedback we plan for efficiency of the workforce. The result is an optimized workforce and an inefficient workflow. We create a sub-par product that has efficient working components but do not effectively work together, and generally this results turf wars over interfaces that do not match the use cases and last ditch efforts to fit square pegs in round holes.

We can learn so much from Dr Ackoff, software alone is not the system, software is a tool, it becomes a system only when it is in use. The only way we can know if the software is efficient is by putting working software in front of a user and for them to use it and give feedback. So the only good way to split a story is in such a way that you are able to get feedback from the user that helps shape the design or to assist in making decisions.

If a story cannot lead to feedback or use, then it has no value, it becomes inventory or work in progress, it is a liability rather than an asset. That Database or API layer that is built with nothing utilizing it is not benefiting you, it is waste, it is an over engineered liability and the pain comes when you integrate it with other components. This extends to unused data fields or unused end points, “we know we will need them later” is a poor excuse for creating additional WiP (work in progress).

Learning is not compulsory… neither is survival

W. Edwards Deming

We as Agile practitioners can learn so much from Dr Deming and Dr Ackoff we are building systems, and the development process itself is a system, if we applied a little more systems thinking I believe we could be far more effective.

But as Deming said “Learning is not compulsory… neither is survival ”

Can being remote enhance agility?

I am a very lucky person, I have my dream job. I work for a huge Solutions Provider as a member of their software consultancy group. The consultancy group has multiple physical offices in the St Louis area, and offices in Denver, New York and London. we have now decided to expand into the virtual space and launch a Virtual Office dedicated to collaborative software delivery. My role is to create this office, define the tools, practices, processes and then to build the team: hiring and supporting the staff and managing and growing the office. It is an incredible opportunity and it is not overstating to say that I wake up excited (and daunted) about it every day.

I wrote a while ago about the new role and about the challenge of remaining true to an Agile mindset. My goal was not to lose our agility as we became separated by technology and tools. https://yorkesoftware.com/2018/10/11/a-3-pipe-problem/

It was a surprise to discover that with the right attitudes and the right tools we are actually able to enhance our agility. We are actually more agile in a virtual space than we were in the physical space.

What is Agility?

To many this will sound like an exaggeration, but as a consultancy firm we sometimes operate in a less than optimal situation, there are challenges when you are working in a slightly abstracted situation. To be truly ‘Agile’ the goal is generally to get the team and business working together and to shorten feedback loops, deliver software quickly. But the reality is that ‘the business’ is a client. They are removed often physically which is bad enough but often they have other priorities and so are removed in an availability sense too. So whilst our teams are together, it is rare that we get the business (SMEs and Product Owners) on site and embedded with our team, when we can this is the ideal situation.

More often we get together for project kick-offs and planning and regularly for demos and retros. But stand-ups are often conducted via web conferencing tools, as are story writing and weekly planning/prioritization meetings. This puts a barrier between the team and the business, we do our best to break down these barriers but the reality is that they exist.

I call out being a consultancy as it is an extreme case but it also happens in most businesses, the PO and SMEs generally have another job and other priorities and the development team gets a slice of time and attention, so this is not unique to consultancy.

Brave New World

So understandably I went into this new venture with the expectation of doing my best to mitigate an already existing problem and to strive to not let it be worse in a Virtual Team.

In the early stages we found a tool called Sococo which is very hard to describe as technically it offers the same as many other remote communication tools, but it uses the metaphor of a physical office to make it easy for us to relate to the situation. When we used this tool something quite amazing happened, suddenly we were in the same metaphoric space as ‘the business’, we were truly working together. If I had a question for the PO I can drop by their office. If we need clarification from a SME we can invite them to join an Ad-hoc meeting.

We were no longer waiting for scheduled meetings to ask questions, we were chatting immediately. Feedback loops became immediate conversations, if someone was busy they would drop in between calls or other meetings rather than scheduling something formal. The casual nature of the metaphor brought us all together. This is how I imagined agile teams should behave in an office, but all too often logistics (read lack of meeting rooms) meant this was rarely a reality.

As a little tangent I worked with a delivery team a few years ago where the PO was available to the team all day but was in an office maybe a 60 second walk away. She made it clear the team could drop by or call her. But they never did. As an experiment I asked her to sit at a desk in the team area, immediately the team was a buzz of questions and conversation, we worked faster and discussions were spontaneous and relevant to the work at hand. This is how Sococo feels now. I can’t express how excited I am about it.

Daily Demos

An interesting thing has happened too, the team had an aspirational goal of daily demos, demonstrating completed stories and getting feedback on direction each day at stand-up. The aim was to challenge the team to keep stories small and to focus on shortening the feedback loop.

What happened instead was the realization that you don’t need to wait for stand-up. When a story was done the team would pull everyone together immediately get feedback and then discuss and plan what was next.

We realized that scheduled meetings for everything from story writing to stand-ups were primarily about availability of people and especially meeting rooms, they had little to do with the product or agility. When not restricted by availability of meeting rooms you can simply talk about what is needed when you need to. It is so liberating.
Naturally such a change requires a great deal of discipline to be effective but you have the potential to be focused on the shortest feedback loop, and reacting immediately.

By moving to a virtual environment we are becoming more agile than we were even together in the office, and having fun doing it. These may not sound like ground breaking discoveries but I can assure you they are having a profound impact on our work.