In today's fast-paced business landscape, staying ahead of the competition requires efficient and effective solutions. According to Microsoft’s Work Trend Index, nearly 70% of employee report that they don’t have sufficient time in the day to focus on “work”, with more time being spent Communicating than Creating.
Microsoft 365 Copilot is designed, with Microsoft’s cloud trust platform at its core, to allow for employees to both be more productive, reduce the time spent searching for information, performing mundane tasks, and other low-value activities.
Your project, despite your best efforts, went completely off the rails. Scope crept, deadlines were missed, budgets were busted, and fingers were pointed. No amount of cajoling your developers made the situation any better, and the client, well, why couldn’t they just be reasonable?
Answers were needed fast because the twin sisters “We’re never doing this again” and “This better not happen again” were ruling the conference rooms and inboxes for weeks.
You’re not alone. If you have used the waterfall method to develop your software, the likelihood is you have experienced this or a strikingly similar event at some point in your career.
Agile or Ag-fall?
As a result of the lessons learned, Agile is birthed into your organization to right the ship. The Agile methodology reflects the natural behavior of actual humans, and after an initial ramp up everything feels like you’ve turned the corner: You are leading your daily scrums, setting up your sprints, going Lean, and making the prettiest Kanban (kän-ˌbän) boards you’ve ever seen. (Full disclosure, in Kentucky, we pronounce it CanBan. It works for us. Don’t judge.)
So, why are your projects consistently more Ag-fall than Agile? Most likely, this is because old habits are dying hard.
Here are some symptoms that your organization hasn’t fully bought-in to the Agile mindset.
-
Extra sprinkles, please.
The difference between “ordinary” and “extraordinary” is only a little bit extra. However, agile teams commit to the reality that they won’t adjust time and cost to build “extras” when an MVP (minimum viable product) is enough. -
The project team is more Hemmingway than Haiku.
As the tides rise and fall and requirements change, you can struggle to document all the specifics of the fish that is not yet in the boat, and then slowly slip into madness as the sharks methodically tear it apart: stealing your elusive reward.
But wouldn’t it be better to drop the notepad, get the fish in the boat and get back to dry land?
Working code is good.
Too much documentation
will prevent progress.
-
You believe great tools can fix any problem.
Fancy tools and rigorous processes can’t be “the focus” of your team’s attention. Projects get completed by people, not their tools. No Gantt Chart, Kanban board, or fancy widget is going to drag the project across the finish line by itself.
Although tools are useful and necessary, make sure overly burdensome administration does not hamstring your motivated, collaborating teams.
-
You're in love with the plan.
Unless you are building a pyramid, be willing to accept that changes to the plan are going to be required to finish your project. Despite your best efforts, you probably based your original plan on insufficient information, so don’t waste time trying to conform to it.
It is better to spend your effort adapting to relevant new information as it becomes available. -
The project team isn’t lazy; they just don’t care.
According to the COCOMO II cost estimation model, having the best, motivated individuals is 10x more important than having the best processes or tools. Unfortunately, teams are often “inherited” and not “hand-selected.” (e.g. Perhaps this project isn’t the team’s favorite type of work, or maybe you’ve not worked together well in the past.)
However, it is possible to motivate teams to reach “their” highest level of potential. One method of motivation is to eliminate micromanagement. Allowing teams to be autonomous when planning their work empowers and motivates the members.
Create an environment of collaboration that allows individuals to blossom with their skills, and the benefits will follow.
-
Too many emails, not enough communication.
It is all too easy to deceive ourselves with email and instant messages. They act as a shield to protect from uncomfortable conversations, and keep us from being “distracted.” (laugh)
Many times, electronic messages are time-wasters camouflaged as productive tasks. Did it take six emails to communicate the same message as one thirty-second conversation? Was the message interpreted as intended?
Develop the project team to focus on effective “face to face” interactions with each other. For natural introverts, this can be a real challenge to overcome. Use email sparingly, such as to recap and document the takeaways from the face to face conversation. If distance prevents face-to-face communication, Skype conferencing will work in a pinch.
-
You’re tracking hours, but not tracking progress.
Everybody is utilized. The team is billing hours. Emails are flying faster than the quick nods and waves in the hallway. You’re carrying a folder (the universally accepted symbol that you are busy). There’s only one problem: you have nothing to show for it. What gives?
You need to transform the mindset from a culture of busyness to a culture of completion. Working software is the true measure of progress. Provide a definition of “done” for each feature, and refuse to recognize interim deliverables that do not provide value to the customer. -
You’re starting. You’re stopping. No, wait…you’re starting again.
Instead of continuously deploying features at a reasonable pace, the team always finds itself in a mad-dash rush to develop prototypes. Work life balance is a foreign notion that gives way to long hours over multiple weeks.
Developers constantly seem burnt out and unmotivated. Mistakes and sloppiness add to the increasing pressure and ensure that developers will need to double-down on the next project to meet its deadline.
A truly Agile team seeks to create working conditions that are sustainable over the long haul. -
You’re a cowboy, not a shepherd.
Cowboys drive the herd where they want it to go; this is the familiar command and control management model.
Shepherds, on the other hand, lead the flock.
True leadership aligns project goals with personal motivations to achieve a higher level of productivity.
-
Your desks are more than 33’ apart.
Because Agile teams emphasize face to face communication, do not overlook the physical workspace layout.
Truly Agile workspaces allow team members to work within 10 meters of each other with no barriers such as walls or doors to separate them. This principle is referred to as “co-location,” and supports osmotic communication.
“Osmotic communication means that information flows into the background hearing of members of the team, so that they pick up relevant information as though by osmosis. Then, when one person asks a question, others in the room can either tune in or tune out, contributing to the discussion or continuing with their work.”
Want to learn more about Agile?
Check out our blog post:
"Five Things You Should Know About DevOps"
