Tom Peruzzi's thoughts on digital, innovation, IT and operations

Imagine you start a new leading job in a company which calls itself agile. Later on you recognize that even if they somehow do some agile stuff they are far away from agility. The mindset is generally right, skill level high but collaboration with business broken, push and pull in parallel, tools over collaboration and way more.
So where and how do you start? Literature is much more focused on how to start becoming agile than turning around such an organisation. Mindset, know-how, skills and attitude are ok but to be challenged …
Now, a few sprints later we can share some of the insights we gained during our journey and yes, we were successful 🙂

1. Start with a spontaneous break! From one day to the other we simply informed everyone that from tomorrow on we will work the following: review and retro every second Friday, planing 1 and 2 every second Monday, daily grooming and bi-weekly sprints. Knowing that we pushed hard, it was the ultimate challenge to switch from one day to the other. There was simply no time for long discussions, collaboration was down, lots of complaints from the business and the simple need to get back to delivery mode. I know that some of the devs hated us for doing so, radically introducing transparency isn’t easy but if you have just one silver bullet please consider it carefully and this was our silver bullet.
2. Stay near the teams, moderate and coach but don’t take over
   For the next couple of weeks we did our very best to stay near the teams, helped them in getting up with the process, getting their buy-in. We helped them with one-on-one and team sessions, but it was up to them to buy-in and adapt it according to their exact need. Everything was ok as long as it didn’t conflict with our main goals: transparency and predictability.
3. Physical boards
   We love confluence and jira, yes we do. Even so we decided to track on epic and story level in Jira but do our daily work on physical boards. The reason is simple: The only thing our business is interested in is getting stories done, no matter how we achieve it. And we wanted to avoid business asking questions on simple task level or starting getting nervous if a task isn’t done in time. So simply for resilience and overview we organized that media break. We started with task planing on the board. After a while we adjusted slightly like:
   • when a task isn’t done in one day (we broke it down like that) we put a red dot on it so it becomes visible to all of us
   • we learned to break it down in single-day tasks. Even if that produces a lot more paperwork it is crucial for success to get doable and trackable pieces of work.
4. Get out of the daily routines
   Once you recognize things moving in the right direction get out of daily routines. If you see grooming going the right direction, let them groom without you, same for retro and review. Just step in occasionally to quick check direction. Trust your teams – if you don’t trust, switch back to waterfall. No agile approach without a certain amount of trust…
5. Wait with KPIs
   There would have been tons of interesting KPIs but first they hinder you from learning and from reaching a certain flow-level. Start estimating from day one but don’t take care on burn down for the first 3 sprints. As long as the team is still experimenting with estimations it isn’t worth too much. Look at stories completed only and check (5 why) why some stories didn’t happen even if we committed to deliver. Look for qualitative signals indicating you right direction or not. After 4-5 sprints start with simple, easy to maintain KPIs. Otherwise you will not be able to fine tune later.
6. Get stakeholder’s support and willingness to change!
   Looking at our org-chart: our POs are not part of our tech organisation, they are within their product-focused teams. Imagine you implement a process which affects all teams (as they all rely on you)… We do spend a lot of time on grooming, lots of hours day per day. Everyone is allowed to join, so even if grooming takes just 30 min (timeboxed) getting 10 people in results in 35 hours a week on grooming. Is it worth the effort? Yes it is, stories get better and better, devs understand business way better than a few months ago and business starts understanding us, our needs and constraints. Agile development is agile product development, it’s not a tech process only. Without the understanding of the problem and the acceptance of your stakeholders you are not able to change anything. So get their buy-in and make sure that they adopt as fast as you change. Inform them pro-actively, there is not enough communication, just too little.
7. reward success, celebrate failure, punish inaction
   Robert Sutton once said that and he is 100% true. So how do you change without making failures? That’s simply not possible so think about how to make failures a success. Whenever you somehow fail, don’t blame others. Think about why you failed and how you can avoid that in the future. Spread that knowhow and then celebrate the successful learning. But don’t forget to reward successful actions too, go out for team dinner, acknowledge new learnings and small successes too, let people know you see and appreciate the progress. And really punish inaction. If you want to strive for success you need people who are willing and eager to go the extra mile, complete the work, adapt to changes. If one does no longer fit into that team and its framing conditions, than it’s not the team. Give responsibility to the team, if it is a good one it will filter out inactive or inappropriately behaving persons. If you see one being inactive and the team isn’t, than challenge the team, maybe they still have to learn a lot.
8. avoid mediocrity
   If you push hard for transparency and predictability your team may be willing to undercommit in order to deliver properly. Without hitting the limits you will not become better. Push your teams hard but create achievable sprint goals. Don’t burn them but do your very best to avoid mediocrity. I would rather go for a slight over-commitment than an undercommitment. If the team is really willing to drive, they will potentially spend more time on delivering what they promised. Don’t forget, trust is the clue of agility. Devs trust POs to understand customer needs, POs trust devs to deliver what they promised. So keep a good balance, have an eye on your team’s performance and your team’s mood and either push hard once or give them some time to recover. No team can over-deliver 52 weeks a year!
9. Challenge their agile mindset
   Challenge it daily, weekly, monthly. If they think they are agile they should at any time be able to answer why they act as they do now. Ask the 5 Whys and dig deep. Pray the agile mindset and live the agile mindset. Don’t expect them to act if you are not willing to change too. Group them properly, allow pair programming, foster collaboration and communication. Pin the agile manifest on each free wall, bring in real agile thinkers and let them discuss, celebrate agility, train agile routines and always remind them of the benefit. Let them explain agility to others (e.g applicants for an open developer job). Don’t persuade them, if one opts out it is his/her decision but they should understand any consequence too. Don’t push them to hard. If they don’t move ask them about their motivation to stay as is, show them paths to go forward, help them develop and change their mindset. Put more optimistic people in each team and only ask for a certain level of patience before they opt out. Anyone should be OK to try at least 3 sprints before he/she decides to opt out.
10. Get a neutral moderator in
    Have one in the organisation who is not in an operational role. Call him moderator, mentor, coach, whatever but not any known scrum-name. That person is a super critical resource. His/her job is to get the buy-in from all parties in long-lasting one-on-one sessions, cleaning up the boards, doing sanity work, pushing for excellence. Don’t call it a scrum master, the role is much more. It is a neutral driver for success on a temporary basis. The one and only job is to get the push done, get the buy-in of the people and take care to not become an essential party in the story. This may be an ideal role for an external as long as the external doesn’t act like an external consultant, it must be a much deeper, personal, yet professional link between him/her and the organisation.

There is a lot more one could consider. To sum up one more essential for me: If people think they are agile, challenge them with agility, don’t adapt your new process to fast, let them tryout and learn before, keep the agile mindset and values in focus, go down the path with your team.