So, you sent your development team to agile training, or better yet, you hired a scrum master to solve the unpredictability and lack of visibility into your software development efforts. Without a doubt, the prospect of facing your board to ask for more money and more time, is a source of great stress and a motivator to get this problem fixed.
After a few months of waiting for better results, you find yourself in the same spot you were in, or worse. Your development team presents you with a menu of features and their associated cost in points, which adds more stress to your day. “You can have this, but not that.” You are continuously reminded that the sprint cannot be interrupted, making it harder to pivot when a once-in-a-lifetime sales opportunity requires a change. You face one wall after another for the sake of predictable deliverables.
And yet, after dealing with the scarcity anxiety this produces, the team misses yet another date. It seems like you can’t catch a break.
You try to get involved to better understand the situation and implement some structure you badly crave. So, you add meetings with your development team to your already busy schedule, and before you know it, you’re spending most of your time in agile project management details instead of taking care of the big picture. Then, your development team starts to complain that they spend most of their time in meetings instead of developing code. They’re frustrated…and justifiably so.
What happened? Wasn’t agile going to make this better?
The bottom line is not that agile doesn’t work. The issue is a common misunderstanding of what agile is. Agile software development is a philosophy rather than a process. Back in 2001, a group of forward-thinking software engineers understood that developing software was not moving at the speed of business. Long and drawn out processes like the waterfall model were the cause of missed business opportunities. This resulted in software that was already irrelevant to their customers and users by its delivery.
So, they created the Manifesto for Agile Software Development, which established 12 principles a software developer should follow to continuously deliver valuable software.
This manifesto encouraged software developers to deliver what the business needs (instead of building a technological marvel), to communicate beyond the software engineering office walls, and accept change as the only constant.
However, it never mentions Scrum or Kanban boards. Don’t get me wrong; these are excellent tools to help manage software development’s daily progress. Nevertheless, they are not the solution to your software problem. Being an agile company starts with a mentality shift of the entire organization.
3 Practices to Make Agile Work for Your Business
1. Communicate your quarterly strategy in concrete terms to your development team.
Software developers are great estimators, even though the evidence might suggest the contrary. They know already if they will miss that promised date as soon as it leaves their mouth. They know you are asking for a Rolls Royce at the cost of a Datsun.
However, missed deadlines can be avoided when you communicate your quarterly goal in concrete terms instead of asking for feature A, such as:
“Our goal this quarter is to move three rocks: 1. Add 500 new subscribers to our platform; 2. Reduce the average number of weekly support calls to 25; 3. Reduce customer attrition from 20 customers per month to 5.”
The development team might suggest prioritizing the improvement of your software product’s specific areas to handle the additional user load, which will improve your existing customers’ experience and your sales demos.
The team might also deliver on the aforementioned Feature A, which is required to sign that big customer with 500 users. Your developers focus on finding a way to provide meaningful functionality and meet your time constraints while eliminating unnecessary gold-plating.
Don’t be surprised if they move mountains to meet your quarterly objectives. Your development team will find the most effective way to use their time if you provide focus.
2. Forget about points!
This is probably the most crucial piece of advice I have for you. Do not manage your expectations in story points! This artifact should be used internally by your development team to better understand an estimate’s guesswork and have a degree of confidence in their commitment using mathematical means.
Let’s take a look at the problem with using points as prescribed by Scrum. The idea is simple: the development team assigns a point value to a work unit (a.k.a user story) based on size, complexity, and perceived risk. In the end, you add up the points of all user stories required to build your feature or product and divide it by the average number of points historically completed by the team during a consistent interval of time (iteration or sprint).
Before I continue, let me ask you a question. Would you invest hundreds of thousands, if not millions of dollars, on an investment with a 50% exposure? If your answer is no, then why are you making this bet every time you build software?
That is right. Scrum uses the average number of points achieved by your team in a time interval. In probability terms, this means that you are calculating software costs, delivery times, customer commitments, and other activities on a 50% chance!
It would be best to ask your team to communicate the development effort in terms of confidence levels. So instead of getting this:
“The estimate totals 1,000 points divided by a weekly average (team velocity) of 100 points; it will take ten weeks to complete.”
Ask for this: “We can deliver Feature A in 11 weeks with a 75% confidence level and 14 weeks with a 90% confidence level.”
You can use the 75% confidence level estimate to track the team’s progress. Use the 90% confidence level estimate to communicate delivery dates, coordinate internal activities outside the development group, and plan software R&D costs.
Never use points as currency or as a cost measure directly. How do you know you are in trouble? If you know your cost per point.
3. Get rid of departmental walls and start working together!
The development, sales, account management, marketing, accounting, and support teams should share insights to help everyone contribute to your overall strategy.
The success of your strategy depends on the sum of the efforts of every person in the organization. Delivering value to your customers is like the rolling gears animation…when everyone stays focused on their job the gears move in perfect synchronicity.
For example, suppose your goal is to reduce customer attrition from 20 customers per month, down to 5. In that case, your account management team might know which competitor’s features are attracting your customers away. Your support team might have insights into the usability issues users find the most painful. The software development team can take this information and create and commit to a plan that can be delivered successfully within the quarter.
The effort is focused; the communication is fluid; and the organization is working to achieve a common goal – your strategy.
Conclusion
In our experience, most CEO’s don’t have the capacity to ensure their development team remains on track. You should spend your energy on bigger, more pressing issues like changing your organization to an agile mentality where your entire organization works towards concrete and strategic goals every quarter, accelerating the achievement of your business goals. And these recommendations are a great place to start.
Unfortunately, there isn’t a magic potion that can make paradigm shifts happen overnight. But working with a trusted partner like Modularis, allows you to focus on what is most important in your business. We take on all the technical headaches and challenges you HATE, which allows your team to speed through feature development and R&D. Through an unrivaled codebase culminating from millions (yes, millions) of lines of code and backed by our expertise, PlatformPlus automates processes that can handle 70% of the infrastructure of any software product with a scalable architecture that sits on-premise or in the cloud of your choice.
Want to see how we can help your team drive revenue? Download our roadmap for R&D success here.