Forem: Benjamin Follis

Traditional Kanban boards aren’t the best for stories.

Benjamin Follis — Tue, 06 Oct 2020 22:34:56 +0000

Kanban was developed for factory floors and operates best with tasks that don’t require additional discussion, are well defined, exist in discrete stages, and proceed in a continuous flow.

Bugs, and very small feature requests fit this model well, which is why Kanban is a popular methodology today with Trello and Github providing popular boards.

Unfortunately, every other kind of story doesn’t work so well. Stories that are part of larger work require frequent collaboration as the overall requirements evolve. Conceptually, such stories exist in discrete stages, but in reality stories influence each other: comments and suggestions abound, and traditional Kanban boards don’t have a way to display the true status.

What’s needed is a new type of Kanban board that integrates stories and communication. Suggestions during implementation should result in resolution during review, and failure to do so should be immediately apparent. Status needs to evolve from a simple column into a real-time view of what people are saying about the story.

Without such improvements, Kanban boards are not able to serve the needs of complex development, and will always be a source of frustration.

Development Collaboration is Complete Bullshit

Benjamin Follis — Mon, 05 Oct 2020 22:11:58 +0000

Developers are not ok with spending hours talking about out what to do next week
Daily standups are rarely actually useful
Backlogs are where things go to do die
Notifications and "responsiveness" are the modern equivalent to a dog leash
Video meetings with children running around are comically painful
Three people can agree on a meeting time, if two of them are dead
We're still dealing with "core hours" when nobody's life is that simple
Only estimating ahead of time doesn't even work for bathroom remodeling
Project management tools give managers what they want but not what they need
Engineers are judged on adherence to process instead of outcomes

What’s needed is a collaboration style that gives developers a seat at the table, without gluing them to their chair.

Backlogs don't make sense anymore

Benjamin Follis — Sat, 19 Sep 2020 00:13:17 +0000

Backlogs are the ordered list of items the team may take on in future sprints.

Modern customers expect short delivery cycles, and aren’t willing to wait for deliverables. In that environment, something that’s not getting done in the next sprint is the first candidate to drop when interruptions “blow up the sprint”.

Unfortunately this means that backlogs are where things go to die.

Maintaining the backlog requires the team to meet every sprint for at least an hour for “refinement”. This only pays off if the backlog items are worked on, which as stated above, is increasingly less likely. This is one of the reasons engineers tend to hate refinement meetings. They are tedious, and the return on time invested is horrible.

There is a better way.

Instead of a backlog of things that won’t get done, only keep track of stories that you’re going to do right now. When a story is created, assign it to a developer, and have the entire team weigh in on whether it should be done. Developers in turn, only start stories that their team considers worthy, and discard ones that don’t make the cut. In other words, continuously refine and plan, instead of waiting for the story to lose relevance.

Planning meetings are an exercise in futility.

Benjamin Follis — Thu, 17 Sep 2020 22:33:40 +0000

When sprint planning was first proposed software development cycles were measured in quarters or years. In that environment getting together to plan once every few weeks made a lot of sense, as the environment the software lived in wouldn’t be likely to change in that time.

That’s just not the case anymore, especially for online platforms. Software is deployed in weeks, or in some shops hours.

Creating a development plan for a fast release cycle costs too much.

Sprint planning is a significant investment of time and energy. The meeting requires everyone to get together for at least an hour, usually more. In order to make that investment pay off you have to speed up delivered software development by at least as many man hours. The shorter the sprint, the worse this ratio gets, and your process overhead goes through the roof.

Plans are unlikely to survive, even if sprints are short.

Traditional agile process has been a victim of its own success. Software delivery speed has gone up, and customers are no longer willing to wait months for a fix or for critical features to be developed. This means that whatever plans you make are increasingly likely to be interrupted by business needs. “Blowing up a sprint” isn’t a big deal if it happens once every few months, but it’s now happening all the time.

A better way is needed

Instead of trying to decide what’s getting done all at once, planning needs to happen all the time. Instead of building a backlog, when a story is created it is directly assigned to a developer, and the entire team weighs in on whether it should be done. Developers in turn, only start stories that their team considers worthy. When a story is blocked, before work starts again it must be considered alongside the new tasks that have arrived.
In other words, there’s no such thing as ‘blowing up the plan” only a succession of stories that are worth working on right now.

Enabling such a process is one of the goals of Uclusion, and we hope you’ll give it a try.

Standups used to make sense, they don’t anymore.

Benjamin Follis — Thu, 17 Sep 2020 01:22:19 +0000

Back when daily standups were conceived they were a good solution to waterfall development problems. Instead of working on their specification in isolation, everyone would get in a room and any issues would be surfaced before they got out of hand.

Unfortunately, they don’t really work well in the world we now find ourselves in.

The assumption that everyone is in the same room doesn’t translate well into online experiences.

Somebody, somewhere, is going to have a technical glitch, or forget to mute, or have a dog turn over the laptop. Unless everyone has a dedicated home office, it’s just not going to be possible to bring the same level of concentration to the meeting.

Once a day isn’t enough.

From the developer side, standups only really worked when we could have all the little conversations to clear blockages outside the standup. We don’t get those hallway conversations anymore, so the standup takes way longer than it should. You can try to keep that out of the meeting, but I’ve never seen it successfully done. Developers just want to help too much.

From the business side, the same lack of little conversations means that progress isn’t being made until tomorrow, and that utterly kills productivity. You can try to fix it by having more frequent group checkins, or a chat channel that should be monitored, but then you just wind up killing productivity because people are always getting interrupted when they need to focus.

There is a better way.

Instead of standups, what’s needed is continuous collaboration. Status isn’t something that exists at a point in time, it’s something that everyone should be able to see whenever they want. Questions and issues need to be reflected in that status, and should cause the appropriate people to be notified, instead of taking the entire team’s time.

Continuous actionable status is one of the things we’re trying to bring to life with Uclusion, and we hope you give it a try.

React Wizards with State

Benjamin Follis — Fri, 11 Sep 2020 02:18:44 +0000

Hi,
Over at Uclusion, we have a fairly large amount of information required to properly set up a Workspace (or Dialog, or Initiative). As we talked about in Wizards aren't just for Hogwarts, to make sure our users aren't hit with too much information at once, we've converted all of our top level creation flows to Wizards.

While doing so we discovered that the most annoying part was keeping track of the form state that the user had entered, and making sure the user could resume if they had to reload or just set down work.

To make sure YOU don't have to go through the same annoyance, we're open sourcing react-formdata-wizard, which will maintain all the state transitions, form data, resets, etc, all in one easy to deal with package.

Unlike other react wizard projects we do not render any UI or nav buttons, but instead provide you with the properties you need to make your own. That keeps state management separate from UI, the way it should be.

Enjoy, and expect more changes as time goes on. We're busily rebasing the entirety of the wizard flow on this package.