Agile Transformation

Over the years I have been involved, pushed for and been pushed into Agile Transformation “Projects” and I aim to place my experiences into an article that will at least make others realise their circumstances are not ‘one of”. 

Many teams are very open to Agile Transformation, and so you would think that the ability to go from the waterfall (top-down planning) to Agile (grass root enabling) would be simple. However, I find that although on the surface teams want Agile, the ability to transform from a follower to a creator can be quite daunting. This coupled with a legacy management structure or a misunderstanding of what Agile is can lead to quick failure or a long stressful journey. Experienced Agile team members have probably come across the following, but it’s good to bring up some of the key reasons why the move to Agile fails:

Agile project managers

• When a business is hiring an Agile Project Manager, it should be a red flag. The adverts can also be hidden in the fact that the agents are asking for Scrum Master/Project Manager. I do not mean that there is no such thing in the market as a Project Manager who can enable others, remove blockers and articulate to stakeholder’s what the big picture is, but it also could mean that the company in question is still looking for someone to “Manage”. If you want to get to market sooner, enable your staff and see productive gains; an Agile Leader is what you need. Call the role Scrum Master, Team Lead, Agile Coach but don’t focus on “Projects” or on “Managing” resources, focus on trusting your staff to deliver value and utilise Project Managers to focus on managing planning.

We are different

• Every business is a unique blend of people, value, customers and technology. However different you think you are or how different your needs are, Agile can be implemented for the positive long-term benefits. The negative attitude towards Agile is based on false information.

We tried “Agile.”

• If you believe you have trialled Agile and it hasn’t worked then do not try again. If you have realised that what you tried was not Agile, then you can focus on delivering your new goals, and this excuse becomes redundant. Remember there are very few true 100% agile powerhouses in the world. Your resident Agile expert has most likely not worked there (I haven’t)

Not realising that Agile is a spectrum

• Some businesses believe they can get a list of items like stand-ups, Kanban and JIRA and suddenly they are Agile, others believe that the entire organisation must buy into the philosophy otherwise it just will not work. Agile is not a light switch; it is a spectrum and a journey. Agile is about cross-functional self-enablement, and yes there are constraints, set your constraints and embrace them. You can work agile every day as an individual, or you can run a full-blown data acceptance test-driven developing bottom-up powerhouse…. Or somewhere in between.

Managers instead of Leaders

• This is a similar reason for the Project Manager issue. You may have a great team, but your cross-functional managers keep pressuring “Their” staff to disrupt priorities and solutions. If you only have presumed empowered teams, then it will always lead to those staff seeking permission and thus removing the accountability from themselves.

Projects Over Product

• Are you looking to do an Agile Project? If you are focusing on the project instead of products, you're not only missing out on a lot of value but you are restricting and not enabling, and this can lead to a, ‘us and them’ mentality instead of a one company value. This doesn’t mean we get rid of projects; it just means we focus on products and feed projects into the product delivery, prioritised by the business owner or measured objectively. This means not feeding people to projects and disrupting natural teams.

Fixed Triangle

• Want to fix time and quality. Then stick to a waterfall plan, Agile requires a minimal viable product (MVP) not an absolute product through fear you won’t get a release 2. Choose your poison, either time constraint or quality/scope. Prioritise and have the line of MVP and measure, re-plan and measure again. You will have a much better understanding of delivery dates once your teams are up and running and if you need to do an ROI, then t-shirt sizing and an objective measurement spreadsheet will work for a ballpark figure.

Measuring Value

• As someone from a Business Analysis background, I am surprised that the project/work package has the very little benefit and it is never down to an appropriate level. Why am I doing this user story? What is it’s value? Why is this story more important than that? If your business doesn’t know then how will the team know? Ensuring that Epics, features and user stories have a link back to benefits, allows you to have objective prioritisation and allows you to understand MVP and to top it off it stops one part of the business pushing their agenda that has a minor benefit but large estimate.

No Trust

• Enough said

Transformation Plans

If we take the approach that your company wishes to transform the entire business to Agile, you need to decide to what point. From now on, I will talk about an MVP to implementation as I have seen some great results from this, instead of pushing for all or nothing. When considering moving to Agile we need to look at understanding how our customer will be impacted by this, what is the benefit of the move and can we measure? Without understanding value, I urge you to stop immediately. Have a look at Agile Benefits to figure this out.

Although I would love to think that this is the CEO reading this and they have the undisputed power to give that power to their staff, I live in the real world where you are probably constrained by another part of the business. Here are some things to think about

• Where are our entry points

1.   How do you receive your work, what type of entry criteria do you need to give your outcomes

• What are your outputs

1.   Think about the value your team, project, business gives and who your customer is, what are their entry criteria and thus what is your exit criteria

• What will your end teams look like

1.   There are a lot of frameworks out there, and it’s good to get an understanding of how your team(s) will look before you begin so you can see who you interface with

• Transitional Requirements

1.   Are you going to stop one day suddenly, or are you going to change over slowly? Do you need training, are your customers going to be communicated to and do you need to purchase resources (you don’t need a $3’000 Kanban board, even at a bank I loved putting post-it notes on the glass or walls)

The long and short of the change management should be where do you want to be and work backwards. Give yourself stories with tasks linked to them and then just work your way forward. Remember the above points, don’t just lump everyone into a single team and hire a Scrum Master. They will run away….

Communicate Nirvana

If you want to transform to self-enabling cross-functional teams that deliver value, then you need to start as you mean to go on. Talk to your team, ask them what they think works now and what could be better. Give them an overview of what you think Nirvana looks like. See if this helps them with their pain points. Be prepared to CHANGE your Nirvana to match what your teams want. Remember it’s their world that is about to turn upside down, and you will need their support to get a successful transition, and for their support, they need to believe and own it.

One of the easiest ways to do this is to get everyone together in a fear-free environment (I always recommend a pub, but I am yet to get a yes), explain why Start-Ups are continuously disrupting the market through innovation, fast to market and quality aimed directly at their customer. A good example that is common is the Car Production line; you don’t keep starting and stopping a car production plant when you change design; you merely feed the work to the process and trust the team know how to build the product that the customer wants. Talk about the customer lifecycle and why we are here and then get THEM to start raising pain points for the customer and themselves. Agree with what they believe is the value of the team, what is the team’s mission and ask permission to offer a potential solution.

Showcase Agile and its benefit and the potential new process, then put the agenda back on to them. How would you change it, subject to size ensure they are up on their feet and engaged. You want a fluid movement to help them come up with the solution. Once you have a potential solution ask the team how we are going to do this. This is where the fun begins because your team know their work better then you and they may come up with some brilliant or scary ideas. Within the constraints and values of the business, it would be advisable to go along with the democratically elected ideas and agree on MVP, agree how you are going to start and find a way to objectively test this theory you have to see if it works.

Baby Steps

Recommended industry standards based on some great long-term studies show the below as MVP (irrelevant of the business), and as long as you are constantly measuring and are willing to change, you can keep evolving your teams until you have a happy, productive business unit.

Cross-Functional Teams

• Every Ninja team should be able to produce value, and you should remove as many barriers to delivery as possible. It is not always possible but try and let the teams be the experts, who do they want to work with and how should be part of their decision. Can they deliver value better as a 5 or 8 people team? Measure and re visit.

Each team determines their process

• So you have agreed on your framework as a wider team, now let your teams decide on their process. Let them drive entry and exit criteria, let them decide on Scrum, Kanban or Scrumban and focus on removing their blockers. Lead them, don’t manage them. Measure and reassess.

Don’t change the team members

• If the teams decide to merge, grow or shrink then let them, don’t try and manage the teams as mini projects. Measure and report

Accountability

• Each member is accountable for their work, there is only one owner of a task, and that person is the only one accountable for finishing

Visible

• Daily communication of what you did yesterday, what you’re planning to do today and if you have any blockers is a vital step in teamwork. Better known as a stand-up, ensure THE TEAM runs this and only those in the team are talking

Communication

• Not always practical to get the customer in, but someone in the business should be responsible for the customer. A product owner is a great role for this, and they should be involved in every decision along the way and be empowered to have the final say within the framework. Measure and report.

Demo

• Be it daily, weekly or monthly. A demo to a wider audience to get more information not only allows your team members to showcase their value they have delivered but it also allows for quick changes or mistakes found early

Leader

• Ensure that you hire or train leaders and not managers. Watch out for the term Fragile or similar names and instead of teams blaming the process, ask them how they would like to change it. What do they need to be enabled?

Everything else is up to you and your team. Remember to measure and then show your team that X didn’t work and ask them shall we try Y? then measure again. It makes work fun as your be constantly changing to find the best process, technology and people. Remember there are always ups and down in all changes but all change is a good change, why? Because it is an opportunity to know something objectively and yes this means you will learn, never to do something again.

Hints?

Buy Coffee...

If someone tries to stop you and your transition. Ask them to voice their concerns, ensure you thoroughly understand this concern and then break it down into a task. Ask the team how they are going to meet the requirement and then ask the question to the concerned colleague. Normally others fear change and if your business unit or team is changing they may find themselves fearful of what it means, by breaking their concerns into manageable entry/exit criteria you can ensure their needs are met, if they still have concerns and those concerns are not objective, then reassure them that this can always be changed if things arise that we didn’t know.

Get a good trust culture going, stop monitoring hours or clothing or anything that forces your team to comply. Push for intrinsic motivation and full engagement. A developer sitting at a desk in a suit in a loud office being told that their ideas are interesting is never going to be as involved as a team member wearing shorts at the café with his team talking about the changes they made together last week and the value they gave their customers.

Keep reporting and monitor value ASAP. The change will always end up in a depressed state and if you have a high amount of change… be prepared for a gloomy IT’S THE END OF THE WORLD mindset from some. Be there with your objective results and stick to positive items to show what value they are producing and for external parties so you can show how and why things are going this way. Also remember if it isn’t going well, be prepared to change. Backwards is still forward if you now have results showing something didn’t work.

 Conclusion

I have tried to place as much detail as I can, but also tried to keep this light. Depending on the size of your team or company, an Agile Transformation can be fun and scary. I hope this post has at least put some ideas in your head. I have also kept this post agnostic for a reason. Agile is not just for technology project delivery; it is for anyone or any business that has an end goal in mind and wishes to have a more dynamic customer-focused approach to get there.

Remember the simple way to go Agile. Is to start today and measure tomorrow.

(oh and remember to adapt)