Scrum, XP, Kanban, or FDD? How long should sprints be? Do we really need to have a four-hour retrospective every other week? And just how many hours equals a Story Point, really?
Too many teams go all in on one Agile methodology, adopting all of the ceremonies and terminology but with an incomplete understanding of their reasoning. Progress slows as everyone tries to conform to the master plan, and resentment builds as a result. This usually leads to abandonment of Agile and in the worst cases, failure of the project itself.
Still, you know you have to do something. You know that what you're doing currently isn't working.
Your first one or two developers were crushing it. They were almost superhuman in their speed and productivity.
About the time the third or fourth developer was hired, you probably found that shipping features became significantly more difficult.
Wildly inaccurate estimations mean missed deadlines. Pressure to ship means bugs in production. Focus on individual development tasks instead of user-facing features means lots of code written, but little of it adding value to your product.
It doesn't have to be this way. Agile, at its core, is based on a few very simple principles. Starting with these foundations, I can help you build a consistent, reliable product delivery pipeline. We won't get caught up in terminology, and we won't bombard your team with meetings and ceremonies.
With a mix of technical expertise, management experience, and a teaching background, I can teach your team to self-organize, focus their collective efforts, and eliminate unspoken assumptions that cause misunderstandings and rework.
"Ben's work is already worth the investment and will continue to pay dividends far into the future."
Our product team had reached a size where the classic early startup "hustle" (i.e. a couple people huddled around a computer writing as much code as possible) was becoming less practical and effective.
Ben has completely revamped the way that our team plans, scopes, and builds product features. Because he's done so in a way that jives so well with the way our team likes to work, the new habits and processes he's implemented have stuck.
He didn't simply take a boilerplate process and apply it. He was careful to listen to our team's specific requirements, preferences, idiosyncrasies, and appetite for change and turn that into bite-sized, custom optimizations that made the most sense for us. Ben's work is already worth the investment and will continue to pay dividends far into the future.
When I work with clients, we work systematically through these five steps to build a strong foundational agile workflow.
We'll introduce each step in order, only moving on to the next when the team has gotten comfortable with the current item and is ready to absorb more information. This is to eliminate the information overload that too many teams experience when they try to adopt Agile all at once.
Your team exists to deliver working software, not lines of code. Your planning routines should reflect that. I will teach your team to think and work in terms of whole features that are valuable to your end user, rather that getting bogged down in technical specifics that quickly lose context. This foundational change in mindset underpins everything else that we'll do.
Humans are terrible at judging how long something will take, especially if they've never done it before. However, we're pretty good at estimating relative complexity. As in, "Thing A will probably be about twice as much work as Thing B". Using relative estimates (ie. Story Points) and their rate of completion, it becomes possible to forecast delivery of milestones (more on that shortly)
You can't track progress if you don't know what you're working toward. As the team gets comfortable with steps 1 and 2 and becomes a feature-producing machine, we'll start organizing the inflow of work items that we feed into that machine. Clear, achievable milestones are the key to measuring progress and ultimately to forecasting your delivery.
Say goodbye to picking drop-dead dates out of thin air and overpromising what your team can deliver. Armed with our milestone-based roadmap and your team's historical pace of story points, we'll build a model that you can use to predict when specific milestones will be complete. It's especially useful for visualizing the effect of scope changes on delivery dates.
As we progress through the first four steps, we will have periodic team retrospectives to clarify and improve on the new routines that we will be adopting. Retrospectives happen every other week and generally take 1 to 2 hours. They are the not-so-secret sauce that makes all of this work and get better over time, and ensures that the team takes ownership of the new routines after my involvement has ended.
You'll come out of this process with a strong foundational Agile workflow, enabling your team to ship features to production reliably and consistently. You'll have all the tools available to adapt your process as your team grows or your needs change. And should you decide later that you want to implement one of the larger methodologies such as Scrum, you'll have a much easier time of it.
We'll create clear, unambiguous steps for specifying work to be completed. This means fewer details left to developer interpretation, less time going back and forth between developers, stakeholders, and QA, and ultimately more efficient delivery of value (ie. working features) to your product.
No more weeks gone by getting vague updates on progress towards Milestone X. Your team will steadily deliver complete, tested, user-ready features that add value to your product.
By tracking the team's pace of feature delivery, it becomes reasonably straightforward to project the time it will take to deliver a milestone based on its specifications. No more arbitrary "drop-dead" dates, no more estimating by gut feeling. No more 90-hour weeks preceding a deadline.
Building on the previous result, you will be able to clearly see what happens if you want to add more features to a milestone (your projected delivery date will shift later) or you need to meet a particular date (you'll need to trim some features).
I'll teach your team a simple framework for collectively identifying and executing improvements to the way they operate. With the team able to self-organize in this way, higher-level employees can spend more time thinking strategically and less time managing day-to-day routines.
You want to ship quality software consistently? You want to confidently tell your stakeholders when you'll reach the next development milestone? You want a tight-knit, self-organizing team that takes initiative so you can focus on long-term strategy?
I want these things for you too. I've helped other teams achieve them and I can help you.
For your convenience, I'm offering my best consulting services as low-risk, fix-priced packages. If you don't find a package that meets your needs, drop me a line at [email protected] to discuss a custom engagement.
Sometimes you just need the right advice at the right time. A Strategy Call can be just the ticket.
I'll meet with you 1:1 each week to help you build and execute a plan for improving your team's output.
I work directly with your entire team to build routines that deliver results.
Questions? I'd love to hear from you! Drop me a line at [email protected]