Thoughts on fixing Fake Agile

The first part of this article I talked about some of agile Fakers and how to spot and identify fake teams, teammates or companies in order to change that shadowy practices into the real thing. In this part, I will suggest some methods and techniques to make that change and transform the team to a beautiful agile team like the ones you are reading about everywhere. I will apply on Scrum.

You need to understand that you will face resistance, as change is not welcome at all times. Most of us does not tend to take risk, especially in our jobs and for sure not in such difficult time like 2020 - COVID19 -. So you need to start the change bit by bit, starting with one team and the rest will follow. Always remember "Small victories will create your big bang". So if you are in a managerial position or a team leader, I want to clarify something , It’s not uncommon to come across management that have little to no experience or exposure to agile, yet spout about being agile everywhere anytime. This disparity has led to huge amounts of managers claiming they’re agile - lean sometimes -, ultimately damaging and hurting the teams they manage, and the experiences of the customers they serve. I will start a two paths journey with you, trying to highlight some practices and some changes to situations for two Authority levels (Managerial position and Nonmanagerial position).

Let's start the journey - Hi manager, You got the power.

Traditional waterfall processes are in our blood as a normal thing, you get something done then the next thing. and we even appreciate multitaskers as people who can do multiple things at the same time, and it can be easy for an agile team to slide down a waterfall without realizing it. So if you are in direct contact with the development team, let's say you are the founder, CTO, PM or team leader working with the team/s and you noticed fake agile pattern as we talked about, and you want to make a change.

First you need to create/find a new team whose members are really want to be agile and work in agile environment, then you will sit-down and talk with them. Remember that if you and your teammates want the same goal or a special environment to work in, the team will eventually achieve it. As I believe in reoccurring small wins will defiantly lead you to the big bang, you will need to change a small team/unit first and the rest will follow.

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. Principles of Agile - Agile Manifesto

You need to Spot the real agile advocates "ready to eat apples" in your team/s and pick that team as your spark or the team will lead the transformation. these advocates will help you moving on through the transformation.

Spotting these individuals is not a hard process and I will give you some clear indicators:

• Someone who is raising red flags about wrong agile practices. Project managers, Scrum masters, Product owners and team leaders - mainly anyone managing a group of individuals whatever his/her title is - will be great at identifying agile advocates within teams. This Advocate/s are a great change teammate as S/he already is an independent advocate, set down with him/her and talk about your vision, which agile methodology you want the team to adapt, listen to what S/he got on mind - his/her ideas may light your way and will provide an insider point of view if you are in managerial position and not involved directly with the development practices.
• Someone who is A Perfectionist. As S/he will tend to change or adapt a new mindset that will help them do the job better. You - as change leader - will need to show that perfectionist the benefits of adapting true agile. Remember, communication is the key, so set down with that team member and talk about the vision and change process - transformation - you have in mind, and listen to what they got in mind.
• Best performers - Stars. They are easily recognizable by the track sheet you keep about for individuals performance, and if you don't have a performance track sheet you may want to start creating one, as it will be a helpful way to assess the growth of each member in the organization and an essential tool for training and improvement plan for the company. If you don't have such tracking sheet, you can ask team leaders and PMs to suggest these members.
• Someone who is studying agile or showed interest in such explorations. Not just doing the practices the team is already doing, but searching for new ways and techniques outside the applied ones, and talking about them. But if you did not find or it was not clear who is investing in themselves, you can take the lead and choose a team to start with.

If you select your team members from multiple teams across your company, you will have to adjust the schedules of your team and the allocation plan for the teams to fill the gabs existed from creating the new change team.

Sit-Down with the team and talk about the current practices

This step is very important for the real change process, as the agile manifesto highlighted the importance of team communications, and as you will - for the first time maybe - communicate your ideas and hear what is on the minds of the selected change teammates. Sit-down with your selected team and ask them some questions about the current framework and practices, this process will hep you identify the current status of team's mindset.

In order to drive agile success, teams need to adopt agile philosophy. They need to change the way they think about work ownership, management, and their relationship and duty to customers.

Take notes or record the session to compare after each sprint/release as the output will help you decide what is the perfect way to start the change process.

• Why are we using Scrum (or Kanban or any agile methodology)? The added value of the current adopted Scrum from each team member perspective.
• What are the steps and practices we are doing right now to get to a release? This is the steps your team is currently executing during the real work, so listen carefully and take notes of it. You will be surprised of how typically it is the scrum time line processes. If not, you are lucky as your work is now much easier and you will purpose the Scrum as the new framework to follow and the journey will be agile transformation instead of fixing fake agile and it's - from my perspective - much easier.
• What does it do for us? As of a full picture of the current situation and the current work flow and the output including the issues raised.
• What are the problems facing you operating according to the current process? I would love you to ask them about the conflicts raised each sprint between the team members. You will be amazed by the issues types and frequency.
• How can each of your team tell a task is done? What is Definition Of Done for each team member. yes DOD varies, and it should vary from one team member to another. For example the tester's DOD would be "all bugs reported are fixed/Nothing in the queue", the development team would say "all user stories are developed/nothing left in the backlog", the project manager would say "we deliver on time and no CRs". This step will help you clearly demonstrate the definition of DOD from Scrum perspective against the current DOD - but just not yet -, then creating the DOD that fits your team and is true agile.
• Is it - the current process - the right process for the team, environment, and company? Remember you are in a managerial position - got the power - so in some companies and under some conditions some of the selected team members will shy away from telling you the full and true thoughts, so it's important to give them the absolute freedom to express what they think about. Even if someone said "retrospectives are the blame meetings and I don't like them" or "I don't think the standup meetings are even worth the time each day" or "why we can't participate in writing the user stories?".

You can’t apply the label of Agile to what you’re currently doing and expect fantastic results.

• What is the problem you - as a team - are trying to solve? Fake agile cares more about process than the problem being solved, so talking about the problems will eliminate the processes talk or at least delay it. Delaying the processes talk - in this stage of the meeting - will give you the space you need to concentrate on mindset change.
• What are we currently doing during each phase? Here you are collecting data about the exact practices in each phase and each activity throughout the current development life cycle. For example what are we currently doing during the daily standup, are we conducting sprint planning meetings?, what activities are we doing in it?, retrospectives?, release planning?, etc...
• What is one thing you want to change in the current process? Here is the gold of this meeting, the team will start to think about the changes they need to do and a new discussion will be created between the team and the points discussed here are the true pain they are facing, or it will be clear to you - by now - that the team is a big fake agile team and it is a deep mindset problem.
• Durations and frequencies of phases. Ask your team about the standups, sprint planning, retrospectives, etc... Maybe the sprint duration is something to be discussed and changed, two weeks are not enough so lets make it 3 or 4 weeks. Can we link it to the backlog size of each project and expected load? all the durations and frequencies can be changed according to your new agile mix and what fits your team. So discuss with them.
• Did you try something else (work around) to avoid that problem or that one thing you want to change? First thing, I guarantee you and the team will hear some hilarious ways and work around on some cases, and this light ending will refresh the minds of the team and create fun spirit. Second thing, some of the work arounds will be true agile techniques - maybe from XP or DevOps - and I think this would be a great thing. Mark that team member who done that work around on your notes - You are taking notes, right?!
• Take notes. It is important, even if you are recording the meeting.

This meeting - or session - would properly take 30 minutes to 1 hour for a team of 3 - 5. Of course the type of the meeting - virtual or physical - will affect the duration, say it's virtual meeting so it will be recoded - I recommend that especially during COVID19 - and that will give you time to take notes and review the session again to extract data and the findings for the change process that you will present and discuss in the next meeting with the same group.

"The key here is that asking for teams to evolve and change should not be about fitting the team to a framework, but the process to the team. The team’s process, as a result, was a Frankenstein mishmash of XP, Waterfall, Scrum, DevOps, with a sprinkle of Simon Sinek to make everything right. But it worked for us!"  Jen Krieger for The Enterprisers Project on how each team creates its own agile environment and practices mix.

Data Processing phase

Now you have the data required to shape/choose your ideal agile methodology, this data is scattered and needs some work to give you direct indicators on what is the closest similar agile match. I like to do it as a simple traceability matrix.

1. Put the whole scrum timeline map in front of you and list the practices the team is doing in the current operations and practices for each phase of scrum release and under that put the true scrum practices or the practices you want to adapt.
2. Under each current practice, list the practices your team is exercising now with details.
3. Under each desired practice, list the practices you expect the team to do in the future - after the change - in details.
4. Then cross, add or edit the practices to match the desired process timeline.
5. Now you are going to shape the strategy you want to follow according to the desired current mishmash processes created from the traceability matrix you made. and I think you will be surprised with the output, some of scrum basics with some of your ideas and some of the teams ideas are all in there shaping a hybrid model of scrum/agile.
6. Prepare your presentation and pitch and set up the next meeting with the team to present and discuss. I think this second meeting will be after 2 days Max.
7. While presenting to your team, be open to comments and be a discussion starter as there is no predefined right or wrong way – you must tweak for your conditions. Understand the business problem you are trying to solve first and allowing the team - as you already did by now - to build their own environment.

Sit-Down with the team and talk about the new created agile framework

• Tell the team the components of the new framework you all helped creating.
• Demonstrate the timeline and the road map of each phase till the release - full cycle -
• Assign basic roles (PO, Scrum master, Development team) and list responsibilities for each role, as the team should have a clear structure from day one.
• Set a new Definition Of Done for the team and put it against the previous definitions of each team member (QA DOD, Development DOD, Design DOD, Analysis DOD, etc...)
• Take notes.

Evaluation phase

You need to evaluate the whole created framework after the first and second releases to get a clear view of what is working as expected and what needs improvements. As mistakes will be made all the time and everywhere so guard yourself and your team against repeating past mistakes that have been made: Evolve your team's viewpoint instead of trying to make sure boxes are checked for each process and phase. Instead embrace and understand the learning curve for each team member and the team as a unit.

It is very important to TRUST your team, they will get the job done so no need to micromanage your team - we all hate it - and it will lower the performance and poison the atmosphere between you and the team and within the team.

You will review and take feedback from each role and from the team as a unit on each role in order to improve the team and the environment. That being said, by all means remember the goal of agile "Agile methodologies main goal is to build or create a working product in short cycles - iterations -".

Nonmanagerial position

You are the advocate I talked about above, you need to practice the right processes and follow the guidelines of agile. Speake about the issues and misfits with your team leader, PM, or your team members but don't disturb the team structure just to make your voice heard.

Change is a tricky thing so be patient and deliver your thoughts to the higher level while pushing the agile practices to your work. While doing that Guard yourself against repeating a past mistake that you have made: Evolve your viewpoint instead of trying to make sure all boxes are checked.

Read a lot about agile, watch videos and follow agile coaches on LinkedIn, Medium, Twitter, etc...., and if its possible for you, study Certification for agile practitioners (ex. PMI-ACP), it will help you a lot improving your work, take the test - It's really rich syllabus.

At the End.

Each team will eventually create its unique agile process, and that is really what matters as the agile manifesto and principles are the guidelines for your practices - the framework if you may -. That is how Ken Schwaber and Jeff Sutherland invented Scrum, Kent Beck and extreme programing (XP), Patrick Debois and DevOps and the list goes on and on. They invented their own techniques following the guidelines of the manifesto and the principles. You are not asked to reinvent the wheel, you are just asked to select whatever techniques - maybe a mix - to be more productive or at least to follow the guidelines.

Know that this work does not end. There is no box to check at the end of the process. The work changes, teaches you something new, and you learn to continue to get better. Continuous improvement should be a fact of agile life for you and your teams. This is hard and messy human work. Work that is worth it because the people who work for you and at your companies or your teammates are worth the effort. You as a leader, there is work that you must do, too. Agile is a journey, You become agile through hard-work and trusting your team because after all they are haired because they are able to get the job done.