10 Key Steps to Take Your Agile Organization from Chaotic to Victorious
Proven Steps from Yours Truly
When I first came to my current employer, part of my responsibility was to build an agile framework and process for 4 dev teams (each in charge of 1 application/system), while being their Product Manager and Scrum Master.
Had I ever built a framework and processes basically from scratch before? Hell no. But I knew I could and I was determined to make positive changes.
It was a challenge, but it was fun. I did the first 3 steps within 60 days, all while managing all the teams.
Want to know how?
Keep reading to see the high-level steps I took to bring them from disorganized, frequent priority shifts to well-structured and focused.
From Chaos to Basic Organization
In the beginning, there were well-intentioned attempts at gathering requests in one location and hosting regular meetings with stakeholders for prioritization and updates. But there was a lack of organization. Tasks were haphazardly thrown into a backlog with no grouping and weekly "prioritization" meetings allowed whichever stakeholder screamed the loudest to get what they wanted.
And as any project or product manager knows, that causes a lot of stress, anxiety, and burn out for a team.
Searching for a request was damn-near close to searching for a needle in a haystack, and requests came in from every avenue you could imagine. Email, IMs, knocks on the door, carrier pigeon. You name it, it was an avenue for getting something on the list.
And worst of all - every stakeholder wanted their item yesterday, expected the team to start on it immediately, and had basically no insight into what else was already on IT's plate.
I knew that my first course of action was to clean and organize, enhance IT's visibility and planning, and have the business define clear, limited top goals.
Here's how I started:
Cleaned up and organized the backlogs into epics and delete duplicates or obsolete items
With each team, I set up backlog review sessions. We'd go through hundreds of tickets and add them to buckets.
Enhancements/new features, bugs, production/operational support, tech debt, and things that were already completed or duplicates of other tickets.
The ones that were already completed or duplicates we would mark as "done" for the completed ones, or "cancelled" for the duplicates, with a link to the related ticket.
Anything that was a bug was changed to a "bug" ticket type (called "issue type" in Jira).
Bugs and production/operational support were all added to a parent project (called "epic" in Jira) to keep them all together.
Tech debt items also were all grouped under their own parent project.
Lastly, the items that were enhancements or new features were grouped according to the request under new parent projects.
For example, if there were 5 tickets related to updating the UI for sales reps and contacts, they would go under a new project called "Sales Rep and Contact UI Updates".
Now that we had a general understanding of what was truly available to work on, we could begin improving the team's ability to view and plan their work out.
Set up Jira with basic needs for scrum teams and deployment cadences
Jira has a really easy way to handle planning work long-term. You can do either Kanban with start and due dates on each ticket, or you can do sprints with your preferred duration.
For my teams initially, we did 2-week sprints and set them up accordingly.
We began to go through the new lists for each team and placed pieces of work into each sprint according to the urgency we were aware of.
Top priority bugs were placed in sprints sooner than medium or low priority ones. Operational requests were placed based on when they needed to be done.
And any tasks that were already in progress and almost complete were also put into sooner sprints than things that hadn't yet been touched.
Now that we had some general direction and planning completed for upcoming weeks, it was time to get the stakeholders on the same page - with us, and with each other.
(P.S. I've been using Jira for 6+ years in nearly every capacity, but you can do this with your own software. If you want to learn my best practices, tips, and tricks for Jira specifically, follow me and subscribe! I'll be creating guides and courses to get you up and running and streamlined in no time!)
Set up prioritizations less frequently than weekly
When you have a clear lack of priorities, or constantly shifting priorities, nothing gets done and everything takes longer.
The result? Pissed stakeholders, unhappy, unfulfilled end users, and stressed dev teams.
I knew that I had to nip it in the bud immediately.
I started by asking all stakeholders to take ownership of their requests/projects that were already created. I reviewed the requests with each of them, cleared out additional projects that were no longer needed, and updated others accordingly.
I also requested information like "when do you truly need it by and why? What would be the downfall of not getting this done? Do you have any workarounds? How much time and money does it save you or how much will it improve your bottom line?"
Questions like these (and others that I implemented later on), prompted stakeholders to really think about how much priority their project deserved and whether or not it was really worth more development time and focus than other projects.
As we found, sometimes projects were requested of IT to save 1 person 3 hours per month, or were cosmetic without any real benefit to anyone.
Prioritization meetings were heavily focused on stakeholders discussing and debating what should be prioritized next. I would go through the list and give a brief explanation, and then unleash the stakeholders to ask each other questions. As they discussed amongst each other, they themselves would move some items to a higher priority, some to a lower one, and arrive at a general agreement on what IT would focus on for the upcoming 2 months. (We started with 8-weeks and ended up with prioritizations every 13-weeks. We also started with one team for the first prioritization and then expanded it to the other 3 teams 2 months later.)
The results? Enterprise-wide goals that were decided and agreed upon by stakeholders, clear marching orders for dev teams, and reduced stress from being pulled every which direction constantly.
Improving the Intake Process and Protecting the Teams
If you've worked in IT, you know just how much pressure there is to meet deadlines. Most of the time, it comes at the cost of the development team's well-being and work-life balance. You also probably have a manager who is constantly in meetings and receiving requests from every channel possible with no gates in place before an item is "prioritized".
Having been there before, I was bound and determined to never end up in that situation myself, nor to ever require my teams to work overtime or on weekends.
Let's jump in.
Set up frameworks around intake needs and requirements, and ensuring stakeholders could vouch for their requests and discuss with others
First off, and related to the 3rd bullet point above, I set up frameworks and processes around project requests.
It started with the questions mentioned in the previous section, and expanded a bit more to include things like, "which corporate initiative is this related to and how does it relate? Are you aware of any other teams that might need to be involved, such as a connection between CRM and ERP, or reporting that would need to be updated/created? What problem are you trying to solve?"
Next, I put a hard-requirement on answering all of the intake questions in full before anything would be accepted into the next prioritization. If they couldn't tell me and others what they wanted, why they wanted, and when it was truly needed, it was not allowed into prioritization.
And trust me, this was one of the hardest things to get past - certain stakeholders will not take kindly to being told that their project can't be worked on just because of their title or their anger.
But your job as a leader in IT is to make sure that the more important goals are focused on (providing value) and to protect your teams.
Set up limitations for how much each team could take on - no burnt-out teams = reduced bugs and improved quality
There's a common misconception in almost every business that IT is there to meet the needs of stakeholders, even if it means dumping requests on IT at the last minute under the guise of "urgency".
And too many teams are pushed past their limits, mentally, physically, and emotionally.
The truth is, once anyone gets past 40 hours, their productivity starts to slow down, and as it approaches 60 hours per week, it not only slows to a halt, it also creates risk of more bugs and quality of code and solutions decreases.
And switching "resources" from one team or project to another creates even more issues. That's for another time.
So for my teams, we never plan over 40 hours per week. In fact, we aim for closer to 80%, because there will always be an unforeseen development need, a production bug to pop up, and someone is bound to get sick.
We also never allow more "prioritized" projects than the team can handle in a 12-week period. Every project request submitted must have high-level requirements fleshed out, which are then reviewed by the dev teams and the dev teams give the development estimates.
Management never, ever gives dev estimates on behalf of the team, and never promises anything to stakeholders without discussing with the team first.
How does this help? It helps us keep our promises more often, even when things don't necessarily go the way we expected - because let's face it, life and coding is always unexpected.
It also gains immense amounts of respect and trust from the dev teams.
Began to build out Jira with custom fields and automations for teams to work more efficiently
Another item that is frequently overlooked to improve the day-to-day processes for teams is how well their task/ticketing system is set up. Especially when it comes to a lot of repetitive input and updates just for categorization or informational purposes.
Jira is really user-friendly when it comes to creating custom fields and automations.
Some fields I've set up include:
Requestor/Owner
Approver
Approval Date
Region (great for global teams and applications/systems)
And that's just a very small percentage. I have created dozens of custom fields that I combine with reporting and automation to improve my and my teams' repetitive tasks.
For automations, some of the best ones and most important are related to updating stakeholders.
Sending auto-emails with ticket details and review/approval instructions once the request hits a certain status
Auto-reminders each Monday morning for stakeholders that still have things pending
Weekly summaries that cycle through a list of projects with a check mark, sending updates to an entire group of stakeholders with snapshots of their projects every Friday
Auto-update of custom categorization fields based on things like who the assign is or which project the task belongs to.
And for teams? You'd be surprised what you can do. For one of my teams, we figured out a way to have a pull request created in DevOps based on a branch listed in a custom field for the project once development was completed for each task.
We also have another automation that will destroy a preview environment once a project has been approved to go to production and the full branch moved to our dev environment (the one this team uses to gather everything that's been approved for deployment).
(If you want more ideas for Jira automations, follow and subscribe!)
Improving Stakeholder Processes and Visibility
I'm a big believer in KPIs, but not in the sense of numbers and charts. For me it's all about "Keeping People Informed". There are 5 things that every stakeholder wants to know:
What are you working on as a team (is my project one of them)?
What's the status of my project?
What's the timeline?
Are there any blockers/risks?
What do you need from me (stakeholder) to keep moving forward?
Answer these five, and you'll have some pretty happy stakeholders.
In addition to the auto-emails I mentioned earlier, there are some things you can do to enhance the KPIs for your stakeholders.
Built out intake forms and visibility tools for stakeholders within Jira
A couple of years ago, Jira came out with the Beta version of Discovery Projects. And I jumped on the list to be part of the Beta program.
Here's what it does:
Each stakeholder can be added as a free "contributor". No license cost.
Each contributor has access to a "discovery project", where they can click one button and access a pre-defined intake form. (This is where I now house the intake questions that are required before prioritization acceptance.)
Once they submit their request, it goes into a list of projects requested by every stakeholder. They can see not only their requests, but the requests of everyone else. Who requested it, what the request is, the status of every project, completion percentages, and more.
The Admins ("Creators") who are usually your project/product managers can customize fields and views that work best for the team and the stakeholders. Lists, timelines, charts, filtered views. You name it, I bet it's possible.
With a set intake form and the ability for stakeholders to see what's going on across the entire enterprise, you are miles ahead in Keeping People Informed.
Continuously iterate and improve the tools and processes if something didn’t work
As is true agile fashion, we've gone through several updates and iterations in the tools (Jira and Confluence) and processes (prioritization, approval deadlines, deployment processes, etc.), all to make things better for everyone - IT and stakeholders.
We continue to grow, improve, and enhance the outcomes for everyone involved at every step of the development cycle, from intake to deployment.
Improving the Work Environment for Dev Teams
When was the last time that you had car go for years without an oil change, a tire rotation, or a new battery? Never, right?
Remember that dev teams also need to do maintenance on their systems and their processes, too. The more you give them time to work on keeping their systems in top condition, and time to improve their internal processes and things like architecture and security, the better things will run for years to come.
If the team's ability to maintain and enhance their processes and systems are neglected, you can be sure that sooner or later, the "car" will break down.
Advocated for teams to have time to do major enhancements on their software so that they could develop quicker and higher quality going forward
I always aim for 25% of the dev team's time to go towards Tech Debt (maintenance and system improvements). 50% of their time goes to prioritized projects and 25% to production and operational support.
This allocation allows them to focus primarily on business objectives while keeping the car running smoothing and being able to fix the occasional flat tire or fender bender.
Provided time during a “prioritization week” for developers to dive deep into requirements with stakeholders for prioritized projects
If you want your dev teams to be able to hit the ground running, consider giving them a prioritization week.
Each 13-week quarter, I have 1 week set aside up front for prioritizations with the business, followed by deep dive sessions between the team and the stakeholders of any prioritized projects. This allows them to dig into the nitty gritty of the high level requests and give stakeholders an up-front list of anything they may need to complete the request.
The goal of the prioritization week is to do two things:
Get the business on the same page and deliver the top goals to IT
Allow IT to gather as much detailed information as possible to improve project success and reduce delays
Do this, and your teams will love you for it.
Now is the Time to Get Started
If your teams are struggling with too many items on their plate and ever-shifting goals, then now is the time to initiate change.
P.S. If you have a lack of true priorities, too much to do and too little done, a budget thrown out the window, and your people are burnt out, then this guide is for you.
5 common myths and mistakes and what you should do instead
Quick steps to get you implemented in 90 days
Discussion points for every area of your business, inside and out
You can also set up a 30-minute call for a quick discussion on your situation and how to start getting unstuck.
If you want to improve your or your company’s resiliency, subscribe for free to get my latest insights via email.