Flock is about communication, motivation and continuous improvement. In part two I went into details about the concept behind Flock development. You are on a team that’s likely doing some version of Scrum-fall. So how do you transition your team to a new, more flexible development methodology?

Change is difficult for a lot of people. In an article by Mitchel Harper he talks about A, B and C players. Likely the majority of your team are B-players who are content with their current situation. I like to call this corporate inertia – the resistance you need to overcome in order to implement change. To that end, start slow by encouraging the team to be more autonomous and motivated. Tell them to self-select their tasks, encourage ideas on how to solve problems and get them communicating outside of meetings.

Cancel all the meetings.

I’m pretty serious about this. Cancel all the meetings that aren’t obviously critical. If you need them later, you can always add them back. Get your team to start working together in real-time. You’ll likely have some push back and complaints about removing meetings. There are people on every team who hide behind meetings as excuses for not getting work done. Keep encouraging them to get up and talk with their colleagues to solve problems. Or heck, just call a impromptu meeting if necessary.

Get persistent chat set up for your team. Rocketchat can be installed in an hour. Slack in less time (although it costs a little money). Move your team out of meetings and off emails.

Get your people excited again.

Boosting morale can have a huge impact into transitioning to Flock. You want your team excited to work. Excited people are motivated. You can do this by having team lunches/happy hours to show your appreciation.

You can encourage them to think outside the box for new solutions. I’ve never met a developer worth their salt that doesn’t want to work with more modern technology. Look for ways to implement those ideas. This aligns with the “embracing technology” principle of Flock. Lay out lofty goals for your project. Suggest big, year-long improvements.

And then work every day to improve and implement those suggestions.

Keep trying new things and see what sticks against the wall. By moving fast, even those afflicted with inertia will be forced to adapt. Being one-change behind isn’t a big deal. But if you’ve changed 4 times in a month, they will need to keep up. Make sure you listen to complaints and take them seriously. I’m not suggesting changing just for change sake. Explain why you are trying out something new and let the team know that if it doesn’t work, we’ll do something else. As Flock says, “Process follows delivery.”

Trust your team.

People want to do the right thing. A lot of the time, they feel like the process or management is restricting them. Break those corporate chains and let people do their jobs! Your team wants to do a good job. They are professionals and understand how to solve complicated problems. As a manager, you’re there to facilitate and grow this initiative. Let them take pride in their work. Show them that finishing tasks or stomping bugs has a direct impact on the customer. A lot of times your development team will feel two-steps removed from the end users. Close that gap and give them the feeling of success when they add a new feature.

You’re going to encounter some problems along the way.

The number one problem you’ll have when moving people to Flock is not having enough authority. If you are not in a position to impose these drastic changes, you will fail. Trying to do so by building a consensus will take too long (and is effectively managing by group). Don’t try to vote on these changes. It won’t work and wastes time. If you don’t have the authority, then talk to your management about the changes you’d like to make. Maybe you need to reorganize the team. I suggest flattening it whenever possible. If that doesn’t work, try suggesting changes to the customer. I encourage a lot of caution with this approach. You do not want to go behind the back of your team. Positive input is always welcomed, so just mention your changes in a meeting.

Or better yet, take the initiative and implement some changes. Make a PowerPoint on new technology that would impact the application. Set up a chat server. Encourage colleagues to collaborate more through code-reviews. Send and discuss interesting articles that are relevant to your group. See if people want to got out for lunch or drinks….okay, okay – I’m talking about building a consensus. Well, more like getting buy in from key stakeholders. The consensus will follow.

I cannot overstate the fact that you will receive push back from cancelling meetings. For as much as everyone complains about meetings, they sure seem to love having them.

You’ll likely need to micromanage the teamwork into people before they become autonomous collaboration machines. Walk around and ask each person what they are working on and see if they are having any problems. If someone is stuck or having a problem, find someone else to help them. Do not suggest the person with the problem go asking for help. It won’t work. Do the opposite. Find the person who can help and ask/tell them to assist the person.

I get this is what stand ups are supposed to be about. The problem is stand ups are only once a day. This type of behavior needs to be ingrained in the team. When they have a problem, they need to seek help. When someone notices a colleague struggling, they need to suggest help.

Some people might get hurt feelings.

There may be folks on your team that take changes personal. As a reflection that they did something wrong or bad. Make sure this is addressed. They didn’t do anything bad, you’re just looking for ways to improve. And you would love if they could suggest ways to make those improvements. This is the rising tide lifts all ships mentality. You are a team and need to work closely as one. That’s literally what Flock is all about. An independent group all working in cohesion.

The likely scenario is about half the team will be excited for these changes. Hopefully the customer will see immediate benefits. Some people may take longer to get on board. Others will likely quit or ask to be reassigned. The truth is, some people just want a 9-5 where their told exactly what to do and little changes day to day. That’s fine – but they won’t succeed in a Flock. Do your best to try and motivate them by seeing what gets them excited to work. Alas, sometimes that fails too. (This is where you get to hire people – my favorite things and the subject of the next few articles.)

Your optimistic time frame is 6 months to transition.

Depending on the inertia, team and client – you’re looking at a good 3-6 months before things start clicking. After 6 months, you’re group should be functioning like a well-oiled development machine – crushing bugs, adding new functionality and excited about the future of the application. To recap on the most important items to transition:

• Communication! Both communicating the changes to the team and encouraging them to collaborate with each other.
• Get buy in from key stakeholders. You’re building a Flock not being a dictator.
• You need the power to be impactful. If you don’t have authority to change, you’re setting yourself up for failure.
• You need thick skin and strong leadership to withstand the push back. Change is hard and don’t take it personal.
• Be proactive. One person can make a huge difference.

Next, the start to hiring a great person – writing the best damn job description ever.