In part one I discussed the problems with Agile in the Government space. This is about its replacement: Flock. (I had a lot of different names but none conveyed the goals as well as Flock. For those interested, I’ve included them at the end) Flock came about from a lot of trial and error while working on a particular difficult program.
On this program, I led a team of 15 where we supported over a dozen different applications of varying size and complexity. And we didn’t have one customer, nor two. We worked for 5 separate customers. Each with different schedules, funding and expectations. These applications had a worldwide user base of nearly 200,000.
When I joined the team, everyone was completely siloed. Each member was appointed to a single application they were responsible. There were weekly scheduled meetings for each application. Regardless of user need, we moved at the speed of one. It was impossible to ramp up on a high priority task because people didn’t have the skills.
We needed a change.
I had success with Scrum in the past but it didn’t work. We had too many projects. So we tried Scaled Agile Framework (SAFE) but that didn’t either. They were all too slow and rigid. And it was difficult to use with five product owners. Could you image having five 2-hour Sprint planning meetings each week with a team of 15?
We needed a system to track our priorities and meet our deliverables. It took about a year, but we finally found a way of working that made a lot of sense for us and our customers.
The more I thought of what we did, the more I realized how different it was from any other development methodology. And that’s the conception of Flock.
Flock is based on free-scale correlation witnessed in the collective movement of animals.
Birds in particular, hence the name. Free-scale correlation is where the overall behavior of the group affects each individual, and each individual affects the group as a whole. Regardless of group size. This is achieved by having a high signal-to-noise ratio amongst all members. In other words, every member has near lossless transmission of information to a subset of the whole. As one individual responds to change, that information is relayed without degradation.
A Starling flock, or murmuration, exhibits this behavior when trying to evade a predator:
This is the goal of Flock, to move as a single cohesive unit with the ability to rapidly adapt to a changing environment. What Flock is about:
- Real-time communication and collaboration
- Prioritized backlog for each project
- Rapidly delivering value
- Rapidly adapting to change
- Process follows delivery
- No defined roles or rituals
- Embracing technology
- Works for any team size
Real-time communication and collaboration.
Embracing chat tools, texting and face-to-face over meetings and emails. I’m going to be a little hyperbolic, but meetings are a waste of time. If you need to talk with someone, walk over and talk with them. The goal of Flock is to drive the number of meetings down to zero. The team should be in constant communication via Slack, RocketChat or something similar. This communication is critical to the success of this methodology.
No more standups.
Are you asking, “how will I know what everyone else is doing? You’re going to talk with them. You’re going to work together to solve problems together.
Let’s be frank – people ignore or just glance over emails. And meetings only postpone conversations. Real-time group chat is a game changer for development.
Prioritized backlog for each project.
The simpler the better. My favorite tool is Waffle.io, a Kanban board built directly on Github Issues. Both Github and Gitlab have similar implementations. If it takes more than one minute to explain the tool, it’s too complicated (I’m looking at you TFS!).
No more definitions of done or long acceptance criteria.
The team as a whole should have a clear understanding of the work and direction the project is headed. It’s counter-intuitive to have programmers only code to acceptance criteria. They will miss the big picture. They won’t try to think for themselves about what’s best for the application.
Just simplify everything.
A simple board with a simple workflow (todo, in progress, done). Simple user stories. Integration with code via webhooks.
The customer should have direct access to the backlog. They should be actively prioritizing work and creating new stories.
For the love of everything nice, do not start your story with “As a luddite, I would like to recreate iGoogle and have customizable widgets…” But feel free to estimate the complexity (not hours) of the stories. We found that individual story estimates worked the best for our team.
Rapidly delivering value.
Get your work in front of the customers as fast as possible. That’s all there is to it. No need to wait for a biweekly Sprint Review. Get ride of Sprints all together! If a feature done, put it somewhere your customers and users can bang on it. Lean towards behavior driven development over test driven.
I often joke that Microsoft doesn’t employee any testers – they just release the product and let the public find all the bugs.
But there is some value to that line of thinking. Your customer is going to be the best functional tester in the world. They know what they need in order to get their jobs done. Utilize them.
Rapidly adapting to change.
Flock is literally about responding to changes. These can be customer changes, problems in production, staffing changes, priorities, funding, anything. Life doesn’t move in 1,2 or 4 week increments.
In 2017, life moves by the minute.
The team needs to be trained and encouraged to be independent in responding to change. (I’ll go deeper into this topic in the next article.) We are all adults and want to do a good job. We work together and succeed as a team. Change promotes growth and improvements. Never be afraid of change.
Process follows delivery.
Improve quality over time by updating your team’s unique processes based on what works best for delivering to your customer. This ties directly to the previous comments about changes.
If you’ve made a PowerPoint slide about your “process” you aren’t improving it fast or often enough.
And just like the Starling flock, processes can and should be individualized. What works best for one programmer rarely works for everyone. Flock is made up of the interactions between these individualized processes. The faster the team understands and adopts to what works best for the individuals, the better the overall product.
No defined roles or rituals.
I’ll repeat this again and again; Flock is all about the collective. This means sharing knowledge and responsibility. It’s okay for the team to have experts in specific areas, but no one should be pigeon-holed. I hate to hear that someone is a “backend developer.” Or this one is a “database administrator.”
Who cares about labels? We need people who can get the job done from operating system to design.
It’s great to have a go-to person when it comes to specialized problems. But on Friday afternoon in the Summer when your app goes down, the person left in the office should have the ability to fix it – regardless of their title.
Give people a chance to do new work and expand their skills. They will surprise you every single time with their motivation and dedication.
Embracing technology.
YES! IT’S OKAY TO BE ON THE BLEEDING EDGE. Don’t be afraid to try new tools like the latest JavaScript framework that promises to revolutionize development. Just try it and maybe it does exactly that. If it doesn’t, then fail fast.
Always fail fast. Adapt to the change and keep improving.
Technology advancements are accelerating. If your team doesn’t adopt they will not reach their full potential. Some might find it weird that embracing technology is a facet of Flock. It’s not and here’s why. Developers and engineers are lazy. Good lazy, but lazy. They want to automate everything that can possibly be automated, reuse everything that solved the problem before, and get to the solution as fast and as painless as possible.
This is perfect for Flock! I don’t call it lazy, I call it efficient.
Works for any size team.
Every PMP holder knows that communication channels grow at [N*(N-1)]/2. For a team size of ten, that’s 45 channels. Doubling the team size to twenty, the number grows to 195! Yikes! We better keep our team size to seven (and completely avoid reality in the process). Chat and integrated tools solves this problem. They are incredibly effective at reducing the number of communication channels making this concept dated.
I get it. The bigger the team, the harder it is to manage. And Agile Scrum completely falls apart with even modestly large teams.
Flock will work with any size team. 20, 30, 100 people? Go for it.
It works because it focuses on the individual and empowers them to be autonomous. And it demands real-time communication and collaboration. That’s all it takes to make your team reactive and cohesive like the Starlings.
The next article will focus on how to transition any team to Flock, regardless of inertia.
Other names:
Radgile: Awesomely rapid-agile. Gnarly!
Avalanche Development: Avalanches are critical systems like Starling flocks and sound cool. But they are also destructive and only move in a single direction.
Swarm or Hive: the name is pretty obvious but I didn’t like the negative connotations to hive-mind. And they are generally controlled by a single Queen. Not the independent little thinkers we want.