Agile Transformation – What is it about?

Image source: Google

“We need Agile urgently!”

I heard our director saying this in a meeting after coming from an international trip where someone mentioned it to him during a sales meeting.

“Our teams are getting out of our control and I think Agile is the way to fix it!”

I was staring at him and thinking about all the stupid shit I have done in my life and taking up this job was the biggest of all (trust me, it was).

“I thought you were a qualified PM and you never even mentioned it once that we can use it to fix the problem. Did you even know what Agile is? I was told that it doesn’t have a PM, so you are scared of losing your job, am I right?”

This was directed towards me and I couldn’t say anything. Just lots and lots of internal screaming!

Have you ever been to a situation like this where your efforts for cultural change were shot down every time and then you hear someone selling Agile to your C-level management? If yes, my sympathies!

This story is not a new one, you will find Project Managers talking about it in forums and on twitter that their employers and/or bosses think that Agile is a magic pill and it is going to solve all of their problems instantly. You will listen to their woes about the fruitless discussions they had with their senior management and ended up getting to sit with a shiny consultant selling false dreams of no chaos and people saying yes to everything, major cost cuts and customers eager to pay more for your services/products. You will scream internally, curse yourself and then move on with the direction that has been forced on you. Does this sound like your life story? If yes, make yourself a hot beverage and take a seat!

I have almost 5 years of experience in Project Management and I have worked with almost a dozen companies helping them in streamlining their processes. I know what Agile is, I teach it, I preach it, and I breathe it. But sometimes, Agile is not the answer, firing stupid headless directors is! (Just kidding, your job is safe!)

Let me take you to the list of misconceptions that I have heard in these years, my thoughts on them and also, some tips on helping your team and company in becoming truly Agile!

Misconception No. 1: Becoming Agile means no-process, impromptu process or chaos!

No it doesn’t. Not having a process is not an Agile thing, it’s a stupid thing. We can’t make things up as we go and then say we are going the Agile way. Agility is about the ability to move, to change, and to pivot. We can only do that when we know where we are going and no, those colorful Gantt charts won’t tell us that!

Misconception No. 2: Agile is a methodology!

No, it’s not. It’s a set of values. It has a manifesto with some solid principles behind it. These principles talk about collaboration, transparency, autonomy, adaptation and leadership. Agile doesn’t tell us how to get the job done, or what processes to use, it just tells us how to be. Agile methodologies include Test DrivenDevelopment, Feature Driven Development, Extreme Programming, Lean, Kanban, and SCRUM.

Misconception No 3: Agile can fix everything!

Nope. Not a quick fix. Can’t fix bad leadership or lousy management or bad hires or dodgy contract terms or even the leaking tap in our office’s cafeteria. Agile is not a magic pill or a wand (HP fan alert!). It’s a process of change that requires time, effort and excellent leadership skills.

Misconception No. 4: Agile will aid in micromanagement.

Agile upholds the principles of transparency and accountability but it doesn’t expect the managers to become nosy. Micromanagement is the opposite of Agile. The reason that most of the Agile based methodologies talk specifically about self-organizing and cross functional teams is because they want the teams to have the autonomy and authority to take decisions for the collective benefit. We can’t stand near the SCRUM board and reorder stories in the middle of a sprint and no hourly reports for anyone. Also, nobody can write 150 emails a day while developing software!  

Misconception No. 5: Agility will come to our team overnight!

Agile transformation is a BPR project, which means change will happen to the end-to-end business process and it is an organizational change which doesn’t happen overnight. It requires changes in everything from team count in a project, to skillsets, to hierarchy and the role of managers. It even make changes in how we estimate our projects. All of this can’t happen on a Monday morning after a long weekend. Even the prep time can take days. Case studies can help but every transformation is different, we will hit some walls, fall into wells but if we know what we are doing, we will come out of it alive and stronger.

Misconception No. 6: We will simply buy Agile.

Lol what??!?

We can’t. Even if we are willing to pay for it with Bill Gate’s net worth. We can hire one million consultants or specialists or coaches or whatever fancy titles these people give themselves, but we can’t just buy it. Can we buy fitness? Nope, we have to work for it. The same way, we work for this cultural change. These consultants are knowledgeable people with a lot of experience but they can’t fix management hurdles or biases trickling from the top. Coaching does help but change happens from the inside.

Misconception No 7: Management’s buy-in is essential.

Nope, we don’t need their mere buy-in, we need their passionate involvement and their full-on commitment. Senior management may think otherwise but you can’t delegate change. Remember, it is a BPR effort which means top to bottom initiative. Bottom up initiatives will fail if management is not willing to inspect, reflect and adapt their own behaviors and work patterns. Becoming a facilitator from a manager doesn’t apply to our functional managers only, to change our organization, we will have to change ourselves!

Misconception No. 8: Reading a Wikipedia page will tell us all about working in an Agile environment.

Our team will need vigorous training, coaching and mentoring. We will have to invest in people and make sure that they are skilling up properly. They will need time to cope with this change and this disruption can also cause displacement, so people who aren’t ready or are unwilling to change, will have to go. It can even temporarily slow down their work progress. We will have to be patient and train with them.

Misconception No. 9: Only Software Development Teams need to be Agile.

No, our whole organization will need to transform and bureaucratic values must go out of the window. SCRUM can be implemented even in non-tech teams and we can teach them to use it to get things done faster. Agile movement was initially about Software Development but with the passage of time and experimentation from both the researchers and practitioners, these principles have moved into other work domains as well.

Misconception No. 10: The purpose of Agile is to increase revenue.

Increased revenue can be a byproduct of Agile Transformation but it is not the sole purpose of it. The real purpose is to deliver high quality services/products to our customers with minimal surprises and delays. When we talk about implementing SCRUM, the main goal is always about eliminating waste, precisely waste of time. This waste happens everywhere, unproductive meetings, lengthy and useless reporting, slow decision making and delays in early defect detection, which can help in reducing rework.

Now let’s talk about the questions that we should consider before taking up Agile Transformation. 

1. What is the vision for change?
2. Do we need it or just want it? And why? 
3. Is anything broken? What is it?
4. Can it be fixed without the transformation?
5. Is our team ready?
6. Do we need transformation or adaptation? BPR or TQM?
7. Do we have any critical deadlines or client commitments approaching?
8. What is our current process? Do we even have one?
9. Who owns the current process? Can we name a person? Does the person know about their ownership?
10. What are the pain points for the team? Are they similar to the ones that the management have?
11. Are we aware of the waste in our process? If yes, what kind of waste is it (Partially Done Work, Extra Features, Relearning, Handoffs, Delays, Task Switching, and Defects)?
12. How do we measure our process efficiency? Do we have communicated metrics for it?
13. Which methodology suits our context better?
14. Do we have budget for investing in infrastructure (tools) and people (training)?
15. Do we have a communicated deadline for this transformation effort?
16. Answer these questions for every stakeholder, what’s in it for him? How will it change his work/day?

These are the questions that we need to sit and discuss with our senior management. We need answers for each one of them to assess the situation and see where we stand and what we will need to accomplish this organizational change.

If you have decided to go for it, here are some tips for you to make it less painful for yourself and your team.

1. Have a transformation agenda that talks about the reasons and expectations from this effort.
2. Start with a visual board (use a wall or a whiteboard), buy sticky notes in different colors and some dry erase markers.
3. Identify people who are going to lead this project.
4. Talk to them, listen to their concerns, give them the answers to the questions and ask them to select a leader within themselves or you take up the headache.
5. Get yourself and your core team trained from an Agile Coach or an industry practitioner. Spend some time in reading books (see the end of this post for some book recommendations) and blogs, watch some relevant talks, and listen to what experts are saying.
6. Make the process simpler by removing buzzwords, jargons and corporate garbage terms from your vocabulary.
7. Find the quick wins or low hanging fruits to top up team’s morale.
8. Find a pilot project to implement the new way of working, observe what hell breaks and why? Orient yourself again, make a decision and act on it.
9. You will have to make sure that no information hoarding is happening, clear, open and continuous communication is the lifeline of Agile so let the board be seen by everyone, have daily standups and let people work with each other to make it happen.
10. If you use tools for managing projects, you will have to take a look at them again. Tools that aren’t user friendly or adapted for Agile should be replaced with simpler more collaborative tools (JIRA, Asana, Slack, and Trello). If not, use a wall and sticky notes.
11. As “mindset change” is the objective, you will have to spend time in communication, trust and team building exercises. Remember, barbeque parties or team lunches won’t enrich trust, everyday interactions and teamwork will. Make sure you and your team are listening to people and helping them as much as you can.
12. Make feedback your best friend, so listen to everyone, your management, your teams and your spouse (just kidding, don’t listen to them. LOL. No, don’t take my advice on that!). Agile methodologies (especially SCRUM) believes in continuous improvement and you will always find ways to improve. Record the feedback, analyze it and then implement whatever is necessary.
13. Create some wall art by posting SCRUM’s (if you have selected it!) pillars, Transparency, Inspection, and Adaptation there. Also, create a quick term repository with it, for example, definition of done, definition of waste, etc.
14. Set some metrics to record the progress and measure the impact of your efforts. You can track your team’s velocity by seeing how many story points/features are done (ready to use) in a single sprint. You can also use different quality metrics (customer feedback/rating/reviews, number of failure reported by the client, time taken to fix, etc.) to see how well your team is doing.
15. Lastly, you will need practice and patience to scale your efforts and let it spread to all of your teams. You will need team rituals to get people going and you may face resistance but don’t let it stop you. 

If you are looking for some books to learn more about Agile, I would recommend the following:

• SCRUM: The Art of Doing Twice theWork in Half the Time by Jeff Sutherland (co-creator of SCRUM)
• Succeeding with Agile SoftwareDevelopment using SCRUM by Mike Cohn
• Agile Estimating and Planning by Mike Cohn
• Agile and Lean ProgramManagement: Scaling Collaboration Across the Organization by Johanna Rothman

Agile Transformation is not a task for a random Tuesday rather a well thought out decision to make things better. Agility can bring so many blessings with it and it sure is helpful but we need to make sure that we are doing it for the right reasons and the right way. At the end of the day, it’s the team that matters and we need to make sure that they are in on this mindset change. It won’t happen overnight and you will stumble upon the way but you will need to keep going till you have a thriving culture of being transparent and adaptive!

I do hope that this long rant will be helpful for you and I would love to listen to your experiences in Agile Transformation. Feel free to comment or tweet at me and I will get back to you!